Re: Surprenant, non ?

Pour être honnête, j'ai trouvé surpenant la venue progressive de systemd dans les distributions : RHEL6/RHEL7/Debian Jessie/Arch Linux/...

Ce n'est pas si surprenant. systemd a prouvé qu'il était bien plus utile et utilisable que SysV. Ce qui aurait été surprenant, c'est que tout le monde l'adopte sans se poser de questions, ce qui n'a pas été le cas.

et toujours notre ami la distribution Ubuntu qui n'en fait qu'à sa tête avec Upstart :)

Oui enfin Ubuntu a prévu d'adopter systemd suite à l'adoption de systemd par Debian.

mais ubuntu a certainement donné des idées à d'autres quant au choix de systemd.

Bah systemd s'inspire de Upstart et launchd.

le SysV c'est vraiment l'histoire découlant d'UNIX, un monument, le remplacer du jour au lendemain... ça fait un choc,

Bah ce n'est qu'un logiciel. Je comprends pas trop cet attachement.

mais je trouve que les changements/évolutions n'ont jamais été autant marqués que ces derniers temps... et cela ne s'arrête pas à systemd, les nouvelles commandes tel que ip address, ip rules, ip link etc... devant faire à terme des commandes existantes (tel que ifconfig / route ...) depuis des dizaines d'années. L'industrie et les acteurs du monde s'y intéressent de plus en plus.

Bah d'une part je vois pas en quoi c'est un mal de changer les logiciels. Surtout que ce n'est jamais changer pour changer (il y a des arguments techniques pour ip, pour systemd, pour wayland, ... Et une implémentation qui marche plutôt qu'un énième standard théorique et irréaliste qui ne sera pas utilisé)

Quelques questions se posent :
Malgré l'accord entre la majorité des poids lourds des distributions, systemd sera t-il une mode ou deviendra t-il obsolète dans quelques temps ?

Bah tout logiciel naît, vit, est utilisé, et meurt. On l'a vu avec SysV, qui fut au final qu'une mode. ;-)

systemd doit permettre de mieux gérer le lancement des scripts avec les dépendances, cela semble noble, mais quid de la stabilité et de la pérennité.

stabilité

Si c'est la stabilité au sens "fiabilité", perso j'ai rien à reprocher à systemd de ce côté là.

Si c'est au sens Debian, je dirais que c'est OK :
- compatible avec les scripts SysV
- nul besoin d'écrire une unité pour la distribution X, une autre pour la distribution Y, et encore une autre pour la distribution Z. On l'écrit une fois et c'est réglé. Et ça fonctionne avec les futurs versions de systemd.

pérennité

Vu que systemd a un code clair et accompagné de tests unitaires, et qu'il est bien plus documenté que ne l'a été SysV ou Upstart, je dirais qu'il est assez pérenne. :-p

Au delà, je crois que beaucoup de gens du libre confondent stabilité et immobilisme. A chaque fois que Linux change, les BSDistes disent que ça change encore uniquement pour changer (alors que ce n'est jamais le cas).

L'autre jour encore dans un édito d'un hors-série de GN/Linux pratique sur les systèmes *BSD (un "mook", il paraît), je suis tombé sur ces deux perles :

une avalanche de technologies les unes après les autres tels que DRI, DRM, GEM, ... Alors que *BSD réfléchit avant de coder

(je résume le troll de l'auteur avec la dernière phrase)

Peut être qu'en bougeant peu un logiciel peut donner l'impression d'être parfait. Mais pour moi c'est surtout le signe d'un manque de contributeurs, comme c'est le cas chez Xfce par exemple.

Et puis, en tant qu'utilisateur de Linux, l'avalanche de technologies noyau... Comment dire... Ah oui : ça touche une oreille sans faire remuer l'autre.

Oui, il y a des changements à une vitesse peut-être affolante. Mais :
1. Je vois pas en quoi ça devrait m'affoler. Au mieux, ça m'excite. ;-) (comme kf5)
2.Ça ne m'a jamais cassé ma distrib du jour au lendemain (même sous Arch ;-) ) car les développeurs noyaux font tout pour ne pas casser l'userspace, que les mainteneurs de distribs font leur boulot, et que ce sont ici des APIs noyau qui sont très loin de concerner l'utilisateur lambda.

un init simple, à la place du tentaculaire systemd

l'auteur confond encore systemd le binaire qui ne s'occupe que de l'init, et systemd le projet qui regroupent des dizaines d'utilitaires qui font chacun une tâche et qui la font bien. ;-)

Ces simplifications ne viennent-elles pas des besoins du monde de la virtualisation et par extension du "cloud" ? : faciliter l'accès/l'administration de linux tel OpenLMI en mettant une couche d'abstraction permettant à terme de faire des opérations depuis l'hyperviseur directement ou depuis l'interface d'administration du cloud ?

SysV n'était pas une bonne abstraction. On devait revenir tout le temps sur son script parce que la distribution X n'est pas compatible et qu'on avait écrit ce script avec la distribution Y à l'esprit. Quant à la compatibilité avec les *BSD dudit script, c'était encore une autre histoire...

Une abstraction qui m'oblige à savoir comment elle fonctionne pour l'utiliser, ce n'est pas une abstraction.
C'est juste du boulot pas intéressant en plus.

Ne va t-on pas devenu des pousses boutons ou certains ne souhaitent ils pas que l'on devienne des pousses boutons à force de mettre des niveaux d'abstractions et donc ne plus avoir besoin de comprendre pour l'utiliser ?

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)