Bonjour, Le samedi 26 juin 2021 à 16:59, BERTRAND Joël <joel.bertr...@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