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.
# OS ou animaux de compagnie.
Posté par Psychofox (Mastodon) . En réponse au lien Grandeur et décadence de Linux (et j'ajoute: sic transit Linux regnum). É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.