bbo a écrit 219 commentaires

Je te rejoins sur les enjeux.

Je réagis sur :

[…] prendre des décisions rapides et efficaces […] redéfinir un fonctionnement clair et largement accepté.

Je crois qu'il est possible d'avoir des "décisions efficaces" et un "fonctionnement clair". Car l'efficacité peut être amenée par la simplicité, qui permet de plus facilement appréhender les choses.

Par contre, il me parait impossible d'avoir des "décisions rapides" et un "fonctionnement largement accepté". Sauf si ce "fonctionnement largement accepté" est de laisser décider un dictateur ou un groupe de personne (donc, une oligarchie). Mais je veux bien que tu détailles ce que tu entends par "fonctionnement largement accepté".

est le service de contrôle d'accès fourni par Atos

Petite précision : Worldline est désormais une entreprise indépendante d'Atos (depuis mai 2019).

Et pour systempay, le whois indique Natixis (groupe BPCE).

https://www.betterbird.eu/faq/former.html

Et bien, l'ambiance a l'air top ! J'ai juste du mal à bien cerner la répartition entre faute possible côté Thunderbird et égo du développeur.

Dans tous les cas, je ne connaissais pas du tout ce fork. Merci pour l'info donc !

Tu t'exposes à utiliser une ancienne version

Et la teneur du message des mainteneurs me fait penser à xscreensaver en son temps.

Pour le cas spécifique de Firefox, il me parait intéressant de noter que la transition snap a été lancée à la demande de Mozilla.

Vu sur discourse.ubuntu.com :

Why the change ?
When Mozilla approached Canonical, they had some clear benefits in mind. Those included:
* Cross-platform support: The snap will run on all distributions that run snapd - now and in the future
* Authenticity: You’re getting Firefox, unadulterated, straight from the source
* Effortless updates: Get security updates from Mozilla, fast
* Less time on maintenance, more time for features: Community developers can focus on innovation, instead of being mired in support

Et plus loin :

Didn’t you do this before? Yes. Kind of, with the transition to the Chromium snap a few years ago. […]. However, that decision was all us, for maintenance reasons. This time around, for Firefox, it’s a coordinated effort between Mozilla and Ubuntu.

Pour rappeler l'ancienneté des positions de Bernard Coutaz un article ancien me parait au contraire tout a fait pertinent

D'autant que ses positions sont bien ancrées dans le sol ! Après c'est le risque avec quelqu'un qui a désormais une vision un peu étriquée du monde.

dont l'avantage, après lecture, se limite à une feature très "niche"

Snap ne fournit pas que l'auto-update.

C'est un peu comme avec Flatpak, laisser de côté le sandboxing (même si tous les snaps ne sont pas confinés, mais c'est indépendant d'Ubuntu) et le fait qu'un seul "paquet" soit installable/utilisable sur plusieurs versions de plusieurs distributions c'est passer à côté d'une grosse partie des raisons ayant amené le développement de ces 2 systèmes de paquets "universels". Raisons qui ne sont pas sans conséquences.

Mais c'est vrai que ces fonctionnalités peuvent aussi être considérées de niche.

Oui, pardon, tu parlais explicitement de logiciel libre. J'aurai dû préciser que je complétais avec des morceaux du programme "dans les thématiques abordées généralement sur LinuxFR" :)

Quoiqu'il en soit, je trouve que cela reste flou. Concrètement, créer un organisme et organiser un débat ne semble pas engager à grand chose.

Tu vas adorer Ubuntu Core sur ton raspberry !

Next Impact parle bien d'EELV. Et c'est effectivement dans le projet du parti pour la présidentielle (pages 76 à 78). Il date de l'été 2021, avant que le candidat ne soit choisi.

Je reconnais que c'est dommage que ces propositions n'aient pas été reprises explicitement dans le programme du candidat.

En complément de ce que tu cites, Jadot propose (page 83) de créer "un organisme pour la transparence et l’éthique des algorithmes" et d'organiser

un débat européen autour de l’émergence d’un écosystème numérique diversifié,déconcentré et démocratiquement contrôlé, avec l’instauration de nouvelles normes européennes anti-trust.

En faite je fabrique mon propre logiciel de sauvegarde (je ne me base donc pas sur un outil existant).

D'après moi, tu dis tout là. Ton logiciel, c'est pour faire… de la sauvegarde !

Stocker des métriques, faire des requêtes dessus et les afficher dans un navigateur ne me parait pas être le but d'un logiciel de sauvegarde.

Franchement, si tu te lances dans un moteur de stockage de données temporelles et dans un outil de visualisation de ces données, dans vraiment pas très longtemps tu ne seras plus en train de développer un outil de sauvegarde.

Si Prometheus et Grafana existent (entre autres, ils ont chacun des concurrents), c'est que le sujet est suffisamment compliqué pour justifier un outil dédié. Si leur doc parait compliquée, c'est peut être qu'il faut du temps pour appréhender certains concepts qui paraissent intuitivement simples mais qui, en réalité, ne le sont pas (le diable se cachant dans les détails). Concepts que tu devras de toute façon bien appréhender pour pouvoir, je te cite :

stocker de manière efficiente les valeurs actuelles, leur historique et ensuite pouvoir les restituer de manière efficiente également

Donc, tes 2 solutions me paraissent être :

• Avoir une dépendance sur un outil dédié (mais externe). Les autres ont déjà donné des pistes.
• Avoir une dépendance sur ton outil qui, en plus je te le dis, marchera moins bien que les outils dédiés, tout en étant moins flexible et pas interopérable

Il me semble que l'auteur des modules color et faker avait été viré de Github suite à ses actions. J'aurai imaginé que Github déplateforme également l'auteur de node-ipc ce qui ne semble pas (encore ?) être le cas…

En fait gUI chipote beaucoup :).

Ce qui est un comportement très peu fréquent sur LinuxFR

ce que je regrette , c'est que les distros rh like ne le propose pas hors epel

En ce qui me concerne, je trouve que c'est mieux que ça soit fourni par EPEL !

Quand KDE était dans les dépôts RHEL, c'était figé. Contrairement à GNOME qui était mis à jour de temps en temps. Il y a bien eu une tentative de fournir Plasma 5 via EPEL pour CentOS 7 mais j'ai pas l'impression que ça se soit bien terminé.

Maintenant qu'il n'y a plus "que" Qt dans RHEL, les contributeurs Fedora peuvent plus facilement pousser dans EPEL (pas de risque de conflit avec des paquets KDE dans RHEL vu qu'il n'y en a plus !). Et je trouve ça beaucoup mieux pour les utilisateurs de Plasma de savoir qu'il y aura environ une mise à jour par an au lieu de zéro (Visiblement Plasma 5.23.3 en ce moment sur CentOS 8, c'est quand même hyper récent pour une distro aussi stable/vieille)

En moins chronophage mais tout autant disruptif : tu vends un NFT contenant :

Toute la collection des Virus Informatique (sauf le 1er numéro) est associée à "mets le nom de celui qui te l'a acheté ici" et se trouvent à "mets ton adresse postale ici".

Ça correspond aux points 1 et 2 décrit ici. Si tu en as marre de les garder, ou que tu les déplaces dans le garage, voir le point 3. Et si tu vends ta maison et déménage, voir point 4.

De rien pour ton temps et ton scanner ;)

Donc j'ai le sentiment que ce qui a été mesuré, c'est la vitesse de démarrage de l’interpréteur python (en C) par rapport à un programme en C.

Pas sûr. Il est dit :

A 10 reprises, chaque solution a été exécutée et les performances associées mesurées « afin de réduire l’impact des démarrages à froid et des effets du cache, d’analyser la cohérence des mesures et d’éviter les valeurs aberrantes ». Et ils rapportent que « les résultats mesurés sont assez cohérents »

Toujours la petite info décalée mais dans le contexte. "Comment by antistress" :)

Peut-être pourras-tu vendre des NFT de tes meilleurs commentaires sur LinuxFR ? ;)

Qu'est ce qui explique la tendance de ces trucs ?

L'opportunisme et la cupidité ?

J'avais lu l'article de S. Bortzmeyer sur les NFT (d'ailleurs cité par SebSauvage). Et je suis assez en phase avec ce qu'il écrit :

Est-ce une escroquerie ? S'il y a des prétentions malhonnêtes (comme l'authenticité de l'œuvre) dans le discours marketing sur les NFT, d'un autre côté, on peut dire que vendre du virtuel n'a rien de mal en soi, cela se fait tout le temps, entre autre dans le marché de l'art, qui est souvent du grand n'importe quoi (mon projet actuel est de laisser un fromage dehors, d'attendre qu'il se couvre de moisissure et de le vendre ensuite comme œuvre d'art). Si des gens achètent, et sont bien informés et conscients de ce qu'ils achètent, pourquoi pas ?

Nous avions déjà la capacité à trouver des moyens de faire de l'argent sur tout avant que les NFT apparaissent.

Du côté de Clever Cloud, sur la partie techno, ils aiment beaucoup Rust et ils ont aussi du Scala pour leurs développements internes. Leur choix de distribution Linux s'est porté sur Exherbo.

Et pour contribuer aux dépôts, il est possible de pousser du code directement dans une discussion. Pas mal.

J'espère que le code de Nest sera rendu public et sous licence libre. Hâte de voir ça.

en attendant d'être propulsé aussi par un Pijulhub

Il y a quand même Nest qui fournit (pour le moment) dépôt de code, discussions et "réseau social" (on peut mettre des étoiles !!!). Par contre, pour le moment, c'est pas libre.

Je suis convaincu qu'un vaccin conventionnel n'y aurait rien changé.

Le Parti Pirate a publié début 2021 une petite synthèse sur la vaccination que j'avais trouvé pas mal. Il y avait notamment un rappel historique de la vaccination.

Je cite :

Comme le rappelle l’historien Laurent-Henri Vignaud dans ses entretiens et dans ses livres, « dès qu’il y a eu vaccin, il y a eu anti-vaccin ».

Tout ça pour dire que je pense que tu as raison : cela n'aurait rien changé.

Les managers "qui vous font grandir" sont très rares.

Peut-être que ce recruteur les connaît tous.

on peut créer une grosse entreprise et l'utiliser pour collecter les paiements pour de nombreux développeurs.

Ou quelque chose sur le modèle de la FreeBSD Foundation qui (si je dis pas de bêtise) utilise les donations pour aussi financer des développements (ce que ne font pas toutes les fondations pour le coup)

c'est une dépendance java, donc liée statiquement et pas dynamiquement dans les logiciels

Comme déjà précisé par kaos, je pense que tu voulais plutôt dire que les applications ne s'appuient pas sur la version fournie par le système mais que chaque application embarque sa propre version de log4j (bundling).

C'est pas lié au fait que ça soit du Java. Juste que le bundling est une pratique courante dans cet écosystème (notamment sur les applications web qui embarquent leurs dépendances dans le WAR).

Mais, même en Java, tu pourrais t'appuyer sur les dépendances systèmes fournies par ta distribution (qui ont des politiques qui poussent à "debundler" les appli Java). Il faut "juste" que ton classpath soit correctement configuré (mais ce n'est pas toujours simple, surtout si tu pars sur un serveur d'application pas toujours packagé dans ta distribution, par exemple Tomcat…) pour que ton appli utilise le log4j système et que tu passes ta dépendance en "provided" côté applicatif.

C'est donc vraiment une politique globale à avoir mais le niveau de coordination entre les équipes systèmes et applicatives serait, je pense, assez compliqué à mettre en œuvre dans un (très) grand nombre d'entreprises (mon expérience n'est pas forcément représentative mais, côté applicatif, je n'ai jamais été encouragé ¹ à m'appuyer sur les lib Java déjà empaquetées par l'OS).

Cependant, j'ai quand même l'impression qu'il y aurait exactement le même problème avec une 0-day dans une lib Python/Ruby/Node/Go/Rust/etc "que tout le monde utilise".

Le délai de correction sera donc assez long : il faut que la bibliothèque soit mise à jour puis que chaque logiciel qui l'utilise soit mis à jour (sachant qu'une partie de ces logiciels ne sont de toute façon plus maintenus !)

+1 ! Quelques bons articles (à mon avis) sur le sujet :
* Let distros do their job (Drew Devault, Alpine)
* The modern packager’s security nightmare (Michał Górny, Gentoo) qui explique les différentes techniques que les développeurs utilisent pour gérer leurs dépendances (static linking, pinning et bundling) et une 2ème partie sur les problèmes que cela pose.