jp willm , dans le message <rb529b$me3$1>, a écrit :
> S6 ?

Principalement, oui. L'auteur connaît très bien son sujet, mais il est assez
seul.

Le 01-06-2020, JKB <jkb> a écrit :
> Le 01 Jun 2020 18:32:04 GMT, Stéphane CARPENTIER <sc>
> écrivait :
> Non, le fait que ce soit lancé en parallèle ne fait pas toujours
> gagner du temps.

Oui, OK, je me suis mal exprimé, je voulais dire que ça pouvait faire
gagner du temps, pas que c'était toujours le cas.

> Quant à l'ordre de démarrage, c'est souvent un peu la roulette
> russe.

Je ne sais pas si c'est très bien géré, mais dans ce que j'ai vu, tu
peux demander un ordre relatif aux tâches (par exemple : ne pas lancer
ntp avant d'avoir le réseau).

>> Je ne me suis pas plongé dans la compréhension de systemd, j'ai juste
>> regardé les parties qui posaient problème lors de l'installation.
> En fait, tout pose problème dans systemd lorsqu'on commence à
> creuser et qu'on a une configuration

Oui, mais encore une fois, c'est pas parce que tu as de bonnes raisons
de vouloir partir que je doive être concerné par ces raisons. Je ne dis
pas que tu dois y retourner. Je dis que je n'ai pas vu de raison de
quitter.

J'ai pas de problème de mémoire et mon ordinateur est à côté de moi.

> qui n'est pas celle de madame Michu.

Parlons-en de madame Michu, justement.

Donc, madame Michu, on lui installe Ubuntu parce que c'est facile. Avec
Ubuntu il y a plein de trucs qui sont lancés, parce que peut-être que ça
pourrait servir mais on sait jamais, en plus des trucs dont elle a
besoin. Lorsque madame Michu lance son ordinateur, c'est un super
gestionnaire de login graphique qui est lancé. Ce super gestionnaire
lance Gnome ou KDE qui déchirent et qui eux aussi lancent plein de trucs
qui pourraient lui servir on sait jamais. La première chose qu'elle fait
une fois connectée, c'est de lancer Firefox avec plein de plugin parce
qu'elle veut aller sur Internet.

Et après on voudrait m'expliquer que les problèmes de performance du
Linux de madame Michu, ça vient de systemd qui est le mal absolu et que
c'est scandaleux.

Ben désolé, mais moi j'ai pas de gestionnaire de login graphique, j'ai
pas de Gonme/KDE, j'ai pas firefox, j'ai pas de gestionnaire de
fichiers qui roxe... Mais j'ai 8 c?urs et 16Go de RAM. Et donc, les
problèmes de performance, je ne suis pas concerné. Vraiment pas.

Donc, que tu aies des machines limitées qui doivent être optimisées je
le conçois. Mais je ne suis pas concerné.

> Le problème de systemd vis à vis de Linux est le même que celui de
> Linux vis à vis de POSIX. Les sources POSIX sont polluées de
> linuxismes,

Oui, ça j'ai lu des critiques sur le fait que systemd ne soit pas
compatible POSIX. Mais pour moi la question est peut-être posée à l'envers.
Est-ce que les incompatibilités répondent à un manque de POSIX ou pas ?
S'il n'y a pas de manque du côté de POSIX, c'est mal. S'il y a un manque
du côté de POSIX, peut-être qu'il faudrait faire évoluer POSIX pour
combler le manque.

Je ne suis pas capable de répondre à cette question. Mais s'accrocher à
une norme parce qu'elle est bien est une bonne chose. Alors que pour
moi, s'accrocher à une norme par principe, même si elle est périmée par
une décision prise il y a quarante ans est néfaste.

Si le besoin est réel, les gens essayeront de s'en affranchir. Quoiqu'il
arrive. Si la norme évolue, ils essayeront globalement de la suivre. Si
la norme est figée, ils feront des adaptations chacun dans son coin et
ça va augmenter les incompatibilités.

Le 01-06-2020, festiventu <festiventu> a écrit :
> Le 28/05/2020 à 18:47, Stéphane CARPENTIER a écrit :
>> Ma première distribution, c'était une slackware, j'ai mangé grave pour
>> faire reconnaitre le lecteur de CD et la carte graphique. Il fallait
>> aussi recompiler mon noyau et tout ça (vers 94/95). À l'époque la doc
>> était éparse (plein de HOWTO sur le CD de la distribution) et
>> entièrement en anglais (à l'époque c'était un problème pour moi).
> Me too, une slack avec un noyo 1.2.13. Quelle époque épique !!!

J'avais dû mettre le noyau 1.3.chaipu parce que le lecteur de CD EIDE
était encore expérimental.

Stéphane CARPENTIER , dans le message
<slrnrdc91b.2ip.sc>, a écrit :
> Et après on voudrait m'expliquer que les problèmes de performance du
> Linux de madame Michu, ça vient de systemd qui est le mal absolu et que
> c'est scandaleux.

Je crois que tu as très bien résumé la situation.

systemd, sur une machine en train de tourner, ne fait strictement rien.

> Oui, ça j'ai lu des critiques sur le fait que systemd ne soit pas
> compatible POSIX. Mais pour moi la question est peut-être posée à l'envers.
> Est-ce que les incompatibilités répondent à un manque de POSIX ou pas ?

POSIX parle d'interfaces système, pas d'administration. Reprocher à systemd
de ne pas respecter POSIX est à peu près aussi pertinent que de lui
reprocher de ne pas respecter cee-onu ffv-36 (concernant la
commercialisation et le contrôle de la qualité commerciale des TOMATES).

> Je ne suis pas capable de répondre à cette question. Mais s'accrocher à
> une norme parce qu'elle est bien est une bonne chose. Alors que pour
> moi, s'accrocher à une norme par principe, même si elle est périmée par
> une décision prise il y a quarante ans est néfaste.

C'est un autre débat, mais tu as raison, c'est quelque chose dont il faut
parler.

Internet, et en particulier le web, est envahi de standards moisis, conçus
plus pour permettre aux publicitaires de nous traquer et de nous infliger
leur daube que pour le bien des utilisateurs. Comme ce sont des standards
industriels, ils sont conçus non pas dans un objectif de simplicité et
d'efficacité, mais avec comme principale considération le fait d'être
compatible avec les produits existants des principaux acteurs payants de la
standardisation.

Mais les auteurs de logiciels libres ont tellement internalisé l'impératif
« il faut respecter les standards » qu'ils essaient d'implémenter ces
standards au lieu d'inventer de meilleurs protocoles. Le résultat est que
plein de logiciels sont des moussakas géantes, qui marchent si on n'a pas un
trop mauvais karma dans les circonstances précises pour lesquelles elles
sont prévues, mais qui sont impossibles à adapter à des circonstances
particulières, comme les faire tourner sur un VPN.

Parfois, ce sont tellement des moussakas géantes qu'il est même impossible
de les compiler soi-même, et même les distributions n'y arrivent pas. La
seule solution est d'installer des paquets binaires, mais on prétend quand
même que c'est du logiciel libre.

Exemples :

- Les logiciels de vidéoconférence. Il y en a qui prétendent être Open
Source, mais pas un ne peut être installé à partir des sources sur une
distribution quelconque par un administrateur raisonnablement compétent
(qu'on me contredise ! par pitié qu'on me contredise ! qu'on me pointe
vers quelqu'un qui a réussi !), donc aucun n'est vraiment libre.

- Les serveurs de média, pour compatibilité avec les télés connectées. On
voit des paquets multicast passer, personne ne répond, le serveur ne
produit aucun log.

Le 02/06/2020 à 11:32, Nicolas George a écrit :
> jp willm , dans le message <rb529b$me3$1>, a écrit :
>> S6 ?
> Principalement, oui. L'auteur connaît très bien son sujet, mais il est assez
> seul.

Oui, j'ai vu ; je l'aiderais bien si j'en avais les compétences...

Et dire que ce gars, pour des raisons d'éthique, a refusé une carrière
dont beaucoup rêveraient.
<https://sysdfree.wordpress.com/2020/05/24/316/>

Le 02-06-2020, jp willm <nicole.jeanpaul.willm> a écrit :
> Le 02/06/2020 à 00:01, Stéphane CARPENTIER a écrit :
>> Pour quelle raison me prendre la tête à changer un truc
>> qui marche bien alors que j'ai plein de choses à faire ?
> Le jour où ce "truc qui marche bien" sera devenu encore plus obèse et
> abscons, mais sera indécrottable de toute distribution Linux, on ne se
> posera plus cette question.

C'est peu probable, des critiques il y en a et elles sont justifiées.
Sauf que des arguments expliquant ce qui est mieux (plutôt que de
pointer vers ce qui est mieux qui est différent) j'en vois moins.

Donc, j'imagine que les concurrents vont monter en maturité et qu'il y
aura de vrais arguments dans le futur. Et que à ce moment là, Archlinux
(si c'est toujours la distribution que j'utilise) basculera vers ce qui
est mieux. Et ça se fera plus simplement que si je bascule de moi-même
en avance de phase.

La question est surtout de savoir si j'aurai besoin de basculer de
moi-même en avance de phase ou si la migration sera faite avant que j'en
ai besoin. En supposant que j'en ai besoin, car ils peuvent aussi
améliorer systemd.

> On est en pleine politique, mais cela vaut le coup de lire un peu :
> [..]

Voilà, c'est ça. N'importe quoi autre que systemd c'est mieux. Mais sans
explication. Moi, je n'achète pas.

> Je ne suis pas informaticien, mais j'observe que l'opensource est
> partout et commence à être contrôlé par de très grandes multinationales.
> Embrace, extend and extinguish :
><https://fr.wikipedia.org/wiki/Embrace,_extend_and_extinguish>

Oui, mais en fait, moi, c'est pas la panique qui me fait avancer.

Surtout que c'est toujours le même problème et c'est pour ça que les
arguments qui disent que tout est mieux sauf systemd sont mauvais. Il
n'y a rien de factuel et c'est mauvais.

Quand c'est sysV qui est universel, c'est bien ça simplifie la gestion
et la portabilité. Quand c'est systemd, c'est d'abord mal parce que
c'est plus compatible. Et une fois que tous les systèmes sont
compatibles, ça devient mal parce que c'est systemd qui s'est imposé.
Donc, la morale à géométrie variable, ça me passe très au dessus.

Mais pourquoi est-ce que c'est mieux que sysV soit partout et pas
systemd ? Il n'y a pas d'argument sérieux. Les arguments se contredisent
parce que tu ne peux pas avoir à la fois une diversité et une
homogénéité.

Il y a des arguments techniques pour me montrer les problèmes de
systemd. Mais il n'y a aucune explication pour me montrer en quoi la
conception (et pas leur utilisation) des alternatives est mieux.

Donc, moi, j'ai mieux à faire. Et les arguments me disant qu'il faut
penser aux autres ne tiennent pas la route. Quand on n'a plus d'argument
valable, on bascule sur l'affect et j'arrête d'écouter. Ça n'a pas
d'intérêt. Si on me montre que mon action est néfaste, je peux me sentir
coupable. Si on me dit que mon action est néfaste mais qu'on est
incapable de me montrer pourquoi, je ne me sens pas obligé de
l'accepter.

>> À mon avis, si systemd est vraiment si mal et que le reste est vraiment
>> mieux, Archlinux quittera systemd pour aller vers autre chose.
> Je me suis aussi déjà fait cette réflexion : espérons...

Je dis Archlinux parce que je suis actuellement dessus et que ça me
plaît bien. Mais si ça change trop, je pourrais aussi quitter Archlinux.

> Toutefois, j'ai lu qu'un des principaux développeurs de Arch travaille
> chez IBM Redhat, chez qui ?uvre aussi l'inventeur de systemd.

D'abord, Archlinux est une distribution à la fois minimale et bleeding
edge, ce que n'est vraiment pas Red Hat. Le gestionnaire de paquet n'a
rien à voir non plus. Les motivations ne sont vraiment pas les mêmes et
ça me surprendrait qu'il se focalise juste sur systemd pour
homogénéisation alors que tout le reste est différent.

Ensuite, systemd est parti d'une bonne chose. Malgré les critiques, son
inventeur a fait du bien à l'initialisation des systèmes. Que ce soit
avec la création de systemd pour utilisation. Ou que ce soit pour
motiver les autres à proposer une alternative. Sans son inventeur, on
serait probablement encore à sysV un peu partout.

Le 02/06/2020 à 13:02, Stéphane CARPENTIER a écrit :

> La question est surtout de savoir si j'aurai besoin de basculer de
> moi-même en avance de phase ou si la migration sera faite avant que j'en
> ai besoin. En supposant que j'en ai besoin, car ils peuvent aussi
> améliorer systemd.

En attendant que la foule suive, "ils" ont aussi besoin des rapports de
bugs.

Le 02-06-2020, Nicolas George <nicolas$george> a écrit :
> Stéphane CARPENTIER , dans le message
><slrnrdc91b.2ip.sc>, a écrit :
> C'est un autre débat, mais tu as raison, c'est quelque chose dont il
> faut parler.

Oui, je suis conscient que c'est un autre débat. Mais ce que tu
expliques après, va dans le sens que j'imaginais et c'est pour ça que
j'en ai parlé. Les deux débats sont très liés.

Le 02-06-2020, jp willm <nicole.jeanpaul.willm> a écrit :
> Le 02/06/2020 à 13:02, Stéphane CARPENTIER a écrit :
>> La question est surtout de savoir si j'aurai besoin de basculer de
>> moi-même en avance de phase ou si la migration sera faite avant que
>> j'en ai besoin. En supposant que j'en ai besoin, car ils peuvent
>> aussi améliorer systemd.
> En attendant que la foule suive, "ils" ont aussi besoin des rapports
> de bugs.

Oui, mais c'est qui « ils » ? Je ne vais pas installer toutes les
alternatives en parallèle juste pour pouvoir envoyer des rapports de
bugs à tout le monde. Et pourquoi systemd n'aurait pas besoin de rapport
de bug pour s'améliorer ?

Parce que l'un des trucs qui est reproché à systemd (sur plein de liens
que tu m'as montré mais aussi sur d'autres que j'avais déjà vu) est leur
arrogance. Mais quand je vois ces sites, ils ne font que de la
destruction de systemd sans la moindre proposition d'amélioration. Oui,
je sais, c'est la conception qui est mauvaise : c'est pas possible de
l'améliorer, il faut le quitter. Mais j'ai du mal à croire que toutes
les alternatives sont bien conçues et que seul systemd est mal conçu
alors que c'est répandu sur des distributions qui n'ont pas les mêmes
objectifs (ie : choix différents, même conclusion).

Je ne sais pas comment la situation actuelle en est arrivée là. Mais
personnellement, je comprends que les développeurs de systemd, qui font
quelque chose de constructif (bien ou pas n'est pas la question : ils
avancent), soient arrogant vis-à-vis de ceux qui leur font la chasse aux
sorcières. J'ai tendance à faire pareil et à mépriser ceux qui ne savent
que critiquer.

Et là, comme ça, rien ne me dit que systemd ne va pas s'améliorer. Rien
ne me dit que systemd est sûr de me poser problème à court terme. Rien
ne me dit que l'éventuel remplacement de systemd existe déjà. Rien ne me
dit qu'il y a quelque chose de mieux que systemd que j'ai intérêt à
utiliser. Je ne me sens pas obligé d'aboyer avec les loups pour dire que
tout est bien sauf systemd.

Le pire, c'est qu'au début j'avais envie de détester systemd et d'avoir
plein d'arguments pour migrer, en faisant un effort, mais pour faire une
bonne action en améliorant mon système. Mais en fait, plus je lis et
plus je vois que les raisons de partir sont des cas particuliers (qui
sont valables, je ne le nie pas, mais ils ne me concernent pas). Plus
j'ai l'impression que c'est une guerre de religion à laquelle je n'ai vu
aucune raison de participer.

Autant les guerres contre Microsoft, Apple, Android, Google, Facebook,
Amazon et Uber (entre autres), j'ai vu plein d'arguments sérieux. Autant
la guerre contre systemd je n'ai rien vu.

Le Tue, 02 Jun 2020 11:02:47 +0000, Stéphane CARPENTIER a écrit :

>> Toutefois, j'ai lu qu'un des principaux développeurs de Arch travaille
>> chez IBM Redhat, chez qui ?uvre aussi l'inventeur de systemd.
> D'abord, Archlinux est une distribution à la fois minimale et bleeding
> edge, ce que n'est vraiment pas Red Hat. Le gestionnaire de paquet n'a
> rien à voir non plus. Les motivations ne sont vraiment pas les mêmes et
> ça me surprendrait qu'il se focalise juste sur systemd pour
> homogénéisation alors que tout le reste est différent.

De mémoire, Archlinux est passée à systemd parce que c'est le truc que
tout le monde utilisait et que pour un certain nombre de services les
mainteneurs d'Arch allait devoir commencer à maintenir eux-mêmes les
scripts à l'ancienne. Du moins c'est ce qu'ils ont annoncé, je ne suis
pas allé vérifier. Il me semble que l'annonce indiquait que si des gens
étaient vraiment intéressés pour faire ce travail, ils pouvaient se faire
connaître. C'est arrivé lors d'un autre choix, quand Archlinux a
abandonné le x86 32 bits ; et des gens sont allés mettre en place arch32
pour assurer la maintenance.

Arch étant une distribution qui propose des logiciels les moins modifiés
possibles, c'est plutôt cohérent de faire comme tout le monde quand les
autres se tournent vers une solution technique particulière, à moins
qu'une autre solution ait de très gros avantages. Devoir maintenir dans
leur coin des spécificités sur tout un tas de paquets, ce n'est pas trop
l'esprit de cette distribution (contrairement à Debian par exemple).

Yliur , dans le message <rb6tbe$5dc$1>, a écrit :
> De mémoire, Archlinux est passée à systemd parce que c'est le truc que
> tout le monde utilisait et que pour un certain nombre de services les
> mainteneurs d'Arch allait devoir commencer à maintenir eux-mêmes les
> scripts à l'ancienne.

Ça ne me semble pas très crédible. C'est de toutes façons le rôle d'une
distribution de faire l'infrastructure de lancement des services.

Le 02/06/2020 à 16:23, Stéphane CARPENTIER a écrit :

> Autant les guerres contre Microsoft, Apple, Android, Google, Facebook,
> Amazon et Uber (entre autres), j'ai vu plein d'arguments sérieux. Autant
> la guerre contre systemd je n'ai rien vu.

Laissons de côté la guerre, mais intéressons-nous à ce qui reste libre.

Le Wed, 03 Jun 2020 09:51:54 +0000, Nicolas George a écrit :

> Yliur , dans le message <rb6tbe$5dc$1>, a écrit :
>> De mémoire, Archlinux est passée à systemd parce que c'est le truc que
>> tout le monde utilisait et que pour un certain nombre de services les
>> mainteneurs d'Arch allait devoir commencer à maintenir eux-mêmes les
>> scripts à l'ancienne.
> Ça ne me semble pas très crédible. C'est de toutes façons le rôle d'une
> distribution de faire l'infrastructure de lancement des services.

Du coup je suis allé fouiller. J'ai retrouvé un message dans un forum,
qui est pointé directement par la page de wiki systemd comme étant
l'explication "officielle".

Le message en question :
[..]

La page de wiki (pour la source) :
[..]

Donc c'est un des développeurs arch et il dit effectivement qu'ils
devaient maintenir les scripts eux-mêmes avant ; par contre il espère que
ce ne sera plus le cas avec systemd (je ne sais pas si son v?u s'est
exaucé) et que ça va permettre de mettre en commun du travail entre
distributions. Les points 5-7 de sa liste d'avantages traitent de ces
sujets.

Globalement il liste un certains nombre d'avantages qu'il voit à systemd,
il semble plutôt enthousiaste. En tout cas le message est intéressant.

Le 04-06-2020, Yliur <yliur> a écrit :
> Le message en question :
> [..]

Ah, ben non. Moi qui voulait détester systemd, tu vas finir par faire de
moi un défenseur.

Ce qui confirme ce que j'imaginais, c'est que les raisons d'avoir migré
sont un peu plus sérieuses que pour faire comme tout le monde.

Ce qui confirme aussi ce que j'imaginais, c'est que certains trucs me
perturbaient parce que je ne me suis pas plongé dans la doc. Il y a plus
de trucs intéressants que ce que j'avais remarqué.

Je comprends aussi pourquoi les machines sous-dimensionnées de JKB ont
du mal à démarrer. Mais d'un autre côté, devoir attendre deux minutes
qu'un périphérique non vital soit reconnu sur ma machine pour pourvoir
l'utiliser parce que sinon, les serveurs qui ont 40 ans ne démarrent pas
me gêne. Alors, OK, systemd est orienté desktop et pas serveur. Ça tome
bien bien, Archlinux est orienté desktop et j'ai un desktop.

En tous cas, ça me confirme qu'avant d'accepter que tout est mieux que
systemd, il me faudra des explications sur le pourquoi et pas sur le
quoi :

"I think there might be this other project that possibly is doing
something similar. I don't really know anything about it, but I'm pretty
sure it is better than systemd"

> La page de wiki (pour la source) :
> [..]

Le problème de cette page en particulier, comme de ce wiki en général,
c'est que c'est plus une liste de recettes qu'une doc. Si tu connais
systemd, c'est très bien. Si tu découvres systemd en arrivant sur
archlinux, tu fais des devinettes en espérant que ça marche. Ils
t'expliquent comment faire, mais pas pourquoi. Et se plonger dans la doc
de systemd au moment de l'installation d'un OS est quand même très
contraignant.

Le 05 Jun 2020 10:21:44 GMT,
Stéphane CARPENTIER <sc> écrivait :
> Le 04-06-2020, Yliur <yliur> a écrit :
> Ah, ben non. Moi qui voulait détester systemd, tu vas finir par faire de
> moi un défenseur.
> Ce qui confirme ce que j'imaginais, c'est que les raisons d'avoir migré
> sont un peu plus sérieuses que pour faire comme tout le monde.
> Ce qui confirme aussi ce que j'imaginais, c'est que certains trucs me
> perturbaient parce que je ne me suis pas plongé dans la doc. Il y a plus
> de trucs intéressants que ce que j'avais remarqué.
> Je comprends aussi pourquoi les machines sous-dimensionnées de JKB ont
> du mal à démarrer.

Dans l'embarqué, tu ne te trimballes pas 4 Go de mémoire pour te
faire plaisir. Je ne vois pas en quoi avoir seulement 512 Mo de
mémoire est sous-dimensionné pour l'immense majorité des cas.

Par ailleurs, certains problèmes de systemd seraient acceptables si,
par exemple, on pouvait simplement lui demander de ne pas essayer de
tout lancer en parallèle. Parce que tu as exactement le même
problème avec des postes diskless (chez moi, tout est diskless sur
un gros serveur, et certaines machines allumées une fois de temps en
temps mettent jusqu'à une demi-heure pour être utilisables, systemd
lançant tout en même temps sur des disques réseau !). Sauf erreur de
ma part, je n'ai pas trouvé dans la doc un drapeau de configuration
permettant de dire à systemd "merci de ne pas forker comme un
goret et d'être gentil en lançant tout séquentiellement".

> Mais d'un autre côté, devoir attendre deux minutes
> qu'un périphérique non vital soit reconnu sur ma machine pour pourvoir
> l'utiliser parce que sinon, les serveurs qui ont 40 ans ne démarrent pas
> me gêne.

Ce qui me dérange plus, c'est l'attente infinie sur certains
périphériques non critiques. Ou le simple fait que l'ordonnanceur ne
soit pas fiable : ce qui fonctionnait avec telle version de systemd
est fichu de ne plus se lancer dans le même ordre avec la version
suivante. Alors il est vrai que c'est sur des trucs comme des
disques iSCSI ou des choses bizarres qu'on ne retrouvera pas chez
madame Michu (enfin, normalement), mais lorsque tu redémarres une
machine, tu aimes bien que ça se comporte de manière prévisible
d'une version à l'autre. Avec systemd, ce n'est pas le cas. Ça
ressemble vraiment au démarrage de type Windows avec en plus un
petit air d'advienne que pourra.

Un autre truc m'énerve au plus haut point. Lorsqu'on choisit un
système de démarrage, on s'y tient ! Avec systemd, dans certains
cas, on ne sait plus ce qui démarre avec une compatibilité SysV en
réécrivant à la volée des modules systemd, ce qui démarre en vrai
SysV, ce qui est lancé depuis /lib/systemd/system ou /etc/systemd
voire /lib/systemd/user et /etc/systemd/user... Lorsque tu as à la
fois un module systemd et un script SysV, tu as intérêt de chercher
attentivement ce que systemd fera parce que là encore, d'une
versionà une autre, il ne se comporte pas forcément de la même
manière. J'ai pensé naïvement qu'il utilisait toujours en priorité
ses modules. Raté, ce n'est pas toujorus vrai (je n'ai pas cherché à
savoir si c'était un bug ou une fonctionnalité).

C'est un merdier sans nom d'autant plus que je suis tombé sur une
bizarrerie d'un paquet debian qui modifie /lib/systemd/system et...
qui est réécrasé à la prochaine mise à jour de systemd. J'ai perdu
trois mois sur un problème pareil.

Pourquoi est-ce que les devs de systemd n'ont pas tout mis au même endroit
en retirant /etc/init.d de l'équation ? Je ne saurais jamais. Mais
le résultat est qu'on a un truc qui explose en vol plus souvent qu'à
son tour. J'ai un exemple récent où systemd (une certaine version du
truc) empêchait le démarrage de pulseaudio sur une machine qui me sert
de serveur multimedia. Je passe sous silence les interactions pas
maîtrisées avec udev. Il y a belle lurette que j'ai forcé les
interfaces réseau de mes serveurs en ethx (en fonction de l'adresse
MAC). Il y a quelques mois, l'une des interfaces était renommée en
eth254 ! Pourquoi, parce que systemd s'était tiré une balle dans le
pied entre udev et le montage des interfaces réseaux (les scripts
étaient bons). Ça fait désordre pour ne pas dire bricolage.

Il y a aussi un truc étrange depuis quelques semaines. Lorsque mon
poste de travail (diskless avec swap en iSCSI) se met à swapper un
peu trop, systemd me ferme ma session graphique. C'est très gentil
de sa part et très pratique. Je suppose qu'il y a maintenant dans le
bouzin un genre de watchdog.

Dernière chose, et non des moindres. Les mises à jour de systemd
sont problématiques parce une nouvelle version de la chose prend
place sur une machine utilisant déjà systemd comme init (pid 1). Et
là, le redémarrage peut être problématique avec des processus
d'extinction qui ne finissent JAMAIS (attente infinie sur... rien
parce que la version du binaire a changé !).

En fait, avec systemd, on est arrivé à un état problématique. Plus
exactement, il est désespérant de voir que ce que les développeurs
de Linux il y a 20 ans reprochaient à Windows se retrouve tel quel
avec les mêmes inconvénients dans Linux.

[..]
> t'expliquent comment faire, mais pas pourquoi. Et se plonger dans la doc
> de systemd au moment de l'installation d'un OS est quand même très
> contraignant.

Après aussi, remarque bien. Systemd est piégeux, son développement
n'a visiblement pas été plus ou pas été mieux pensé que celui de PL/1.
Nouveau besoin, nouveau patch et, à la fin, on a une usine à gaz avec
des fuites qui marche dans 95% des cas. Tant pis pour toi si tu es
dans les 5% restants.

JKB