Innanzitutto, una dichiarazione di non responsabilità sul conflitto di interessi: sono uno sviluppatore GoboLinux di lunga data.
In secondo luogo, un'affermazione anticipata dell'esperienza del dominio: sono uno sviluppatore GoboLinux di lunga data.
Ci sono alcune diverse strutture nell'uso attuale. GoboLinux ne ha uno e strumenti come GNU Stow , Homebrew , ecc., Usano qualcosa di abbastanza simile (principalmente per i programmi utente). NixOS utilizza anche una gerarchia non standard per i programmi e la filosofia di vita. È anche un esperimento LFS ragionevolmente comune.
Descriverò tutti questi, e poi commenterò per esperienza su come funziona in pratica ("fattibilità"). La risposta breve è che sì, è fattibile, ma devi volerlo davvero .
GoboLinux
GoboLinux ha una struttura molto simile a ciò che descrivi. Il software è installato in /Programs: /Programs/ZSH/5.0.8contiene tutti i file appartenenti a ZSH 5.0.8, nelle normali directory bin/ lib/ .... Gli strumenti di sistema creano collegamenti simbolici a quei file in una /System/Linksgerarchia, che viene mappata su /usr¹. La PATHvariabile contiene solo la singola directory eseguibile unificata ed LD_LIBRARY_PATHè inutilizzata. Più versioni del software possono coesistere contemporaneamente, ma solo un file con un determinato nome ( bin/zsh) verrà collegato attivamente alla volta. Puoi accedere agli altri attraverso i loro percorsi completi.
Un insieme di link simbolici di compatibilità esiste anche, in modo /bine /usr/binmappare la directory di file eseguibile unificato, e così via. Ciò semplifica la vita del software in fase di esecuzione. Una patch del kernel, GoboHide, consente a quei collegamenti simbolici di compatibilità di essere nascosti dagli elenchi di file (ma ancora attraversabili).
Per contro un'altra risposta, non è necessario modificare il codice del kernel: GoboHide è puramente cosmetico e il kernel non dipende dai percorsi dello spazio utente in generale². GoboLinux ha un sistema init su misura, ma anche questo non è richiesto.
Lo slogan è sempre stato "il filesystem è il gestore dei pacchetti", ma ci sono strumenti di gestione dei pacchetti ragionevolmente ordinari nel sistema. Si può fare tutto usando cp, rme ln, però.
Se vuoi usare GoboLinux, sei il benvenuto. Noterò, tuttavia, che si tratta di un piccolo team di sviluppo e probabilmente scoprirai che alcuni software che desideri non sono confezionati se nessuno ha voluto usarlo prima. La buona notizia è che in genere è abbastanza facile costruire un programma per il sistema (una "ricetta" standard è lunga circa tre righe); la cattiva notizia è che a volte è spiacevolmente complicato, che tratterò più avanti.
pubblicazioni
Ci sono alcune "pubblicazioni". Ho fatto una presentazione a linux.conf.au 2010 sul sistema nel suo insieme che copre tutto in generale, che è disponibile in video: ogv mp4 (anche sul tuo mirror Linux Australia locale); Ho anche scritto i miei appunti in prosa. Ci sono anche alcuni documenti più vecchi, tra cui il famoso " I am not clueless ", sul sito Web GoboLinux , che affronta alcune obiezioni e problemi. Penso che siamo tutti un po 'meno entusiasti in questi giorni, e sospetto che una versione futura adotterà /usrcome posizione di base per i collegamenti simbolici.
NixOS
NixOS mette ogni programma installato nella propria directory sotto /nix/store. Queste directory hanno un nome simile /nix/store/5rnfzla9kcx4mj5zdc7nlnv8na1najvg-firefox-3.5.4/: esiste un hash crittografico che rappresenta l'intera serie di dipendenze e configurazioni che portano a quel programma. All'interno di quella directory ci sono tutti i file associati, con localizzazioni più o meno normali localmente.
Ti permette anche di avere più versioni contemporaneamente e di usarne una qualsiasi. NixOS ha un'intera filosofia associata alla configurazione riproducibile: essenzialmente ha un sistema di gestione della configurazione integrato fin dall'inizio. Si basa su alcune manipolazioni ambientali per presentare all'utente il giusto mondo di programmi installati.
LFS
È abbastanza semplice passare a Linux From Scratch e impostare esattamente la gerarchia desiderata: basta creare le directory e configurare tutto per installarlo nel posto giusto. L'ho fatto un paio di volte nel costruire esperimenti su GoboLinux, e non è sostanzialmente più difficile del semplice LFS. In tal caso è necessario creare i collegamenti simbolici di compatibilità; altrimenti è sostanzialmente più difficile, ma un uso attento dei supporti del sindacato potrebbe probabilmente evitarlo se lo desideri davvero.
Mi sento come se ci fosse un suggerimento LFS su questo esattamente ad un certo punto, ma non riesco a trovarlo ora.
Sulla fattibilità
La cosa su FHS è che è uno standard, è molto comune e riflette ampiamente l'uso esistente al momento in cui è stato scritto. La maggior parte degli utenti non sarà mai su un sistema che non segue sostanzialmente quel layout. Il risultato è che molti software hanno dipendenze latenti da esso che nessuno si rende conto, spesso del tutto involontariamente.
Tutti quegli script con #!/bin/bash? Non va bene se non hai Bash lì. Ecco perché GoboLinux ha tutti quei symlink di compatibilità; è solo pratico. Un sacco di software non funziona in fase di compilazione o in fase di esecuzione in un layout non standard e quindi richiede patch per correggere, spesso in modo piuttosto intrusivo.
Il tuo programma Autoconf di base si installa normalmente felicemente ovunque tu lo dica, ed è abbastanza facile automatizzare il processo di passaggio nel modo corretto --prefix. Altri sistemi di compilazione non sono sempre così belli, sia intenzionalmente infornando nella gerarchia, sia dai principali autori a scrivere configurazioni non portatili. CMake è un grande trasgressore in quest'ultima categoria. Ciò significa che se vuoi vivere in questo mondo devi essere preparato a fare un sacco di lavoro complicato in anticipo nei sistemi di costruzione di altre persone. È una vera seccatura dover patchare dinamicamente i file generati durante la compilazione.
Il runtime è di nuovo un'altra questione. Molti programmi hanno ipotesi su dove si trovano i propri file, o quelli di qualcun altro, relativi o assolutamente relativi. Quando inizi a utilizzare i collegamenti simbolici per presentare una vista coerente, molti programmi presentano dei bug che li gestiscono (o, a volte, comportamenti probabilmente discutibili che non ti sono utili). Ad esempio, uno strumento foobarpotrebbe aspettarsi di trovare l' bazeseguibile accanto o dentro ../sbin. A seconda che legga o meno il suo link simbolico, questi possono essere due posti diversi e nessuno dei due può essere corretto comunque.
Un problema combinato è la /usr/sharedirectory. È per i file condivisi, ovviamente, ma quando metti ogni programma nel suo prefisso non vengono più effettivamente condivisi. Ciò porta a programmi incapaci di trovare icone standard e simili. GoboLinux ha affrontato questo in un modo piuttosto brutto: al momento della compilazione, $prefix/shareera un $prefix/Sharedcollegamento simbolico a , e dopo aver creato il collegamento è stato invece indirizzato alla sharedirectory globale . Ora utilizza il sandboxing in fase di compilazione e lo spostamento dei file per gestire share(e le altre directory), ma gli errori di runtime dalla lettura dei collegamenti possono ancora essere un problema.
Le suite di più programmi sono un altro problema. GoboLinux non ha mai fatto funzionare GNOME completamente, e non credo nemmeno che NixOS lo abbia fatto, perché le interdipendenze del layout sono così elaborate che è solo intrattabile curarle tutte.
Quindi sì, è fattibile , ma:
- C'è molto lavoro da fare solo per far funzionare le cose.
- Alcuni software potrebbero non funzionare mai.
- Le persone ti guarderanno in modo divertente.
Tutti questi possono o meno essere un problema per te.
¹ Utilizza la versione 14.01 /System/Index, che mappa direttamente su /usr. Sospetto che una versione futura potrebbe far cadere la gerarchia di collegamenti / indici e utilizzarla /usrsu tutta la linea.
² È necessario /bin/shche esista per impostazione predefinita.