Vraiment triste que son usage s'impose comme la norme par suivisme de DeadRat, dans les distributions principales,
Là tu insultes l’intelligence de l’ensemble des mainteneurs des distributions concernés ayant effectué ce choix.
avec les problèmes fondamentaux qu'il entraîne.
Bah à part la façon dont le projet est géré, je ne vois en quoi les distributions fonctionnent moins bien.
Beaucoup de propagande pour présenter systemd comme une rupture et un progrès inéluctables,
Bah, de la publicité pour le logiciel ça n’est pas interdit? Jusqu’à présent, je ne crois pas qu’il y ait beaucoup de mensonges à propos de systemd (s’il y en a eu).
et une mise à l'écart malsaine et malhonnête des nombreuses alternatives sensées.
systemd flies in the face of the Unix philosophy: "do one thing and do it well," representing a complex collection of dozens of tightly coupled binaries1. Its responsibilities grossly exceed that of an init system, as it goes on to handle power management, device management, mount points, cron, disk encryption, socket API/inetd, syslog, network configuration, login/session management, readahead, GPT partition discovery, container registration, hostname/locale/time management, and other things. Keep it simple, stupid.
In a way, you are right. systemd centralizes complexity from tons of init scripts into a single place. However, it therefore makes it very easy for maintainers to write service files (equivalent of an init script) and provides a consistent and reliable interface for service management. Furthermore, it is different than sysvinit, and different solutions often seem complex at first. While systemd consumes more resources than sysvinit, it uses them to make more information available about services; its finer-grained service management requires more state-keeping, but in turn offers you more control over your services.
Ah, et peut-être que la philosophie Unix ne s’applique pas à tous les cas, de façon littérale, telle une religion. De plus systemd n’est pas un énorme composant unique mais plutôt bien découpé.
systemd's journal files (handled by journald) are stored in a complicated binary format2, and must be queried using journalctl. This makes journal logs potentially corruptible, as they do not have ACID-compliant transactions. You typically don't want that to happen to your syslogs. The advice of the systemd developers? Ignore it. No, seriously. Oh, and there's embedded HTTP server integration (libmicrohttpd). QR codes are served, as well, through libqrencode.
Ça tombe bien, on est pas censé gérer le journal, c’est journald qui s’occupe de nous sortir quelque chose d’intelligible (un peu comme une base de données et son frontal). Autrement, je dirais que le format est complet, extensible et bien documenté. Pas vraiment une catastrophe.
Pour la corruption, ça arrive rarement et il est possible (si ça n’est pas le cas par défaut) de faire de la rotation de journaux. Je ne saurais dire autrement si le format en lui-même peut permettre de retrouver facilement les bonnes informations après corruption partielle cependant.
Quand à la mention des deux bibliothèques, Lennart y a répondu. Je ne me prononcerais pas sur la pertinence, mais franchement quand on sait que ça peut être utile et très léger, il n’y a pas de quoi en faire tout en fromage.
systemd's team is noticeably chauvinistic and anti-Unix, due to their open disregard for non-Linux software and subsequent systemd incompatibility with all non-Linux systems. Since systemd is very tightly welded with the Linux kernel API, this also makes different systemd versions incompatible with different kernel versions. This is an isolationist policy that essentially binds the Linux ecosystem into its own cage, and serves as an obstacle to software portability.
Au cas où cette argument n’a pas été suffisamment démonté: c’est un procès d’intention (ils ne font pas un site s’appelant boycottunix.org non plus hein), les deux précédentes solutions ne fonctionnent pas sur BSD[1] (scripts d’initialisation propres à chaque distribution ou Upstart). De plus ça ne change rien à la portabilité des logiciels ou à un quelconque enfermement (comme dit avant, les autres solutions ne marchaient pas mieux sur BSD).
udev and dbus are forced dependencies. In fact, udev merged with systemd a long time ago3. The integration of the device node manager that was once part of the Linux kernel is not a decision that is to be taken lightly. The political implications of it are high, and it makes a lot of packages dependent on udev, in turn dependent on systemd, despite the existence of forks, such as eudev. Starting with systemd-209, the developers now have their own, non-standard and sparsely documented sd-bus API that replaces much of libdbus's job, and further decreases transparency.
J’ai l’impression que c’est la faute de systemd alors que la fusion a eu lieu parce que son mainteneur a bien voulu. Et malgré tout ce qu’on pourra dire, c’est bien le droit du mainteneur du logiciel d’en faire ce qu’il veut, même si ça ne nous plait pas...
Ceci étant dit, on peut regretter que la compatibilité avec les systèmes non-systemd ne soit pas assurée. D’un autre côté le projet s’appelle systemd. L’équipe de systemd a déjà fait un gros boulot pour prendre en charge les anciens scripts d’initialisation.
Au lieu que chaque distribution ait sont truc à maintenir, il n’y aura du boulot que pour ceux n’utilisant pas systemd, ce qui est dommage mais logique (et les distributions non-systemd peuvent mutualiser leurs efforts également).
Mais allons directement à l’avant-dernier argument:
Ultimately, systemd's parasitism is symbolic of something more than systemd itself. It shows a radical shift in thinking by the Linux community. Not necessarily a positive one, either. One that is vehemently postmodern, monolithic, heavily desktop-oriented, choice-limiting, isolationist, reinvents the flat tire, and just a huge anti-pattern in general. If your goal is to pander to the lowest common denominator, so be it. We will look for alternatives, however.
On dirait le discours des anti-mariage pour tous, pathétique. La moitié des choses est choses.
postmodern
Anticiper un peu le futur c’est mal? On préfère rester des vieux cons et avoir un métro de retard comme d’habitude?
monolithic
Ai-je besoin de dire pourquoi c’est faux?
heavily desktop-oriented
Ça n’empêche pas de fonctionner sur serveur (et systemd existe en embarqué aussi — quand ça n’est pas possible de l’utiliser c’est pareil qu’avant, on fait un truc personnalisé).
choice-limiting
Certes, ça demande un peu de travail pour ceux qui n’utilisent pas la solution standard. Mais encore une fois je trouve qu’on exagère en disant vehemantly.
isolationist
En quoi ça isole Linux de quoi? Avant c’était en théorie portable sur BSD mais tout le monde s’en foutait. Maintenant c’est plus possible et BSD s’en fout.
reinvents the flat tire
Ils ont refait Upstart en mieux, et à priori les démons que l’on appelle NIH sont simplement des versions légères pour les cas les plus simples et donc les plus courants (genre presque tout le monde, les autres sauront modifier, avec systemd c’est pas compliqué).
just a huge anti-pattern
Sérieusement? Je pourrais dire la même chose de ce qu’il y avait avant...
Est-ce que je dois continuer ou c’est bon? Ce site web contient beaucoup d’arguments mille fois démontés, dommage ça noie les arguments pertinents dans la masse de connerie.
[1]: On peut remplacer BSD par autre choses hein, c’est juste que c’est le plus souvent cité.
[^] # Re: Assimilation forcée
Posté par ariasuni . En réponse à la dépêche systemd versions 212 à 215. Évalué à 6.
Là tu insultes l’intelligence de l’ensemble des mainteneurs des distributions concernés ayant effectué ce choix.
Bah à part la façon dont le projet est géré, je ne vois en quoi les distributions fonctionnent moins bien.
Bah, de la publicité pour le logiciel ça n’est pas interdit? Jusqu’à présent, je ne crois pas qu’il y ait beaucoup de mensonges à propos de systemd (s’il y en a eu).
Ouais, non.
Ça fait du bien de rigoler de temps en temps.
Sur la page du lien de la note 1, on y trouve une «justification» de l’argument 1. Or sur cette même page, il lien vers une page du même auteur qui démonte complètement cet argument.
Ah, et peut-être que la philosophie Unix ne s’applique pas à tous les cas, de façon littérale, telle une religion. De plus systemd n’est pas un énorme composant unique mais plutôt bien découpé.
Ça tombe bien, on est pas censé gérer le journal, c’est journald qui s’occupe de nous sortir quelque chose d’intelligible (un peu comme une base de données et son frontal). Autrement, je dirais que le format est complet, extensible et bien documenté. Pas vraiment une catastrophe.
Pour la corruption, ça arrive rarement et il est possible (si ça n’est pas le cas par défaut) de faire de la rotation de journaux. Je ne saurais dire autrement si le format en lui-même peut permettre de retrouver facilement les bonnes informations après corruption partielle cependant.
Quand à la mention des deux bibliothèques, Lennart y a répondu. Je ne me prononcerais pas sur la pertinence, mais franchement quand on sait que ça peut être utile et très léger, il n’y a pas de quoi en faire tout en fromage.
Au cas où cette argument n’a pas été suffisamment démonté: c’est un procès d’intention (ils ne font pas un site s’appelant boycottunix.org non plus hein), les deux précédentes solutions ne fonctionnent pas sur BSD[1] (scripts d’initialisation propres à chaque distribution ou Upstart). De plus ça ne change rien à la portabilité des logiciels ou à un quelconque enfermement (comme dit avant, les autres solutions ne marchaient pas mieux sur BSD).
J’ai l’impression que c’est la faute de systemd alors que la fusion a eu lieu parce que son mainteneur a bien voulu. Et malgré tout ce qu’on pourra dire, c’est bien le droit du mainteneur du logiciel d’en faire ce qu’il veut, même si ça ne nous plait pas...
Ceci étant dit, on peut regretter que la compatibilité avec les systèmes non-systemd ne soit pas assurée. D’un autre côté le projet s’appelle systemd. L’équipe de systemd a déjà fait un gros boulot pour prendre en charge les anciens scripts d’initialisation.
Au lieu que chaque distribution ait sont truc à maintenir, il n’y aura du boulot que pour ceux n’utilisant pas systemd, ce qui est dommage mais logique (et les distributions non-systemd peuvent mutualiser leurs efforts également).
Mais allons directement à l’avant-dernier argument:
On dirait le discours des anti-mariage pour tous, pathétique. La moitié des choses est choses.
Anticiper un peu le futur c’est mal? On préfère rester des vieux cons et avoir un métro de retard comme d’habitude?
Ai-je besoin de dire pourquoi c’est faux?
Ça n’empêche pas de fonctionner sur serveur (et systemd existe en embarqué aussi — quand ça n’est pas possible de l’utiliser c’est pareil qu’avant, on fait un truc personnalisé).
Certes, ça demande un peu de travail pour ceux qui n’utilisent pas la solution standard. Mais encore une fois je trouve qu’on exagère en disant vehemantly.
En quoi ça isole Linux de quoi? Avant c’était en théorie portable sur BSD mais tout le monde s’en foutait. Maintenant c’est plus possible et BSD s’en fout.
Ils ont refait Upstart en mieux, et à priori les démons que l’on appelle NIH sont simplement des versions légères pour les cas les plus simples et donc les plus courants (genre presque tout le monde, les autres sauront modifier, avec systemd c’est pas compliqué).
Sérieusement? Je pourrais dire la même chose de ce qu’il y avait avant...
Est-ce que je dois continuer ou c’est bon? Ce site web contient beaucoup d’arguments mille fois démontés, dommage ça noie les arguments pertinents dans la masse de connerie.
[1]: On peut remplacer BSD par autre choses hein, c’est juste que c’est le plus souvent cité.
Écrit en Bépo selon l’orthographe de 1990