Ciao, mi intrometto anche io con i miei "2 cents" Il giorno mar, 24/01/2023 alle 16.48 +0100, Federico Di Gregorio ha scritto: > On 24/01/23 11:51, Alessandro Rubini wrote: > > > Inoltre se usi una Debian moderna, probabilmente > > > hai gia` "usrmerge", ovvero /bin e /lib sono due link simbolici che > > > puntano a /usr/bin e /usr/lib. > > > > Che brutta cosa. Ci spieghi il razionale[1]? Sulle mie macchine tendo a > > Non sono un esperto della cosa ma il razionale che più mi convince è che > da sempre le varie distribuzioni hanno scelto in maniera completamente > arbitraria cosa mettere in "/bin" e cosa in "/usr/bin". Tipo "dai, > Python è di sistema , mettiamolo in /bin/python" rispetto a "ma che > schifo fa Python? vabbè, gli utenti lo vogliono, mettiamolo come add-on > in /usr/bin". Questo causa alcuni problemi di portabilità di vari script > e/o eseguibili che chiamano programmi esterni. Si, OK, esisterebbe "env" > ma tanto nessuno lo usa... Mettendo tutto assieme si evita questo problema. > > Poi c'è chi dice che così è più facile esportare "/usr" da rete per i > thin client ma sinceramente l'ultimo thin claient l'ho visto 20 anni fa...
Credo che la FHS indichi /bin per tutto quello che deve funzionare finché non ci sono gli altri file system montati (per il boot, per montare gli altri fs, una shell, eccetera). /usr/bin per tutti gli altri comandi. Con l'aggiunta che la /usr può essere esportata e condivisa, ma non solo per i thin client, anche per tutti i server diskless (questi sono un po' più diffusi dei thin client, anche se solo in alcuni contesti). Aggiungo che systemd ha la unit local-fs.target. Chi parte al boot prima di questo target dovrebbe usare solo /bin, chi parte dopo dovrebbe poter usare anche /usr/bin e quindi dipendere da essa. Ciao, Giuseppe
