-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Bonjour,
Étienne Mollier a écrit :
> À vue de nez, pas tant que ça. Les prérequis pour monter / et /usr
> sont les mêmes, c.-à-d. supporter le Sata et l'Ext4 ;
Sauf que si le système est bien foutu, tu n'as absolument pas besoin
de /usr pour qu'il démarre jusqu'au bout. Pour un Unix traditionnel
(c'est-à-dire dans usrmerge), tu as besoin :
- - du noyau
- - éventuellement de ses modules (dans /lib sous Linux, /stand ailleurs..
.)
- - de /bin et /sbin
- - de /lib
- - de /etc pour la configuration
- - éventuellement de /var.
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.
Accessoirement, un Unix bien fichu contient aussi un répertoire
/rescue avec les utilitaires du système compilés en statique pour
remettre d'équerre un OS, ce qui évite en cas de plantage de /lib de
rechercher un media bootable. Avec /rescue, le système est toujours
utilisable a minima.
/usr/bin et /usr/sbin contiennent les applications de l'utilisateur
et non du système. Celles-ci ne sont pas requises pour démarrer le
système de base (elles peuvent l'être une fois le système initialisé,
c'est-à-dire une fois que les disques peuvent être montés).
/usr/local/bin et /usr/local/sbin contiennent normalement les
applications 'locales' à la machine.
> Historiquement parlant, le premier schisme entre / et /usr aurait
> eu lieu quand K&R sont arrivés au bout de l'espace disponible sur
> la bande / de leur DEC PDP-11, si j'en croie les archives de la
> liste de diffusion de Busybox[2]. Les considérations techniques
> sont apparues ensuite pour permettre à la machine de démarrer
> correctement sans avoir immédiatement la bande /usr à disposition.
> Aujourd'hui le rôle d'un tel / a dérivé vers l'initrd (voir vers le
> chargeur de démarrage), du coup le schisme n'a théoriquement plus
> vraiment lieu d'être, en dehors de maintenir la compatibilité avec
> l'existant ; du coup, je peux comprendre que certains pensent que /
> et l'initrd fassent un peu double emploi.
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}
JKB
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEq4YCoAJMwLElZVYXOAfo0lKQ8+cFAmDXQOMACgkQOAfo0lKQ
8+fXxw/+Ll/+y/Szo7EHnyqUW88fD/7QLRGfmOgNPDuZ1VxC6Kf7RIqzTQucIuDu
iM0VpnsNXn1tA32loDiNs435jvSw4rm8b9rdolJq/gL+2FkqZpPa77TUtKQYwrry
Ey2vwbe2JC4DPgymIFlf+OKloPYC70z/pmC8fJwyvFETuSzX7ySZMsmGJPX7NmST
OF1rcTyAK3Kx3Ssko+uzkhI5GoM9uawK+cqCzxYJcbrBtZfm7d4epMPIId64caIm
HfbAU+c8GYiaZmBHMfdxBcv0hyJlt7TzVEJrBgiPpo0Jzlqh3Fu6+6SggCbl+dtS
yf+yo9IkVTpIByOWWTdLvtOumN/AT85tqdIUiWqKihgJnlvPM7RRSwo2DV9+kbPg
3CUB5NdVj7pFw2tj4+lzoYRdVK/AsT3OnNr7Hvl94dIqSw+u4jK3rRoX7rXtTHjs
jcTNYM1ybCheRw0o0sQFv2gkuu5AOlEc4FvQuPjqycLE5SAHFF12xKHKvBwkzYma
W6wSHuvkubYBXaepZL5Ztchg+drOnRCe+t/6dwK+llxaXOthPkP6vAJaZUXqVOdI
p1EqzKH4QEnJFwMyJ+YyX3Kd1fqDx2A4hnYBxsFXwnZtJ5CGgpYxDjDmXPL/Tu1z
//df5eqEc/lALjE0QV95dXfC0BR4QorrVClI7rDcRnXMUONrM3M=
=A/Pj
-----END PGP SIGNATURE-----
