Léa-Linux & amis :   LinuxFR   GCU-Squad   Zarb.Org   GNU
Archive de la liste aide - [Aide] [DEBAT] Quelle évolution pour Linux sur le marché et chez vous: sysvinit / upstart / systemd
Le 06/09/2014 14:09, Peko a écrit :
> Whao, excellente page Ille, merci d'apporter cela au débat.

> http://boycottsystemd.org/ )

Ce site ressemble surtout à un gros FUD.
Je pense que l'équipe systemd a déjà largement répondu point par point à
ces arguments.
(et il serait bien de ne pas seulement traduire ce que dise les
détracteurs de systemd, mais aussi ses défenseurs)

> @Remi Collet, cela ne te préoccupe-t-il pas?

Non.

Je pense qu'aucun projet n'est immunisé aux bugs, mais je pense qu'on
peut aussi faire confiance aux dév. derrière systemd pour être sérieux
et réactif.

Ok, Systemd prends en charge beaucoup de choses, en fait ce qui est lié
au démarrage du système et la réaction aux événements matériels (donc
démarrage aussi). Est qu'on fait les mêmes reproches au noyau ? (qui
pourtant centralise l'accès au matériel).

Dans ce cadre, maintenir des scripts d'init de plusieurs dizaines de
lignes pour chaque service, le plus souvent spécifique à chaque
distribution est, de nos jours une hérésie. Un script d'init c'est du
code (shell). Un fichier systemd, c'est juste quelques lignes de
configuration, exemple:

	[Unit]
	Description=DNS caching server.
	After=network.target
	[Service]
	ExecStart=/usr/sbin/dnsmasq -k
	[Install]
	WantedBy=multi-user.target

ou
http://git.php.net/?p=php-src.git;a=blob_plain;f=sapi/fpm/php-fpm.service.in;hb=HEAD
 [2]
Le risque de bug est sans aucune comparaison.
Rien de compliqué (pour ceux qui ont déjà utiliser la commande man, car
contrairement à ce que dise certains détracteur, j'ai rarement vu un
projet avec autant de documentation)

Un des problèmes d'upstart était qu'il était principalement utilisé en
mode 'compatibilité sysV' (c'est à dire pour lancer des scripts d'init),
sans effort de portage et de contribution upstream pour intégrer la
prise en charge.

Un truc qu'il me semble nécessaire de reconnaitre, c'est l'effort
important réalisé par les développeurs Fedora[1] (dans son ensemble pas
juste systemd), pour porter l'ensemble des services en "unit file",
reversé upstream.

Pour la sécurité, au lieu de parler des risques et de citer quelques
CVE, qui ne sont qu'une preuve de la réactivité à corriger et de la
transparence du projet... je préfèrerais qu'on parle des progrès
important apportés:

- cgroups => gestion des ressources par service
- PrivateTmp => limite tellement de bugs liés à l'utilisation de /tmp
- PrivateNetwork => pourquoi donner le réseau à un service qui n'en as
pas besoin ?
- User/Group => oui changé d'utilisateur nécessite pas mal de code dans
chaque service qui a si souvent été l'objet de bug de sécurité...
(abandon des groupes notamment)
- etc

L'argument de complexité... FUD encore.
Qu'est ce qui est complexe ?  L'écriture  des fichier de config ?
L'exemple précédent me semble prouver le contraire.
L'utilisation. Là, effectivement, c'est indiscutable...

Avant j'utilisais [3]
	service  foo  start

Maintenant, j'utilise
	service  foo  start

Quel effort !

Je pense que l'un des principaux freins à systemd c'est le comportement
"j'ai peur du neuf, je veux pas changer ce que je connais". Je ne dis
pas qu'il ne faut pas se poser de questions, et d'ailleurs Debian à, je
pense, murement réfléchi à la question [4]. Mais comme souvent, il me
semble nécessaire de tester, d'utiliser, pour se faire une opinion réaliste.


Après, on pourrait se concentrer sur des points particuliers de mise en
oeuvre.


Remi.






[1] il faut rendre à césar... et je suis fier d'y avoir participé.
[2] histoire de montrer que c'est upstream
[3] oui je sais, il y a encore des adeptes du "/etc/rc.d/foo start"
alors que cette méthode a toujours était mauvaise et problématique (env
utilisateur vs environnement système)
[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708 pour ceux
qui auraient le courage de le lire en entier... ;)

Serveur hébergé par ST-Hebergement et Lost-Oasis / IRC hébergé par FreeNode / NS secondaire hébergé par XName
Sauf mention contraire, les documentations publiées sont sous licence Creative-Commons