barmic 🦦 a écrit 5744 commentaires

Quand tu as vu, comme moi des softs hyper critiques être maintenu depuis des années par 1 seul bonhomme (qui est le seul à connaitre le code, la partie métier) à quart de temps dessus et qui n'a jamais eu d'astreinte pour ça…
tu descends un peu de ta tour d'ivoire. (attention : j'ai jamais dit que c'était bien mais c'est un constat)

Tu n'a peut être pas dis que c'était bien, mais tu considère que quelqu'un qui dis que si un environnement a des SLA il faut travailler en équipe et gérer des astreintes est dans sa tour d'ivoire. C'est juste le droit de travail. Être totalement hors des clous comme ça ce n'est même pas légal. C'est pas une question d'aimer le travail bien fait ou la passion pour ce qu'on fait. Accepter de travailler dans ces conditions et en plus considérer cela comme normal (pointer comme un quelqu'un qui ne veux pas s'engager et prendre pour soit le résultat de cet état de fait), ça dévalue ton travaille.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

En fait, barmic, tu construis ton argumentaire autours de plusieurs postulats qui ne sont pas forcément vrai.

C'est toi qui parle d'une prod qui casse un vendredi à 18h. Le fait d'avoir une prod implique beaucoup de choses (la presque obligation légale d'être en équipe - tu n'a pas le droit d'être en astreinte 24/7 -, le fait qu'il s'agisse d'un service,…) que tu es entrain de remettre en cause dans ce commentaire.

Je pense plutôt qu'il y a une constante : n'importe quel boite souhaite la meilleur qualité et donc des salariés le plus compétents possibles, agiles, volontaires etc.

Je ne suis pas du tout d'accord. La plupart des boites ne savent pas ce qu'est et se foutent de la qualité logiciel. C'est simple elles ne la définissent pas. Parce que c'est une notion complexe et ça peut devenir très chère. Donc non la plupart veulent le niveau suffisant de qualité pour ne pas être trop emmerdé et que ça ne coûte pas trop chère.

Mon constat c'est que beaucoup de choses "critiques" (les fameuses 500 qui font tant plaisir) peuvent être évités en amont avec du typage, du pattern matching et de l'immutabilité.

J'ai vu des projets utilisant les même techno à des niveaux de résilience et de correction très différents et c'est la qualité des tests qui les départagées. Bien sûr le contexte joue sur la qualité des tests, mais c'est mécanique : tu test, ça marche, tu test pas, ça ne marche pas.

La simplicité du rollback, c'est bien mais faut pas que ça devienne une solution de facilité.
Bien entendu qu'il est impossible de livrer en prod sans un dérapage mais ce qui me semble plus important que le rollback en lui-même c'est les mesures prisent après rollback :
pourquoi c'est arrivé et comment on évite à l'avenir.
Avec ça, on réduit leur fréquence graduellement et on peut se permettre d'éviter des dettes techniques : maj des libs régulières, refacto etc.

Je ne suis pas d'accord. Évidement que tu va réfléchir à ce qui s'est mal passé en cas de rollback sinon tu ne livre plus. Ça n'est pas une question de bonne pratique, c'est mécanique. La capacité de rollback c'est ce qui te permet de ne pas avoir peur de ta prod. Les projets qui ont peur de leur prod accumulent de la dette. Les projets qui n'en n'ont pas peur vont se permettre de mettre en prod plus régulièrement donc vont déployer.

En plus, il y a tellement de cas ou un rollback n'est pas possible (ou que celui-ci a un coût) que de s'appuyer dessus c'est le désastre assuré.

Donc tu dis, « bon désolé mais si on a raté quelque chose, tout sera cassé jusqu'au prochain fix ou desaster recovery pour pouvoir remonter des données cohérentes ». Ça tu peut le faire quand tu as des SLA très petites, que la valeur de ta prod est plus faible que celle de ton dev et/ou que tu a le goût du risque. Il arrive qu'on ne puisse pas le faire, mais c'est un défaut à assumer (se préparer à faire un desaster recovery ou un hotfix en urgence. Travailler dans l'urgence, perso j'évite autant que possible.

Reproduire, c'est souvent 90% du taf et quand je fais le constat amer d'avoir passé des heures a arriver à reproduire un bug qui est lié à du typage, ça me fait rager parce que je sais qu'il pouvait être évité en amont.

Je n'ai jamais vu ce type de bug arriver dans une prod. Je ne connais pas tout, hein, mais ça ne m'est jamais arrivé. Du moins dans ce qui est classiquement le rôle du typage. Donc pas les types dépendants par exemple qui s'approche presque plus de la preuve de programme.

Néanmoins, je pense que l'apprentissage de Rust m'a permis de m'améliorer sur plein de sujets et je recommande vivement de sortir de sa zone de confort avec ce genre de langage.

Je n'ai jamais remis ça en cause. Ni les qualités intrinsèques de rust. Comprendre et jouer avec une variété de langage est très enrichissant. Regarder du coté de rust, de lisp, de smalltalk,… C'est très enrichissant, pour comprendre et utiliser le langage que tu utilise au quotidiens.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Avec un langage fortement typé et qui fait un max de vérifications à la compilation, tu t'évites l'écriture d'une paires de tests (débiles pour la plupart) qu'un langage interprété et faiblement typé t'oblige pour avoir la même rigueur avant déploiement.

Je ne suis pas d'accord. Ça joue sur lors du développement. Si tu laisse passer un problème de typage en prod, le problème c'est pas le langage, c'est la qualité que tu livre. L'effort pour fournir la même qualité ne sera effectivement pas la même, mais hors cas pathologique (comme ce pourquoi a était fait rust pour remplacer c++), la différence ne sera pas si grande.

La solidité de ton déploiement : c'est pas forcément au dev de gérer ça donc hs.

Tu parle de prod, parler de prod sans parler d'opérationnel, ça n'a pas de sens. Mais surtout si la prod est le problème du développeur alors son déploiement aussi. Sinon le fait que la prod tombe le vendredi à 18h ça n'est pas son problème.

La simplicité du rollback : si tu rollback, c'est que t'as cassé la prod, non ? (donc pouvoir rollback c'est bien mais éviter de casser la prod, c'est mieux)

Donc c'est bien une question de qualité de ce que tu livre. Mais les prods les plus solides vivent avec le fait qu'ils casseront leur prod. Parce qu'il est humainement impossible d'avoir un niveau de test suffisant pour garantir que tu ne casse jamais. Ça ne veut pas dire que tu ne va pas tout faire pour améliorer ta qualité, mais tu sais que reproduire la charge de ta prod est impossible par exemple. C'est pour que les canary release ou l'A/B testing existent.

Niveau workflow, j'aurais plutôt parlé des logs, des métriques, des envs de recette avec cahiers de tests (tu sais, piloté par des humains : c'est encore ce qui se fait de mieux).

Il faut les twelve factors et oui on est d'accord, mais dans tout ça il n'y a pas le typage de ton langage.

Je vais le dire autrement…

Tu veux fournir de la qualité. Tu as 2 stratégies possibles. Soit tu embauche les meilleurs développeurs possibles et ils choisissent le meilleur langage existant et code un excellent logiciel. Tout repose sur la qualité de chacun des développeurs. Soit tu cherche à avoir une qualité « systémique », c'est l'organisation de l'équipe qui produit de la qualité. C'est parce que les tests sont écrit par un autre développeur (entre autre) que tu obtiens de la qualité. Cette seconde stratégie est plus fiable car elle ne repose pas sur un recrutement trop complexe et est résiliente aux faiblesse ponctuelles qu'auront les développeurs.

Bref tout ça pour dire que les typages dynamiques et pire encore les typages faibles, je suis pas fan du tout, mais je ne les prendrais pas comme boucs émissaires en cas de problème en prod.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

tu espères amortir ce temps perdu à développer proprement en évitant de casser ta production au moment où tu le souhaites le moins (comme d'habitude, le vendredi à 18h…)

Pour moi ce n'est pas le langage qui permette ça. C'est plutôt le workflow de déploiement (les tests que tu fais avant déploiement, la solidité de ton déploiement, la simplicité du rollback,…).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Il y a un glissement dans ta réflexion entre, « j'ai trouvé des outils en rust » et « rust doit être mieux que les autres pour des outils cli ».

Si tu prendre d'autres exemples, par exemple httpie, vegeta et vtop. Ils sont écrit respectivement en python, go et js.

Je suis d'accord qu'en principe l'absence de runtime rend le démarrage plus rapide et que ce temps de démarrage peut être désagréable. Personnellement sur PC et laptop je ressent pas le temps de démarrage de python ou go, sur rpi je trouve que python commence à se faire sentir.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

J’avais présenté, il y a quelque temps, trois utilitaires écrits en Rust pour remplacer grep, ls et find (à savoir ripgrep, exa et fd). Cette dépêche est l’occasion de présenter trois nouveaux utilitaires également écrits en Rust : delta, dust et watchexec.

Il y a une forme de fétichisme pour rust ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je ne suis pas si vieux dans la communauté :)

Mais quand je suis arrivé, beaucoup disait que gnome2 c'était le DE pour pas trop te brusquer quand tu venait de windows. Je suis d'accord que c'est sujet à caution.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Pour être passé par là, ça ne doit pas être l'unique cause de très loin. Si totof a voulu partir souhaitons lui bonne continuation.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Mon expérience : tous les tests maintenus en dehors du code sont condamnés à devenir obsolètes et non maintenus.

Je ne suis pas d'accord. Si ces tests font parti de ton flow d'intégration continue, je ne vois pas pourquoi ils ne seraient pas maintenu (puisque cela casserait ton build).

Enfin, même si ce n'est pas du code, on voit très rapidement que les non techniciens ne sont pas capables de générer des tests solides et pérennes. Et ne sont pas autonomes. C'est vrai également avec du Cucumber ; la personne avec la compétence fonctionnelle/métier doit forcément travailler en paire avec un technicien à l'aise avec l'outil de test, qui va le guider sur ce qui est possible/pas possible, lui créer des squelettes de tests, etc.

La démarche peut aller jusqu'à 3 amis même. La démarche BDD permet à un fonctionnel de lire et comprendre les cas de tests et donc aide énormément à leur maintiens. Et c'est une documentation plus accessible que le code de test pour le développeur. Enfin la mise à jour ou les ajouts de cas de tests peuvent être suffisamment simple.

Bref ça a du sens surtout dans une optique de DDD (oui ça fait beaucoup de *DD).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

A une époque, il était pressenti pour devenir le window manager officiel de GNUStep, la réimplémentation libre d'OpenStep, avant que GNU mise tout sur GNOME.

Ce qui a l'époque signifiait choisir celui qui s'inspire de Microsoft plutôt que celui d'Apple.

Élégant et rapide, il était un favori de nombreux utilisateurs de GNU/Linux à la fin des années 90 et du début des années 2000.

Mais les vrais en jetaient pleins la vue avec e16 :p

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Cerberus permet également de faire des tests de services web (SOAP, REST, JSON, mais aussi Apache Kafka sur des opérations de production et recherche d’événements dans des topics).

Est-ce qu'il a un intérêt particulier quand on ne parle que d'API REST ? Ou est-ce qu'il n'est pas un peu gros pour cet usage ? Pour un projet sur le quel je travail, on a mis en place un simple petit outil dans nos sources qui prend en paramètre une collection de fichier yaml qui décrivent une requête et les vérifications à faire et une configuration d'environnement. C'est très simple à faire (l'outil n'est qu'une glue entre 3 bibliothèques : http, yaml et jsonpath), la description des cas de tests est simple et le versionnement se fait avec notre code (pour tester un environnement, on utilise la branche liée à cet environnement).

Est-ce que cerberus m'apporterait beaucoup ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Il y a pleins d'options :

• tu peux accepter le fait que ça ne marche pas, à toi d'avoir préconfiguré tes droits avant si tu utilise en TTY ;
• tu peux avoir un mode statique, les droits sont attribué à l'installation ;
• tu peux regarder ce que font les LSM qui ont des modes, comme selinux.

Il ne s’agit pas d'une impossibilité technique, mais d'un choix. Ça peut probablement se justifier (complexité, une volonté de définir le bureau linux sans CLI,…).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

J'espère que tu ne va pas me trouver trop relou :)

Il pourrait y avoir des notifications aux outils en cli. Si tu veux les utiliser dans des scripts automatisés libre à toi d'avoir valider leurs autorisations avant.

Mais surtout c'est quoi un outil cli par rapport à un outil graphique ? network-manager est dans une sandbox, mais pas nm-cli ? Il y a un paquet d'outils comme ça, c'est bizarre de considérer que ça doit s'installer différemment et avoir des droits différents alors qu'ils font la même chose voir qu'ils collaborent.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Si la métaphore a bien sûr des limites, elle me semble quand même plus joli que la notion de clientèle que transmet la notion de librairie et puis ça reste la traduction correcte au lieu d'utiliser un faux ami.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

un librairie modulaire pour construire un compositeur Wayland.

Je me permet une petite remarque sur la traduction library est un faux ami. Sa traduction française est « bibliothèque ». Bien sûr tout le monde comprends « librairie », mais je trouve dommage d'utiliser librairie plutôt que bibliothèque particulièrement dans un contexte d'une bibliothèque libre. En effet si le résultat est le même (de prendre quelque chose « sur étagère »), le modèle de partage des bibliothèques n'est pas le même que pour les librairies.

Conférences à distance

Covid-19 oblige, de nombreuses conférences ont du être annulées ou transformées en conférences online. Cela s’est-il bien passé ? Quelles conséquences à court et long termes ? Quelques éléments de réponses dans ces deux articles en anglais. Le premier au sujet de la conférence de Red Hat et le second au sujet de la PyCon US.

Je suis dans l'organisation d'une conférence orientée développement. Le snowcamp est un évènement qui se déroule fin janvier chaque année. Cette année nous n'avons donc pas eu de problème. On va voir comment ça se passe pour l'an prochain.

Les conférences en lignes sont un moyen de subsister, c'est utile quand tu es Google ou RedHat parce que la conférence est pour beaucoup une vitrine de ce que tu as à proposer, mais pour des conférences moins teintées d'entreprise c'est assez moyen. Pour les organisateurs comme pour une partie des plus habitués une conférence est un lieu social, une opportunité de rencontrer et de discuter avec des gens du même domaine mais beaucoup plus loin que ton cercle de contact habituel. Les conférences en lignes ça revient à publier des vidéos de présentation avec un direct au départ. Il n'y a pas besoin d'organisateurs pour faire ça twitch et youtube seront heureux d'accueillir toutes les personnes qui auraient quelque chose à dire. C'est gratuit pour les spectateurs et ça peut potentiellement rémunérer un peu l'orateur.

Les annulations ont poussé à améliorer la communication entre certaines conférences (devoxx, alpescraft, snowcamp, blendwebmix, afup, agile grenoble, lehack, riviera dev, voxxed luxembourg, devfest paris, MixIT, tourainetech, devfest nantes,…). C'est super pour améliorer l'entraide et la co-organisation.

La plupart des conférences sont organisées par de petites associations. Souvent il s'agit surtout de s'adosser à un lieu qui fourni plus ou moins de service et impose plus ou moins de règles. Ce sont ces lieux qui vont définir la gueule qu'auront les prochaines conférences (et bien sûr ils ne vont faire qu'appliquer les règles qui seront mises en vigueurs à ce moment là). La densité de personnes, l'obligation de port de masque, la mise à disposition de gel hydroalcoolique,… Tout ça ce sont des inconnues totales.

Tu peux voir un inventaire qui tente d'être à jour de conférence ici : https://github.com/scraly/developers-conferences-agenda (si tu en a d'autres Aurélie sera heureuse d'accepter des PR).

Il y a aussi pas mal d'inconnues lors de la reprise des conférences. Est-ce que les gens voudront venir ? Est-ce que les sponsors continueront à sponsoriser ? Est-ce qu'il y aura toujours des orateurs ? Avant le confinement les entreprises se montraient de plus en plus frileuses à ce sujet (conseillant à leurs employer d'éviter de venir par exemple). Des conférences comme le devoxx qui ont un rayon de diffusion international peuvent se retrouver à redevenir locale. Hors du débat si c'est bien ou pas ça demande un certain nombre de changement organisationnel.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Personnellement ça m'amuse un peu les positions extrêmes car elles renient souvent le droit de faire des compromis, ou de le faire de manière différente. Même si tu mets de l'eau dans ton vin par après, cette partie reste assez typique.

Il ne s'agit pas d'une position extrême, juste de pointer une limite. C'est dommage de tenter de mettre du personnel dans la discussion. Comme tu le dis c'est un compromis et c'est ce que j'ai voulu exprimer en parlant d'assumer.

J'utilise avec parcimonie flatpak. Paspparce que je ne veux pas m'en servir plus mais parce que j'en ai pas besoin de plus. Si un logiciel n'est pas dispo dans ma distribution ou pas dans la version qui me convient je suis là procédure du site officiel etje ne me plain pas.

Il est là ton extrémiste qui exige quelque chose.

Dans mon travail quand je prends une décision, je produit architecture decision record qui décrit le choix et sa raison d'être et pointe les limites connues. Tu aura remarqué que cette question n'est pas dans les 2 points que je trouvais dommage dans flatpak un peu plus haut.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Donc il n'y a pas de raison qu'une mise à jour du runtime casse l'application qui en dépendait.

Ça c'est en théorie. L'ABI ne fait pas tout et les problème sus-nomé de pitivi ne sont pas au niveau de l'ABI je présume.

Si l'ABI est mis à jour ou que le correctif est plus important, le runtime change de version. Les applications maintenues utiliseront la nouvelle version dès qu'ils seront compatibles avec celui-ci et les non maintenus pourront utiliser l'ancien.

C'est là dessus que travaillent les distributions stables.

Les distributions font d'ailleurs beaucoup de travail, parfois bancal pour s'assurer que l'ensemble fonctionne. Car à quelques exceptions près, toute application doit utiliser la même version d'une bibliothèque alors qu'elles ont rarement été développées pour ces versions.

C'est exactement ce que tu décris, ils restent sur la même ABI donc comme tu le dis plus haut il n'y a pas de raison que ça ne marche pas hors effectivement ça ne marche pas.

Donc cela requiert beaucoup de tests, de correctifs manuels dans tous les sens pour s'assurer qu'elles seront fonctionnelles.

Beaucoup de tests oui bien sûr si tu prend debian tu ne peux pas envisager 60k paquets et un logiciel de la même façon c'est évident. Mais en terme de correctifs manuels, je ne crois pas qu'il y en ai tant que ça (je serais intéressé de regarder). Debian s'est fait connaître à cause de plusieurs histoires là dessus, mais cet éclairage important sur quelques cas donne une fausse impression qu'il y a beaucoup de modifications.

Flatpak apporte la possibilité de le faire en plusieurs étapes. Les applications très maintenues peuvent bénéficier très vite des derniers correctifs, les applications qui le sont moins en profiteront quand elles seront prêtes. Et entre temps, l'utilisateur peut profiter de toutes ses applications.

Il peut profiter de ces vielles applications des failles de sécurité qui vont avec, de l'occupation disque des runtime devenu obsolètes,… En soit cette flexibilité a un coût avec ou sans flatpak, c'est quelque chose à assumer.

Comme je l'ai précisé dans l'article, le fonctionnement traditionnelle d'une distribution n'est pas magique. Elle fait un compromis qui a ses avantages et inconvénients pour l'utilisateur comme les mainteneurs. Flatpak propose un autre modèle, avec aussi ses avantages et inconvénients. Aucune solution n'est parfaite et universelle. Il est bon de le reconnaître.

On est tout à fait d'accord. Je ne viens pas dire que les distributions sont la solution. Flatpak est une brique très intéressante, il faut tout de même être conscient de ses limites et que c'est une solution encore jeune qui va encore évoluer en fonction de son usage et des problèmes rencontrés (la création de paquet ne semble pas toujours aisée d'après devnewton - ça fait aussi parti de ce qui me donne l'impression que la démarche loin d'être universelle a était de remplir les besoins des application Gnome et KDE -).

Je ne suis moi même pas sur une distribution vanilla et utilise une distribution stable pour l'énorme majorité de ce que j'utilise et installe moi-même les quelques logiciels dont j'ai besoin qu'il soit à jour. C'est ma façon de faire et je ne doute pas qu'elle ne convienne pas à tout le monde.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

C'est un avis tout à fait personnel, mais je trouve que les runtimes standards/classiques/supportés son beaucoup trop gros.

Pour info n'importe qui peut créer ou maintenir un runtime pour en avoir des plus petits s'il le juge nécessaire.

C'est pour ça que je parle des classiques/standards/supportés et oui je ne l'ai pas dis mais ce n'est pas forcément un problème systémique, ça peut évoluer.

Mais si tu utilises beaucoup de ces applications ensemble, finalement tu seras proche de la taille d'installation qu'avec ta distribution préférée aujourd'hui.

Je sais bien et je me doute que le choix est fait pour simplifier la vie des développeurs qui ont moins de question à se poser. C'est important quand comme c'est le cas de flatpak tu es bon dernier arrivé. Si tu embête les développeurs, ton store restera vide et ne servira à rien.

Mais malgré ça cette taille pose des problèmes. Par essence flatpak est fait pour gérer de la profusion et de la simplicité pour l'utilisateur. Avoir plusieurs versions d'une même application, installer la petite application Qt alors que ton bureau est gtk,… Ce sont des comportements explicitement encouragés par flatpak (ce qui est bien), mais les runtimes vont se multiplier. L'espace disque c'est pas chère, mais tu le vois à l'usage. Télécharger et installer en 3s ou en 30s ça n'a rien à voir en terme de ressenti pour l'utilisateur que celui-ci soit un utilisateur final ou un développeur.

Et si je parle de Qt ce n'est pas pour rien. Il existe des applications juste Qt, est-ce qu'il vaut mieux qu'elles utilisent KDE qui est immense pour elles, mais qui augmente la potentielle réutilisation ou bien une plus petite qui va tuer la réutilisation mais être plus légère pour ceux qui n'utilisent pas KDE.

Donc oui pour installer une application en Flatpak seulement, ce sera un gros poids en plus. Mais si ton système repose dessus (comme c'est le cas avec Silverblue) finalement ça devient intéressant.

Je ne parle que flatpak en soit et pas de silverblue, mais même lui est sujet à ce problème il l'est juste moins.

Aucune solution existante ne permettait de gérer tout ça à la fois.

Ce n'est pas ce que j'ai dit. J'ai dit que je vois les même travers que les débuts de docker en particulier et que je ne serait pas surpris que dans les prochaines années on voit les même mouvements. Le contexte est différent et on peut imaginer que ça n'arrivera pas et c'est tout ce que je leur souhaite, mais j'en serais surpris.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Ensuite si je prends l'exemple de Pitivi, celui-ci nécessite souvent des versions assez précises de bibliothèques. C'est totalement trivial et transparent en flatpak. Avec des dépendances aur, deb ou rpm, c'est très souvent cassé.

Le problème n'est pas le système de paquet et flatpak ne sera pas une solution. Si le runtime sur le quel s'appuie Pitivi est mis à jour avec une version d'une dépendance qui le casse tu ne pourra pas le mettre à jour (même si ce nouveau runtime fixe des CVE ou apporte une version d'une autre dépendance qui elle t'apporterait quelque chose). Ça n'est qu'à peine plus enviable et c'est la situation que tu as déjà en moins bien avec une distribution stable.

En utilisation flatpak ça fonctionne très bien depuis bien 2-3 ans. Les snap la dernière fois que j'ai essayé, c'était encore bien laborieux, en termes de rapidité de lancement, homogénéité des thèmes, qualité, suivi des versions des logiciels …

Ce que t'es entrain de dire c'est que les distributions font mal leur travail. C'est possible, mais je pense que si on envisageait sous ce biais là on pourrait parler de solutions très différentes et potentiellement bien différentes.

Donc en temps qu'utilisateur c'est vraiment bien plus simple et souple qu'un système de paquets à l'ancienne.

Tu apprends dans les journaux qu'il y a une CVE critique sur libBiduleTruc. Ils viennent de sortir les versions 1.2.123, 1.4.3 et 2.0.4 qui corrige la faille. Comment tu t'assure de ne pas l'avoir ? Qu'est-ce que tu fais de pitivi qui va planter avec la dernière version des runtimes ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Une application est liée à un ou plusieurs runtimes (contextes d'exécution en français dans la dépêche).

C'est un avis tout à fait personnel, mais je trouve que les runtimes standards/classiques/supportés son beaucoup trop gros. Grosso modo quand on en voit la taille et comment ça a était fait, c'est fait pour avoir des distributions linux relativement complète (c'est presque l'équivalent de kde-plasma-desktop). Ça donne l'impression que c'est avec des œillères, il y a d'autres solutions qui existent depuis plus longtemps ça aurait était intéressant de faire un état de l'art avant de pondre quelque chose et pas que d'un point de vu technique mais aussi d'un point de vu écosystème. Et ailleurs on voit que la taille de ces choses là est importantes.

L'autre point qui est dommageable amha c'est le fait de complètement orienté la techno pour les bureaux. Ça complexifie le travail des distributions qui ne sont pas particulièrement orientée bureau. Elles doivent jongler avec ces 2 profiles qui sont tout à fait arbitraires.

Pour un travail qui se veut standard et issu d'un consensus (contrairement à snap par exemple), je trouve que ça aurait pu être bien mieux.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Par exemple, les environnement virtuels Python ont réglé de nombreux problèmes, mais quand on analyse, on a simplement transféré un fardeau sur l'utilisateur.

Hum ? virtualenv n'est pas fait pour l'utilisateur de ce que je crois en savoir. Donc rien est transféré à l'utilisateur.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

J'ai toujours utilisé dia personnellement. Il fait pas des schémas très sexy, mais il fait le taff et permet de faire des liens fléchés qui sont maintenu et ça c'est vraiment cool. LibO peut faire ce genre de choses, mais le logiciel est bien plus lourd et un résultat plus sexy mais pas tant suffisamment pour que ça me fasse y passer.

C'est cool qu'il garde un développement actif, il est presque resté le même depuis que j'ai commencé à l'utilisé il y a plus de 10 ans maintenant.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Hazelcast fait références aux premiers GCs qui mettaient en pause la JVM

Tu parle du stop the world que G1 a encore ? (Doc Oracle de G1)

@+

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Il se place comment par à rapport à d'autres solutions ? Je connais surtout Zenitram qui est très réputé en terme d'alerte par exemple.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Concernant le profiling, c'est un peu plus gris, en Java je vais préférer que tout soit dans une même JVM pour avoir une vision globale et juste (historique des threads et lock dans JProfiler par exemple).

He ben ce n'est pas l'avis de certains développeurs de base de données clef-valeur en mémoire pour java qui préconisent d'avoir plusieurs JVM de tailles réduites et expliquent qu'on a de meilleures performance en lui dédiant du matériel (page 28). À savoir qu'hazelcast possède les 2 modes il peut être utilisé comme bibliothèque et comme cluster à coté.

Pour les statistiques NoSQL que tu présentes, se pose en effet la question de savoir si le nombre de drivers est lié à la simplicité du protocole.
Autre réflexion :
plus une base de données est populaire,
plus le nombre d'utilisateurs est grand,
plus le nombre d'utilisateurs de langages peu utilisés est important,
plus la probabilité qu'un développeur/utilisateur se colle à la création du driver est importante.

Tu en raconte des trucs, mais en l'état tu remet en cause ce qu'avance les développeurs de redis avec uniquement des « bouts de réflexions ». Pour le reste du commentaire je ne vois qu'à moitié où tu veux en venir et tu t'es amha perdu dans la conversation.

Bref :

• là où la question des drivers peut être critique pour une base de données qui se crée, ils sont parti avec cette idée et ça a semble-t'il marché. Ça ne veut pas dire que c'est l'unique solution, c'est celle qu'ils ont choisi et tu peu difficilement avancer qu'ils ne sont pas arrivé à leurs fins
• pas mal de base de données utilisent ou proposent des protocoles textes sans que ça ne semble les rendre inutilisables (redis donc, mais aussi elasticsearch, couchdb, hazelcast a une API rest,…) comme quoi ça ne doit pas être aussi bloquant que cela
• tu sors des arguments qui se mordent la queue, tu n'a pas a le faire car des gens l'ont fais, merci, mais si tu regarde de plus prêt des langages relativement récents tu va voir que, le choix de base de données va d'un coup se limiter, tu as le droit de dire que tu t'en fout, mais c'est pas la question

Bon du coup j'en était à ma seconde tentative. La discussion n'est pas plus intéressante qu'auparavant. Si tu n'a rien de plus concret que ça a avancé je vais t'abandonner ici. Le fait qu'il ai débat et que je puisse te pointer des développeurs de différents projets qui ont un avis différents du tiens pourraient te montrer que, les choses ne sont pas aussi simples que tu l’avançais au départ (les protocoles textes et l'utilisation d'un serveur unique de base de données clef-valeur sont mauvais, avancé avec une certaines véhémence et aplomb), si ça n'a pas suffit je ne serais pas en mesure de te convaincre. Bref restons-en là.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll