Personnellement, tant que je peux garder / et /usr séparées, je le
ferai. Et lorsque ce sera une obligation, je passerai Í autre chose.
Personnellement, tant que je peux garder / et /usr séparées, je le
ferai. Et lorsque ce sera une obligation, je passerai Í autre chose.
Personnellement, tant que je peux garder / et /usr séparées, je le
ferai. Et lorsque ce sera une obligation, je passerai Í autre 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…
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…
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…
Bonjour,
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.
Merci
S
Bonjour,
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.
Merci
S
Bonjour,
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.
Merci
S
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.
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.
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.
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).
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.
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
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.
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é.
Ç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.
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}
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).
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.
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
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.
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é.
Ç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.
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}
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).
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.
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
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.
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é.
Ç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.
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}