Je partage l’inquiétude autour de Snap.



L’idée de départ était bonne et facilitait le travail des développeurs, le temps de pouvoir sortir des paquets dédiés aux différentes distrib.

Mais là son usage, qui plus est étendu par Canonical qui le met particulièrement en avant, est de plus en plus fourvoyé et pousse les développeurs à ne faire aucun effort sous prétexte de faire du multi-distrib…



Surtout qu’un snap reste largement plus consommateur de ressources et d’espace qu’un paquet dédié, (plus ou moins) optimisé pour la distribution sur laquelle il va tourner. Aucun système de dépendance etc.

Ça n’a aucun sens d’en promouvoir l’usage pour remplacer les paquets.



Ça me fait penser à tous ces outils (npm, etc) que l’on a en dev web et qui font que les sites/appli font ensuite un poids considérable, donc qui consomment toujours plus de ressources, sous prétexte de faciliter la vie du dev… Alors que le job d’un dev c’est aussi d’optimiser son code et faire en sorte qu’il consomme le moins possible.



Cette dérive est inquiétante je trouve (et illustre une perte de compétences quelques part). Surtout à une époque où l’on devrait réduire la consommation du code à des fins environnementales/énergétiques.

Pas compris ta réaction (oui je ne sais pas le sens de l’image) :)



Sans parler d’obsolescence, on est surtout dans une fuite en avant technologique. On a du matériel avec des capacités énormes mais le code, lui, devient de plus en plus crade et non-optimisé.

Quand je vois ce que l’on arrivait à faire il y a 20 ans avec du matériel limité, ou encore ceux que peuvent faire certains (comme le scène démo), je me dis qu’il y a là des questions à se poser sur comment on conçoit les logiciels à notre époque et les contraintes que l’on impose aux développeurs.



Je le vois tous au quotidien dans le développement web. Et dès que j’essaie de le faire comprendre autour de moi on me répond “on verra plus tard” ou encore “ça fonctionne ? Laisse alors. Si c’est pour gagner quelques ms/ko ça sert à rien” (sauf que “quelques” part ci par là, au final…).

Il faut aller toujours plus vite, donc on sort des outils qui permettent cela, et tant pis si la consommation en ressources augmente exponentiellement par manque d’optimisation du code, et donc augmente in fine l’impact énergétique/écologique.

TheKillerOfComputer a écrit :



Le dev n’a pas à optimiser son code pour tourner avec le moins de puissance possible, mais à faire en sorte que l’application fonctionne avec la majorité des machines en service aujourd’hui.





Faux. Du moins selon le point de vue que tu abordes.

Si tu es pour la débauche matérielle pour faire qu’un simple “Hello World!” puisse s’afficher, en effet.

Si tu es contre et que tu te dis que le code doit laisser une empreinte la plus petite possible, pour au passage tourner sur le plus grand nombre de machines possibles, alors le dev doit optimiser son code.



Et perso je suis dans cette seconde optique.

Je ne l’étais pas forcément au début de ma carrière de dev. Mais mon expérience et les projets sur lesquels j’ai bossé depuis, plus la veille que j’effectue, m’ont fait prendre conscience de cet effet de surenchère et de débauche, avec un code qui consomme toujours plus pour arriver à un même résultat qu’il y a 10 ans ou plus.



Tout cela sous prétexte de faciliter le dev (ce qui n’est pas toujours vrai et reste tout relatif), et surtout réduire les coûts… donc du business avant tout.

Pas pour faciliter la vie de l’utilisateur.