Dans un autre post concernant pulseaudio, Hugues parle de usrmerge. Je
teste sur mon système:
ls -ail /
12 drwxr-xr-x 2 root root 12288 23 jun 09:52 bin
917506 drwxr-xr-x 2 root root 12288 10 jun 08:36 sbin
262146 drwxr-xr-x 17 root root 4096 7 jun 08:27 lib
131074 drwxr-xr-x 2 root root 4096 21 mai 07:00 lib64
Ce ne sont manifestement pas des liens symboliques.
Cette machine a été mise Í niveau depuis squeeze et a donc probablement
raté cette étape.
Sur https://wiki.debian.org/UsrMerge, on lit:
In February 2021, the Technical Committee has resolved that Debian
'bookworm' should support only the merged-usr root filesystem layout,
dropping support for the non-merged-usr layout. (978636)
Ma question est donc de savoir si je peux y aller les yeux fermés ou si
je dois faire particulièrement attention Í quelque chose.
Le 24-06-2021, Í 08:48:45 +0200, BERTRAND Joël a écrit :
Personnellement, tant que je peux garder / et /usr séparées, je le ferai. Et lorsque ce sera une obligation, je passerai Í autre chose.
Et bien c'est rassurant comme réponse :) Je vais donc rester comme je suis en attendant d'autres réponses peut-être moins anxiogènes…
Frédéric MASSOT
Le 24/06/2021 Í 11:29, steve a écrit :
Le 24-06-2021, Í 08:48:45 +0200, BERTRAND Joël a écrit :
    Personnellement, tant que je peux garder / et /usr séparées, je le  ferai. Et lorsque ce sera une obligation, je passerai Í autre chose.
Et bien c'est rassurant comme réponse :) Je vais donc rester comme je suis en attendant d'autres réponses peut-être moins anxiogènes…
J'ai utilisé usrmerge sur mon PC perso sans problème. Il n'y avait qu'une partition pour l'ensemble du système. -- =============================================| FRÉDÉRIC MASSOT | | http://www.juliana-multimedia.com | | mailto: | | +33.(0)2.97.54.77.94 +33.(0)6.67.19.95.69 | ==========================Þbian=GNU/Linux==
Le 24/06/2021 Í 11:29, steve a écrit :
Le 24-06-2021, Í 08:48:45 +0200, BERTRAND Joël a écrit :
    Personnellement, tant que je peux garder / et /usr séparées, je le
 ferai. Et lorsque ce sera une obligation, je passerai Í autre chose.
Et bien c'est rassurant comme réponse :)
Je vais donc rester comme je suis en attendant d'autres réponses
peut-être moins anxiogènes…
J'ai utilisé usrmerge sur mon PC perso sans problème. Il n'y avait
qu'une partition pour l'ensemble du système.
Le 24-06-2021, Í 08:48:45 +0200, BERTRAND Joël a écrit :
    Personnellement, tant que je peux garder / et /usr séparées, je le  ferai. Et lorsque ce sera une obligation, je passerai Í autre chose.
Et bien c'est rassurant comme réponse :) Je vais donc rester comme je suis en attendant d'autres réponses peut-être moins anxiogènes…
J'ai utilisé usrmerge sur mon PC perso sans problème. Il n'y avait qu'une partition pour l'ensemble du système. -- =============================================| FRÉDÉRIC MASSOT | | http://www.juliana-multimedia.com | | mailto: | | +33.(0)2.97.54.77.94 +33.(0)6.67.19.95.69 | ==========================Þbian=GNU/Linux==
Hugues Larrive
Bonjour, Le jeudi 24 juin 2021 Í 08:27, steve a écrit :
Bonjour, Dans un autre post concernant pulseaudio, Hugues parle de usrmerge. Je
En fait je l'ai découvert dans un post du forum dont j'ai donné le lien, je l'ai écarté comme cause du problème de pulseaudio vu que sur mon système fraÍ®chement installé en bullseye, c'était déjÍ des liens symboliques (ce qui ne m'enchante guère).
teste sur mon système: ls -ail / 12 drwxr-xr-x 2 root root 12288 23 jun 09:52 bin 917506 drwxr-xr-x 2 root root 12288 10 jun 08:36 sbin 262146 drwxr-xr-x 17 root root 4096 7 jun 08:27 lib 131074 drwxr-xr-x 2 root root 4096 21 mai 07:00 lib64 Ce ne sont manifestement pas des liens symboliques. Cette machine a été mise Í niveau depuis squeeze et a donc probablement raté cette étape. Sur https://wiki.debian.org/UsrMerge, on lit: In February 2021, the Technical Committee has resolved that Debian 'bookworm' should support only the merged-usr root filesystem layout, dropping support for the non-merged-usr layout. (978636) Ma question est donc de savoir si je peux y aller les yeux fermés ou si je dois faire particulièrement attention Í quelque chose.
Sur un système avec tout dans la même partition ça ne devrait pas poser de problème, même en mettant tous les binaires dans un dossier unique avec des liens symboliques de leurs dossiers d'origine pointant dessus ça devrait fonctionner. Le problème c'est si tu distribues des chose, par exemple un script shell commençant par #!/bin/sh fonctionnera dans tous les cas (tant qu'il y a un symlink de /bin -> /usr/bin, mais s'il commençait par #!/usr/bin/sh il ne fonctionnerait pas sur un système o͹ sh se trouve dans /bin. Ou si tu as une configuration avec /usr sur une partition séparée, dans ce cas il faut que tout le nécessaire pour monter cette partition soit dans l'initrd.
Merci S
Bonjour,
Le jeudi 24 juin 2021 Í 08:27, steve <dlist@bluewin.ch> a écrit :
Bonjour,
Dans un autre post concernant pulseaudio, Hugues parle de usrmerge. Je
En fait je l'ai découvert dans un post du forum dont j'ai donné le lien, je
l'ai écarté comme cause du problème de pulseaudio vu que sur mon système
fraÍ®chement installé en bullseye, c'était déjÍ des liens symboliques (ce qui
ne m'enchante guère).
teste sur mon système:
ls -ail /
12 drwxr-xr-x 2 root root 12288 23 jun 09:52 bin
917506 drwxr-xr-x 2 root root 12288 10 jun 08:36 sbin
262146 drwxr-xr-x 17 root root 4096 7 jun 08:27 lib
131074 drwxr-xr-x 2 root root 4096 21 mai 07:00 lib64
Ce ne sont manifestement pas des liens symboliques.
Cette machine a été mise Í niveau depuis squeeze et a donc probablement
raté cette étape.
Sur https://wiki.debian.org/UsrMerge, on lit:
In February 2021, the Technical Committee has resolved that Debian
'bookworm' should support only the merged-usr root filesystem layout,
dropping support for the non-merged-usr layout. (978636)
Ma question est donc de savoir si je peux y aller les yeux fermés ou si
je dois faire particulièrement attention Í quelque chose.
Sur un système avec tout dans la même partition ça ne devrait pas poser de
problème, même en mettant tous les binaires dans un dossier unique avec
des liens symboliques de leurs dossiers d'origine pointant dessus ça devrait
fonctionner. Le problème c'est si tu distribues des chose, par exemple un
script shell commençant par #!/bin/sh fonctionnera dans tous les cas (tant
qu'il y a un symlink de /bin -> /usr/bin, mais s'il commençait par
#!/usr/bin/sh il ne fonctionnerait pas sur un système o͹ sh se trouve dans
/bin. Ou si tu as une configuration avec /usr sur une partition séparée,
dans ce cas il faut que tout le nécessaire pour monter cette partition soit
dans l'initrd.
Bonjour, Le jeudi 24 juin 2021 Í 08:27, steve a écrit :
Bonjour, Dans un autre post concernant pulseaudio, Hugues parle de usrmerge. Je
En fait je l'ai découvert dans un post du forum dont j'ai donné le lien, je l'ai écarté comme cause du problème de pulseaudio vu que sur mon système fraÍ®chement installé en bullseye, c'était déjÍ des liens symboliques (ce qui ne m'enchante guère).
teste sur mon système: ls -ail / 12 drwxr-xr-x 2 root root 12288 23 jun 09:52 bin 917506 drwxr-xr-x 2 root root 12288 10 jun 08:36 sbin 262146 drwxr-xr-x 17 root root 4096 7 jun 08:27 lib 131074 drwxr-xr-x 2 root root 4096 21 mai 07:00 lib64 Ce ne sont manifestement pas des liens symboliques. Cette machine a été mise Í niveau depuis squeeze et a donc probablement raté cette étape. Sur https://wiki.debian.org/UsrMerge, on lit: In February 2021, the Technical Committee has resolved that Debian 'bookworm' should support only the merged-usr root filesystem layout, dropping support for the non-merged-usr layout. (978636) Ma question est donc de savoir si je peux y aller les yeux fermés ou si je dois faire particulièrement attention Í quelque chose.
Sur un système avec tout dans la même partition ça ne devrait pas poser de problème, même en mettant tous les binaires dans un dossier unique avec des liens symboliques de leurs dossiers d'origine pointant dessus ça devrait fonctionner. Le problème c'est si tu distribues des chose, par exemple un script shell commençant par #!/bin/sh fonctionnera dans tous les cas (tant qu'il y a un symlink de /bin -> /usr/bin, mais s'il commençait par #!/usr/bin/sh il ne fonctionnerait pas sur un système o͹ sh se trouve dans /bin. Ou si tu as une configuration avec /usr sur une partition séparée, dans ce cas il faut que tout le nécessaire pour monter cette partition soit dans l'initrd.
Merci S
steve
Le 25-06-2021, Í 09:09:32 +0000, Hugues Larrive a écrit :
Sur un système avec tout dans la même partition ça ne devrait pas poser de problème, même en mettant tous les binaires dans un dossier unique avec des liens symboliques de leurs dossiers d'origine pointant dessus ça devrait fonctionner. Le problème c'est si tu distribues des chose, par exemple un script shell commençant par #!/bin/sh fonctionnera dans tous les cas (tant qu'il y a un symlink de /bin -> /usr/bin, mais s'il commençait par #!/usr/bin/sh il ne fonctionnerait pas sur un système o͹ sh se trouve dans /bin. Ou si tu as une configuration avec /usr sur une partition séparée, dans ce cas il faut que tout le nécessaire pour monter cette partition soit dans l'initrd.
J'ai un partitionnent un peu plus compliqué que ça, avec du Raid 1 pour certaines: udev on /dev type devtmpfs (rw,nosuid,relatime,size239944k,,modeu5) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,modeb0,ptmxmode 0) /dev/sdb5 on / type ext4 (rw,relatime,errors=remount-ro) /dev/sdb6 on /usr type ext4 (rw,relatime) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime) hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M) /dev/sdb1 on /boot type ext4 (rw,relatime) /dev/sde1 on /vm type ext4 (rw,relatime) /dev/md0 on /var type ext4 (rw,relatime) /dev/md1 on /home type ext4 (rw,relatime) /dev/md2 on /DATA type ext4 (rw,relatime) /dev/sdb3 on /boot/efi type vfat (rw,relatime,fmask 77,dmask 77,codepageC7,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro) Risqué de se lancer dans cette opération de merge ?
Le 25-06-2021, Í 09:09:32 +0000, Hugues Larrive a écrit :
Sur un système avec tout dans la même partition ça ne devrait pas poser de
problème, même en mettant tous les binaires dans un dossier unique avec
des liens symboliques de leurs dossiers d'origine pointant dessus ça devrait
fonctionner. Le problème c'est si tu distribues des chose, par exemple un
script shell commençant par #!/bin/sh fonctionnera dans tous les cas (tant
qu'il y a un symlink de /bin -> /usr/bin, mais s'il commençait par
#!/usr/bin/sh il ne fonctionnerait pas sur un système o͹ sh se trouve dans
/bin. Ou si tu as une configuration avec /usr sur une partition séparée,
dans ce cas il faut que tout le nécessaire pour monter cette partition soit
dans l'initrd.
J'ai un partitionnent un peu plus compliqué que ça, avec du Raid 1 pour
certaines:
udev on /dev type devtmpfs (rw,nosuid,relatime,size239944k,nr_inodes@59986,modeu5)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,modeb0,ptmxmode 0)
/dev/sdb5 on / type ext4 (rw,relatime,errors=remount-ro)
/dev/sdb6 on /usr type ext4 (rw,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
/dev/sdb1 on /boot type ext4 (rw,relatime)
/dev/sde1 on /vm type ext4 (rw,relatime)
/dev/md0 on /var type ext4 (rw,relatime)
/dev/md1 on /home type ext4 (rw,relatime)
/dev/md2 on /DATA type ext4 (rw,relatime)
/dev/sdb3 on /boot/efi type vfat (rw,relatime,fmask 77,dmask 77,codepageC7,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
Risqué de se lancer dans cette opération de merge ?
Le 25-06-2021, Í 09:09:32 +0000, Hugues Larrive a écrit :
Sur un système avec tout dans la même partition ça ne devrait pas poser de problème, même en mettant tous les binaires dans un dossier unique avec des liens symboliques de leurs dossiers d'origine pointant dessus ça devrait fonctionner. Le problème c'est si tu distribues des chose, par exemple un script shell commençant par #!/bin/sh fonctionnera dans tous les cas (tant qu'il y a un symlink de /bin -> /usr/bin, mais s'il commençait par #!/usr/bin/sh il ne fonctionnerait pas sur un système o͹ sh se trouve dans /bin. Ou si tu as une configuration avec /usr sur une partition séparée, dans ce cas il faut que tout le nécessaire pour monter cette partition soit dans l'initrd.
J'ai un partitionnent un peu plus compliqué que ça, avec du Raid 1 pour certaines: udev on /dev type devtmpfs (rw,nosuid,relatime,size239944k,,modeu5) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,modeb0,ptmxmode 0) /dev/sdb5 on / type ext4 (rw,relatime,errors=remount-ro) /dev/sdb6 on /usr type ext4 (rw,relatime) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime) hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M) /dev/sdb1 on /boot type ext4 (rw,relatime) /dev/sde1 on /vm type ext4 (rw,relatime) /dev/md0 on /var type ext4 (rw,relatime) /dev/md1 on /home type ext4 (rw,relatime) /dev/md2 on /DATA type ext4 (rw,relatime) /dev/sdb3 on /boot/efi type vfat (rw,relatime,fmask 77,dmask 77,codepageC7,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro) Risqué de se lancer dans cette opération de merge ?
Hugues Larrive
Bonjour, Le samedi 26 juin 2021 Í 16:59, BERTRAND Joël 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
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}
Bonjour, Le samedi 26 juin 2021 Í 16:59, BERTRAND Joël 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
