usrmerge

Le 10-09-2022, JKB <JKB@hilbert.invalid> a écrit :

Bonjour Í  tous,

Existe-t-il encore une distribution quelque part sans usrmerge ?
J'ai viré Debian pour Devuan en raison de systemd qui met un bazar
monstrueux sur des serveurs en étant un nid Í  bugs, mais j'ai
l'impression que usrmerge est en train de faire son apparition chez
Devuan aussi.

Pas la peine de me convaincre du bien fondé de cette nouvelle lubie,
je considère que c'est une erreur de conception et qu'il vaudrait
mieux, au lieu de tout regrouper dans un répertoire, instaurer un
/rescue comme dans NetBSD par exemple. Un système doit pouvoir
démarrer avec des /bin, /sbin et /lib minimalistes avant de monter
le système dans /usr (et sans l'horreur initramfs). Du reste, pour
les systèmes embarqués, c'est ce que l'on fait pour éviter justement
la casse en gardant / en ro.

Bref, merci de ne pas engager la discussion sur ce terrain, ce qui
m'intéresse est de savoir s'il existe quelque part une distribution
qui indique clairement ne pas recourir Í  cette horreur.

Merci,

JKB

Personne ? Ne me dites pas que le monde Linux est devenu aussi
merdique que cela...

--
Si votre demande me parvient en code 29, je vous titiouillerai volontiers
une réponse.

On 9/28/22 16:12, JKB wrote:

Personne ? Ne me dites pas que le monde Linux est devenu aussi
merdique que cela...

Ne m'étant jamais trouvé devant cette problématique, je ne
me permettrais pas d'avoir le moindre avis.

Sauf que merger /bin et /usr/bin, je ne vois pas pourquoi
on n'y rajouterais pas dans la foulée /usr/local/bin, et,
soyons fous, /opt/bin ;)

--
+------------------------------------------------------------------+
| http://la.buvette.org/video/fusion/xper.html |
+------------------------------------------------------------------+

tTh , dans le message <th248g$1vtk$1@news.gegeweb.eu>, a écrit :

Sauf que merger /bin et /usr/bin, je ne vois pas pourquoi
on n'y rajouterais pas dans la foulée /usr/local/bin, et,
soyons fous, /opt/bin ;)

Parce que les raisons de séparer /usr/local et /opt sont toujours
d'actualité, alors que les raisons pour garder /bin hors de /usr ont cessé
d'être pertinentes Í  peu près Í  l'époque o͹ les compétences de certains
administrateurs système qui interviennent ici se sont fossilisées.

Le 28-09-2022, tTh <tth@none.invalid> a écrit :

On 9/28/22 16:12, JKB wrote:

Personne ? Ne me dites pas que le monde Linux est devenu aussi
merdique que cela...

Ne m'étant jamais trouvé devant cette problématique, je ne
me permettrais pas d'avoir le moindre avis.

Sauf que merger /bin et /usr/bin, je ne vois pas pourquoi
on n'y rajouterais pas dans la foulée /usr/local/bin, et,
soyons fous, /opt/bin ;)

Toutafé.

--
Si votre demande me parvient en code 29, je vous titiouillerai volontiers
une réponse.

Le 28-09-2022, Nicolas George <nicolas$george@salle-s.org> a écrit :

tTh , dans le message <th248g$1vtk$1@news.gegeweb.eu>, a écrit :

Sauf que merger /bin et /usr/bin, je ne vois pas pourquoi
on n'y rajouterais pas dans la foulée /usr/local/bin, et,
soyons fous, /opt/bin ;)

Parce que les raisons de séparer /usr/local et /opt sont toujours
d'actualité, alors que les raisons pour garder /bin hors de /usr ont cessé
d'être pertinentes Í  peu près Í  l'époque o͹ les compétences de certains
administrateurs système qui interviennent ici se sont fossilisées.

Je ne t'ai pas demandé ton avis. Il s'avère que je bosse
essentiellement sur des systèmes embarqués ou mélanger / et /usr est
une connerie sans nom pour tout un tas de raisons qui dépasse la
médiocrité de ton entendement. Mais comme je suis bon prince, je
vais t'en filer quelques unes :
1/ on aime bien (pour tout un tas de raisons) utiliser des systèmes
de fichiers non journalisés parce qu'on chasse les mW ;
2/ on aime bien pouvoir reprendre la main Í  distance sur une machine
crachée (et donc sans accès local avec un shell dans l'horreur
initramfs, de toute façon, on n'a généralement pas de clavier,
seulement une interface réseau) ;
3/ pour pouvoir reprendre la main Í  distance, il faut que /
permettant de démarrer la machine reste en readonly, /usr pouvant
être en readwrite. Dans le cas d'usrmerge, /usr est en readonly et
le premier crash empêche la machine de redémarrer. Au mieux, tu te
retrouves dans busybox qui est une horreur sans nom quand tu n'es
pas devant la machine. Au passage, ladite machine n'a généralement
pas autre chose qu'un interrupteur on/off.

Il y a d'autres raisons.

usrmerge a été poussé par des gens aussi compétents que ceux qui ont
poussé systemd et wayland (d'ailleurs, ce sont en partie les mêmes)
et qui n'ont aucune idée de ce qu'il se passe ailleurs que sur les serveurs
et stations de travail, surtout quand on voit les arguments déployés
comme "il est idiot de séparer / et /usr vue la taille des disques
durs". Dans la vraie vie de l'embarqué, on peut s'estimer heureux
lorsqu'on a un système de fichier de 8 Go !

/ et /usr ont des fonctions différentes dans le système et ceux qui
ne comprennent pas la différence ne devraient surtout pas
administrer autre chose que leur machine de travail personnelle. Ils
ne devraient surtout pas imposer des choses pareilles parce que
Solaris (par exemple) l'a déjÍ  fait. Solaris était potable jusqu'aux
premières version de Solaris 10. Depuis, c'est une horreur qui
n'arrive même plus Í  passer ses propres patches de sécurité parce
que les disques sont soi-disant pleins alors qu'il reste 1 To de
disponible !

Que des gens veuillent absolument regrouper / et /usr, pourquoi pas
si ceux qui sont emmerdés par cette chose peuvent l'éviter.

Au lieu de dépenser de l'énergie folle pour imposer cette merde (et
je pèse mes mots), les petits gars de RedHat et consorts seraient
bien avisés de s'inspirer par exemple de NetBSD qui a un répertoire
/rescue. Je te laisse chercher par toi-même Í  quoi ça sert. Parce que
le nombre de fois o͹ des systèmes embarqués sont en vrac Í  la suite
d'une mise Í  jour de sécurité alors qu'on a tout testé sur une
machine dite de test ne se comptent plus ! Avec usrmerge et sans
rescue, c'est un techos qui va sur le terrain. sans usrmerge et avec
un rescue, tu peux TOUT remettre d'équerre Í  distance pour peu que
tu aies prévu un accès distant dans /.

JKB

PS: pas la peine de me répondre, je ne sais d'ailleurs pas comment tu es
sorti de mon killfile. Faut que je vérifie ça.

--
Si votre demande me parvient en code 29, je vous titiouillerai volontiers
une réponse.

Le 28-09-2022, JKB nous expliquait dans
fr.comp.os.linux.debats
(<63345657$0$25807$426a34cc@news.free.fr>) :

Personne ? Ne me dites pas que le monde Linux est devenu aussi
merdique que cela...

Slackware est encore totalement "systemd free" et ne semble pas
intéressé par ces histoires de merge Í  la con. Mais rien ne dit que cela
restera le cas dans les années Í  venir.

Slackeux depuis plus de 20 ans, je suis **fatigué** de voir les
distributions Linux autoproclamées majeures (RH, Debian, Ubuntu) imposer
leurs délires ineptes.

Du coup je migre gentiment vers FreeBSD qui me fait de l'oeil depuis bien
longtemps et je finirai probablement par aller faire un tour vers NetBSD.

Pour ajouter au troll, pour ma part j'exclus OpenBSD qui me semble trop
radical pour un usage en desktop. Mes quelques tentatives sur ce système
me l'ont fait considérer comme trop contraignant Í  utiliser au
quotidien.

--
Mais l'ombre des plaisirs s'enfuit
Toujours plus loin vers l'inconnu.
-- H.F. Thiéfaine, La mÍ´me kaléͯdoscope

Le 29-09-2022, Doug713705 <doug.letough@free.fr> a écrit :

Le 28-09-2022, JKB nous expliquait dans
fr.comp.os.linux.debats
(<63345657$0$25807$426a34cc@news.free.fr>) :

Personne ? Ne me dites pas que le monde Linux est devenu aussi
merdique que cela...

Slackware est encore totalement "systemd free" et ne semble pas
intéressé par ces histoires de merge Í  la con. Mais rien ne dit que cela
restera le cas dans les années Í  venir.

Ça ne va pas me rajeunir, la première distribution que j'ai
installée fut une slack je ne sais plus combien en 1995... Í  partir
d'une pile de disquettes.

Ce qui m'ennuie, c'est un peu son mode de développement et sa
pérennité. Est-ele toujours développée par une personne seule ?

Slackeux depuis plus de 20 ans, je suis **fatigué** de voir les
distributions Linux autoproclamées majeures (RH, Debian, Ubuntu) imposer
leurs délires ineptes.

On n'est bien d'accord. J'ai d'ailleurs posté un mail sur la liste
de diffusion francophone de Debian avec comme sujet "grosse fatigue"
Í  la suite d'un problème systemd datant de plusieurs mois (années,
en fait). Je me suis fait recevoir par un type de l'équipe de dev...
Tout ça pour m'expliquer qu'il faut utiliser auditd pour trouver
pourquoi systemd merdoie. Sauf qu'on est en _diskless_ et que le
lancement de ce truc, même en filtrant Í  mort, met Í  genou le
serveur NFS. Accessoirement, toutes les machines du réseau se
prennent des "nfs server not responding". Ce qui fait que tu ne sais
pas si ce que tu va trouver avec auditd est réellement pertinent.

On a l'impression qu'il faut absolument rester dans les configurations
standard et testées. Dès que tes installations sont un peu tordues
sans être exceptionnelles, ça merdoie gentiment (ou un peu moins
gentiment). Et surtout, certains choix sont faits par des gens qui
ne comprennent pas tout. J'ai un souvenir ému d'un patch de sécurité
qui était un trou béant, de l'interdiction d'utiliser certains
chiffrement (interdisant Í  un serveur de mail Í  parler Í  autre chose
que debian Í  jour en face !), la conséquence étant la désactivation
de SSL/TLS sur sendmail (!), de app-armor qui fout le bordel en
configuration diskless et de systemd qui est une horreur inf͢me...
Je ne parle même pas d'initramfs. Le type qui a inventé ça n'a
jamais regardé ce qui existait déjÍ . J'en oublie certainement.

Du coup je migre gentiment vers FreeBSD qui me fait de l'oeil depuis bien
longtemps et je finirai probablement par aller faire un tour vers NetBSD.

Toutes les machines récemment installées chez moi sont du FreeBSD en
station et du NetBSD en serveur. Sinon, j'ai migré mes derniers
Linux de Debian Í  Devuan (au moins, on évite systemd et ses
comportements aberrants). Il me reste encore deux Debian officielle,
un serveur de mail que j'ai la flemme de réinstaller from scratch
même en ayant une copie de la configuration (il gère des tas de
domaines sous Sendmail avec des queues différentes par
destinataires...) et ma machine de dev en raison d'un soft propriétaire.

Pour ajouter au troll, pour ma part j'exclus OpenBSD qui me semble trop
radical pour un usage en desktop. Mes quelques tentatives sur ce système
me l'ont fait considérer comme trop contraignant Í  utiliser au
quotidien.

On est d'accord. Un truc qui m'empêche d'utiliser strncpy() lorsque
je compile avec -Werror m'énerve assez rapidement. Zut, j'ai marché
dedans !

JKB

--
Si votre demande me parvient en code 29, je vous titiouillerai volontiers
une réponse.

Le 29-09-2022, JKB nous expliquait dans
fr.comp.os.linux.debats
(<63354abd$0$25836$426a74cc@news.free.fr>) :

Slackware est encore totalement "systemd free" et ne semble pas
intéressé par ces histoires de merge Í  la con. Mais rien ne dit que cela
restera le cas dans les années Í  venir.

Ça ne va pas me rajeunir, la première distribution que j'ai
installée fut une slack je ne sais plus combien en 1995... Í  partir
d'une pile de disquettes.

Ce qui m'ennuie, c'est un peu son mode de développement et sa
pérennité. Est-ele toujours développée par une personne seule ?

Oui et non, Patrick Volkerding est toujours le dictateur bienveillant
mais il est entouré d'une équipe restreinte qui l'aide dans sa tÍ¢che.

Les patches d'utilisateurs sont généralement bienvenus même si, de mon
point de vue, le mode de transmission des patches et le mode de discussions
via linuxquestions.org me semble vraiment **merdique**.

J'ai depuis longtemps renoncer Í  fournir des patches et je patche gentiment
mes systèmes en fonction de mes besoins sans nécessairement remonter ça Í 
upstream.

Slackeux depuis plus de 20 ans, je suis **fatigué** de voir les
distributions Linux autoproclamées majeures (RH, Debian, Ubuntu) imposer
leurs délires ineptes.

On n'est bien d'accord. J'ai d'ailleurs posté un mail sur la liste
de diffusion francophone de Debian avec comme sujet "grosse fatigue"
Í  la suite d'un problème systemd datant de plusieurs mois (années,
en fait). Je me suis fait recevoir par un type de l'équipe de dev...
Tout ça pour m'expliquer qu'il faut utiliser auditd pour trouver
pourquoi systemd merdoie. Sauf qu'on est en _diskless_ et que le
lancement de ce truc, même en filtrant Í  mort, met Í  genou le
serveur NFS. Accessoirement, toutes les machines du réseau se
prennent des "nfs server not responding". Ce qui fait que tu ne sais
pas si ce que tu va trouver avec auditd est réellement pertinent.

On a l'impression qu'il faut absolument rester dans les configurations
standard et testées. Dès que tes installations sont un peu tordues
sans être exceptionnelles, ça merdoie gentiment (ou un peu moins
gentiment). Et surtout, certains choix sont faits par des gens qui
ne comprennent pas tout. J'ai un souvenir ému d'un patch de sécurité
qui était un trou béant, de l'interdiction d'utiliser certains
chiffrement (interdisant Í  un serveur de mail Í  parler Í  autre chose
que debian Í  jour en face !), la conséquence étant la désactivation
de SSL/TLS sur sendmail (!), de app-armor qui fout le bordel en
configuration diskless et de systemd qui est une horreur inf͢me...
Je ne parle même pas d'initramfs. Le type qui a inventé ça n'a
jamais regardé ce qui existait déjÍ . J'en oublie certainement.

Ça fait *très* longtemps (i.e bien avant l'arrivée de systemd) que je considère
Debian comme une des pires bouses. Je n'ai jamais compris la réputation
de fiabilité qu'on lui octroie. Cette distribution n'est qu'une
collection de bugs plus ou moins pacthés et qui fonctionne presque par
chance.

Du coup je migre gentiment vers FreeBSD qui me fait de l'oeil depuis bien
longtemps et je finirai probablement par aller faire un tour vers NetBSD.

Toutes les machines récemment installées chez moi sont du FreeBSD en
station et du NetBSD en serveur. i

C'est probablement vers ce quoi je m'oriente. J'ai vraiment été
impressionné par la facilité de prise en main de FreeBSD. La transition
depuis Linux a été totalement transparente et je ne parle pas du temps
de boot qui est d'une magnitude inconnue sous Linux. Il en est de même
pour le temps d'installation.

Debian est le parfait contre exemple, le temps d'installation et de
mise Í  jour est simplement d'une lenteur ahurissante.

Sinon, j'ai migré mes derniers
Linux de Debian Í  Devuan (au moins, on évite systemd et ses
comportements aberrants).

Honnêtement bien qu'ayant une nette préférence pour de bons vieux
scripts pour démarrer mes services, j'utilise systemd sans vraiment
de difficulté. La documentation n'est pas aussi mauvaise qu'elle a pu être
et ça fonctionne, tout au moins j'arrive Í  le faire fonctionner.

Le vrai problème de systemd c'est qu'il veut tout gérer, y compris et
surtout des choses qui n'ont aucun rapport avec un init qui se respecte.

Sans surprise, Lennart Poettering est parti chez Microsoft. Bon
débarras.

Il me reste encore deux Debian officielle,
un serveur de mail que j'ai la flemme de réinstaller from scratch
même en ayant une copie de la configuration (il gère des tas de
domaines sous Sendmail avec des queues différentes par
destinataires...) et ma machine de dev en raison d'un soft propriétaire.

Postfix et Ansible sont tes amis.

Pour ajouter au troll, pour ma part j'exclus OpenBSD qui me semble trop
radical pour un usage en desktop. Mes quelques tentatives sur ce système
me l'ont fait considérer comme trop contraignant Í  utiliser au
quotidien.

On est d'accord. Un truc qui m'empêche d'utiliser strncpy() lorsque
je compile avec -Werror m'énerve assez rapidement. Zut, j'ai marché
dedans !

/me collecte son point Théo :D

--
Mais l'ombre des plaisirs s'enfuit
Toujours plus loin vers l'inconnu.
-- H.F. Thiéfaine, La mÍ´me kaléͯdoscope

Le 29-09-2022, Doug713705 <doug.letough@free.fr> a écrit :

Le 29-09-2022, JKB nous expliquait dans
fr.comp.os.linux.debats
(<63354abd$0$25836$426a74cc@news.free.fr>) :

Slackware est encore totalement "systemd free" et ne semble pas
intéressé par ces histoires de merge Í  la con. Mais rien ne dit que cela
restera le cas dans les années Í  venir.

Ça ne va pas me rajeunir, la première distribution que j'ai
installée fut une slack je ne sais plus combien en 1995... Í  partir
d'une pile de disquettes.

Ce qui m'ennuie, c'est un peu son mode de développement et sa
pérennité. Est-ele toujours développée par une personne seule ?

Oui et non, Patrick Volkerding est toujours le dictateur bienveillant
mais il est entouré d'une équipe restreinte qui l'aide dans sa tÍ¢che.

Point positif.

Les patches d'utilisateurs sont généralement bienvenus même si, de mon
point de vue, le mode de transmission des patches et le mode de discussions
via linuxquestions.org me semble vraiment **merdique**.

J'ai depuis longtemps renoncer Í  fournir des patches et je patche gentiment
mes systèmes en fonction de mes besoins sans nécessairement remonter ça Í 
upstream.

Slackeux depuis plus de 20 ans, je suis **fatigué** de voir les
distributions Linux autoproclamées majeures (RH, Debian, Ubuntu) imposer
leurs délires ineptes.

On n'est bien d'accord. J'ai d'ailleurs posté un mail sur la liste
de diffusion francophone de Debian avec comme sujet "grosse fatigue"
Í  la suite d'un problème systemd datant de plusieurs mois (années,
en fait). Je me suis fait recevoir par un type de l'équipe de dev...
Tout ça pour m'expliquer qu'il faut utiliser auditd pour trouver
pourquoi systemd merdoie. Sauf qu'on est en _diskless_ et que le
lancement de ce truc, même en filtrant Í  mort, met Í  genou le
serveur NFS. Accessoirement, toutes les machines du réseau se
prennent des "nfs server not responding". Ce qui fait que tu ne sais
pas si ce que tu va trouver avec auditd est réellement pertinent.

On a l'impression qu'il faut absolument rester dans les configurations
standard et testées. Dès que tes installations sont un peu tordues
sans être exceptionnelles, ça merdoie gentiment (ou un peu moins
gentiment). Et surtout, certains choix sont faits par des gens qui
ne comprennent pas tout. J'ai un souvenir ému d'un patch de sécurité
qui était un trou béant, de l'interdiction d'utiliser certains
chiffrement (interdisant Í  un serveur de mail Í  parler Í  autre chose
que debian Í  jour en face !), la conséquence étant la désactivation
de SSL/TLS sur sendmail (!), de app-armor qui fout le bordel en
configuration diskless et de systemd qui est une horreur inf͢me...
Je ne parle même pas d'initramfs. Le type qui a inventé ça n'a
jamais regardé ce qui existait déjÍ . J'en oublie certainement.

Ça fait *très* longtemps (i.e bien avant l'arrivée de systemd) que je considère
Debian comme une des pires bouses. Je n'ai jamais compris la réputation
de fiabilité qu'on lui octroie. Cette distribution n'est qu'une
collection de bugs plus ou moins pacthés et qui fonctionne presque par
chance.

Il ne faut pas exagérer. Lorsque je suis passé de RedHat qui ne
s'appelait pas encore Fedora Í  Debian, je suis tombé sur un système
bien plus carré.

Du coup je migre gentiment vers FreeBSD qui me fait de l'oeil depuis bien
longtemps et je finirai probablement par aller faire un tour vers NetBSD.

Toutes les machines récemment installées chez moi sont du FreeBSD en
station et du NetBSD en serveur. i

C'est probablement vers ce quoi je m'oriente. J'ai vraiment été
impressionné par la facilité de prise en main de FreeBSD. La transition
depuis Linux a été totalement transparente et je ne parle pas du temps
de boot qui est d'une magnitude inconnue sous Linux. Il en est de même
pour le temps d'installation.

Mais comment font-ils sans systemd ?

Debian est le parfait contre exemple, le temps d'installation et de
mise Í  jour est simplement d'une lenteur ahurissante.

4 heures pour mettre Í  jour TeXlive en configuration diskless. Il
faut voir les transactions NFS qui passent. apt n'essaie pas
d'ouvrir un fichier en récupérant les erreurs pour voir s'il existe
et travailler dessus. Ce serait trop simple.
Il tente l'ouverture pour récupérer l'erreur, le ferme puis le
rouvre pour l'écrire et le referme... Économies de moyens...

Le pire est que j'ai un équipement pro qui tourne sur une vieille
machine que je n'avais pas encore mis Í  jour. Un K6-III avec 256 Mo
de mémoire (la carte-mère n'accepte pas plus). Quand on est passé de
init-SysV Í  systemd, la durée du boot est passée de moins d'une
minute Í ... 45 minutes. Et rien que pour le boot, systemd balançait
des trucs dans le swap (forcément, il essaye de tout lancer en même
temps) et occupait les 750 Mo disponibles ! Depuis, j'ai mis Í  la
place une vieille Alpha sous NetBSD.

Sinon, j'ai migré mes derniers
Linux de Debian Í  Devuan (au moins, on évite systemd et ses
comportements aberrants).

Honnêtement bien qu'ayant une nette préférence pour de bons vieux
scripts pour démarrer mes services, j'utilise systemd sans vraiment
de difficulté. La documentation n'est pas aussi mauvaise qu'elle a pu être
et ça fonctionne, tout au moins j'arrive Í  le faire fonctionner.

Le vrai problème de systemd c'est qu'il veut tout gérer, y compris et
surtout des choses qui n'ont aucun rapport avec un init qui se respecte.

Le problème de systemd, c'est qu'une fois que tu n'es plus dans une
configuration canonique, c'est la misère. En diskless par exemple,
il faut réécrire une bonne partie des unités (en raison de timeouts
trop courts et du fait que cette bouse essaie de tout lancer en même
temps sur un réseau, saturant le serveur nfs). Encore, ça peut
passer, mais Í  chaque mise Í  jour des unités, il faut refaire le
boulot. J'ai essayé de trouver une option permettant de limiter le
nombre de processus lancés en parallèle, visiblement, ça n'existait pas.
Il y a d'autres choses plus amusantes comme les différences
d'acceptions entre Require et After d'une version Í  l'autre par exemple
(la mise Í  jour de cet été fut rigologène Í  ce titre).
Je suis en train de convertir des rPI3 qui me servent de borne WiFi
un peu particulières de Debian Í  Devuan pour cette raison.

Sans surprise, Lennart Poettering est parti chez Microsoft. Bon
débarras.

Il me reste encore deux Debian officielle,
un serveur de mail que j'ai la flemme de réinstaller from scratch
même en ayant une copie de la configuration (il gère des tas de
domaines sous Sendmail avec des queues différentes par
destinataires...) et ma machine de dev en raison d'un soft propriétaire.

Postfix et Ansible sont tes amis.

Il m'arrive d'utiliser Postfix, mais pour des configurations
tordues, j'ai un faible pour le Sendmail des familles.

Pour ajouter au troll, pour ma part j'exclus OpenBSD qui me semble trop
radical pour un usage en desktop. Mes quelques tentatives sur ce système
me l'ont fait considérer comme trop contraignant Í  utiliser au
quotidien.

On est d'accord. Un truc qui m'empêche d'utiliser strncpy() lorsque
je compile avec -Werror m'énerve assez rapidement. Zut, j'ai marché
dedans !

/me collecte son point Théo :D

Je te le laisse. ;-)

--
Si votre demande me parvient en code 29, je vous titiouillerai volontiers
une réponse.

Le 29/09/2022 Doug713705 <doug.letough@free.fr> écrivait :

Slackware est encore totalement "systemd free" et ne semble pas
intéressé par ces histoires de merge Í  la con. Mais rien ne dit que cela
restera le cas dans les années Í  venir.

Slackeux depuis plus de 20 ans, je suis **fatigué** de voir les
distributions Linux autoproclamées majeures (RH, Debian, Ubuntu) imposer
leurs délires ineptes.

me too, depuis 1996 et même sur un RaspBerry

Du coup je migre gentiment vers FreeBSD qui me fait de l'oeil depuis bien
longtemps et je finirai probablement par aller faire un tour vers NetBSD.

J'ai utilisé un FB 2.2.5 puis 3.1 pendant des années, même sur un Rasp

Pour ajouter au troll, pour ma part j'exclus OpenBSD qui me semble trop
radical pour un usage en desktop. Mes quelques tentatives sur ce système
me l'ont fait considérer comme trop contraignant Í  utiliser au
quotidien.

bon troll, ne pas changer de troll