Tout à fait, merci pour l'information.
J'ajoute pour les gens qui utilisent Firefox sur le canal Release sous Debian (ici 66.0.1 sous sid, donc pas la version ESR), le problème concerne également les Language Packs.
about:config
rechercher signatures.required
passer extensions.langpacks.signatures.required à false
passer xpinstall.signatures.required à false
redémarrer Firefox
Et oui, bien penser à remettre tout d'origine quand le bug sera corrigé.
… sachant que /var/run est un lien symbolique vers /run ?
Et pourquoi donc supprimer cette ligne ?
- add_dir /var/run/plymouth
<mode pour_vendredi>
Merci pour ton article, ça donne une vue d'ensemble plus précise de ce qu'il est nécessaire de savoir en plus pour mettre en place un initrd : savoir scripter + savoir alimenter initcpio via son vocabulaire + ajouter des unités via le vocabulaire systemd + patcher l'existant) </mode>
C'est néanmoins très complet et ça prend en compte LVM + le chiffrement + Plymouth, merci donc.
Ah mais pas du tout Monsieur, ça marche très bien comme ça et ça va rester ainsi justement !
Python va surtout me servir pour certaines administratives lourdes, comme le catalogue en ligne des paquets par exemple. La gestion des paquets ne doit plus changer maintenant, quand ça marche on ne répare pas comme dirait l'autre. :)
Merci pour ton travail et ta constance au passage, Spack n'a pas la visibilité qu'il mérite, à mon sens.
Je viens de réparer le wiki qui avait effectivement explosé (upgrade de dokuwiki -> dépassement de quota -> boum).
Pour systemd, je te renvoie à ce commentaire. Pour info, systemd a alourdi la charge de travail côté intégration/empaquetage uniquement. Côté utilisateur c'était bien plus positif (mais pas parfait).
0linux a pu naître grâce aux méthodes de Linux From Scratch, Cross LFS et DIY Linux pour construire une première chaîne d'outils permettant de compiler pour les 2 architectures, x86 et x86_64. La distribution s'est dans un premier temps beaucoup inspirée de Slackware (appliquer le moins de correctifs possible, utiliser une initialisation à la BSD) pour construire le système final. Elle a sa propre chaîne d'outils depuis 2010 (le nom complet de la « machine » est -0linux-linux-gnu) et se recompile elle-même avec bonheur.
Le passage d'un système cousu main à un système avec un gestionnaire de paquets se fait quasi naturellement, pourvu que le gestionnaire soit simple et abordable : j'avais commencé à écrire des SlackBuilds (de simples scripts) et à utiliser les pkgtools de Slackware pour reprendre ce que je faisais déjà à la main de manière automatisée. Se lancer directement dans des trucs complets qui gèrent les dépendances et les dépôts tiers comme les outils pour rpm ou deb est à mon sens une erreur si on veut apprendre progressivement la gestion de paquets. Mais la transition se fait sans trop de bobos puis qu'on va simplement greffer un gestionnaire par-dessus un système déjà existant qui va garder une trace des fichiers de chaque paquet afin de pouvoir les désinstaller ou les mettre à niveau.
Il est vrai que, bien qu'hors-sujet dans la méthode LFS, un gestionnaire de paquets est indispensable pour continuer à maintenir son propre système, sinon il faut tout simplement tout recommencer depuis le début, ça peut vite décourager.
Je recommande donc personnellement et selon mon expérience Spack ou les pkgtools de Slackware (qui se comporte tous deux de la même ; Spack est de plus compatible avec les paquets Slackware) pour débuter sa gestion de paquets sans s'encombrer de la gestion des dépendances. Sous 0Linux, c'est 0g qui fait les mises à jour en ligne et qui s'occupe des dépendances, le code de 0g est dispo ici. J'en discuterai avec plaisir à quiconque est intéressé.
« Généraliste » signifie « non spécialisé » mais en aucun cas orienté débutant. J'ai néanmoins déjà pensé à un installateur automatique qui s'occuperait du formatage et du partitionnement.
Je n'ai pas de LDFLAGS spécifique. peux-tu commenter les tiens ?
L'éditeur de liens est optimisé (comme celui de Gentoo), (voir man ld) ; en gros il allège le nombre de bibliothèques liées à chaque binaire et procède à une optimisation et un tri dans les symboles. Voir aussi chez Gentoo.
Si je linke sur /usr/lib${LIBDIRSUFFIX} c'est essentiellement pour gérer le multilib sous x86_64 (où $LIBDIRSUFFIX se vide quand on passe en 32 bits pour linker sur /usr/lib. De là on compile avec CC="gcc -m32", c'est apparenté à une compilation croisée mais ça ne l'est pas vraiment, le compilateur sous x86_64 produisant aussi du 32 bits nativement.
je ne met pas de "man", ni "info" (le public visé n'en a, a mon avis, pas besoin) mes "modules" sont en squashfs
Je gagnerais énormément d'espace disque si je supprimais la documentation, mais c'est sciemment que chaque paquet de 0linux dispose du maximum venant de l'upstream (sûrement trop).
Il faut surtout voir que les projets auraient à partager leurs ressources, si c'ets faisable et surtout ce qu'il auraient à y gagner.
De quoi parles-tu exactement quand tu parles de qualité : veux-tu dire par là « les binaires sont vérifiés et ne sont pas pétés », « chaque binaire est testé en environnement de production », « chaque symbole est vérifié », « les paquets sont recompilés en continu », « la doc est présente, bien rangée et compressée aux bons endroits», « les logs de compilation sont présents », « les mises à jour de sécurité arrivent le jour même des découvertes de failles », etc. ?
Il y a plein d'aspects à considérer quand on veut faire des paquets de qualité et c'est un concept subjectif. Archlinux fait des paquets de très bonne qualité, ça n'en empêche pas certains de péter occasionnellement lors de la publication, par exemple. Slackware, qui compte 800 à 900 paquets est à la base maintenue par une seule personne (c'est cela dit moins vrai aujourd'hui) et la qualité de ses paquets est connue et reconnue (de plus, GNOME était présent à l'époque où le dev était seul).
Techniquement, les paquets sont vérifiés à l'empaquetage et à l'installation (liens symboliques, emplacements, santé des binaires) puis tout le système hôte est scanné pour s'assurer qu'aucun binaire n'est cassé (auquel cas le serveur ordonne la recompilation de chaque paquet concerné), les fichiers de configuration sont préservés, les permissions sur les fichiers services également, un mécanisme reposant sur Busybox permet de prévenir tout cassage sur les paquets critiques (comme glibc, bash ou coreutils) et une documentation sur la santé de chaque paquet (logs de construction, paquets en dépendances, liste des libs partagées) est intégrée à la doc de chaque paquet.
Ce n'est certainement pas optimal et on est très loin d'une infra à la Debian où chaque paquet est inspecté et testé en profondeur mais pour une distribution d'amateur, marginale et spécifique, je trouve qu'on s'en tire pas trop mal quand on regarde derrière soi.
Mes CFLAGS pour ARM sont les suivants : FLAGS="-O2 -march=armv7-a -mfpu=vfpv3-d16 -pipe". J'ai néanmoins des RaspBerry Pi (rev. B) à disposition qui à priori me feraient tester d'abord sur cette machine.
Le code n'est néanmoins pas tout à fait prêt pour ARM (il me manque uniquement le "-gnueabi" dans la triplette cible et aucun patch/code spécifique n'a été écrit pour le moment, notamment concernant l'amorçage).
Je ne sais pas dans quelle mesure Dibab pourrait se « synergiser » avec 0Linux, tu as des idées ?
Il faut savoir que 0Linux a quelques spécificités (rien n'est figé néanmoins) :
pas de systemd
pas de pulseaudio (présent néanmoins, mais uniquement pour disposer des libs pour contenter Steam)
Non, pas d'extension de ce genre, même AdBlock Plus est désactivé pour linuxfr. Je fais un test sur Chrome sans aucune extension pour reproduire.
Bon, ça fonctionne très bien sous Chrome, je recommence sous Firefox en désactivant TOUTES les extensions.
Et ça fonctionne ! J'ai une extension qui pose problème, j'essaie de l'isoler à tâtons.
Edit : bon ben ça marche quelque soient les extensions présentes… Je remarque que j'avais un halo rouge autour du champ Titre du journal, comme si le titre était toujours détecté invalide, là ça n'est plus le cas (halo vert) et tout fonctionne. Je ne sais pas quoi dire.
Je reviendrai sur ce bug si je retombe dessus. Merci !
Il sont d'ailleurs eu la très bonne initiative de vouloir directement fournir tous les fichiers pour un maximum de services et binaires connus (tous ceux présents dans LFS et BLFS en fait). On regrettera par contre certaines commandes dont on a volontairement bâillonné les sorties, notamment des commandes comme mount -q || true pour rpcbind par exemple, mais le code est là et ça c'est très bien car la plupart des tentatives de remplacement de sysvinit se soldent souvent par des échecs, dus justement au manque de fichiers services mis à disposition.
Je pense que les anti-systemd sont ceux qui hackent (ou ont hacké) le système de boot. C'est lumineusement simple, basé sur du shell, et le fait de passer par un truc binaire carré fait penser à la base de registre de microsoft: bien intégré, rapide mais obscur. Et comme systemd vient de partout, bah il faut le manger quand même, envie ou pas.
Les zamoureux de systemd ont du regarder vaguement un jour l'init, voient systemd avec des fichiers .unit tout basiques et > disent que "ça marche, c'est rapide, et ça fait le job". Pourquoi pas.
Je trouve que tu as bien saisi la nuance de jugement selon le public : les sysadmins/utilisateurs qui trouvent ça bien foutu et facile à utiliser (je suis aussi de cet avis), et les bidouilleurs et autres intégrateurs/packageurs qui ont vu l'envers du décor, pas forcément joli-joli.
Pour avoir intégré systemd il fut un temps à la distribution que je maintiens (http://0linux.org), c'est ce côté-là qui m'a rebuté : systemd ne sait pas se tenir tranquille. À chaque release ce sont des binaires supplémentaires qui apparaissent et s'accaparent un rôle supplémentaire, de nouvelles règles Udev qui modifient le comportement, des déplacements de binaires, un paquet qui devient finalement obèse tout comme sa documentation (que ce soit un bien ou un mal, il faut se la coltiner)…
Nous avons donc utilisé systemd pendant 6-8 mois avec quasi-bonheur (bien qu'on ait dû se taper quelques unités à écrire et bien faire attention au mécanisme de dépendances ainsi qu'à un vocabulaire qui évolue vite où de nouveaux mots-clés font leur entrée régulièrement) côté utilisateur, mais côté intégration/empaquetage on n'a jamais été vraiment à l'aise et confronté à des limitations et à un manque de souplesse qui a fini par avoir raison de sa présence dans 0Linux, car demandant trop de hacking, justement, de notre part sur un logiciel qu'on connaît quand même plutôt mal.
En vrac : la restriction du démarrage des sessions du bureau sur le tty1, la création de fichiers spécifiques plus ou moins obscurs pour démarrer un initramfs (pour un Live par exemple) nous forçant peu à peu à passer à dracut qui lui intègre tout ce qu'il faut, le journal binaire qui a occasionné de beaux plantages de la machine, les consoles qui sautent après un certain temps si on ne s'y connecte pas, le service d'optimisation du temps de démarrage « readahead » qui a fini par être encore plus lent que mes initscripts à la BSD/Slackware et sûrement d'autres aspects que j'oublie.
Mais de là à dire que systemd n'est pas du tout hackable, il y a un fossé. Mis à part le journal en binaire, tout est au contraire très modulaire et le vocabulaire des unités et des options des binaires couvre très largement les usages et besoins (même si ça doit passer par la réécriture de nombreuses unités mais c'est un autre problème, systemd fournit le maximum de fichiers pour que tout marche tout de suite, on ne va pas s'en plaindre).
Plus le temps passe et plus je me dis que Lennart aurait bien mieux fait de concevoir une sorte de protocole ou une norme/RFC bien définie et stable (car les idées sont toutes très bonnes à la base) mais surtout pas d'implémenter tout ça dans un gros machin comme systemd, qui veut tout savoir faire tout en continuant d'avancer très vite (il va peut-être même un jour gérer nos paquets !). Ici on va conserver notre init BSD-like en attendant que les choses se tassent.
Donc, pour répondre à ta question : les deux. Intégration pour l'utilisateur, hackabilité pour le mainteneur/bidouilleur. Et justement systemd est peut-être trop intégré pour être hackable, bien qu'il le soit suffisamment (hackable).
Xfce fonctionne très bien ici sans systemd. Il faut en revanche garder à l'esprit que les sessions doivent être gérées pour permettre le montage de volumes en tant que simples utilisateurs (entre autres.
Il faut donc utiliser le mécanisme polkit + consolekit + udisks. Seul GNOME3 demande systemd pour gérer ses sessions desktop ainsi que le suspend/resume si ma mémoire est bonne. systemd est un cancer mais un bon dépistage permet de l'éviter.
J'ajoute pour le troll que systemd depuis sa version 214 demande CINQ utilisateurs dédiés sur le système ainsi que SIX groupes dédiés, dont le groupe "systemd-bus-proxy", groupe qui fait 17 caractères.
Dixit "man 8 groupadd" à la section "Avertissements" :
[^] # Re: Contournement temporaire
Posté par appzer0 (site web personnel) . En réponse au journal Firefox ne peut plus utiliser d'extension. Évalué à 4.
Tout à fait, merci pour l'information.
J'ajoute pour les gens qui utilisent Firefox sur le canal Release sous Debian (ici 66.0.1 sous sid, donc pas la version ESR), le problème concerne également les Language Packs.
about:configsignatures.requiredextensions.langpacks.signatures.requiredàfalsexpinstall.signatures.requiredàfalseEt oui, bien penser à remettre tout d'origine quand le bug sera corrigé.
# /var/run -> /run
Posté par appzer0 (site web personnel) . En réponse à la dépêche Aujourd’hui c’est déjà demain : systemd dans l’initrd sous Arch Linux. Évalué à 4.
Pourquoi dois-tu patcher ceci :
… sachant que
/var/runest un lien symbolique vers/run?Et pourquoi donc supprimer cette ligne ?
<mode pour_vendredi>Merci pour ton article, ça donne une vue d'ensemble plus précise de ce qu'il est nécessaire de savoir en plus pour mettre en place un initrd : savoir scripter + savoir alimenter initcpio via son vocabulaire + ajouter des unités via le vocabulaire systemd + patcher l'existant)
</mode>C'est néanmoins très complet et ça prend en compte LVM + le chiffrement + Plymouth, merci donc.
[^] # Re: Merci pour ce moment
Posté par appzer0 (site web personnel) . En réponse à la dépêche Maintenir sa distribution : état des lieux de 0Linux après 4 ans de développement. Évalué à 3.
Ah mais pas du tout Monsieur, ça marche très bien comme ça et ça va rester ainsi justement !
Python va surtout me servir pour certaines administratives lourdes, comme le catalogue en ligne des paquets par exemple. La gestion des paquets ne doit plus changer maintenant, quand ça marche on ne répare pas comme dirait l'autre. :)
Merci pour ton travail et ta constance au passage, Spack n'a pas la visibilité qu'il mérite, à mon sens.
[^] # Re: Retour sur systemd
Posté par appzer0 (site web personnel) . En réponse au journal Maintenir sa distribution : état des lieux de 0Linux après 4 ans de développement. Évalué à 2.
Je viens de réparer le wiki qui avait effectivement explosé (upgrade de dokuwiki -> dépassement de quota -> boum).
Pour systemd, je te renvoie à ce commentaire. Pour info, systemd a alourdi la charge de travail côté intégration/empaquetage uniquement. Côté utilisateur c'était bien plus positif (mais pas parfait).
Au passage, il reste une doc sur le wiki que je garde « au cas où » : http://0.tuxfamily.org/doku.php/documentation/systemd
[^] # Re: Beyond beyond Linux from scratch
Posté par appzer0 (site web personnel) . En réponse à la dépêche Maintenir sa distribution : état des lieux de 0Linux après 4 ans de développement. Évalué à 6.
Pour reprendre le contenu de l'accueil du wiki :
Le passage d'un système cousu main à un système avec un gestionnaire de paquets se fait quasi naturellement, pourvu que le gestionnaire soit simple et abordable : j'avais commencé à écrire des SlackBuilds (de simples scripts) et à utiliser les pkgtools de Slackware pour reprendre ce que je faisais déjà à la main de manière automatisée. Se lancer directement dans des trucs complets qui gèrent les dépendances et les dépôts tiers comme les outils pour rpm ou deb est à mon sens une erreur si on veut apprendre progressivement la gestion de paquets. Mais la transition se fait sans trop de bobos puis qu'on va simplement greffer un gestionnaire par-dessus un système déjà existant qui va garder une trace des fichiers de chaque paquet afin de pouvoir les désinstaller ou les mettre à niveau.
Il est vrai que, bien qu'hors-sujet dans la méthode LFS, un gestionnaire de paquets est indispensable pour continuer à maintenir son propre système, sinon il faut tout simplement tout recommencer depuis le début, ça peut vite décourager.
Je recommande donc personnellement et selon mon expérience Spack ou les pkgtools de Slackware (qui se comporte tous deux de la même ; Spack est de plus compatible avec les paquets Slackware) pour débuter sa gestion de paquets sans s'encombrer de la gestion des dépendances. Sous 0Linux, c'est 0g qui fait les mises à jour en ligne et qui s'occupe des dépendances, le code de 0g est dispo ici. J'en discuterai avec plaisir à quiconque est intéressé.
[^] # Re: Test dans blog
Posté par appzer0 (site web personnel) . En réponse à la dépêche Maintenir sa distribution : état des lieux de 0Linux après 4 ans de développement. Évalué à 4.
« Généraliste » signifie « non spécialisé » mais en aucun cas orienté débutant. J'ai néanmoins déjà pensé à un installateur automatique qui s'occuperait du formatage et du partitionnement.
[^] # Re: Dibab?
Posté par appzer0 (site web personnel) . En réponse au journal Maintenir sa distribution : état des lieux de 0Linux après 4 ans de développement. Évalué à 2.
Non, ça n'existe pas ! :) Les échanges que j'ai eus se sont toujours passés sur IRC : #0linux sur Freenode
[^] # Re: Dibab?
Posté par appzer0 (site web personnel) . En réponse au journal Maintenir sa distribution : état des lieux de 0Linux après 4 ans de développement. Évalué à 2.
Bieeen !
L'éditeur de liens est optimisé (comme celui de Gentoo), (voir
man ld) ; en gros il allège le nombre de bibliothèques liées à chaque binaire et procède à une optimisation et un tri dans les symboles. Voir aussi chez Gentoo.Si je linke sur
/usr/lib${LIBDIRSUFFIX}c'est essentiellement pour gérer le multilib sous x86_64 (où $LIBDIRSUFFIX se vide quand on passe en 32 bits pour linker sur/usr/lib. De là on compile avec CC="gcc -m32", c'est apparenté à une compilation croisée mais ça ne l'est pas vraiment, le compilateur sous x86_64 produisant aussi du 32 bits nativement.Je gagnerais énormément d'espace disque si je supprimais la documentation, mais c'est sciemment que chaque paquet de 0linux dispose du maximum venant de l'upstream (sûrement trop).
Il faut surtout voir que les projets auraient à partager leurs ressources, si c'ets faisable et surtout ce qu'il auraient à y gagner.
[^] # Re: Qualité ?
Posté par appzer0 (site web personnel) . En réponse au journal Maintenir sa distribution : état des lieux de 0Linux après 4 ans de développement. Évalué à 8.
De quoi parles-tu exactement quand tu parles de qualité : veux-tu dire par là « les binaires sont vérifiés et ne sont pas pétés », « chaque binaire est testé en environnement de production », « chaque symbole est vérifié », « les paquets sont recompilés en continu », « la doc est présente, bien rangée et compressée aux bons endroits», « les logs de compilation sont présents », « les mises à jour de sécurité arrivent le jour même des découvertes de failles », etc. ?
Il y a plein d'aspects à considérer quand on veut faire des paquets de qualité et c'est un concept subjectif. Archlinux fait des paquets de très bonne qualité, ça n'en empêche pas certains de péter occasionnellement lors de la publication, par exemple. Slackware, qui compte 800 à 900 paquets est à la base maintenue par une seule personne (c'est cela dit moins vrai aujourd'hui) et la qualité de ses paquets est connue et reconnue (de plus, GNOME était présent à l'époque où le dev était seul).
Techniquement, les paquets sont vérifiés à l'empaquetage et à l'installation (liens symboliques, emplacements, santé des binaires) puis tout le système hôte est scanné pour s'assurer qu'aucun binaire n'est cassé (auquel cas le serveur ordonne la recompilation de chaque paquet concerné), les fichiers de configuration sont préservés, les permissions sur les fichiers services également, un mécanisme reposant sur Busybox permet de prévenir tout cassage sur les paquets critiques (comme glibc, bash ou coreutils) et une documentation sur la santé de chaque paquet (logs de construction, paquets en dépendances, liste des libs partagées) est intégrée à la doc de chaque paquet.
Ce n'est certainement pas optimal et on est très loin d'une infra à la Debian où chaque paquet est inspecté et testé en profondeur mais pour une distribution d'amateur, marginale et spécifique, je trouve qu'on s'en tire pas trop mal quand on regarde derrière soi.
[^] # Re: Dibab?
Posté par appzer0 (site web personnel) . En réponse au journal Maintenir sa distribution : état des lieux de 0Linux après 4 ans de développement. Évalué à 1.
Mes CFLAGS pour ARM sont les suivants :
FLAGS="-O2 -march=armv7-a -mfpu=vfpv3-d16 -pipe". J'ai néanmoins des RaspBerry Pi (rev. B) à disposition qui à priori me feraient tester d'abord sur cette machine.Le code n'est néanmoins pas tout à fait prêt pour ARM (il me manque uniquement le "-gnueabi" dans la triplette cible et aucun patch/code spécifique n'a été écrit pour le moment, notamment concernant l'amorçage).
Je ne sais pas dans quelle mesure Dibab pourrait se « synergiser » avec 0Linux, tu as des idées ?
Il faut savoir que 0Linux a quelques spécificités (rien n'est figé néanmoins) :
LDFLAGS="-L/usr/lib${LIBDIRSUFFIX} -Wl,-O1,--as-needed,--sort-common"/usr/libpour le 32 bits,/usr/lib64pour le 64,), le reste est « pur » et standard, libs dans/usr/lib/usr/manet/usr/info(/usr/share/{info,man}sont des liens symboliques)# pas d'ipfuck
Posté par appzer0 (site web personnel) . En réponse à l’entrée du suivi Page blanche lors de la prévisualisation d'un journal. Évalué à 1 (+0/-0).
Non, pas d'extension de ce genre, même AdBlock Plus est désactivé pour linuxfr. Je fais un test sur Chrome sans aucune extension pour reproduire.
Bon, ça fonctionne très bien sous Chrome, je recommence sous Firefox en désactivant TOUTES les extensions.
Et ça fonctionne ! J'ai une extension qui pose problème, j'essaie de l'isoler à tâtons.
Edit : bon ben ça marche quelque soient les extensions présentes… Je remarque que j'avais un halo rouge autour du champ Titre du journal, comme si le titre était toujours détecté invalide, là ça n'est plus le cas (halo vert) et tout fonctionne. Je ne sais pas quoi dire.
Je reviendrai sur ce bug si je retombe dessus. Merci !
[^] # Re: Et systemd ???
Posté par appzer0 (site web personnel) . En réponse à la dépêche LFS en version 7.6. Évalué à 4.
Il sont d'ailleurs eu la très bonne initiative de vouloir directement fournir tous les fichiers pour un maximum de services et binaires connus (tous ceux présents dans LFS et BLFS en fait). On regrettera par contre certaines commandes dont on a volontairement bâillonné les sorties, notamment des commandes comme
mount -q || truepour rpcbind par exemple, mais le code est là et ça c'est très bien car la plupart des tentatives de remplacement de sysvinit se soldent souvent par des échecs, dus justement au manque de fichiers services mis à disposition.# Du point de vue utilisateur ou mainteneur ?
Posté par appzer0 (site web personnel) . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 10.
Je trouve que tu as bien saisi la nuance de jugement selon le public : les sysadmins/utilisateurs qui trouvent ça bien foutu et facile à utiliser (je suis aussi de cet avis), et les bidouilleurs et autres intégrateurs/packageurs qui ont vu l'envers du décor, pas forcément joli-joli.
Pour avoir intégré systemd il fut un temps à la distribution que je maintiens (http://0linux.org), c'est ce côté-là qui m'a rebuté : systemd ne sait pas se tenir tranquille. À chaque release ce sont des binaires supplémentaires qui apparaissent et s'accaparent un rôle supplémentaire, de nouvelles règles Udev qui modifient le comportement, des déplacements de binaires, un paquet qui devient finalement obèse tout comme sa documentation (que ce soit un bien ou un mal, il faut se la coltiner)…
Nous avons donc utilisé systemd pendant 6-8 mois avec quasi-bonheur (bien qu'on ait dû se taper quelques unités à écrire et bien faire attention au mécanisme de dépendances ainsi qu'à un vocabulaire qui évolue vite où de nouveaux mots-clés font leur entrée régulièrement) côté utilisateur, mais côté intégration/empaquetage on n'a jamais été vraiment à l'aise et confronté à des limitations et à un manque de souplesse qui a fini par avoir raison de sa présence dans 0Linux, car demandant trop de hacking, justement, de notre part sur un logiciel qu'on connaît quand même plutôt mal.
En vrac : la restriction du démarrage des sessions du bureau sur le tty1, la création de fichiers spécifiques plus ou moins obscurs pour démarrer un initramfs (pour un Live par exemple) nous forçant peu à peu à passer à dracut qui lui intègre tout ce qu'il faut, le journal binaire qui a occasionné de beaux plantages de la machine, les consoles qui sautent après un certain temps si on ne s'y connecte pas, le service d'optimisation du temps de démarrage « readahead » qui a fini par être encore plus lent que mes initscripts à la BSD/Slackware et sûrement d'autres aspects que j'oublie.
Mais de là à dire que systemd n'est pas du tout hackable, il y a un fossé. Mis à part le journal en binaire, tout est au contraire très modulaire et le vocabulaire des unités et des options des binaires couvre très largement les usages et besoins (même si ça doit passer par la réécriture de nombreuses unités mais c'est un autre problème, systemd fournit le maximum de fichiers pour que tout marche tout de suite, on ne va pas s'en plaindre).
Plus le temps passe et plus je me dis que Lennart aurait bien mieux fait de concevoir une sorte de protocole ou une norme/RFC bien définie et stable (car les idées sont toutes très bonnes à la base) mais surtout pas d'implémenter tout ça dans un gros machin comme systemd, qui veut tout savoir faire tout en continuant d'avancer très vite (il va peut-être même un jour gérer nos paquets !). Ici on va conserver notre init BSD-like en attendant que les choses se tassent.
Donc, pour répondre à ta question : les deux. Intégration pour l'utilisateur, hackabilité pour le mainteneur/bidouilleur. Et justement systemd est peut-être trop intégré pour être hackable, bien qu'il le soit suffisamment (hackable).
[^] # Re: Portabilité et forçage
Posté par appzer0 (site web personnel) . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 2.
Xfce fonctionne très bien ici sans systemd. Il faut en revanche garder à l'esprit que les sessions doivent être gérées pour permettre le montage de volumes en tant que simples utilisateurs (entre autres.
Il faut donc utiliser le mécanisme polkit + consolekit + udisks. Seul GNOME3 demande systemd pour gérer ses sessions desktop ainsi que le suspend/resume si ma mémoire est bonne. systemd est un cancer mais un bon dépistage permet de l'éviter.
J'ajoute pour le troll que systemd depuis sa version 214 demande CINQ utilisateurs dédiés sur le système ainsi que SIX groupes dédiés, dont le groupe "systemd-bus-proxy", groupe qui fait 17 caractères.
Dixit "man 8 groupadd" à la section "Avertissements" :