Cela ne m'empêche pas d'être inquiété, comme d'autres, par le fait que systemd remplace des dépendances vers un composant sous-jacent au choix par des dépendances (certes unilatérales) vers un composant sous-jacent imposé, à plusieurs niveaux. Le nier, ou esquiver plutôt que d'expliquer en quoi c'est faux, ne fera pas avancer le débat.
Bah ça c'est autre chose : c'est depuis le début le parti pris de systemd de gérer une base de code dans un tout cohérent, dans le même dépôt.
On the other hand, there is a central repository, a single place where you can find the entire operating system sources, including all older versions.
BSD projects maintain the entire "Operating System", not only the kernel. This distinction is only marginally useful: neither BSD nor Linux is useful without applications. The applications used under BSD are frequently the same as the applications used under Linux.
As a result of the formalized maintenance of a single CVS source tree, BSD development is clear, and it is possible to access any version of the system by release number or by date. CVS also allows incremental updates to the system: for example, the FreeBSD repository is updated about 100 times a day. Most of these changes are small.
Alors certes on a pas encore le kernel Linux dans le même dépôt/projet, mais avoir systemd + udev + les outils systemd (systemctl, journalctl, ...) ensemble c'est voulu.
Myth: systemd is not UNIX.
In fact the design of systemd as a suite of integrated tools that each have their individual purposes but when used together are more than just the sum of the parts, that's pretty much at the core of UNIX philosophy. Then, the way our project is handled (i.e. maintaining much of the core OS in a single git repository) is much closer to the BSD model (which is a true UNIX, unlike Linux) of doing things (where most of the core OS is kept in a single CVS/SVN repository) than things on Linux ever were.
Dans ce sens, dire "on ne soutient plus les config udev sans systemd" pour moi ça veut dire que les configs udev sans systemd ne sont tous simplement pas testées. C'est responsable et logique de dire que ceux qui sortent des configs testés le font à leurs risques et périls.
De là à dire que udev dépend de systemd faudrait savoir si c'est vraiment le cas (suffit d'essayer de booter la dernière version de udev sans systemd). Je suis pas non plus pour dire si c'est un gros plat de spaghetti sans voir le code.
[^] # Re: Description de systemd ?
Posté par xcomcmdr . En réponse à la dépêche systemd versions 212 à 215. Évalué à 6. Dernière modification le 09 octobre 2014 à 13:05.
Bah ça c'est autre chose : c'est depuis le début le parti pris de systemd de gérer une base de code dans un tout cohérent, dans le même dépôt.
C'est du "à la BSD" si je ne m'abuse :
Alors certes on a pas encore le kernel Linux dans le même dépôt/projet, mais avoir systemd + udev + les outils systemd (systemctl, journalctl, ...) ensemble c'est voulu.
Dans ce sens, dire "on ne soutient plus les config udev sans systemd" pour moi ça veut dire que les configs udev sans systemd ne sont tous simplement pas testées. C'est responsable et logique de dire que ceux qui sortent des configs testés le font à leurs risques et périls.
De là à dire que udev dépend de systemd faudrait savoir si c'est vraiment le cas (suffit d'essayer de booter la dernière version de udev sans systemd). Je suis pas non plus pour dire si c'est un gros plat de spaghetti sans voir le code.
Et de là à dire qu'on ne peut pas remplacer les outils/implémentations d'APIs de systemd par d'autres :
- Ubuntu a utilisé systemd-logind avec Upstart
- OpenBSD réimplémente les parties de Gnome 3 dont systemd dépend (timedated, localed, hostnamed and logind).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)