Ca inclue d'utiliser des langages réputés pour leur performance malgré leur difficulté d'apprentissage: C, C++, Rust, pascal, ... au lieu de python, javascript, html5/css4 (je suis p'tet outdated, on est p'tet à html10/css6 maintenant) qui bouffent des ressources de dingue.
Prend un dev de base. Fait lui pondre le même code en C et en Python. En C il va devoir réinventer la roue (très mal) et te sortir un algo tout pété en O( n999999 ), en Python il va juste utiliser la lib standard, optimisée et qui travaille en C au final.
On peut aussi parler, ben oui, des systèmes d'init. Pourquoi gâcher 30 megs de rss dans systemd (de mémoire, ils ont p'tet opti depuis) quand runit (par exemple) lié en static ne consomme que 4 kilos?
Faut savoir configurer systemd, tu peux désactiver pas mal de choses si t’utilises pas.
runit n’est PAS un système d’init mais un hyperviseur de service qui propose éventuellement un init. Je boycotte systemd parce que je boycotte tout système d’init qui veut faire autre chose que de l’init. Un hyperviseur de service c’est déjà bloated pour un usage perso (ça sert à assurer la disponibilité des services parce que le noyau Linux est tellement foireux qu’il peut te kill le ssh de ton serveur chéri à 783km de là...). J’utilise l’init historique SysV qui est amplement suffisant (RSS : 1,6K, ton truc est clairement bloated ×ばつ2,5)
Sur un poste fixe le hardware change pas, j’imagine que tu as tout ton /dev en static, plutôt que ce bloat de udevd qui tourne en permanence et bouffe du CPU pour rien à chaque démarrage.
Et encore tu semble ne pas connaître les joie du devops où pour compiler un 'Hello world!' il faut faire un commit/push sur un serveur, virtualisé of course, de dépôt qui va lancer un outil d’automatisation de chaîne d’intégration continue qui va demander à un gestionnaire de conteneurs de démarrer des applications isolées dans un conteneur sur le cloud, donc à travers le réseau sur une machine elle-même virtualisée, pour ensuite récupérer le résultat de la compilation qui sera pris en charge pour le déploiement sur la machine de test, elle même virtualisée et remontée à chaque fois.
Mais, magie de l’informatique moderne! tout est fait en toute transparence pour le dév ! Il a même le temps d’aller se faire un (削除) petit (削除ここまで)gros kawa en attendant.
[^] # Re: Pas besoin de lire...
Posté par ml . En réponse au lien Informatique frugale : à quand un numérique compatible avec les limites planétaires ? . Évalué à 4. Dernière modification le 26 mai 2023 à 08:47.
Prend un dev de base. Fait lui pondre le même code en C et en Python. En C il va devoir réinventer la roue (très mal) et te sortir un algo tout pété en O( n999999 ), en Python il va juste utiliser la lib standard, optimisée et qui travaille en C au final.
Et encore tu semble ne pas connaître les joie du devops où pour compiler un 'Hello world!' il faut faire un commit/push sur un serveur, virtualisé of course, de dépôt qui va lancer un outil d’automatisation de chaîne d’intégration continue qui va demander à un gestionnaire de conteneurs de démarrer des applications isolées dans un conteneur sur le cloud, donc à travers le réseau sur une machine elle-même virtualisée, pour ensuite récupérer le résultat de la compilation qui sera pris en charge pour le déploiement sur la machine de test, elle même virtualisée et remontée à chaque fois.
Mais, magie de l’informatique moderne! tout est fait en toute transparence pour le dév ! Il a même le temps d’aller se faire un
(削除) petit (削除ここまで)gros kawa en attendant.