Re : Re: Re : usrmerge
Bonjour,
Le samedi 26 juin 2021 à 16:59, BERTRAND Joël <joel.bertrand@systella.fr> a écrit :
> Sur un système bien fichu, tu n'as même pas besoin de initrd ou autre
> bidouillerie. initrd n'est qu'un bidule contournant un problème de
> design du démarrage de Linux (il n'y a aucune raison valable pour que
> le noyau ne puisse pas se débrouiller tout seul à l'instar des *BSD).
C'est vrai qu'ils feraient mieux de chercher à éliminer l'initrd au profit de la
partition racine plutôt que l'inverse...
> Même sur un i386, ça ne se justifie pas. Au lieu de réinventer la
> roue, les développeurs devraient aller voir un peu comment sont fichus
> les autres Unix.
Les mecs considèrent Solaris (dont la dernière version date d'il y a plus de 10
ans) comme la principale implémentation commerciale d'Unix, ils n'ont
vraisemblablement jamais touché un Mac de leur vie... sous macos /bin et /sbin
ne sont pas des liens symboliques, /lib est remplacé par /Library et
/System/Library (comme un genre de /lib et /slib), et surtout les applications
graphiques sont scriptables (automator / applescript), dommage qu'on ne sache pas
en faire autant dans le libre.
> La vraie question que je me pose depuis que des trucs comme ça sont
> apparus (je classe systemd, dbus et usrmerge dans la même catégorie)
> est de savoir si les développeurs actuels des linuxeries sont bien
> conscients des détails techniques qui ont permis d'arriver à une
> arborescence à peu près standardisée et à un système de démarrage de
> type SystemV ou RC. Visiblement non et la palme semble être mise au
> développeur qui sort l'idée la plus tordue (pour rester poli),
> généralement contraire au KISS, proposant quelque chose qui fait tout
> à peu près, donc qui ne fait rien correctement. J'ai suivi les
> discussions sur usrmerge et certains arguments étaient pathétiques (du
> style, on ne sait plus si tel ou tel programme est dans /bin ou
> /usr/bin... Ben mon cochon, c'est qu'ils ne comprennent pas la
> différence et s'ils ne comprennent pas la différence, sont-ils
> légitimes d'imposer de telles décisions ?). Il est vrai que j'ai déjà
> vu des shells dans /usr/bin... Quelle sera la prochaine étape ? Tout
> coller dans un seul répertoire ? /bin, /sbin, /usr/bin, /usr/sbin
> ensemble ? Et tant qu'on y est avec /lib et /usr/lib pour simplifier
>
LOL ben oui, même tout en vrac dans / avec un "searchd" comme ça le système
ressemblerait à un genre de cloud...
> ld (qui est déjà un bloatware en lui-même) ?
> Le fait, historiquement, d'avoir /, /usr et /usr/local séparés a
> surtout eu un côté pratique. Le fait de pouvoir démarrer un système
> minimal sur une partition qui pouvait être en ro et le rester. C'était
> la certitude d'avoir un système fonctionnel quelle que soit la
> situation. Et c'est encore ce qu'on cherche dans l'embarqué. En
> mélangeant / et /usr, on fait l'hypothèse spécieuse que /usr sera
> toujours accessible au moins en lecture (ou qu'on embarquera tout ce
> qu'il faut dans un initrd). Sauf que dans le cas général, ce n'est pas
> forcément vrai. Même dans l'embarqué, rares sont les partitions /usr
> qui peuvent rester en ro.
>
Il y a quelques années j'avais fais un réseau de 5 raspberry pi avec /var
et /usr en iscsi par réseau wifi, ça aurait été beaucoup plus compliqué
avec usrmerge...
> Une fois de plus, debian pousse des choses qui sont peut-être
> acceptables sur un poste de travail, qui deviennent discutables sur un
> serveur et totalement inacceptable dans le monde de l'embarqué.
>
On dirait qu'ils ont un peut oublié le sens du slogan "Le système
d'exploitation universel".
> Ça pourrait passer à la limite si le choix était à la discrétion de
> l'utilisateur. Mais ça n'est pas le cas. La dernière fois que j'ai
> installé une debian, je me suis retrouvé avec usrmerge.
>
À ce sujet j'ai une question : en cherchant un peu j'ai trouvé que
debootstrap a une option --no-merged-usr mais je n'ai pas trouvé
comment faire avec debian-installer.
> \begin{mode vieux con}
> Ce qui me navre, c'est que je peux faire aujourd'hui les mêmes
> reproches que je faisais à Windows à la fin des années 1990. Certaines
> choses démarrent aléatoirement (merci systemd et son démarrage
> concurent non maîtrisé !), Xorg plante de plus ne plus sans raison
> (fermeture des sessions et retour à wdm dans raison valable) et le
> développement semble réellement être sur une mauvaise pente... Je ne
> parle même pas de la glibc qui trimballe les mêmes bugs depuis au
> moins 15 ans. Remarque bien, on finit par les connaître, à force !...
> \end{mode vieux con}
>
Bienvenue au club des vieux con ;)
Cordialement
Hugues
Reply to: