Sommaire
Je vais sûrement m'attirer les foudres, les moinssages et les questions épineuses, mais tant pis je me lance, même si je ne suis pas à l'aise avec les commentaires.
Il était une fois
Un peu d'histoire déjà : je suis passé sous ArchLinux en 2007. Je suis tombé amoureux du principe de rolling-release, du principe KISS qui me faisait penser à une Slackware mais en plus fun et intégré, à la quantité de paquets déjà disponibles, et la possibilité de facilement créer ses paquets lorsque cela manque (comme une Slackware). Bref vous l'avez compris, j'ai commencé sous Slackware, puis j'ai migré par flemme sous Ubuntu, aussi parce que c'était hype; mais ne me sentant pas chez moi, j'ai testé Arch dès que j'en ai entendu parlé, et n'en suis jamais revenu.
C'était le paradis, les fleurs bourgeonnaient, les papillons virevoltaient dans la prairie baignée de soleil, et je faisais mes mises à jour régulièrement. Je riaient d'ailleurs, du haut de mon nuage, en voyant tout le monde se battre pour ou contre systemd, vu que Arch ne l'utilisait pas. Ben oui, une distro KISS n'est pas censée utiliser systemd, si ?
Oui mais les dev d'Arch ont décidé de passer sous systemd, que je n'aimais pas comme vous avez du vous rendre compte par les mots qui précèdent. Mais je n'avais pas le choix, les autres atouts de cette distributions étaient toujours là. Alors je m'y suis fait. Je remets pas en cause d'homogénéité que cet OS ce système d'init aux stéroïdes apporte, mais comme pour les distributions que j'utilisais avant, je ne me sentais pas à l'aise avec.
J'ai bien vu l'émergence des projets sans systemd, mais ça manquait de stabilité, c'était compliqué à mettre en œuvre, et j'avais encore la flemme il faut bien le dire.
Puis j'ai entendu parler du petit ArtixLinux…
La révélation
Le deal, c'est d'avoir une Arch sans systemd. Tous les avantages de ma distribution préférée sans être sous systemd. Mais des années à utiliser cette boîte noire m'ont rendues ignorant, je sachant même pas quoi choisir comme système d'init; mais au moins, j'avais le choix. Je l'ai donc testée dans une machine virtuelle (sous VirtualBox), en essayant plusieurs systèmes d'init, cherchant à obtenir le plus de facilités possible en gardant la souplesse d'un système simple, léger et facile à appréhender. Sans toutefois passer mon ordinateur sous Artix (disponibilité, flemme, toussa), j'ai longuement gardé une VM je j'ai oublié puis reprise et réinstallée.
Récemment (en 2021) un nouveau système d'init est apparu dans la sphère Artix : dinit. Bien qu'immature, sa conception et son utilisation correspondaient tout à fait à mes attentes et mon bien-être.
J'ai alors prévu une migration en créant un script d'automatisation de l'installation, afin que la migration se fasse le plus rapidement possible et sans douleur (qui installe tous les paquets dont j'ai besoin, copie mes tweaks persos dans /etc et /usr/local/bin, me copie touts mes données et configurations de mon « desktop » depuis mon backup). Le projet n'est pas finalisé (et pas vraiment documenté, donc pas trop utilisable par d'autres personnes que moi), mais je suis confiant pour une migration d'ici la fin de l'année.
Et la description d'Artix alors ?
Oui c'est vrai, j'ai surtout parlé de moi, et peu de la distribution elle-même. Voilà donc ce que je retiens d'elle.
Artix est basée sur Arch. C'est vraiment une Arch sans systemd. Bien-sûr pour que cela soit possible, elle doit avoir ses propres dépôts pour que tous les paquets incompatibles avec un système d'exploitation sans systemd puissent être repris et adapté aux autres système d'init. Oui, ArtixLinux ne force pas l'utilisation d'un seul système d'init, de gestionnaire de réseaux ou de gestion des journaux. On revient au bon vieux bordel de choisir celui qui nous convient le mieux. Officiellement le projet supporte openrc, runit, s6, and dinit.
Mais la compatibilité reste là, et on peut ajouter les dépôts Arch, profiter d'AUR et des dépôts non officiels (paquets AUR déjà prêts). Cela fonctionne car les dépôts d'Artix sont prioritaires. Pour les paquets fournissant un service mais n'existant pas sous Artix (ou même juste sous son système d'init préféré), il est possible bien-sûr de contribuer.
Le wiki est plutôt maigre, mais je pense que c'est volontaire, celui d'Arch étant déjà une référence quasi-complète de l'écosystème. On peut être parfois paumé lorsqu'on est, comme moi, devenu ignorant (ne plus savoir comment fonctionnent les choses quand on les contrôle directement), mais les forums et IRC sont là pour répondre aux questions.
Le mot de la fin
Je pense être sur la voie d'un bien-être informatique. J'aime les principes d'Archlinux, mis à par son système d'init depuis qu'il a été imposé. J'ai trouvé avec ArtixLinux le palliatif, avec un système d'exploitation plus brut et compréhensible pour moi, prenant un minimum de ressources au repos (un même environnement prend la moitié moins de mémoire et d'usage CPU au repos sous Artix, me permettant d'utiliser ces ressources pour autre chose).
Ce n'est pas si compliqué de se remettre à un système d'init différent de systemd, les journaux gérés par metalog ou syslog-ng, la synchro du temps avec openntpd ou ntpd, le gestionnaire de réseaux avec … ce qu'on veut.
C'est agréable d'être libre de choisir.
# je garde un oeil dessus
Posté par chimay . Évalué à 8.
Je l’avais déjà repérée il y a quelque temps, elle a effectivement l’air sympa, tout comme void ou autre distro minimaliste.
Qu’est-ce qui différencie dinit des autres alternatives, comme openrc ou runit ?
[^] # Re: je garde un oeil dessus
Posté par riri le breton (site web personnel) . Évalué à 3.
runit ne gère pas les dépendances, dinit oui. J'avais choisi runit au début pour sa simplicité, mais le manque de gestion de dépendance n'était pas top. dinit n'est pas parfait non plus. Par exemple par défaut si un service dont on dépend s'arrête, par exemple le réseau, celui qui en dépend, par exemple ntp, ne s'arrête pas. On peut toutefois le forcer.
openrc a les mêmes concepts que dinit, mais est selon moi plus lourd. Par comparaison, un même système lancé via openrc mettra plus de temps à avoir un environnement prêt, et consommera plus.
Ce sont des tests empiriques qui m'ont guidés, via mes machines virtuelles, mais c'était flagrant. De plus j'aime le côté vraiment KISS de dinit.
Le seul défaut que je lui trouve pour l'instant, est qu'on ne peut pas désactiver un service pour le prochain démarrage sans l'arrêter, et vice versa; les deux sont liés.
[^] # Re: je garde un oeil dessus
Posté par freem . Évalué à 3.
Je n'ai aucune expérience avec dinit, vu que j'ai appris son existence hier soir en tombant sur ce journal, mais j'ai un peu lu la doc et il me semble qu'il est censé supporter cette fonctionnalité, si la dépendance est "hard"?
[^] # Re: je garde un oeil dessus
Posté par PR . Évalué à 5. Dernière modification le 12 septembre 2022 à 11:46.
VADE RETRO SATANA !
Comment oses-tu vouloir une telle usine à gaz. Un service manager et un init n’ont ABSOLUMENT rien à voir entre eux.
(quitte à ne pas vouloir de systemd, autant faire les choses bien :-°)
PS : voir par exemple https://en.wikipedia.org/wiki/Daemontools
Mort aux cons !
[^] # Re: je garde un oeil dessus
Posté par chimay . Évalué à 1.
Ce ne doit pourtant pas être trop compliqué à ajouter, si c'est géré par
des liens symboliques (pure hypothèse)
faudra que je teste dans une box virtuelle à l'occasion.
# Je suis déjà passé par Artix
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à -2.
Ca sentait le gaz.
[^] # Re: Je suis déjà passé par Artix
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 4.
Gentoo doit avoir un côté Corse : Elle maintient une version « Canal historique » avec openrc au côté du « Canal habituel » assujettie à systemd. Personne ne dira que ça sent le gaz. Éventuellement les contempteurs, par souci de cohérence avec la nomenclature précédente affirmeraient que ça embaume le « Casgiu Marzu. »
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
# Compliqué d'être sans systemd aujourd'hui
Posté par David Demelier (site web personnel) . Évalué à 7.
Perso je suis ni pour ni contre systemd. Il y a des choses que j'aime bien et d'autres moins.
Par contre, même si au départ il y avait beaucoup de distributions sans systemd, on ne peut pas nier que c'est de plus en plus difficile de s'en passer. Notamment parce que certains desktops en font parfois un prérequis à tel point que beaucoup de projets sortent des composants systemd en standalone (eudev, elogind). Mais à part ça, on peut aussi remarquer que certains projets deviennent de moins en moins maintenu. Les vénérables syslog et cron par exemple, la plupart des implémentations deviennent délaissées alors les sans-systemd deviennent vraiment des citoyens de seconde zone.
C'est dommage, pas spécialement pour les linuxiens anti-systemd mais pour les gens qui tournent sur des systèmes alternatifs comme OpenBSD, illumos et autres. Par exemple, le mode night shift de GNOME n'est pas disponible sous les non-linux parce que colord a une dépendance stricte à udev (si je me souviens bien).
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Compliqué d'être sans systemd aujourd'hui
Posté par freem . Évalué à 4.
Pour rappel, systemd-udevd ne dépend absolument pas de systemd (ou en tout cas, pas la version présente dans debian stable) et ne contiens "systemd-" dans le nom que parce que le projet est maintenant maintenu par la même "organisation" que systemd. C'est même un truc que les pro-systemd répète à l'envi (et à raison je suppose?).
Pour ce qui est de eudev, je n'en vois que peu l'intérêt personnellement, si je devais reprocher un truc à udev, c'est son côté usine à gaz et… eudev le partage, vu que c'est "juste" un fork.
Et avant qu'on me pose la question, non, je n'ai pas expérimenté avec les alternatives (et bien que j'aie 2-3 liens sur mon PC perso qu'il faut que je me sorte les doigts pour tester, ça reste un élément de TODO-list).
# Merci, je connaissais pas, je vais regarder.
Posté par Skilgannon . Évalué à 4.
Je suis moi aussi pas fan de systemd et fan de ArchLinux; donc : voir le titre ! :)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.