[FRsAG] deb.sury.org... miroir ou sauvegarde ?

Xavier Beaudouin kiwi at oav.net
Lun 20 Juil 08:10:28 CEST 2020


Hello la liste,

Je n'écris pas souvent alors je me permet de réagir....

> Je suis aussi utilisateur, mais tardif.

Très tardif, mais je suis en train de ne plus être utilisateur (voir plus bas).

> Les scripts sysinit m'ont toujours rebuté, entre la répétition entre scripts,
> l'incompatibilité entre distribs, le boilerplate dans chaque daemon, la
> gestion des dépendances ...
> Il y quelques années j'avais essayé initng

initng me paraissais bien en tous cas pour les linux qui le supportaient.

> choix avant de passer a systemd

Idem. Passé dessus parce qu'on m'as pas demandé mon choix (enfin, techniquement
je pourrais, mais l'install de base du linux m'obligeant sur les devices linux
only que j'ai... j'ai dû m'adapter)

(...)

 
> Je n'ai pas l'envie de le lancer un débat, mais il y a quand même un certain
> découpage des programmes et fonctions dans le projet/paquet systemd. Il y a le
> /sbin/init et les fonctions annexes (networkd par exemple) sont dans des
> binaires séparés. Est-ce qu'il n'y a pas trop de choses dans le pid 1, pour ca
> les opinions divergent ...

Heu là je suis un dino, et la phylosophie des unix c'est KISS : keep it simple and
stupid. Sans compter le repects des RFC qui sont totalement ignorées par les dev.
Exemple : le DNS, le client DHCP, les RA etc...

Systemd avec tout le merdier dans pid 1 est tout SAUF KISS. Et ses dépendances
ne le sont pas, ainsi que les besoins de plein de lib, a un tel point qu'on arrive
a faire des choses "fat" pour un OS qui as la réputation d'être simple (voir encore
plus bas).

(...)

 
> Le problème de la doc est que vu qu'il faut créer (pour chaque interface) 3
> types de fichier, il faut regarder dans 3 pages de man : systemd.link
> systemd.netdev systemd.network .
> Et aussi, ca multiplie très vite le nombre de fichiers, par exemple sur une
> passerelle un peu complexe j'en suis a plus de 30 ...

Suis désolé mais 3 fichiers pour chacune des interfaces, c'est tout sauf KISS.
Quand par exemple je fait du NAT compliqué avec un os libre, j'ai besoin d'avoir
tout sur un fichier pour comprendre les choses.

En terme de maintenabilité, c'est tout sauf maintenable. Un moment de trop
découper on deviens une usine a gaz et on espère que les dépendances sont correctement
gérées.

Pourquoi je râle ? Simple: quand on reprends une infra d'un tier et qu'il faut 
passer plusieurs jours a comprendre les systemdiseries qui bien évidement
changent parce qu'il n'y a pas de stabilité dans les implementation, on croise
les doigts pour ce machin n'explose pas en vol.

Si pour le poste de travail, je n'ai rien contre systemd (oui on peux l'encadrer),
dans le cadre d'infra serveur, je n'ai absolument pas besoin de ce truc.
On a plein de méthode pour éviter ce délire, et les containers (docker, jails, etc...)
permettent d'arbitrer correctement le lancement des dépendance si on est pas idiot, 
et aussi permettre de faire une archi scalable.

Systemd en env serveur n'as rien a faire dedans. D'ailleurs les idées de fichiers
découpés en plusieurs fichiers ont tjrs rendu les choses compliquées que simple,
mais l'habitude des debian a fait que ça a dérapé.

De mon coté, je pousse du FreeBSD, des jails et un vrai stack réseau qui marche.
Un /etc/rc.conf qui contient tout la configuration système est bcp plus pratique
qu'une centaine de fichiers mis un peu partout...

Après connaissant bien le monde de linux, je suis avec mon générateur de popcorn,
et comme debian permet de nouveau de ne pas dépendre de systemd, c'est que quand
même il y a de l'espoir...

Xavier


Plus d'informations sur la liste de diffusion FRsAG