Et tous les logiciels les utilisant/embarquant, le document indiquant que les dépendances doivent être CE…
Canonical ou Redhat vont ils prendre le risque d'apposer CE sur "ssh", "rsync",… pour rester sur le marché de l'UE?
Le CRA semble passer inaperçu sous couvert de "c'est bien, c'est pour votre sécurité"…
Hors on a bien vu comment les conformités évoluent (avec les logiciels de paiement/comptabilité récemment).
Au début, peut-être une auto attestation possible et rapidement une certification externe contraignante, régulière et couteuse avec l'introduction d'une norme.
J'ai l'espoir que les géants du logiciel boycotteront l'UE afin que tout ce cirque soit annulé, une fois que les idéologues seront vivement poussés à solutionner la crise logicielle majeure qu'ils ont créé.
Il faut vraiment être un doux rêveur pour penser que tout le monde est prêt à la certification CE.
Peut-être que les "certifiants" se réjouissent, mais dans la grande majorité les "certifiés" laisseront tombé ou quitteront le territoire.
Cela m'étonnerait grandement que des "petits" développeurs américains se préoccupent assez de l'Europe pour ne pas tout simplement couper les ponts et couler des milliers de projets à travers les dépendances non CE.
mettre en avant spécifiquement le libre ici me semble être trompeur
Non, car c'est prendre en compte qu'un code ouvert rend l'inclusion de fonctionnalités de fraude quasi impossible car trop visible.
Rendre obligatoire l'open-source dans les logiciels de caisses serait un moyen efficace pour éradiquer les fonctionnalités de fraude inclues par les éditeurs (en pratique, dans les logiciels propriétaires pour tous les cas de fraude avérés).
Mais bon, les normes existent aussi pour de bonnes raisons.
Oui, je pense qu'il faudrait s'arrêter à ça, cad requérir que ces logiciels soient conformes à une norme (NF525 par exemple), et qu'il soit interdit d'utiliser un logiciel de caisse qui n'est conforme à cette norme.
Nul besoin d'une certification obligatoire.
On aimerait aussi que la NF525 soit gratuite et libre d'accès, ce qui n'est pas le cas aujourd'hui.
Je doute d'ailleurs de la légalité d'imposer des règles payantes.
Je doute également que les députés aient payé (et même lu) la NF525 avant de voter pour l'imposer.
quid des caisses des plus grosses structures où les enregistrements remontent a un système centralisé ?
Ca fait partie du lot, ce sont des systèmes de caisse.
Qu'est ce qui est a certifier ?
La NF525 n'est pas libre d'accès, il n'est pas permis de partager son contenu.
Qu'est ce qui se passe pour les structures qui développent peut être eux-mêmes leur solution ?
Elles devront faire certifier NF525 leur logiciel. Infocert est à votre disposition pour un audit, l'accompagnement et la certification, dans des budgets proches de ceux cités plus haut.
Le fond du problème est que sous couvert de la lutte contre la fraude, on ajoute une certification obligatoire et couteuse (on parle d'un budget de plus de 10k€ par version).
Un logiciel libre pour lequel il faut débourser 10 000€ pour toute modification de la partie caisse n'est plus un logiciel sous licence libre. On pourra juste le qualifier d'open-source.
Dans les faits, quand on regarde de près les arguments (fraude TVA, millions d'euros détournés, rapport INSEE), on se rend compte que :
- la majorité de la fraude concerne la TVA (non-reversement de la TVA perçue, facturation fictive ou de complaisance, fraude à la TVA carrousel)
- la fraude concerne principalement le milieu de l'immobilier selon l'INSEE (donc en rien les logiciels de caisse)
- la fraude "de caisse" qui consiste à supprimer des enregistrements de recettes est une "fonctionnalité" qui n'a été découverte que dans les logiciels propriétaires. Ce qui parait un peu normal vu que le code des logiciels libre est consultables facilement.
- la manière la plus simple de faire disparaitre une vente en espèce est de ne pas la saisir dans un logiciel, certifié…ou non.
Bref, la certification n'apporte rien, complexifie tous les systèmes inutilement, a un coût élevé (estimé à 50 000 € annuel pour OpenConcerto) et n'aura qu'un effet : la disparition de nombreux acteurs du logiciel libre.
Le sujet est souvent détourné par des idéologues ou des vendeurs de blockchain, merci de ne pas retomber dans ces travers, constamment relayés par des politiques peu au fait des réalités.
Ces formats existent plus ou moins, on peut citer pour les factures : UBL, XML Invoice de GS1, FacturX… , pour les écritures comptables: le FEC, etc… OpenConcerto en implémente quelques
unes. La difficulté réside dans les relations entre les éléments, les structures sont biens différentes d'un logiciel à l'autre. De plus, faut-il normaliser sur "le moins disant" ou sur l'implémentation la plus complète?
En attendant un "standard" nous avons développé l'import depuis quasi toutes les solutions du marché (MS Dynamics, Cegid, Sage, EBP, Ciel, Odoo, Dolibarr… et d'autres moins connus)
Concernant la confiance et la pérennité financière, nous avons dépassé les 20 ans d'activité et ne manquons pas de travail. Une bonne partie des sociétés avec qui nous travaillons et pour lesquelles leur ERP est un point critique, prennent notre contrat de maintenance. A priori, elles semblent satisfaites.
Concernant la 2035, vous devriez sans grande difficultés retrouver les chiffres qui vous intéressent via le 2033.
Ne sachant pas ce qu'est un "code hyper disponible", je ne sais pas ce que l'on peut proposer de mieux que ce que l'on propose déjà, à savoir un dépôt libre d'accès et une licence libre (GPL).
Concernant la documentation, le guide PDF téléchargeable d'une vingtaine de page est suffisant pour démarrer. L'achat du manuel (papier) est comme pour un grand nombre de projet open-source, le moyen le plus simple de nous soutenir.
Le code est accessible depuis https://code.openconcerto.org (lien de la dépêche), suite à de nombreuses tentatives de hack, nous avons installé il y a 2 ans un filtrage par IP pour bloquer certains pays et les accès depuis un VPN.
Comme vous l'indiquez, tout est sous licence GPL.
C'est tellement ancré dans nos esprits que nous avons oublié de le repréciser dans la dépêche comme nous l'avions fait dans les précédentes.
Vos remarques sont intéressantes, voici quelques éléments de réponse.
Je comprend très bien que le fait qu'une application web ne nécessitant pas d'installation est plus pratique à déployer, mais nous avons tout fait pour que cela soit rapide (moins d'une minute par poste). Une version portable est même disponible pour du "zero install".
En revanche, les applications "natives" restent toujours plus intégrées au système et bien plus véloces que leurs équivalents web. Pour l'instant ce n'est pas du tout un frein à l'adoption d'OpenConcerto. Le principal frein est sa gratuité, difficile de combattre le biais cognitif "plus c'est cher, mieux c'est".
Nous travaillons depuis déjà un bon moment sur la "version web" du logiciel et sur un client léger, ils vous sembleront donc peut être plus "moderne". Nous continuerons la version client-server, l'architecture actuelle permet d'avoir les 3 modes. 2024 semble une bonne année pour leurs sorties officielles.
Concernant la gestion de production, ce n'est pas un domaine d'activité simple à séduire. Tout d'abord parce que les besoins sont très différents en terme de complexité d'une entreprise à une autre et que chaque type de produit à fabriquer requiert de fortes adaptations du système. Cependant le point important est que les entreprises faisant de la production sont déjà équipées en logiciel et sont très peu sensibles à l'open-source car satisfaites des solutions propriétaires dont le prix exorbitant les rassurent.
Je ne souhaite pas commenter votre dernière remarque vu qu'elle me semble particulièrement orientée sachant que que vous êtes partenaire Axelor et Cegid.
que se passerait-il si quelqu'un dénonçait ce genre de pratique auprès d'un procureur ?
Ce serait un bon moyen pour l'April de se faire connaître.
Bien que la devise affichée sur son site soit "Promouvoir et défendre le logiciel libre",
je serais surpris de les voir bouger.
Une autre solution, non dépendante de LibreOffice : jOpenDocument
Cette librairie Java permet de créer, manipuler et remplir des fichiers ODS/ODT..
et aussi de faire le "rendu" d'un fichier ODS en PDF (mais aussi l'impression et le rendu en bitmap).
Cette librairie est d'ailleurs utilisée par l'ERP OpenConcerto pour créer tous les documents via modèle ODT (un peu logique, vu que les auteurs sont les mêmes :) )
Tu as raison d'évoquer les travers des systèmes d'intégration, de compilation ou encore la paresse qui fait dire à certain qu'on est pas à 1Go près ni à 10ms près.
J'ajouterais à cette liste, les requêtes SQL inutiles/trop larges, les accès disques non cachés et la faible appétence à essayer d'optimiser quoique ce soit, sous prétexte que "c'est les autres le problème".
Il n'empêche que ce n'est pas une raison pour ignorer les problèmes liés à l'utilisation de certains langages (PHP, Lua, Ruby, Perl, Python…).
Si tu considères que la majorité des applications écrites dans ces langages passent leur temps à attendre (un top sur certains de mes serveurs tendent à prouver que non, mais bon, pourquoi pas l'envisager), utiliser un langage deux fois plus efficient permet de faire tourner deux fois plus de ces applications "patientes" sur un même serveur,
donc mécaniquement de diminuer le nombre de serveurs (on parle de centaines de millions, 3% de la consommation électrique mondiale).
Oui, en effet, en compilant du code Python en code natif avec ces outils, les voyants reviennent au vert.
Ce qui m'inquiète le plus c'est le fait que tous les projets et les distributions que je vois passer, ainsi que la plupart des développeurs Python avec qui je peux échanger reste sur "l'interpréteur" standard, malgré souvent la connaissance d'alternatives.
Java a également des outils pour avoir des exécutables natifs, mais la encore, on peut constater que quasi personne ne les utilise.
Dommage qu'il n'y ai pas plus de communication à ce sujet sur le site officiel de Python ou lors des conférences.
En ces temps de crise énergétique et de réchauffement climatique, il est toujours bon de rappeler qu'un programme en Python consomme 30x plus d'énergie qu'un programme en Java… programme Java qui est déjà deux fois plus "consommateur" par rapport à des programmes écrits C ou Rust.
On peut VRAIMENT créer un équivalent d'AD et des outils d'administration comme ça ? des trucs que MS a mis des années à peaufiner ?
Les outils de Microsoft ne sont pas jeunes, Active Directory date de 1996… c'est un annuaire LDAP dont il existe plusieurs implémentation sous Linux depuis fort longtemps.
Pour les outils d'administrations graphique, ils sont "peaufinés" depuis plus de 20 ans, mais on été créés avant les années 2000, en moins 5 ans si on suit la chronologie des "avancées techniques Microsoft".
L'avantage qu'à Linux est que tous les outils d'administrations (en ligne de commande) et/ou fichiers de configurations existent. Sur Windows, ce n'est pas toujours le cas, d'où la complexité de la chose.
Evidement, faire aussi bien, même mieux que ce qu'à fait Microsoft, ne peut pas se faire en quelques semaines. En revanche, en moins de 5 ans pour une équipe de 10 personnes je n'ai aucun doutes.
Mes doutes sont plutôt dans la lucidité des décideurs, qui préfèrent ne pas "risquer" 5 millions d'euros pour en économiser des centaines.
Quelles solutions libres existent pour remplacer Active Directory et des outils Windows d'administration dans son ensemble ?
A mon avis quand on commence à prendre le problème par là, on se trompe de chemin.
L'administration dépense de millions dans les outils Microsoft, avec une petite partie de ce budget on peut créer tous les outils du parfait petit administrateur système qui veut "tout gérer en 2 clics".
Ce n'est pas un problème technique, n'importe quelle petite équipe d'ingénieur est capable de créer une solution bien meilleure que ce que peut proposer Microsoft. C'est politique.
Vous remarquerez que c'est d'ailleurs la manière dont ceux qui ont intérêts à ce que rien ne change qui engagent le débat sur l'existence ou non d'alternatives, en se passant bien d'évoquer l'option de créer une alternative.
D'un autre côté, laisser programmer des web developers agiles frontend/backend [TM] en C, en sachant pertinemment qu'ils n'auront ni l'envie ni la contrainte d'écrire une suite de tests… c'est très risqué, voir dangereux ;)
Passer de C à Javascript c'est surtout encore consommerutiliser intelligemment plus de ressource processeur et de mémoire vive.
Effectivement, Rust aurait été un meilleur choix risqué. Mais il y a aussi l'option d'auditer le code C et d'écrire une suite de test complète.
Thunderbird fait partie de ces logiciels qui se dégradent lentement mais surement avec le tempsqui migrent vers les technologies du web 3.0 . Pour gérer mes 4 boîtes emails, il s'accaparen'utilise admirablement qu' un unique gigaoctet de mémoire vive, a des lenteurs et crashs aléatoiresincite son utilisateur a le fermer régulièrement dans un soucis d'optimisation des ressources.
L'équipe de développement a clairement pris le chemin de la réécriture totale en JavaScript, une route sans retour au pays du typage dynamique et autres joyeuseté qu'il est bon de fuir quand on cherche à faire un logiciel performant et fiabledes meilleurs logiciels actuels.
Heureusement que l'on a de jolies icônes maintenant, merci la MZLA Technologies Corporation.
Et bien, je t'invite à te renseigner sur le fonctionnement d'un serveur web, de la "mise en route" d'une connexion TLS.
La team "on est pas à 10Mo près et à 100ms près" me déprime.
(NDLR : mais bon, on est maintenant dans un monde de croyances assez folles, ou l'optimum c'est du node.js en docker. Et comme c'est à la mode, les biais cognitifs font que toutes réalités informatiques relatés par ceux qui connaissent l'assembleur, les vrais performances du matériel et les langages dits "bas niveau" par les ignares sont ignorées.)
Je vous conseille la lecture des commentaires de Lyon Mag, c'est ce que l'on fait de mieux en terme de dissonance cognitive et biais cognitifs concernant les logiciels libres.
DynFi Firewall, le premier parefeu Open Source français
ou plutôt "la version traduite en francais de OPNSense".
L'affirmation ci-dessus aurait un sens si DynFi n'utilisait pas le parefeu "pf", le reste n'étant qu'une interface évoluée de configuration de "pf" et du système FreeBSD… qui n'ont rien de français.
Bref… demain je traduis TensorFlow et l'autoproclame la première plateforme d'apprentissage automatique?
[^] # Re: Merci !
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Guide CNLL/inno³ sur le Cyber Resilience Act : êtes-vous prêts pour les échéances de 2026 et 2027 ?. Évalué à 3 (+1/-0).
Et tous les logiciels les utilisant/embarquant, le document indiquant que les dépendances doivent être CE…
Canonical ou Redhat vont ils prendre le risque d'apposer CE sur "ssh", "rsync",… pour rester sur le marché de l'UE?
Le CRA semble passer inaperçu sous couvert de "c'est bien, c'est pour votre sécurité"…
Hors on a bien vu comment les conformités évoluent (avec les logiciels de paiement/comptabilité récemment).
Au début, peut-être une auto attestation possible et rapidement une certification externe contraignante, régulière et couteuse avec l'introduction d'une norme.
J'ai l'espoir que les géants du logiciel boycotteront l'UE afin que tout ce cirque soit annulé, une fois que les idéologues seront vivement poussés à solutionner la crise logicielle majeure qu'ils ont créé.
[^] # Re: Merci !
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Guide CNLL/inno³ sur le Cyber Resilience Act : êtes-vous prêts pour les échéances de 2026 et 2027 ?. Évalué à 3 (+1/-0).
Il faut vraiment être un doux rêveur pour penser que tout le monde est prêt à la certification CE.
Peut-être que les "certifiants" se réjouissent, mais dans la grande majorité les "certifiés" laisseront tombé ou quitteront le territoire.
Cela m'étonnerait grandement que des "petits" développeurs américains se préoccupent assez de l'Europe pour ne pas tout simplement couper les ponts et couler des milliers de projets à travers les dépendances non CE.
[^] # Re: Est-ce vraiment un problème de liberté du logiciel
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Qui veut la peau des logiciels libres de caisse ?. Évalué à 3.
Non, car c'est prendre en compte qu'un code ouvert rend l'inclusion de fonctionnalités de fraude quasi impossible car trop visible.
Rendre obligatoire l'open-source dans les logiciels de caisses serait un moyen efficace pour éradiquer les fonctionnalités de fraude inclues par les éditeurs (en pratique, dans les logiciels propriétaires pour tous les cas de fraude avérés).
[^] # Re: Mais est-ce que quelqu'un veut vraiment la peau des logiciels libres ?
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Qui veut la peau des logiciels libres de caisse ?. Évalué à 6.
Oui, je pense qu'il faudrait s'arrêter à ça, cad requérir que ces logiciels soient conformes à une norme (NF525 par exemple), et qu'il soit interdit d'utiliser un logiciel de caisse qui n'est conforme à cette norme.
Nul besoin d'une certification obligatoire.
On aimerait aussi que la NF525 soit gratuite et libre d'accès, ce qui n'est pas le cas aujourd'hui.
Je doute d'ailleurs de la légalité d'imposer des règles payantes.
Je doute également que les députés aient payé (et même lu) la NF525 avant de voter pour l'imposer.
[^] # Re: Qu'est ce qu'une caisse ?
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Qui veut la peau des logiciels libres de caisse ?. Évalué à 4.
Ca fait partie du lot, ce sont des systèmes de caisse.
La NF525 n'est pas libre d'accès, il n'est pas permis de partager son contenu.
Elles devront faire certifier NF525 leur logiciel. Infocert est à votre disposition pour un audit, l'accompagnement et la certification, dans des budgets proches de ceux cités plus haut.
[^] # Re: Est-ce vraiment un problème de liberté du logiciel
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Qui veut la peau des logiciels libres de caisse ?. Évalué à 10.
Le fond du problème est que sous couvert de la lutte contre la fraude, on ajoute une certification obligatoire et couteuse (on parle d'un budget de plus de 10k€ par version).
Un logiciel libre pour lequel il faut débourser 10 000€ pour toute modification de la partie caisse n'est plus un logiciel sous licence libre. On pourra juste le qualifier d'open-source.
Dans les faits, quand on regarde de près les arguments (fraude TVA, millions d'euros détournés, rapport INSEE), on se rend compte que :
- la majorité de la fraude concerne la TVA (non-reversement de la TVA perçue, facturation fictive ou de complaisance, fraude à la TVA carrousel)
- la fraude concerne principalement le milieu de l'immobilier selon l'INSEE (donc en rien les logiciels de caisse)
- la fraude "de caisse" qui consiste à supprimer des enregistrements de recettes est une "fonctionnalité" qui n'a été découverte que dans les logiciels propriétaires. Ce qui parait un peu normal vu que le code des logiciels libre est consultables facilement.
- la manière la plus simple de faire disparaitre une vente en espèce est de ne pas la saisir dans un logiciel, certifié…ou non.
Bref, la certification n'apporte rien, complexifie tous les systèmes inutilement, a un coût élevé (estimé à 50 000 € annuel pour OpenConcerto) et n'aura qu'un effet : la disparition de nombreux acteurs du logiciel libre.
Le sujet est souvent détourné par des idéologues ou des vendeurs de blockchain, merci de ne pas retomber dans ces travers, constamment relayés par des politiques peu au fait des réalités.
[^] # Re: formats de données
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche OpenConcerto 1.7.3. Évalué à 10.
Ces formats existent plus ou moins, on peut citer pour les factures : UBL, XML Invoice de GS1, FacturX… , pour les écritures comptables: le FEC, etc… OpenConcerto en implémente quelques
unes. La difficulté réside dans les relations entre les éléments, les structures sont biens différentes d'un logiciel à l'autre. De plus, faut-il normaliser sur "le moins disant" ou sur l'implémentation la plus complète?
En attendant un "standard" nous avons développé l'import depuis quasi toutes les solutions du marché (MS Dynamics, Cegid, Sage, EBP, Ciel, Odoo, Dolibarr… et d'autres moins connus)
Concernant la confiance et la pérennité financière, nous avons dépassé les 20 ans d'activité et ne manquons pas de travail. Une bonne partie des sociétés avec qui nous travaillons et pour lesquelles leur ERP est un point critique, prennent notre contrat de maintenance. A priori, elles semblent satisfaites.
[^] # Re: Architecture technique... un old school ?
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche OpenConcerto 1.7.3. Évalué à 8.
L'export FEC étant obligatoire, comment aurions nous pu ne pas l'intégrer? ;)
(cf https://www.openconcerto.org/fr/comptabilite.html)
Concernant la 2035, vous devriez sans grande difficultés retrouver les chiffres qui vous intéressent via le 2033.
Ne sachant pas ce qu'est un "code hyper disponible", je ne sais pas ce que l'on peut proposer de mieux que ce que l'on propose déjà, à savoir un dépôt libre d'accès et une licence libre (GPL).
Concernant la documentation, le guide PDF téléchargeable d'une vingtaine de page est suffisant pour démarrer. L'achat du manuel (papier) est comme pour un grand nombre de projet open-source, le moyen le plus simple de nous soutenir.
[^] # Re: Architecture technique... un old school ?
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche OpenConcerto 1.7.3. Évalué à 7.
Le code est accessible depuis https://code.openconcerto.org (lien de la dépêche), suite à de nombreuses tentatives de hack, nous avons installé il y a 2 ans un filtrage par IP pour bloquer certains pays et les accès depuis un VPN.
Comme vous l'indiquez, tout est sous licence GPL.
C'est tellement ancré dans nos esprits que nous avons oublié de le repréciser dans la dépêche comme nous l'avions fait dans les précédentes.
[^] # Re: Architecture technique... un old school ?
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche OpenConcerto 1.7.3. Évalué à 10.
Vos remarques sont intéressantes, voici quelques éléments de réponse.
Je comprend très bien que le fait qu'une application web ne nécessitant pas d'installation est plus pratique à déployer, mais nous avons tout fait pour que cela soit rapide (moins d'une minute par poste). Une version portable est même disponible pour du "zero install".
En revanche, les applications "natives" restent toujours plus intégrées au système et bien plus véloces que leurs équivalents web. Pour l'instant ce n'est pas du tout un frein à l'adoption d'OpenConcerto. Le principal frein est sa gratuité, difficile de combattre le biais cognitif "plus c'est cher, mieux c'est".
Nous travaillons depuis déjà un bon moment sur la "version web" du logiciel et sur un client léger, ils vous sembleront donc peut être plus "moderne". Nous continuerons la version client-server, l'architecture actuelle permet d'avoir les 3 modes. 2024 semble une bonne année pour leurs sorties officielles.
Concernant la gestion de production, ce n'est pas un domaine d'activité simple à séduire. Tout d'abord parce que les besoins sont très différents en terme de complexité d'une entreprise à une autre et que chaque type de produit à fabriquer requiert de fortes adaptations du système. Cependant le point important est que les entreprises faisant de la production sont déjà équipées en logiciel et sont très peu sensibles à l'open-source car satisfaites des solutions propriétaires dont le prix exorbitant les rassurent.
Je ne souhaite pas commenter votre dernière remarque vu qu'elle me semble particulièrement orientée sachant que que vous êtes partenaire Axelor et Cegid.
[^] # Re: Le retour de l'open bar Microsoft ?
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Revue de presse de l’April pour la semaine 51 de l’année 2023. Évalué à 4.
Ce serait un bon moyen pour l'April de se faire connaître.
Bien que la devise affichée sur son site soit "Promouvoir et défendre le logiciel libre",
je serais surpris de les voir bouger.
# jOpenDocument
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche LoTemplate générateur de documents à partir d'ODT. Évalué à 3.
Une autre solution, non dépendante de LibreOffice : jOpenDocument
Cette librairie Java permet de créer, manipuler et remplir des fichiers ODS/ODT..
et aussi de faire le "rendu" d'un fichier ODS en PDF (mais aussi l'impression et le rendu en bitmap).
Cette librairie est d'ailleurs utilisée par l'ERP OpenConcerto pour créer tous les documents via modèle ODT (un peu logique, vu que les auteurs sont les mêmes :) )
[^] # Re: Energie
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Programme de la PyConFR 23. Évalué à 2. Dernière modification le 05 février 2023 à 19:34.
Tu as raison d'évoquer les travers des systèmes d'intégration, de compilation ou encore la paresse qui fait dire à certain qu'on est pas à 1Go près ni à 10ms près.
J'ajouterais à cette liste, les requêtes SQL inutiles/trop larges, les accès disques non cachés et la faible appétence à essayer d'optimiser quoique ce soit, sous prétexte que "c'est les autres le problème".
Il n'empêche que ce n'est pas une raison pour ignorer les problèmes liés à l'utilisation de certains langages (PHP, Lua, Ruby, Perl, Python…).
Si tu considères que la majorité des applications écrites dans ces langages passent leur temps à attendre (un top sur certains de mes serveurs tendent à prouver que non, mais bon, pourquoi pas l'envisager), utiliser un langage deux fois plus efficient permet de faire tourner deux fois plus de ces applications "patientes" sur un même serveur,
donc mécaniquement de diminuer le nombre de serveurs (on parle de centaines de millions, 3% de la consommation électrique mondiale).
[^] # Re: Energie
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Programme de la PyConFR 23. Évalué à -1.
J'aimerai savoir d'où ca sort… (a part d'un fort biais cognitif d'un développeur Python).
[^] # Re: Energie
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Programme de la PyConFR 23. Évalué à 3.
Oui, en effet, en compilant du code Python en code natif avec ces outils, les voyants reviennent au vert.
Ce qui m'inquiète le plus c'est le fait que tous les projets et les distributions que je vois passer, ainsi que la plupart des développeurs Python avec qui je peux échanger reste sur "l'interpréteur" standard, malgré souvent la connaissance d'alternatives.
Java a également des outils pour avoir des exécutables natifs, mais la encore, on peut constater que quasi personne ne les utilise.
Dommage qu'il n'y ai pas plus de communication à ce sujet sur le site officiel de Python ou lors des conférences.
# Energie
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Programme de la PyConFR 23. Évalué à -3.
Dommage que le programme soit déjà bouclé, j'aurais bien fait un speech sur l'efficacité énergétique catastrophique de Python, basé sur
https://www.devsustainability.com/p/paper-notes-energy-efficiency-across-programming-languages
En ces temps de crise énergétique et de réchauffement climatique, il est toujours bon de rappeler qu'un programme en Python consomme 30x plus d'énergie qu'un programme en Java… programme Java qui est déjà deux fois plus "consommateur" par rapport à des programmes écrits C ou Rust.
[^] # Re: Administration de tout ça
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Le poste de travail Linux : un objectif gouvernemental ?. Évalué à 8.
Les outils de Microsoft ne sont pas jeunes, Active Directory date de 1996… c'est un annuaire LDAP dont il existe plusieurs implémentation sous Linux depuis fort longtemps.
Pour les outils d'administrations graphique, ils sont "peaufinés" depuis plus de 20 ans, mais on été créés avant les années 2000, en moins 5 ans si on suit la chronologie des "avancées techniques Microsoft".
L'avantage qu'à Linux est que tous les outils d'administrations (en ligne de commande) et/ou fichiers de configurations existent. Sur Windows, ce n'est pas toujours le cas, d'où la complexité de la chose.
Evidement, faire aussi bien, même mieux que ce qu'à fait Microsoft, ne peut pas se faire en quelques semaines. En revanche, en moins de 5 ans pour une équipe de 10 personnes je n'ai aucun doutes.
Mes doutes sont plutôt dans la lucidité des décideurs, qui préfèrent ne pas "risquer" 5 millions d'euros pour en économiser des centaines.
[^] # Re: Administration de tout ça
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Le poste de travail Linux : un objectif gouvernemental ?. Évalué à 10.
A mon avis quand on commence à prendre le problème par là, on se trompe de chemin.
L'administration dépense de millions dans les outils Microsoft, avec une petite partie de ce budget on peut créer tous les outils du parfait petit administrateur système qui veut "tout gérer en 2 clics".
Ce n'est pas un problème technique, n'importe quelle petite équipe d'ingénieur est capable de créer une solution bien meilleure que ce que peut proposer Microsoft. C'est politique.
Vous remarquerez que c'est d'ailleurs la manière dont ceux qui ont intérêts à ce que rien ne change qui engagent le débat sur l'existence ou non d'alternatives, en se passant bien d'évoquer l'option de créer une alternative.
[^] # Re: dépot légal ?
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Des nouvelles du Frido. Évalué à 3.
Ce n'est plus gratuit, voici les tarifs officiels : 1ère de demande : 30 € HT (36 € TTC)
Voir https://www.afnil.org/tarification/ pour les détails.
[^] # Re: Pour des raisons de sécurité
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Dernières avancées du côté de Thunderbird. Évalué à 10.
D'un autre côté, laisser programmer des web developers agiles frontend/backend [TM] en C, en sachant pertinemment qu'ils n'auront ni l'envie ni la contrainte d'écrire une suite de tests… c'est très risqué, voir dangereux ;)
[^] # Re: Pour des raisons de sécurité
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Dernières avancées du côté de Thunderbird. Évalué à 10.
Passer de C à Javascript c'est surtout encore
consommerutiliser intelligemment plus de ressource processeur et de mémoire vive.Effectivement, Rust aurait été un
meilleurchoix risqué.Mais il y a aussi l'option d'auditer le code C et d'écrire une suite de test complète.Thunderbird fait partie de ces logiciels
qui se dégradent lentement mais surement avec le tempsqui migrent vers les technologies du web 3.0 . Pour gérer mes 4 boîtes emails, ils'accaparen'utilise admirablement qu' un unique gigaoctet de mémoire vive,a des lenteurs et crashs aléatoiresincite son utilisateur a le fermer régulièrement dans un soucis d'optimisation des ressources.L'équipe de développement a clairement pris le chemin de la réécriture totale en JavaScript, une route sans retour au pays
du typage dynamique et autres joyeuseté qu'il est bon de fuir quand on cherche à faire un logiciel performant et fiabledes meilleurs logiciels actuels.Heureusement que l'on a de jolies icônes maintenant, merci la MZLA Technologies Corporation.
[^] # Re: Not free enough
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche L'Agenda de Odoo Experience, et lancement Odoo 16. Évalué à 5.
Je me disais la même chose :)
On va bientôt en reparler avec la gestion de lot, de numéro de série, DLCU, DLUO…
[^] # Re: Si je puis me permettre ...
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Oubliez les web services, utilisez des tubes nommés. Évalué à 10. Dernière modification le 02 septembre 2022 à 16:32.
Et bien, je t'invite à te renseigner sur le fonctionnement d'un serveur web, de la "mise en route" d'une connexion TLS.
La team "on est pas à 10Mo près et à 100ms près" me déprime.
(NDLR : mais bon, on est maintenant dans un monde de croyances assez folles, ou l'optimum c'est du node.js en docker. Et comme c'est à la mode, les biais cognitifs font que toutes réalités informatiques relatés par ceux qui connaissent l'assembleur, les vrais performances du matériel et les langages dits "bas niveau" par les ignares sont ignorées.)
# Lyon
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Revue de presse de l'April pour la semaine 27 de l'année 2022. Évalué à 5.
Je vous conseille la lecture des commentaires de Lyon Mag, c'est ce que l'on fait de mieux en terme de dissonance cognitive et biais cognitifs concernant les logiciels libres.
# Traduction d'OpenOffice
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche DynFi Firewall, le premier parefeu Open Source français. Évalué à 10.
ou plutôt "la version traduite en francais de OPNSense".
L'affirmation ci-dessus aurait un sens si DynFi n'utilisait pas le parefeu "pf", le reste n'étant qu'une interface évoluée de configuration de "pf" et du système FreeBSD… qui n'ont rien de français.
Bref… demain je traduis TensorFlow et l'autoproclame la première plateforme d'apprentissage automatique?