pour résumer:
- ça a changé
- j'aime pas, je préférais avant, vous comprenez mon bon monsieur, de mon temps…
- de toute façon j'utilise que des *BSD maintenant.
J'aime bien l'argument sur les noms d'interfaces… Il a rien regardé au pourquoi et ne s'est pas du tout dis que c'est déjà la stratégie des bsd et donc que eth0 n'est pas unix, mais une spécificité de linux. C'est beau les arguments bien construit 🙂
Pour le coup, de ce côté, son discours est très étrange…
D'une part, il râle parce qu'avant il fallait jouer avec udev pour avoir des noms fiables:
Le noyau Linux a eu la bonne idée depuis des lustres de nommer les interfaces Ethernet en eth. Premier problème, d'une version à une autre, l'énumération ne se faisait pas forcément dans le même sens.
Puis il râle que udev renomme les interfaces (en accusant une MàJ kernel, quand même…)
Plus récemment, les noms de périphériques ont été changés et ce qui était eth0 a pu devenir au gré d'une mise à jour de noyau enp0s31f6, ce qui était très pratique pour les gens qui utilisaient un firewall bloquant tout par défaut sur une machine à distance. Mais encore, en lisant la documentation et en acceptant d'ouvrir un peu tous les ports le temps de la migration, il était possible de s'en tirer.
Et enfin il râle que systemd re-renomme les interfaces:
Vous noterez qu'il n'y a plus de eth0 mais un lan0. Pourquoi ? Parce que cette saleté de systemd a décidé depuis sa dernière mouture d'entrer en conflit avec le renommage des interfaces par udev
Bon, en fait, je crois que son propos ici c'est que c'est le kernel qui devrais le faire. Ce qui est en soit défendable. Personnellement je ne sais pas vraiment comment udev fait pour exposer les noms des interfaces réseau, donc je ne jugerai pas sur ce point (faudrait que je creuse le sujet un jour).
C'est un constat certes sévère, mais que je partage un peu, en séparant toutefois 2 cas d'utilisation, la vision "serveur/sysadmin" et "station/utilisateur".
Est-ce que le principe de (relative) simplicité qui prévalait auparavant est devenu obsolète? Ou alors c'est ma réticence au "changement" qui m'aveugle?
J'ai du mal à mesurer ce que j'ai gagné à utiliser entre autres quotidiennement des meta-commandes comme systemctl, journalctl, firewall-cmd etc pour gérer des services allant des plus essentiels au système jusqu'aux interfaces réseaux/dns, chercher dans les logs, écrire des règles de filtrage….
Des commandes qui font tellement de trucs que l'indispensable parcours des pages de manuel est devenu une course d'obstacles.
Bon,ceci étant dit, s'il faut en passer par là pour simplifier la tâche des développeurs du noyau, pour avoir un système plus universel, prenant en charge une plus grande diversité d'architectures, un meilleur support matériel, un système plus optimisé et économe en ressources, c'est un sacrifice auquel je consentirais de bonne grâce.
Mais est-ce bien le but poursuivi? Il est vrai que pour des serveurs qui ne sont pas destinés à être rebootés 5 fois par jour, gagner 5s sur un démarrage n'est pas un gain absolument indispensable (surtout quand le hardware lui-même passe par 20 étapes de vérification de tout composant allant du backplane aux contrôleurs raids en passant par la RAM et les ventilos à chaque démarrage :-))
Ce qui me laisse un poil optimiste malgré tout c'est que des dérivées de Debian comme Emmabuntüs me permettent encore de donner un second souffle à des PCs et Macs relativement anciens (>=11 ans), de les confier aux gamins ou aux anciens de mon entourage avec une "notice" minimale tenant sur 2 feuilles A4 leur permettant de vaquer à leurs occupations numériques habituelles, et nécessitant peu d'intervention par la suite.
J'ai du mal à mesurer ce que j'ai gagné à utiliser entre autres quotidiennement des meta-commandes comme systemctl, journalctl, firewall-cmd etc pour gérer des services allant des plus essentiels au système jusqu'aux interfaces réseaux/dns, chercher dans les logs, écrire des règles de filtrage….
Peut être que tu n'as rien gagné toi personnellement dans l'affaire, mais d'autres oui. On a tous nos besoins, certains sont très contents de fonctionner comme dans les années 90 car leur besoin est satisfait ainsi et ils ont leur habitude.
Mais le monde a changé, de nouveaux besoins sont apparus et de nouvelles idées ont émergé. C'est un peu dommage de croire qu'on devrait tout figer dans le marbre dans un tel contexte.
D'ailleurs UNIX a beaucoup progressé entre 1970 et 1990, pour tenir compte des changements dans le milieu : réseau, interface graphique, internationalisation, etc. Ses concepteurs ont préféré faire Plan 9 plutôt que contribuer à changer UNIX car ses défauts étaient trop profonds pour corriger par couche successive.
Tout cela montre que croire que UNIX a atteint une forme de perfection dans les années 90 et ne devrait plus bouger est une chimère. Cela ne reflète pas la réalité historique de l'informatique ou d'UNIX.
Mais est-ce bien le but poursuivi? Il est vrai que pour des serveurs qui ne sont pas destinés à être rebootés 5 fois par jour, gagner 5s sur un démarrage n'est pas un gain absolument indispensable (surtout quand le hardware lui-même passe par 20 étapes de vérification de tout composant allant du backplane aux contrôleurs raids en passant par la RAM et les ventilos à chaque démarrage :-))
Le but de systemd n'a jamais été de gagner de la vitesse. C'est une conséquence de son architecture qui conduit à une amélioration de cette vitesse. Il ne faut pas inverser la causalité ici.
Et d'ailleurs, l'article critique systemd en contexte embarqué car soit disant ça bouffe des ressources. Et non.
Je suis développeur embarqué, et j'ai travaillé sur des cartes qui ont systemd et ça se comporte très bien. Pourtant avec 256 Mio de RAM (bien loin donc du 1 Gio nécessaire selon lui). Car en réalité oui systemd parallélise les lancements donc ça bouffe un peu en RAM, mais dans ce contexte les services restent petits et ne sont donc pas un problème.
Et je suis justement très content de gérer un projet embarqué avec systemd. Cela demande un peu plus de ressources que SysV c'est vrai (mais dans pas mal de projets ce n'est pas un problème). Mais cela apporte tellement à côté comme le relancement automatique du service dans certaines conditions ou la gestion des dépendances qui rend cela bien plus agréable à faire qu'à l'ancienne. Je gagne personnellement du temps de développement et en qualité de service du produit.
Bref, dans cet article je vois surtout une forme de résistance au changement. Alors certes il étaye son point de vue, je le comprends, mais il regarde cela uniquement sous le prisme de ses propres besoins en oubliant qu'il n'est pas seul dans ce monde.
Et je trouve qu'il manque beaucoup d'humilité aussi. Je veux dire, si un grand nombre de développeurs et mainteneurs ont opéré ces changements, et qu'ils ont été adoptés assez massivement, c'est la preuve qu'il y a un certain besoin ou que des choses ont changé pour justifier cela. Dire que tous ces changements sont des erreurs c'est finalement se croire meilleur que tout ce beau monde en considérant ce travail comme inutile ou nuisible…
Car en réalité oui systemd parallélise les lancements donc ça bouffe un peu en RAM, mais dans ce contexte les services restent petits et ne sont donc pas un problème.
Y a probablement des contextes où ça peut être un soucis (par exemple si 2 processus consomment beaucoup de RAM au démarrage qu’ils libèrent après), mais honnêtement, c’est des cas particuliers et c’est typiquement des cas où c’est à l’administrateur de configurer son système en conséquence.
Posté par AlexTérieur .
Évalué à 6.
Dernière modification le 13 juillet 2020 à 21:10.
Perso, je ne jugerai pas SystemD, car je l'avoue, jamais (Dieu soit loué ?) je n'ai eu de gros problème. Mais venant d'un système comme OpenRC de Gentoo, qui a il me semble bien avant l'avènement de systemd, amorcé la parallélisation des services, il est vrai que sauter à la logique "SystemD" a eu de quoi en rebuter plus d'un… Entre les "Before", les "After", les WantedBy"… il y a vraiment de quoi perdre la tête.
Je suis développeur embarqué, et j'ai travaillé sur des cartes qui ont systemd et ça se comporte très bien. Pourtant avec 256 Mio de RAM (bien loin donc du 1 Gio nécessaire selon lui). Car en réalité oui systemd parallélise les lancements donc ça bouffe un peu en RAM, mais dans ce contexte les services restent petits et ne sont donc pas un problème.
Et puis il me semble que rien dans le noyau ne force à utiliser systemd et dans l'embarqué on se créé une distrib custom si besoin. Donc partant de là je ne vois pas trop en quoi sa prose sur l'embarqué a du sens.
Pas trop envie de m'étendre sur mon opinion de systemd, ça n'apporterais rien. Je préfère apporter des solutions aux «problèmes» soulevés par cette personne, ça me semble plus constructif.
Je note personnellement que l'auteur du billet n'est pas aussi compétent qu'il veut le faire croire avec Debian.
1: le meta-paquet "init" dépends, au choix, de:
systemd-sysv aka systemd (oui, le nom est a chier, probablement un héritage du fait que lors de l'introduction ça dépendait de sysv-rc);
sysvinit-core aka sysvinit qui dépend de sysv-rc;
runit-init aka… bah, runit, ui dépend de sysv-rc pour une raison simple: il faut du temps pour implémenter un système d'init complet (de mémoire, dans Jessie systemd-sysv aussi en dépendait);
2: si la séparation de / et /usr lui est si chère, pourquoi ne pas conserver cette séparation?
Pour ce qui est du point 1, le seul truc que je peux regretter est l'absence de nosh dans la liste, j'aurait bien aimé qu'on me mâche le boulot avec celui-la, ça m'aurait permis de le découvrir in-situ.
Parmi ses avantages supposés (de mémoire):
possibilité de convertir les unit systemd en scripts nosh
un "DSL shell" (pour domain specific language shell, l'appellation est de moi)
correction du problème "thundering herd solution" qui est l'apanage des héritiers des daemon tools
mais faut que lise la doc, donc la flemme :)
Je reconnais que, pour ne pas avoir systemd installé par défaut (et donc devoir le désinstaller via apt après l'install) et/ou pour conserver la séparation de / et /usr il faut passer par une procédure plus complexe:
démarrer sur l'iso
ne pas sélectionner "install" mais "rescue"
Une fois dans le "rescue mode", il faut ensuite faire l'installation de la façon qui se fait sur d'autres distributions, qui ciblent des utilisateurs avancés (ça tombe bien, il semble en être un!): préparer le système cible, utiliser deboostrap avec les paramètres qui vont bien, configurer le système, configurer le bootloader.
Oui, c'est compliqué, mais plutôt que râler, il aurait été plus efficace de rappeler que c'est possible, j'ai émis plusieurs journaux sur ce genre de manipulations, donc en fouillant il devrais même ne pas avoir trop de boulot a faire pour construire son propre script.
Mais non, comme «tous» les «anti-systemd»(1) il préfère râler en ignorant (volontairement?) le fait que systemd est loin d'être obligatoire, surtout sur la distribution dont il parle qui propose quand même 2 alternatives pour ceux qui le veulent!
Et, vraiment? 1Go de RAM pour systemd?
Heureusement que ça n'est pas vrai, parce que sinon cette collection d'outils, qui nécessiterait sur mon système l'usage de 14.4Mio de disque, doit leak quelque chose de bien! Pas crédible.
Oui, systemd est plus gourmand en ressources.
C'est normal: il gère réellement les processus, il ne se contente pas de les lancer et faire comme si ça ne plante jamais!
D'ailleurs, c'est encore plus important sur un système embarqué qui va se retrouvé exposé a des conditions bien éloignée du labo. J'ai déjà vu un système freezer par le simple fait de recevoir un appel téléphonique trop près (bon, dans ce cas, c'était le hard qui partait en couilles, certes, il aurait fallu un watchdog hard, mais bon…)!
Par contre, je serais curieux de savoir la consommation mémoire (réelle) de systemd. Dans le cas de runit compilé avec glibc, j'ai:
Dans la plupart des instances de runsv, svlogd, runit et runsvdir, RSS chute a 4 dans le cas d'une compilation avec musl. Je ne sais pas pourquoi certaines instances de runsv montent a plus d'1Mo…
Si quelqu'un peut mesurer l'impact de systemd compilé avec glibc ou mieux, si possible, avec musl?
Bon, sur la plupart des machines, ces quelques megs de mémoire consommés ne sont pas gênant, mais je me dis que sur de l'embarqué très serré (genre, avec moins de 64Mo de RAM, comme certains routeurs ou autres) ça peut compter.
Perso, je vois surtout le fait que je serais capable de lire et maintenir le code de runit si besoin est, alors que ce n'est pas le cas pour systemd.
1: dont, techniquement, je fais partie puisque je n'utilise pas cet init. Cela dis, je préférerais utiliser systemd que revenir à sysvinit + rc.d, sans hésitation, surtout sur des machines sur lesquelles je n'ai pas la possibilité d'avoir un accès physique!
Je suis développeur embarqué, et j'ai travaillé sur des cartes qui ont systemd et ça se comporte très bien. Pourtant avec 256 Mio de RAM (bien loin donc du 1 Gio nécessaire selon lui). Car en réalité oui systemd parallélise les lancements donc ça bouffe un peu en RAM, mais dans ce contexte les services restent petits et ne sont donc pas un problème.
De plus la multiplication des processus et tout ce qui vient avec (changement de contexte, lecture en plus sur disque,…) peu aussi se faire ressentir sur du hardware moins puissant.
Surtout quand on voit l'usine à gaz qu'est l'implémentation par debian de rc.d… pour chaque service, ce sont des milliers de lignes de bourne shell qui sont exécutées, réparties dans je ne sais plus combien de fichiers disséminés un peu partout…
Posté par claudex .
Évalué à 6.
Dernière modification le 13 juillet 2020 à 18:28.
Il est vrai que pour des serveurs qui ne sont pas destinés à être rebootés 5 fois par jour, gagner 5s sur un démarrage n'est pas un gain absolument indispensable (surtout quand le hardware lui-même passe par 20 étapes de vérification de tout composant allant du backplane aux contrôleurs raids en passant par la RAM et les ventilos à chaque démarrage
Mais sur une VM hébergé sur ce serveur, c'est intéressant. Pouvoir démarrer des VM à la volée parce que la charge augmente, c'est pratique (bon, maintenant on le fait plus avec des conteneurs, mais ça ne veut pas dire que tous les usages de VM on disparus).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
pour des serveurs qui ne sont pas destinés à être rebootés 5 fois par jour, gagner 5s sur un démarrage n'est pas un gain absolument indispensable
Mais est-ce que tu dis la même chose de tous le travail qui est fait dans le kernel pour gagner quelque pouillèmes de millisecondes ?
Parce qu’il y a beaucoup, BEAUCOUP de taff qui est fait dans ce sens là et on pourrait dire la même chose : ça sert à rien, ma machine met 20 minutes à démarrer.
Est-ce que le principe de (relative) simplicité qui prévalait auparavant est devenu obsolète? Ou alors c'est ma réticence au "changement" qui m'aveugle?
Le principe de simplicité qui prévalait auparavant non seulement prévaut toujours mais s'accompagne d'autres avantages, je crains donc que ce ne soit la seconde proposition qui soit la bonne.
Bon,ceci étant dit, s'il faut en passer par là pour simplifier la tâche des développeurs du noyau, pour avoir un système plus universel, prenant en charge une plus grande diversité d'architectures, un meilleur support matériel, un système plus optimisé et économe en ressources, c'est un sacrifice auquel je consentirais de bonne grâce.
Mais est-ce bien le but poursuivi?
C'est une partie du but poursuivi, bien qu'en réalité il y en a d'autres bien plus importants et essentiels. Par exemple :
- systemd n'a pas servi à simplifier la tâche des développeurs du noyau, si ce n'est pour trouver des dysfonctionnements dans celui-ci. Ce n'était pas possible auparavant, car on attribuait le problème aux différents systèmes utilisés, systemd a permis de révéler ces problèmes dans le noyau qui s'en trouve meilleur aujourd'hui ;
- les systèmes peuvent désormais démarrer dans le même état à coup sûr (hors problème matériel) s'ils sont bien configurés, contrairement à auparavant où un système, sans rien changer, pouvait voir sa configuration de carte réseau changer au redémarrage, ou encore sa disposition des disques si le BIOS avait subi la moindre modification, ou simplement en insérant une clé USB. Pour l'utilisateur lambda, c'est beaucoup mieux. La plupart des utilisateurs/administrateurs avaient des problèmes dont ils n'ont jamais cherché ou trouvé la cause, parce que beaucoup trop compliqué à investiguer. Les administrateurs des distributions ont forcément eu le cas avec la quantité d'utilisateurs qui remontent des problèmes. Même moi qui crée mes OS entièrement, je savais que même avec tous mes scripts personnalisés, les serveurs avaient toujours une chance de ne pas redémarrer correctement avant systemd ;
- les problèmes pouvaient survenir rien que par le fait que les anciens systèmes d'init ne géraient pas les événements, or le noyau Linux s'était adapté depuis bien longtemps avec udev et encore avant avec son prédécesseur (dont j'ai oublié le nom), il envoie des événements que les systèmes d'init ignoraient joyeusement, et c'était une misère pour gérer le démarrage et des choses simples comme connecter une clé USB et la voir prise en compte. Un exemple du KISS respecté, il est plus simple de simplement brancher sa clé USB que d'encore aller exécuter des commandes ensuite pour y avoir accès ;
- les systèmes sont beaucoup plus sécurisés qu'auparavant. Il est maintenant possible de vraiment cloisonner simplement ses démons, son poste de travail pour l'utilisateur, et même en multiseat ou en multi-sessions. Une de mes hantises sur les serveurs était qu'il était très facile de placer des malwares dans les scripts d'init sans que cela ne soit détecté (hors utilisation d'IDS) ;
- les fonctionnalités de qualité de vie, d'optimisation, de sécurité, de performance, etc. du noyau Linux sont enfin utilisées et améliorées puisque vraiment utilisées, grâce à systemd. Les détracteurs se contentent de dire "mais si on peut faire" mais ne font jamais en réalité, d'où le fait que seul systemd a permis de remonter des dysfonctionnements sur ces options du noyau ;
- rien que monter un VPN (avec wireguard récemment) est devenu d'une simplicité sans comparaison avec ce qui se faisait ;
Lorsqu'on a eu les mains dans le cambouis comme moi (je fais mes propres OS, le même travail que font les distributions) depuis plus de 20 ans, il est évident du pourquoi de l'adoption de systemd par quasiment toutes les distributions, qui souvent utilisaient des binaires pour tenter de faire démarrer de manière cohérente leurs OS. Lorsque systemd est arrivé il y a plus de 10 ans, je l'ai accueilli sans hésiter, j'ai sauté sur les toutes premières versions de développement. Il faut dire que je maintenais tout seul simpleinit-msb jusque-là (j'avais abandonné l'abomination qu'est sysvinit en quelques mois d'utilisation), en espérant trouver mieux. Je n'y croyais pas trop au départ mais j'espérais fortement que systemd tienne ses promesses, et non seulement il les a tenues mais il a pu s'insérer comme une référence.
D’après ton sous-titre en latin, la dégradation que tu prêtes aux distributions Linux en causerait la chute.
Cependant, Windows est toujours le système le plus utilisé au monde sur micro‐ordinateur, alors qu’il est devenu un gros malware dans sa dernière version (mouchards, installation forcée de logiciels…).
La situation est similaire sur smartphone (s’il ne force pas l’installation de logiciels, Android est certainement l’inspiration de Microsoft pour ajouter des mouchards).
Une des boissons les plus consommées au monde est juste du décapant métaux avec une tonne de sucre (ou d’édulcorant selon la version) pour le cacher.
Des tas de gens fument, alors que cette pratique n’apporte clairement de bénéfice qu’aux industriels du tabac.
Le néolibéralisme triomphe sur toute la planète, alors que le seul problème qu’il résout réellement est de permettre à ceux qui sont déjà les plus riches de s’enrichir encore plus, quitte à gaspiller des ressources finies et à exploiter des populations.
Bref, la rationalité ne mène (malheureusement) pas le monde, et même si on accorde la même importance que toi à la perte du principe KISS par les distributions Linux (accessoirement, je le regrette aussi), que ça en entraîne la chute n’a rien d’évident.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
S’il faut mobiliser toutes affaires cessantes un Edward Gibbon (« Grandeur et décadence »), autant le faire à la E.G. à fond : aborder systématiquement les causes intrinsèques et extrinsèques, prouver la soi-disante « perte du principe KISS » à l’aide des ressources disponibles, ainsi que sa relation avec « la chute ».
Bref, oui, la rationalité n’est pas de ce monde (programme ambitieux). Elle n’est même pas dans cet article-là (il était permis d’espérer).
Mais les gens ils trouvent où le temps de râler pendant 10 ans (!) maintenant ?
Perso j’utilise un OS pour répondre à des besoins et même si ça m’arrive que la façon dont c’est fait me plaît pas, mes besoins disparaissent pas pour autant…
Posté par Psychofox (Mastodon) .
Évalué à 7.
Dernière modification le 14 juillet 2020 à 12:20.
Honnêtement je ne suis pas développeur et le C est un peu loin derrière moi, mais je veux bien le croire que le code d'un projet puisse être beaucoup plus goret qu'un autre.
Et j'apprécie aussi l'usage des systèmes BSD, leur stabilité dans le temps, dans le cas d'openbsd certains choix qui mettent en avant la sécurité sans compromission. Mais s'il l'évoque en parlant de systèmes gérables par l'utilisateur sans utiliser vi, il zappe un peu vite leur manques.
Je partage aussi le caractère un peu bordélique de systemD et certains choix. Même s'il est utile de séparer par exemple les units installées par les paquets de celles écrites par l'admin de la machine, je trouve moche que ce soit un tel bordel dans le fs. En revanche l'auteur de ce billet ignore (volontairement?) certains avantages de systemD. Un exemple parmi d'autres je trouve très pratique de pouvoir créer un service à la fois géré dans l'espace utilisateur. Aussi, on peut ne pas aimer le format binaire des logs systemd mais si tu veux accéder aux logs d'un service, tu n'as pas besoin de deviner le chemin et le nom du fichier log qui même s'il attérit généralement dans /var/log diffère en général selon les distribs/éditeurs/mainteneurs de paquets. Pas la peine non plus de passer dans des pipe gzip pour accéder aux logs de la semaine dernière.
L'auteur ignore aussi (volontairement encore?) qu'il existe des distribs sans systemD (alpine, devuan, antiX, slackware pclinuxos, chrome-os/chromium-os, android-lineagos-/e) et que d'autres comme Gentoo ou arch permettent d'en utiliser un autre. Bref on n'a pas de pistolet sur la tempe pour utiliser systemd.
Par contre pour la séparation /bin /usr/bin et /sbin /usr/sbin là on nage en plein délire. C'était utile quand on avait des systèmes avec des tous petis disques internes et le reste sur des nfs partagés pour de multiples systèms mais c'est une pratique qui ne se fait plus et pour de bonnes raisons. Une partition racine qui ne se monte pas, qu'elle fasse 500MB ou 50GB t'es dans la même merde. Et depuis qu'on a des systèmes de fichiers journalisés on n'a plus tellement de raisons d'avoir besoin de faire des fsck du système.
Personnellement si j'ai une partition dégueulasse, j'ai:
1. un fort doute sur l'intégrité des données après réparation
2. un fort doute sur l'intégrité du disque
Donc je vais tester le disque et s'il n'y a pas de panne physique manifeste recréer la partition (voire tout le système) de zero. Avec foreman je déploie et réinstalle un serveur en 5 minutes. Un coup de puppet plus tard il a retrouvé sa configuration originale. Tout système qui a des données critiques aura de toute façon de la haute dispo configurée, que ce soit via de la synchronisation de DB, une synchro drbd, les données sur un volume nfs/s3/ceph/autrefs distribué, ou autre. Dans les cas où c'est moins critiques soit tu réinstalles sans toucher aux données, soit tu restaures depuis une sauvegarde en quelques minutes. À quoi ça servirait en 2020 d'essayer de bidouiller, sur une console et réparer un système qui ne démarre plus sur sa partition racine ? Si ça arrive c'est soit parce qu'on a un bug noyau majeur, soit parce qu'on a fait le con, soit parce qu'on a une panne disque.
Manifestement l'auteur de ce billet en est encore à gérer ses serveurs comme des animaux de compagnie. Ça occupe les heures de bureaux mais c'est peu efficace. Dans le cas d'un laptop/desktop, j'aurais tendance à utiliser un liveusb de toute manière car c'est plus confortable, on peut avoir du réseau et un navigateur si besoin pour lire une doc, installer n'importe quoi et chrooter.
# circulez...
Posté par Anonyme . Évalué à 10.
pour résumer:
- ça a changé
- j'aime pas, je préférais avant, vous comprenez mon bon monsieur, de mon temps…
- de toute façon j'utilise que des *BSD maintenant.
[^] # Re: circulez...
Posté par j (site web personnel) . Évalué à 5.
oui… il y a (presque) une dizaine d'années déjà https://dougvitale.wordpress.com/2011/12/21/deprecated-linux-networking-commands-and-their-replacements/
et cette page iproute2 a été commencée en 2013.
Cependant j'ai trouvé le billet de blog intéressant.
[^] # Re: circulez...
Posté par barmic 🦦 . Évalué à 6.
J'aime bien l'argument sur les noms d'interfaces… Il a rien regardé au pourquoi et ne s'est pas du tout dis que c'est déjà la stratégie des bsd et donc que eth0 n'est pas unix, mais une spécificité de linux. C'est beau les arguments bien construit 🙂
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: circulez...
Posté par freem . Évalué à 2.
Pour le coup, de ce côté, son discours est très étrange…
D'une part, il râle parce qu'avant il fallait jouer avec udev pour avoir des noms fiables:
Puis il râle que udev renomme les interfaces (en accusant une MàJ kernel, quand même…)
Et enfin il râle que systemd re-renomme les interfaces:
Bon, en fait, je crois que son propos ici c'est que c'est le kernel qui devrais le faire. Ce qui est en soit défendable. Personnellement je ne sais pas vraiment comment udev fait pour exposer les noms des interfaces réseau, donc je ne jugerai pas sur ce point (faudrait que je creuse le sujet un jour).
# le principe "KISS" est-il devenu obsolète?
Posté par bistouille . Évalué à 8.
C'est un constat certes sévère, mais que je partage un peu, en séparant toutefois 2 cas d'utilisation, la vision "serveur/sysadmin" et "station/utilisateur".
Est-ce que le principe de (relative) simplicité qui prévalait auparavant est devenu obsolète? Ou alors c'est ma réticence au "changement" qui m'aveugle?
J'ai du mal à mesurer ce que j'ai gagné à utiliser entre autres quotidiennement des meta-commandes comme systemctl, journalctl, firewall-cmd etc pour gérer des services allant des plus essentiels au système jusqu'aux interfaces réseaux/dns, chercher dans les logs, écrire des règles de filtrage….
Des commandes qui font tellement de trucs que l'indispensable parcours des pages de manuel est devenu une course d'obstacles.
Bon,ceci étant dit, s'il faut en passer par là pour simplifier la tâche des développeurs du noyau, pour avoir un système plus universel, prenant en charge une plus grande diversité d'architectures, un meilleur support matériel, un système plus optimisé et économe en ressources, c'est un sacrifice auquel je consentirais de bonne grâce.
Mais est-ce bien le but poursuivi? Il est vrai que pour des serveurs qui ne sont pas destinés à être rebootés 5 fois par jour, gagner 5s sur un démarrage n'est pas un gain absolument indispensable (surtout quand le hardware lui-même passe par 20 étapes de vérification de tout composant allant du backplane aux contrôleurs raids en passant par la RAM et les ventilos à chaque démarrage :-))
Ce qui me laisse un poil optimiste malgré tout c'est que des dérivées de Debian comme Emmabuntüs me permettent encore de donner un second souffle à des PCs et Macs relativement anciens (>=11 ans), de les confier aux gamins ou aux anciens de mon entourage avec une "notice" minimale tenant sur 2 feuilles A4 leur permettant de vaquer à leurs occupations numériques habituelles, et nécessitant peu d'intervention par la suite.
[^] # Re: le principe "KISS" est-il devenu obsolète?
Posté par Renault (site web personnel) . Évalué à 10.
Peut être que tu n'as rien gagné toi personnellement dans l'affaire, mais d'autres oui. On a tous nos besoins, certains sont très contents de fonctionner comme dans les années 90 car leur besoin est satisfait ainsi et ils ont leur habitude.
Mais le monde a changé, de nouveaux besoins sont apparus et de nouvelles idées ont émergé. C'est un peu dommage de croire qu'on devrait tout figer dans le marbre dans un tel contexte.
D'ailleurs UNIX a beaucoup progressé entre 1970 et 1990, pour tenir compte des changements dans le milieu : réseau, interface graphique, internationalisation, etc. Ses concepteurs ont préféré faire Plan 9 plutôt que contribuer à changer UNIX car ses défauts étaient trop profonds pour corriger par couche successive.
Tout cela montre que croire que UNIX a atteint une forme de perfection dans les années 90 et ne devrait plus bouger est une chimère. Cela ne reflète pas la réalité historique de l'informatique ou d'UNIX.
Le but de systemd n'a jamais été de gagner de la vitesse. C'est une conséquence de son architecture qui conduit à une amélioration de cette vitesse. Il ne faut pas inverser la causalité ici.
Et d'ailleurs, l'article critique systemd en contexte embarqué car soit disant ça bouffe des ressources. Et non.
Je suis développeur embarqué, et j'ai travaillé sur des cartes qui ont systemd et ça se comporte très bien. Pourtant avec 256 Mio de RAM (bien loin donc du 1 Gio nécessaire selon lui). Car en réalité oui systemd parallélise les lancements donc ça bouffe un peu en RAM, mais dans ce contexte les services restent petits et ne sont donc pas un problème.
Et je suis justement très content de gérer un projet embarqué avec systemd. Cela demande un peu plus de ressources que SysV c'est vrai (mais dans pas mal de projets ce n'est pas un problème). Mais cela apporte tellement à côté comme le relancement automatique du service dans certaines conditions ou la gestion des dépendances qui rend cela bien plus agréable à faire qu'à l'ancienne. Je gagne personnellement du temps de développement et en qualité de service du produit.
Bref, dans cet article je vois surtout une forme de résistance au changement. Alors certes il étaye son point de vue, je le comprends, mais il regarde cela uniquement sous le prisme de ses propres besoins en oubliant qu'il n'est pas seul dans ce monde.
Et je trouve qu'il manque beaucoup d'humilité aussi. Je veux dire, si un grand nombre de développeurs et mainteneurs ont opéré ces changements, et qu'ils ont été adoptés assez massivement, c'est la preuve qu'il y a un certain besoin ou que des choses ont changé pour justifier cela. Dire que tous ces changements sont des erreurs c'est finalement se croire meilleur que tout ce beau monde en considérant ce travail comme inutile ou nuisible…
[^] # Re: le principe "KISS" est-il devenu obsolète?
Posté par Anonyme . Évalué à 2.
Y a probablement des contextes où ça peut être un soucis (par exemple si 2 processus consomment beaucoup de RAM au démarrage qu’ils libèrent après), mais honnêtement, c’est des cas particuliers et c’est typiquement des cas où c’est à l’administrateur de configurer son système en conséquence.
[^] # Re: le principe "KISS" est-il devenu obsolète?
Posté par AlexTérieur . Évalué à 6. Dernière modification le 13 juillet 2020 à 21:10.
Perso, je ne jugerai pas SystemD, car je l'avoue, jamais (Dieu soit loué ?) je n'ai eu de gros problème. Mais venant d'un système comme OpenRC de Gentoo, qui a il me semble bien avant l'avènement de systemd, amorcé la parallélisation des services, il est vrai que sauter à la logique "SystemD" a eu de quoi en rebuter plus d'un… Entre les "Before", les "After", les WantedBy"… il y a vraiment de quoi perdre la tête.
[^] # Re: le principe "KISS" est-il devenu obsolète?
Posté par Psychofox (Mastodon) . Évalué à 4.
Et puis il me semble que rien dans le noyau ne force à utiliser systemd et dans l'embarqué on se créé une distrib custom si besoin. Donc partant de là je ne vois pas trop en quoi sa prose sur l'embarqué a du sens.
[^] # Re: le principe "KISS" est-il devenu obsolète?
Posté par freem . Évalué à 5.
Pas trop envie de m'étendre sur mon opinion de systemd, ça n'apporterais rien. Je préfère apporter des solutions aux «problèmes» soulevés par cette personne, ça me semble plus constructif.
Je note personnellement que l'auteur du billet n'est pas aussi compétent qu'il veut le faire croire avec Debian.
1: le meta-paquet "init" dépends, au choix, de:
2: si la séparation de / et /usr lui est si chère, pourquoi ne pas conserver cette séparation?
Pour ce qui est du point 1, le seul truc que je peux regretter est l'absence de nosh dans la liste, j'aurait bien aimé qu'on me mâche le boulot avec celui-la, ça m'aurait permis de le découvrir in-situ.
Parmi ses avantages supposés (de mémoire):
mais faut que lise la doc, donc la flemme :)
Je reconnais que, pour ne pas avoir systemd installé par défaut (et donc devoir le désinstaller via apt après l'install) et/ou pour conserver la séparation de
/et/usril faut passer par une procédure plus complexe:Une fois dans le "rescue mode", il faut ensuite faire l'installation de la façon qui se fait sur d'autres distributions, qui ciblent des utilisateurs avancés (ça tombe bien, il semble en être un!): préparer le système cible, utiliser
deboostrapavec les paramètres qui vont bien, configurer le système, configurer le bootloader.Oui, c'est compliqué, mais plutôt que râler, il aurait été plus efficace de rappeler que c'est possible, j'ai émis plusieurs journaux sur ce genre de manipulations, donc en fouillant il devrais même ne pas avoir trop de boulot a faire pour construire son propre script.
Mais non, comme «tous» les «anti-systemd»(1) il préfère râler en ignorant (volontairement?) le fait que systemd est loin d'être obligatoire, surtout sur la distribution dont il parle qui propose quand même 2 alternatives pour ceux qui le veulent!
Et, vraiment? 1Go de RAM pour systemd?
Heureusement que ça n'est pas vrai, parce que sinon cette collection d'outils, qui nécessiterait sur mon système l'usage de 14.4Mio de disque, doit leak quelque chose de bien! Pas crédible.
Oui, systemd est plus gourmand en ressources.
C'est normal: il gère réellement les processus, il ne se contente pas de les lancer et faire comme si ça ne plante jamais!
D'ailleurs, c'est encore plus important sur un système embarqué qui va se retrouvé exposé a des conditions bien éloignée du labo. J'ai déjà vu un système freezer par le simple fait de recevoir un appel téléphonique trop près (bon, dans ce cas, c'était le hard qui partait en couilles, certes, il aurait fallu un watchdog hard, mais bon…)!
Par contre, je serais curieux de savoir la consommation mémoire (réelle) de systemd. Dans le cas de runit compilé avec glibc, j'ai:
Dans la plupart des instances de runsv, svlogd, runit et runsvdir, RSS chute a 4 dans le cas d'une compilation avec musl. Je ne sais pas pourquoi certaines instances de runsv montent a plus d'1Mo…
Si quelqu'un peut mesurer l'impact de systemd compilé avec glibc ou mieux, si possible, avec musl?
Bon, sur la plupart des machines, ces quelques megs de mémoire consommés ne sont pas gênant, mais je me dis que sur de l'embarqué très serré (genre, avec moins de 64Mo de RAM, comme certains routeurs ou autres) ça peut compter.
Perso, je vois surtout le fait que je serais capable de lire et maintenir le code de runit si besoin est, alors que ce n'est pas le cas pour systemd.
1: dont, techniquement, je fais partie puisque je n'utilise pas cet init. Cela dis, je préférerais utiliser systemd que revenir à sysvinit + rc.d, sans hésitation, surtout sur des machines sur lesquelles je n'ai pas la possibilité d'avoir un accès physique!
[^] # Re: le principe "KISS" est-il devenu obsolète?
Posté par barmic 🦦 . Évalué à 2.
De plus la multiplication des processus et tout ce qui vient avec (changement de contexte, lecture en plus sur disque,…) peu aussi se faire ressentir sur du hardware moins puissant.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: le principe "KISS" est-il devenu obsolète?
Posté par freem . Évalué à 3.
Surtout quand on voit l'usine à gaz qu'est l'implémentation par debian de rc.d… pour chaque service, ce sont des milliers de lignes de bourne shell qui sont exécutées, réparties dans je ne sais plus combien de fichiers disséminés un peu partout…
[^] # Re: le principe "KISS" est-il devenu obsolète?
Posté par claudex . Évalué à 6. Dernière modification le 13 juillet 2020 à 18:28.
Mais sur une VM hébergé sur ce serveur, c'est intéressant. Pouvoir démarrer des VM à la volée parce que la charge augmente, c'est pratique (bon, maintenant on le fait plus avec des conteneurs, mais ça ne veut pas dire que tous les usages de VM on disparus).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: le principe "KISS" est-il devenu obsolète?
Posté par Anonyme . Évalué à 0.
Mais est-ce que tu dis la même chose de tous le travail qui est fait dans le kernel pour gagner quelque pouillèmes de millisecondes ?
Parce qu’il y a beaucoup, BEAUCOUP de taff qui est fait dans ce sens là et on pourrait dire la même chose : ça sert à rien, ma machine met 20 minutes à démarrer.
[^] # Re: le principe "KISS" est-il devenu obsolète?
Posté par ookaze . Évalué à 0.
Le principe de simplicité qui prévalait auparavant non seulement prévaut toujours mais s'accompagne d'autres avantages, je crains donc que ce ne soit la seconde proposition qui soit la bonne.
C'est une partie du but poursuivi, bien qu'en réalité il y en a d'autres bien plus importants et essentiels. Par exemple :
- systemd n'a pas servi à simplifier la tâche des développeurs du noyau, si ce n'est pour trouver des dysfonctionnements dans celui-ci. Ce n'était pas possible auparavant, car on attribuait le problème aux différents systèmes utilisés, systemd a permis de révéler ces problèmes dans le noyau qui s'en trouve meilleur aujourd'hui ;
- les systèmes peuvent désormais démarrer dans le même état à coup sûr (hors problème matériel) s'ils sont bien configurés, contrairement à auparavant où un système, sans rien changer, pouvait voir sa configuration de carte réseau changer au redémarrage, ou encore sa disposition des disques si le BIOS avait subi la moindre modification, ou simplement en insérant une clé USB. Pour l'utilisateur lambda, c'est beaucoup mieux. La plupart des utilisateurs/administrateurs avaient des problèmes dont ils n'ont jamais cherché ou trouvé la cause, parce que beaucoup trop compliqué à investiguer. Les administrateurs des distributions ont forcément eu le cas avec la quantité d'utilisateurs qui remontent des problèmes. Même moi qui crée mes OS entièrement, je savais que même avec tous mes scripts personnalisés, les serveurs avaient toujours une chance de ne pas redémarrer correctement avant systemd ;
- les problèmes pouvaient survenir rien que par le fait que les anciens systèmes d'init ne géraient pas les événements, or le noyau Linux s'était adapté depuis bien longtemps avec udev et encore avant avec son prédécesseur (dont j'ai oublié le nom), il envoie des événements que les systèmes d'init ignoraient joyeusement, et c'était une misère pour gérer le démarrage et des choses simples comme connecter une clé USB et la voir prise en compte. Un exemple du KISS respecté, il est plus simple de simplement brancher sa clé USB que d'encore aller exécuter des commandes ensuite pour y avoir accès ;
- les systèmes sont beaucoup plus sécurisés qu'auparavant. Il est maintenant possible de vraiment cloisonner simplement ses démons, son poste de travail pour l'utilisateur, et même en multiseat ou en multi-sessions. Une de mes hantises sur les serveurs était qu'il était très facile de placer des malwares dans les scripts d'init sans que cela ne soit détecté (hors utilisation d'IDS) ;
- les fonctionnalités de qualité de vie, d'optimisation, de sécurité, de performance, etc. du noyau Linux sont enfin utilisées et améliorées puisque vraiment utilisées, grâce à systemd. Les détracteurs se contentent de dire "mais si on peut faire" mais ne font jamais en réalité, d'où le fait que seul systemd a permis de remonter des dysfonctionnements sur ces options du noyau ;
- rien que monter un VPN (avec wireguard récemment) est devenu d'une simplicité sans comparaison avec ce qui se faisait ;
Lorsqu'on a eu les mains dans le cambouis comme moi (je fais mes propres OS, le même travail que font les distributions) depuis plus de 20 ans, il est évident du pourquoi de l'adoption de systemd par quasiment toutes les distributions, qui souvent utilisaient des binaires pour tenter de faire démarrer de manière cohérente leurs OS. Lorsque systemd est arrivé il y a plus de 10 ans, je l'ai accueilli sans hésiter, j'ai sauté sur les toutes premières versions de développement. Il faut dire que je maintenais tout seul simpleinit-msb jusque-là (j'avais abandonné l'abomination qu'est sysvinit en quelques mois d'utilisation), en espérant trouver mieux. Je n'y croyais pas trop au départ mais j'espérais fortement que systemd tienne ses promesses, et non seulement il les a tenues mais il a pu s'insérer comme une référence.
# La qualité ne fait pas le succès
Posté par Arthur Accroc . Évalué à 10.
D’après ton sous-titre en latin, la dégradation que tu prêtes aux distributions Linux en causerait la chute.
Cependant, Windows est toujours le système le plus utilisé au monde sur micro‐ordinateur, alors qu’il est devenu un gros malware dans sa dernière version (mouchards, installation forcée de logiciels…).
La situation est similaire sur smartphone (s’il ne force pas l’installation de logiciels, Android est certainement l’inspiration de Microsoft pour ajouter des mouchards).
Une des boissons les plus consommées au monde est juste du décapant métaux avec une tonne de sucre (ou d’édulcorant selon la version) pour le cacher.
Des tas de gens fument, alors que cette pratique n’apporte clairement de bénéfice qu’aux industriels du tabac.
Le néolibéralisme triomphe sur toute la planète, alors que le seul problème qu’il résout réellement est de permettre à ceux qui sont déjà les plus riches de s’enrichir encore plus, quitte à gaspiller des ressources finies et à exploiter des populations.
Bref, la rationalité ne mène (malheureusement) pas le monde, et même si on accorde la même importance que toi à la perte du principe KISS par les distributions Linux (accessoirement, je le regrette aussi), que ça en entraîne la chute n’a rien d’évident.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: La qualité ne fait pas le succès
Posté par gipoisson . Évalué à 1.
[warning : commentaire allant sur une tangente …]
S’il faut mobiliser toutes affaires cessantes un Edward Gibbon (« Grandeur et décadence »), autant le faire à la E.G. à fond : aborder systématiquement les causes intrinsèques et extrinsèques, prouver la soi-disante « perte du principe KISS » à l’aide des ressources disponibles, ainsi que sa relation avec « la chute ».
Bref, oui, la rationalité n’est pas de ce monde (programme ambitieux). Elle n’est même pas dans cet article-là (il était permis d’espérer).
# Beaucoup de temps
Posté par Sacha Trémoureux (site web personnel) . Évalué à 2.
Mais les gens ils trouvent où le temps de râler pendant 10 ans (!) maintenant ?
Perso j’utilise un OS pour répondre à des besoins et même si ça m’arrive que la façon dont c’est fait me plaît pas, mes besoins disparaissent pas pour autant…
# OS ou animaux de compagnie.
Posté par Psychofox (Mastodon) . Évalué à 7. Dernière modification le 14 juillet 2020 à 12:20.
Honnêtement je ne suis pas développeur et le C est un peu loin derrière moi, mais je veux bien le croire que le code d'un projet puisse être beaucoup plus goret qu'un autre.
Et j'apprécie aussi l'usage des systèmes BSD, leur stabilité dans le temps, dans le cas d'openbsd certains choix qui mettent en avant la sécurité sans compromission. Mais s'il l'évoque en parlant de systèmes gérables par l'utilisateur sans utiliser vi, il zappe un peu vite leur manques.
Je partage aussi le caractère un peu bordélique de systemD et certains choix. Même s'il est utile de séparer par exemple les units installées par les paquets de celles écrites par l'admin de la machine, je trouve moche que ce soit un tel bordel dans le fs. En revanche l'auteur de ce billet ignore (volontairement?) certains avantages de systemD. Un exemple parmi d'autres je trouve très pratique de pouvoir créer un service à la fois géré dans l'espace utilisateur. Aussi, on peut ne pas aimer le format binaire des logs systemd mais si tu veux accéder aux logs d'un service, tu n'as pas besoin de deviner le chemin et le nom du fichier log qui même s'il attérit généralement dans /var/log diffère en général selon les distribs/éditeurs/mainteneurs de paquets. Pas la peine non plus de passer dans des pipe gzip pour accéder aux logs de la semaine dernière.
L'auteur ignore aussi (volontairement encore?) qu'il existe des distribs sans systemD (alpine, devuan, antiX, slackware pclinuxos, chrome-os/chromium-os, android-lineagos-/e) et que d'autres comme Gentoo ou arch permettent d'en utiliser un autre. Bref on n'a pas de pistolet sur la tempe pour utiliser systemd.
Par contre pour la séparation /bin /usr/bin et /sbin /usr/sbin là on nage en plein délire. C'était utile quand on avait des systèmes avec des tous petis disques internes et le reste sur des nfs partagés pour de multiples systèms mais c'est une pratique qui ne se fait plus et pour de bonnes raisons. Une partition racine qui ne se monte pas, qu'elle fasse 500MB ou 50GB t'es dans la même merde. Et depuis qu'on a des systèmes de fichiers journalisés on n'a plus tellement de raisons d'avoir besoin de faire des fsck du système.
Personnellement si j'ai une partition dégueulasse, j'ai:
1. un fort doute sur l'intégrité des données après réparation
2. un fort doute sur l'intégrité du disque
Donc je vais tester le disque et s'il n'y a pas de panne physique manifeste recréer la partition (voire tout le système) de zero. Avec foreman je déploie et réinstalle un serveur en 5 minutes. Un coup de puppet plus tard il a retrouvé sa configuration originale. Tout système qui a des données critiques aura de toute façon de la haute dispo configurée, que ce soit via de la synchronisation de DB, une synchro drbd, les données sur un volume nfs/s3/ceph/autrefs distribué, ou autre. Dans les cas où c'est moins critiques soit tu réinstalles sans toucher aux données, soit tu restaures depuis une sauvegarde en quelques minutes. À quoi ça servirait en 2020 d'essayer de bidouiller, sur une console et réparer un système qui ne démarre plus sur sa partition racine ? Si ça arrive c'est soit parce qu'on a un bug noyau majeur, soit parce qu'on a fait le con, soit parce qu'on a une panne disque.
Manifestement l'auteur de ce billet en est encore à gérer ses serveurs comme des animaux de compagnie. Ça occupe les heures de bureaux mais c'est peu efficace. Dans le cas d'un laptop/desktop, j'aurais tendance à utiliser un liveusb de toute manière car c'est plus confortable, on peut avoir du réseau et un navigateur si besoin pour lire une doc, installer n'importe quoi et chrooter.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.