Journal DD: entre le marteau et l'enclume

Posté par Snark le 02 août 2020 à 14:01. Licence CC By‑SA.

Étiquettes :

août

2020

Salut Diego,

j'ai vu que certains se plaignent du manque de journaux plus orientés vers la technique—du coup je vais raconter quelques petites choses sur ma modeste expérience de DD (développeur debian).

Un DD, c'est quelqu'un qui empaquette des bouts de logiciel puis qui maintient ces paquets à jour, pour des correctifs ou pour de nouvelles versions ; une sorte d'interface entre les utilisateurs en aval pas forcément versés dans la technique et les développeurs en amont qui sont eux très au point dessus. D'un côté, on reçoit les logiciels de l'amont et on les met à disposition des utilisateurs de façon à ce que l'installation et l'utilisation soient les plus simples possibles ; d'un autre côté quand les utilisateurs ont un souci, on est en première ligne pour faire le tri dans les rapports, et on essaie d'obtenir le maximum de renseignements pour faire une remontée la plus qualitative possible pour simplifier la vie en amont.

Suivant les sujets, le DD est lui même plus ou moins côté utilisateur ou côté développeur. Par exemple, sur les projets en C/C++, je suis en général capable de faire beaucoup de choses tout seul ; quand il s'agit de java ou de JavaScript, je suis complètement dans les choux.

C'est parfois gratifiant : on repère un problème, on bosse dessus avec les développeurs en amont, et la nouvelle version arrive et passe impeccablement la totalité des tests unitaires sur toutes les architectures qui tiennent la route—c'est très souvent le cas avec mes paquets pour FLINT ou EClib.

D'autres fois, c'est moins bien : même avec l'aide amont, on ne s'en sort pas, parce qu'on n'arrive pas à mettre le doigt sur le nœud du problème, comme avec Giac, qui est cassé sur architecture S390X depuis quelques semaines. J'ai plusieurs fois relevé le gant et essayé avec B.Parisse de trouver où les choses dérapent, mais sans succès jusqu'à présent. Après quelques jours de pause, je pense retenter demain : prendre du large aide souvent.

Il arrive aussi que l'amont, sans être hostile, se montre un peu énervant de mollesse : quand en novembre 2017 j'ai vu que le paquet Scilab était abandonné par son DD, j'ai repris le flambeau ; une Debian sans Scilab aurait été un scandale! Il n'empêche que c'est un des paquets sur lequel j'ai le plus de rustines, car malgré mes remontées, l'intégration ne se fait pas… du coup j'ai souvent des coups de déprime à son sujet et je me demande parfois si je ne devrais pas passer la main.

Enfin, parmi les cas les plus frustrants, il y a par exemple ast-types : c'est un projet en JavaScript, dont je ne sais ni exactement à quoi il sert ni comment il marche. Je suis tombé dessus parce que je visais un truc, qui nécessitait un bidule qui avait besoin de ce machin, donc je suis arrivé assez loin de mes centres d'intérêt et de compétence. À un moment, le développeur s'est mis à utiliser typescript. [Et du coup : j'ai empaqueté TypeScript pour Debian : toujours plus loin!] Le souci est que TypeScript était tout beau et tout nouveau, donc pas bien stabilisé. Et depuis un certain nombre de versions, le code dans ast-types n'est plus compatible. La situation est donc la suivante :
1. le développeur d'ast-types fait la sourde oreille. Il pré-mâche ses sources pour les utilisateurs avec son vieux compilo tout moisi, rend disponibles les sources et la régurgitation ;
2. les utilisateurs d'ast-types utilisent le résultat de la pré-compilation, sortent de nouvelles versions, construisent sur ce qui fondamentalement est du vide. Tant que ça marche, ça leur va!
3. je vois bien que les sources ne sont pas utilisables, donc je reste coincé, très ennuyé à l'idée que quelqu'un puisse avoir besoin d'une version plus récente—et cela non seulement sur ce paquet, mais sur les paquets tiers qui en dépendent!

Bref, il y a un peu de tout, c'est très enrichissant en général, et on a l'impression de faire œuvre utile.

Voilà, Nal ; j'espère que ce petit aperçu de l'activité d'un DD va étancher ta soif de contenu plus technique, tout en restant accessible au plus grand nombre.

À bientôt mon Diego!

PS1: pourquoi Diego là où d'autres saluent Nal? C'est le même! Ce cher Diego Nal, un peu de travers mais tellement sympathique!

# Bon courage

Posté par _kaos_ le 02 août 2020 à 15:13. Évalué à -10. Dernière modification le 02 août 2020 à 15:15.

Salut,

Je crois que je me suis arrêté là dans la lecture attentive :

je vais raconter quelques petites choses sur ma modeste expérience

Merci pour ce retour, et continue d'être DD !

C'est bien d'être modeste dans ses contributions.

Matricule 23415
# business

Posté par ckiller le 02 août 2020 à 15:32. Évalué à 10.

Les bibliothèques javascript, python… mono mainteneur a base de github, on pourrait se poser la question d'intégrer ca dans debian.

Rien n'indique la pérennité et de la volonté de s'inscrire dans la durée.

Une fondation "à la apache" prenant en charge la maintenance de ce genre de paquet certe utile, parfois vital ca serait intéressant.

Quand à Scilab, leur refus d'intégration vient probablement du fait que c'est un fremium dont les vrais produits sont portés par ESI Group. et ils n'ont probablement que faire d'intégrer des patchs permettant une meilleure exploitation de logiciel open source.

En bref, créer un paquet sans, et parfois contre upstream, c'est voué à l'échec.

Les projets ne prenant pas en compte certaines remontées d'un projet majeur comme debian (bon, oui, il y a déjà eu des abus) ne devraient pas compter le support de la communauté.
- [^] # Re: business
  
  Posté par Anonyme le 02 août 2020 à 16:56. Évalué à 10.
  
  Une fondation "à la apache" prenant en charge la maintenance de ce genre de paquet certe utile, parfois vital ca serait intéressant.
  
  On pourrait lui donner une constitution, une hiérarchie de mainteneurs avec un « chef » à leur tête, élu au suffrage universel parmi les développeurs. On pourrait même appeler ça Debian.
  
  Parce que même si c’est pas le but de Debian, les mainteneurs ont totalement le droit de corriger des bugs avant que ça ne soit fait upstream.
  - [^] # Re: business
    
    Posté par barmic 🦦 le 03 août 2020 à 10:06. Évalué à 6.
    
    On pourrait lui donner une constitution, une hiérarchie de mainteneurs avec un « chef » à leur tête, élu au suffrage universel parmi les développeurs. On pourrait même appeler ça Debian.
    
    Pas vraiment. L'objectif n'a rien à voir. Debian ne filtre pas ses paquets. Si c'est libre et que le paquet est fait correctement, il n'y a pas de raison que les FTP masters ne l'intègrent pas.
    
    Là il est question de garantir certaines propriétés. C'est exactement ce que font apache et eclipse lors de l'incubation. Ils vérifient le fonctionnement des projets (gouvernance, licence, nombre de contributions,…).
    
    Je trouve dommage que ce ne soit pas vers ça que se tourne GNU puisque c'est exactement ce qui est important pour eux et ils pourraient fournir toute une infra FSF (hébergement, support légal,…). Actuellement il y a un répertoire de projets, mais je ne sais pas trop personnellement ce que ça signifie d'être là dedans. C'est dommage pour des gens qui veulent mettre en en avant une certaine idée de ce qu'est un projet libre.
    
    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
    - [^] # Re: business
      
      Posté par gouttegd le 03 août 2020 à 15:48. Évalué à 7.
      
      Debian ne filtre pas ses paquets.
      
      Euh, si, un peu quand même.
      - [^] # Re: business
        
        Posté par barmic 🦦 le 03 août 2020 à 16:05. Évalué à 4.
        
        Ça reste tout à fait minimaliste comme filtrage. En tout cas bien loin de ce qui est proposé plus haut.
        
        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# rustines++

Posté par NicolasP le 02 août 2020 à 19:33. Évalué à 10.
Et depuis un certain nombre de versions, le code dans ast-types n'est plus compatible

Si tu aimes les rustines, tu peux changer la ligne incriminée par :
```
(builtInTypes[name] as any)= type;
```
Ça indique au compilateur de ne pas vérifier le type de builtInTypes[name]. Du coup, si le code initial est fonctionnel avec une version précédente de tsc, il devrait toujours l'être avec une version plus récente de tsc.

En tout cas, merci pour ton courage et celui de tes semblables !
- [^] # Re: rustines++
  
  Posté par Snark le 02 août 2020 à 22:29. Évalué à 8.
  
  Ça améliore nettement la situation, mais ce n'est toujours pas parfait ; ça plantouille encore joyeusement à divers endroits après. À vue de nez, je dirais qu'il y a deux types de soucis : un, le code n'est pas assez défensif (cherche le type de foo.constructor sans vérifier si ça existe!) et deux, il me manque visiblement des déclarations de type…
  
  En tout cas merci : du coup ça me motive pour aller gratter un peu et améliorer la situation!
  - [^] # Re: rustines++
    
    Posté par Nicolas Boulay (site web personnel) le 03 août 2020 à 10:38. Évalué à 3.
    
    Question bête vu que la mode docker est de faire un gros paquet avec toutes les dépendances, vu que ast-type ne t'es utile que pour un seul logiciel, ne serait-il pas possible d'utiliser le code moisi généré et de le livrer avec le logiciel que tu visais en premier ?
    
    "La première sécurité est la liberté"
    - [^] # Re: rustines++
      
      Posté par barmic 🦦 le 03 août 2020 à 10:41. Évalué à 6. Dernière modification le 03 août 2020 à 10:41.
      
      Je crois pas que ça soit acceptable pour un paquet officiel Debian…
      
      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
    - [^] # Re: rustines++
      
      Posté par ʭ ☯ le 03 août 2020 à 17:21. Évalué à 6.
      
      Une distribution libre ne doit jamais fournir un binaire issu de code qui ne compile pas avec la distribution, sinon on perd la liberté de modifier!
      
      ⚓ À g'Auch TOUTE! http://afdgauch.online.fr
      - [^] # Re: rustines++
        
        Posté par Nicolas Boulay (site web personnel) le 03 août 2020 à 17:39. Évalué à 3.
        
        Je comprends l'idée mais si cela fait parti du logiciel d'origine ?
        
        "La première sécurité est la liberté"
        
        [^] # Re: rustines++
        
        Posté par ʭ ☯ le 03 août 2020 à 18:53. Évalué à 4.
        
        Bin non. C'est le principe des firmwares distribués comme blobs.
        Ainsi pour parler de ce que je connais bien Mageia a un dépôt "nonfree" pour tout ce qui n'est pas libre, et cela inclut des logiciels libres précompilés.
        
        ⚓ À g'Auch TOUTE! http://afdgauch.online.fr
  - [^] # Re: rustines++
    
    Posté par NicolasP le 03 août 2020 à 11:14. Évalué à 5. Dernière modification le 03 août 2020 à 11:14.
    Ça améliore nettement la situation, mais ce n'est toujours pas parfait ; ça plantouille encore joyeusement à divers endroits après.
    
    Du coup, j'ai cloné le repo sur mon PC pour aller un peu plus loin.
    Si tu veux une rustine rapide, tu peux encore caster soit en any pour ignorer le typage, soit en {} car c'est de ça qu'il s'agit ici.
```
 if (example  && typeof (example as {}).constructor === "function") {
      builtInCtorFns.push((example as {}).constructor);
      builtInCtorTypes.push(type);
    }
```
    Une fois cette correction et la précédente effectuées, chez moi ça compile avec TSC 3.9.7.
    Après si tu veux une correction un peu plus propre, je pense qu'il faudrait splitter la fonction en 2, l'une qui considère que T extends {} et l'autre qui ne prend pas d'example. Par contre, ça fait un patch plus gros à maintenir.
    Si ça t'intéresse quand même et que tu as forké le code dans github (ou n'importe quel repo git accessible) je peux te faire une PR.
    - [^] # Re: rustines++
      
      Posté par barmic 🦦 le 03 août 2020 à 11:28. Évalué à -1.
      Après si tu veux une correction un peu plus propre, je pense qu'il faudrait splitter la fonction en 2, l'une qui considère que T extends {} et l'autre qui ne prend pas d'example.
      
      Je suis sincèrement pas contre les anglicismes, mais « étends » et « exemple »¹ sont pas mal dans le contexte :)
      
      mais là je ne suis pas certains, je ne sais pas ce qu'est un "example" en typescript et une recherche ne me donne que des exemples de code… ↩
      
      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
      - [^] # Re: rustines++
        
        Posté par NicolasP le 03 août 2020 à 11:44. Évalué à 4. Dernière modification le 03 août 2020 à 11:47.
        
        Je suis sincèrement pas contre les anglicismes, mais « étends » et « exemple »1 sont pas mal dans le contexte :)
        
        J'avoue que j'utilise souvent des anglicismes, surtout quand je me mets à discuter code. Mais sur tes 2 exemples, je ne pense pas avoir abusé.
        
        "T extends {}" est littéralement le code TypeScript à utiliser et "example" est le nom du paramètre choisi par le développeur initial. Les traduire en français nuirait donc à la compréhension.
        
        [^] # Re: rustines++
        
        Posté par barmic 🦦 le 03 août 2020 à 11:56. Évalué à 2.
        
        "T extends {}" est littéralement le code TypeScript à utiliser
        
        C'est probablement moi, j'ai tendance à vocaliser ce que je lis et c'est un mot sur le quel je butte. Je sais que c'est un mot clef du langage, mais ce n'est pas un bout de code que tu as donné ce mot clef est un verbe de ta phrase.
        
        "example" est le nom du paramètre choisi par le développeur initial
        
        D'acc je comprends mieux et je suis tout à fait d'accord.
        
        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
        
        [^] # Re: rustines++
        
        Posté par Graveen le 03 août 2020 à 16:11. Évalué à 3.
        
        Je pense que excepté "splitter", le reste se justifie :)
        (si on veut reprendre ta petite critique, perso je n'ai pas tiqué du tout)
        
        [^] # Re: rustines++
        
        Posté par barmic 🦦 le 03 août 2020 à 16:19. Évalué à 2. Dernière modification le 03 août 2020 à 16:19.
        
        Hé hé tu vois je ne l'avais même pas vu… Comme quoi
        
        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
    - [^] # Re: rustines++
      
      Posté par Snark le 03 août 2020 à 17:17. Évalué à 3.
      
      Ok, je suis toujours coincé, mais a priori c'est dû à diverses causes externes (état de babel dans Debian, essentiellement).
      
      Ce serait bien de proposer le patch à upstream :-)
      
      Merci!
    - [^] # Re: rustines++
      
      Posté par vv222 le 06 août 2020 à 15:20. Évalué à 3.
      
      Pour éviter que tes correctifs finissent oubliés dans les commentaires de ce journal, ce serait probablement une bonne idée de les soumettre par ici : https://salsa.debian.org/js-team/node-ast-types
# Débuts

Posté par pieq (site web personnel, Mastodon) le 03 août 2020 à 06:13. Évalué à 10.

En voyant DD dans le titre, j'ai cru que ça allait parler de l'utilitaire Unix pour copier des fichiers :)

Merci pour ce retour d'expérience, c'est très intéressant. Comment as-tu commencé ? Combien de paquets est-ce que tu maintiens maintenant ?
# Scilab

Posté par Sylvestre Ledru (site web personnel) le 03 août 2020 à 09:48. Évalué à 7.

j'ai repris le flambeau ; une Debian sans Scilab aurait été un scandale!

Merci encore ;)
# Scilab

Posté par barmic 🦦 le 03 août 2020 à 10:47. Évalué à 5.

Il arrive aussi que l'amont, sans être hostile, se montre un peu énervant de mollesse : quand en novembre 2017 j'ai vu que le paquet Scilab était abandonné par son DD, j'ai repris le flambeau ; une Debian sans Scilab aurait été un scandale! Il n'empêche que c'est un des paquets sur lequel j'ai le plus de rustines, car malgré mes remontées, l'intégration ne se fait pas… du coup j'ai souvent des coups de déprime à son sujet et je me demande parfois si je ne devrais pas passer la main.

Tu as regardé s'il était inclut dans d'autres distributions et comment est-ce que ça se passe pour eux ? Peut être qu'ils maintiennent eux aussi des patchs ou qu'ils seraient intéressés par les tiens ? J'ai toujours en tête Go-oo qui a était un précurseur à LibO.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
- [^] # Re: Scilab
  
  Posté par Thierry Thomas (site web personnel, Mastodon) le 03 août 2020 à 15:36. Évalué à 6.
  
  Pour comparer avec ce qu’il se passe ailleurs, j’aime beaucoup Repology.
  
  Par ex. pour Scilab ça donne cette liste, à partir de laquelle on a accès à l’état des différents paquets.
  - [^] # Re: Scilab
    
    Posté par ZeroHeure le 03 août 2020 à 17:14. Évalué à 5. Dernière modification le 03 août 2020 à 17:14.
    
    pkgs.org est pas mal aussi, plutôt pour les administrateurs qui trouvent beaucoup de détails sur les paquets.
    
    "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
- [^] # Re: Scilab
  
  Posté par ZeroHeure le 03 août 2020 à 17:18. Évalué à 7. Dernière modification le 03 août 2020 à 17:19.
  
  J'utilise SuSE OpenBuildService sur lequel on peut empaqueter pour plusieurs distributions et créer des branches comme on veut. C'est effectivement très pratique pour mutualiser le travail en évitant que chacun maintienne ses patches dans son coin. En plus on peut créer des services qui vont, par exemple, suivre les versions amonts, récupérer des patches sur un autre dépôt, …
  Les distros gagneraient à centraliser les paquets patchés sur une telle plateforme, quitte à ce qu'elle ne soit qu'une étape intermédiaire.
  
  "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
# Highway to dependency hell

Posté par devnewton 🍺 (site web personnel) le 03 août 2020 à 17:57. Évalué à 8.
L'industrie a beaucoup de chemin à faire pour avoir des applis stables. Il faudrait au moins:
- des langages qui ne demandent pas de passer 42% du temps pour compiler un projet. Bonnet d'âne: C. Bon élève: Go.
- des libs et API de bases stables. Bonnet d'âne: Node.js. Bon élève: Java.
- Ne pas dépendre d'un énorme et gigantesque runtime et même d'un petit en fait. Bonnet d'âne: Java. Bon élève: ???
En attendant une chanson pour te donner du courage: https://youtu.be/Ai5TuhlWMwk

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
- [^] # Re: Highway to dependency hell
  
  Posté par barmic 🦦 le 03 août 2020 à 18:11. Évalué à 4.
  
  Ne pas dépendre d'un énorme et gigantesque runtime et même d'un petit en fait. Bonnet d'âne: Java. Bon élève: ???
  
  Je me suis toujours dis que le JDK était gros puis, un jour, j'ai installé beam et son écosystème :)
  
  https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
- [^] # Re: Highway to dependency hell
  
  Posté par ʭ ☯ le 03 août 2020 à 18:54. Évalué à 6.
  
  Je pense que le C est un bon candidat pour le dernier bon élève, comme ça tu rentres dans les dépendances circulaires ;-)
  
  ⚓ À g'Auch TOUTE! http://afdgauch.online.fr
- [^] # Re: Highway to dependency hell
  
  Posté par groumly le 03 août 2020 à 21:44. Évalué à -7.
  
  L’industrie en général, ça fait 15 ou 20 ans qu’elle a résolut le problème de stabilité.
  L’os fournit les api nécessaires aux développeurs tiers pour faire ce qu’ils ont à faire, maintient la compat binaire pour que l’existant continue de marcher, tout en facilitant l’intégration d’api tierces pour couvrir les fonctionnalités que l’os ne fournit pas.
  
  Ça permet de laisser les développeurs faire ce qu’ils savent faire (leur appli métier) et les devs système faire ce qu’ils savent faire (developer une plateforme).
  Ça évite de devoir repackager 15 fois les meme choses, ça laisse les devs tiers gérer leurs releases comme ils l’entendent (ce qui supprime le besoin de back ports au passage, et évite à upstream de se traîner des casseroles parce que Debian ou autre distribue une version vielle de plusieurs mois/années), et ça évite des situations ubuesques ou un mainteneur se retrouve à empaqueter un soft sans vraiment savoir ce qu’il est censé faire.
  
  Alors, oui, ok, DLL hell, mais ce problème est largement résolu depuis Windows 2000.
  J’imagine que ce modèle de distribution centralisé sur la distro était intéressant en 2000, mais je trouve sidérant qu’on y soit encore 20 ans plus tard, vu le succès qu’ont eu Windows et macOS de leur côté.
  
  Donnez au dev tiers les moyens de packager leur softs eux même, ça sera bien plus efficace pour tout le monde.
  
  Linuxfr, le portail francais du logiciel libre et du neo nazisme.
  - [^] # Re: Highway to dependency hell
    
    Posté par devnewton 🍺 (site web personnel) le 04 août 2020 à 09:54. Évalué à 6.
    
    L’os fournit les api nécessaires aux développeurs tiers pour faire ce qu’ils ont à faire
    
    Par exemple pour les IHM, tous les OS fournissent GTK en standard, heu non en fait c'est Qt, ha mince, non bon on va utiliser directement X11, bon non plus voilà Wayland, zut, je vais faire de l'opengl direct alors, ah non il y a des OS sans et des variantes ES…
    
    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
    - [^] # Re: Highway to dependency hell
      
      Posté par groumly le 04 août 2020 à 16:29. Évalué à 2.
      
      oui, c’est exactement ce que je dit. Sous Linux, sorti de la libc, t’as pas la moindre idée de ce qui va être dispo, ni dans quelle version.
      
      Sous Windows, t’es à peu près sur que wpf existe. Sous macOS, t’es certain que Cocoa existe.
      Tu peux facilement utiliser des features récentes de ces frameworks et toujours pondre un binaire qui tourne sur des version antérieures.
      
      Si t’utilises Qt, tu peux facilement le bundler toi même dans ton installeur, sans avoir à te demander quelle version le packageur a spécifiquement inclus dans chacune de la dizaine/vingtaine de distro/version de distro que tu doit supporter, et sans craindre que le packageur vienne patcher ton appli à la truelle pour le faire marcher avec une vieille version de la libraire.
      
      Linuxfr, le portail francais du logiciel libre et du neo nazisme.
- [^] # Re: Highway to dependency hell
  
  Posté par SpaceFox (site web personnel, Mastodon) le 04 août 2020 à 10:19. Évalué à 2. Dernière modification le 04 août 2020 à 10:19.
  - des libs et API de bases stables. Bonnet d'âne: Node.js. Bon élève: Java.
  - Ne pas dépendre d'un énorme et gigantesque runtime et même d'un petit en fait. Bonnet d'âne: Java. Bon élève: ???
  Il y a bien des techniques pour diminuer sensiblement la taille du runtime de Java (notamment en le compilant avec GraalVM) mais l’effet de bord c’est que… ça devient vraiment lent à compiler :(
  
  La connaissance libre : https://zestedesavoir.com
  - [^] # Re: Highway to dependency hell
    
    Posté par barmic 🦦 le 04 août 2020 à 10:51. Évalué à 3.
    
    graalvm c'est vraiment particulier. C'est presque un fork de java qui ne peux compiler qu'un sous-ensemble du langage.
    
    Par contre en standard, depuis java9 tu as la modularisation du jdk avec jlink tu peux créer un jdk sans les parties qui ne t'intéressent pas et c'est une étape que tu ne fais qu'une fois et si d'aventure tu change les module du jdk dont tu as besoin, mais ça ne devrait pas arriver tous les 4 matins.
    
    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
    - [^] # Re: Highway to dependency hell
      
      Posté par SpaceFox (site web personnel, Mastodon) le 04 août 2020 à 10:53. Évalué à 3. Dernière modification le 04 août 2020 à 10:53.
      
      Exact, le problème c’est qu’il y a encore trop de dépendances qui ne fonctionnent pas avec le système de modules :(
      
      C’est clair que GraalVM n’est pas adapté à tout (en particulier dès qu’il y a de l’introspection, c’est la mort).
      
      La connaissance libre : https://zestedesavoir.com
      - [^] # Re: Highway to dependency hell
        
        Posté par barmic 🦦 le 04 août 2020 à 11:08. Évalué à 3.
        
        Oui à savoir aussi pour ceux qui cherchent la perf que graalvm n'est pas forcément plus performant. Il démarre plus et à une empreinte mémoire plus faible, mais sur des charges qui créent/détruisent un certain nombre d'objets, le fait que le gc va se débrouiller pour compacter la mémoire peut devenir vraiment utile.
        
        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
    - [^] # Re: Highway to dependency hell
      
      Posté par wismerhill le 04 août 2020 à 11:19. Évalué à 3.
      
      Par contre en standard, depuis java9 tu as la modularisation du jdk avec jlink tu peux créer un jdk sans les parties qui ne t'intéressent pas et c'est une étape que tu ne fais qu'une fois et si d'aventure tu change les module du jdk dont tu as besoin, mais ça ne devrait pas arriver tous les 4 matins.
      
      Ça ce n'est intéressant que pour les développeurs qui veulent fournir un binaire prêt à l'emploi, sans devoir demander d'installer un JDK complet (car il n'y a plus de JRE), c'est un peu comme compiler en statique, ou fournir une image pour une technologie de conteneur quelconque.
      Ce n'est pas destiné aux distributions, où on veut au contraire que tous les programmes java utilisent le même JDK installé globalement, et ne surtout pas devoir recompiler chaque programme si on met à jour ce JDK.
      - [^] # Re: Highway to dependency hell
        
        Posté par barmic 🦦 le 04 août 2020 à 11:52. Évalué à 2.
        
        ne surtout pas devoir recompiler chaque programme
        
        Pourquoi ? Parce que la machine de build est sous l'eau ? Ça je peux le comprendre mais par principe, sur changement d'une dépendance faire du rebuild n'est pas une mauvaise chose au contraire. Ils n'ont d'ailleurs pas le choix avec les programme go.
        
        Je comprends mieux la volonté de partager et c'est un choix, tu as le même avec toute dépendance quelque soit la techno¹, est-ce que tu préfère optimiser pour chaque cas ou utiliser une solution réutilisable mais moins optimale.
        
        Mais en soit rebuilder les logiciels c'est tout de même pour ça qu'ils utilisent du logiciel libre et tu as des distributions qui font ce choix. On pense bien sûr à gentoo, mais elle n'est pas seule. Et tu peux très bien demander à ta gentoo de compiler en statique il me semble.
        
        C'est une décision qui a des impacts on est d'accord, mais une décision et pas une obligation.²
        
        Mais au final le jdk est probablement plus à comparer aux runtimes de flatpak, c'est quelque chose qui arrive batteries inclues (qu'il ne faut pas comparer avec juste la libstdc++ ou gtk) et sa taille n'est plus si grande.
        
        si tu compile tes logiciels C++ en statique, tu va pouvoir bénéficier d'une élimination de code mort plus agressive. ↩
        
        après c'est un dogme d'ops (dont on a déjà beaucoup parlé ici) de vouloir changer les dépendances des logiciels sans repasser par les développeurs parce que de toute manière les développeurs ne comprennent rien aux problèmes des ops ↩
        
        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Merci !

Posté par vv222 le 04 août 2020 à 08:58. Évalué à 10.

Je profite de ce journal pour remercier tous les mainteneurs de paquets au sein de nos distributions, qui en font des systèmes aussi agréables à utiliser ;)

Et tout particulièrement Phil Morrell, qui ne s’est pas contenté de proposer l’intégration de ./play.it aux dépôts Debian mais a travaillé avec nous à la mise en place d’un système de build facilitant son intégration à un système de paquets. Alors que je croyais que l’intégration aux dépôts Debian était un processus long et complexe, il en a fait une formalité vite expédiée.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.