Qual è il vantaggio del modo in cui Linux organizza i file dei programmi installati? [chiuso]


10

In Windows, l'unità di sistema C:ha una directory program_files, in cui ogni programma ha la propria directory.

In Linux, sotto /usr/e /usr/local/, ci sono /bin, /etc, /share, /src, ecc.

Quindi in Windows, tutti i file di ciascun programma sono raggruppati nella stessa directory, mentre in Linux sono file dello stesso tipo di tutti i programmi.

Penso che il modo in cui Windows organizza i programmi installati sia più logico di quello di Linux, e quindi i programmi installati sono più facili da gestire manualmente.

Qual è il vantaggio del modo in cui Linux organizza i file dei programmi installati? Grazie.

Ho questa domanda quando ho il problema di Come organizzare i programmi installati in $ HOME per la shell per cercarli durante l'esecuzione? , dove provo ad organizzare i miei programmi $HOMEcome Windows, ma ho qualche problema a specificare i percorsi di ricerca dei programmi.


9
@RandallStewart il tuo " imprevedibile e sparso " è il nostro posizionamento razionale e la non duplicazione delle DLL.
RonJohn

1
Questo è storicamente basato - principalmente al fine di poter montare diverse partizioni di dischi montati pur essendo in grado di eseguire il bootstrap avendo solo gli elementi essenziali necessari. Una situazione simile era quando i BIOS del PC potevano vedere solo la prima parte di hard disk molto grandi, quindi una partizione separata contenente tutto il necessario per l'avvio è stata inserita in quella prima parte. In genere chiamato "/ boot". Oggi la necessità di sandbox e app non attendibili ha portato a questo ripensamento - vedi ad esempio gli scatti di Ubuntu.
Thorbjørn Ravn Andersen,

9
Consentitemi di essere il primo a sottolineare che Windows attualmente non inserisce tutti i file di ciascun programma nella directory smae. Oltre a "File di programma" e "File di programma (x86)" ci sono, tra gli altri, le directory "Utenti \ <nomeutente> \ Appdata" di "Local", "LocalLow" e "Roaming". Né Windows ha sempre usato una cartella "Programmi" per i programmi o usato questo in modo coerente attraverso la sua cronologia. * nix è molto più coerente nella gestione dei file nel tempo.
YLearn

5
@JAB, d'accordo, e capisci questo. Stavo sottolineando che l'affermazione dell'OP, ovvero "Quindi in Windows, tutti i file di ciascun programma sono raggruppati nella stessa directory" semplicemente non è vera. Inoltre non ho messo in discussione il registro di Windows, che può anche essere visto come memorizzazione della configurazione e di altri dati sui programmi Windows e non fa parte di una directory "Programmi".
YLearn

2
Linux organizza i file dei programmi installati? Da quando?
Hobbs

Risposte:


17

In Linux le diverse posizioni di solito, se ben mantenute, rispecchiano una parte della logica. Per esempio.:

  • /bin contiene gli strumenti di base (programmi)
  • /sbin contiene i programmi di amministrazione più basilari

Entrambi contengono i comandi elementari utilizzati dall'avvio e dalla risoluzione dei problemi fondamentali. E qui vedi la prima differenza. Alcuni programmi non sono pensati per essere utilizzati da utenti normali.

Allora dai un'occhiata /usr/bin. Qui dovresti trovare una più ampia scelta di comandi (programmi), di solito più di 1000 di essi. Sono strumenti standard, ma non essenziali come quelli in /bine /sbin.

/usr/bincontiene i comandi, mentre i file di configurazione risiedono altrove. Ciò separa entrambe le entità funzionali (programmi), la loro configurazione e altri file, ma in termini di funzionalità dell'utente, questo è utile, poiché avere i comandi non mescolati con qualsiasi altra cosa consente il semplice uso della PATHvariabile che punta agli eseguibili. Inoltre introduce chiarezza. Qualunque cosa sia dovrebbe essere eseguibile.

Date un'occhiata al mio PATH,

$ echo "$PATH" | perl -F: -anlE'$,="\n"; say @F'
/home/tomas/bin
/usr/local/bin
/usr/bin
/bin
/usr/local/games
/usr/games

Esistono esattamente sei posizioni contenenti i comandi che posso chiamare direttamente (cioè non tramite i loro percorsi, ma con i nomi dei loro eseguibili).

  • /home/tomas/bin è la mia directory privata nella mia cartella home per i miei eseguibili privati.
  • /usr/local/bin Spiegherò separatamente di seguito.
  • /usr/bin è descritto sopra.
  • /bin è anche descritto sopra.
  • /usr/local/gamesè una combinazione di /usr/local(da spiegare di seguito) e giochi
  • /usr/gamessono giochi. Da non mescolare con eseguibili di utilità, hanno posizioni separate.

Adesso a /usr/local/bin. Questo è un po 'scivoloso, ed è stato già spiegato qui: che cos'è / usr / local / bin? . Per capirlo, devi sapere che la cartella /usrpotrebbe essere condivisa da molte macchine e montata da una posizione di rete. I comandi non sono necessari all'avvio, come notato prima, a differenza di quelli in /bin, quindi la posizione può essere montata nelle fasi successive del processo di avvio. Può anche essere montato in sola lettura. /usr/local/bind'altra parte, è per i programmi installati localmente e deve essere scrivibile. Quindi, sebbene molte macchine di rete possano condividere la /usrdirectory generale , ognuna di esse avrà il proprio /usr/localmontato all'interno del comune /usr.

Infine, dai un'occhiata al PATHmio utente root:

# echo "$PATH" | perl -F: -anlE'$,="\n"; say @F'
/usr/local/sbin
/usr/local/bin
/usr/sbin
/usr/bin
/sbin
/bin

Contiene questi:

  • /usr/local/sbin, che contiene i comandi admin del tipo /usr/local
  • /usr/local/bin, che sono gli stessi che l'utente normale può utilizzare. Ancora una volta, il loro tipo può essere descritto come /usr/local.
  • /usr/sbin sono le utility di amministrazione non essenziali.
  • /usr/bin sono l'amministrazione non essenziale e le utilità utente regolari.
  • /sbin sono gli strumenti di amministrazione essenziali.
  • /bin sono gli strumenti essenziali per l'amministratore e l'utente normale.

Grazie. Sono molto interessato a come organizzi i programmi da installare /home/tomasz/bin/, vedi unix.stackexchange.com/questions/431793/…
Tim

La mia comprensione era che mentre la separazione di /bined /usr/binera effettivamente per evitare problemi con le /usrdirectory montate in rete , la separazione di /usred /usr/localè per la differenziazione tra file forniti dal fornitore ( /usr) e file installati manualmente sulla macchina stessa ( /usr/local) e non aveva nulla a che fare con i problemi di montaggio in rete. È preciso?
Keiji,

4
@Keiji, la gestione vendor-vs-local è oggi l'uso più comune (e convenzionale) per quella distinzione, ma se si osservano le installazioni UNIX tradizionali, /usr-off-a-network (vs /usr/localessere, beh, locale ) non è inaudito di.
Charles Duffy,

questa è una pessima idea nel 2018
amara

7

Oggi penso che questa sia eredità storica dal classico UNIX.

Nelle prime versioni UNIX, i programmi non erano così grandi come ai giorni nostri. I programmi consistevano spesso in un file eseguibile che utilizzava le librerie di sistema. Quindi, nessuno ha pensato ai programmi che saranno costituiti da un paio di librerie proprie. La libreria principale era la libreria C e ogni programma ne era a conoscenza.

Inoltre, l'ambiente UNIX è stato considerato come prodotto finito (per la preparazione della documentazione). Pertanto sono stati corretti i percorsi di tutti gli strumenti.

Al giorno d'oggi sono presenti alcuni vantaggi dei percorsi fissi nei giorni di HDD (Hard Disk Drive). Se FSH (File System Hierarchy) si divide su partizioni del disco separate e inserisce partizioni con binari e librerie vicino ai settori primari dell'HDD, il tempo di avvio del programma sarà leggermente più veloce.


6
Ci sono vantaggi convincenti che rimangono utili oggi. Mantenimento di file binari /usr/bin, file di dati statici /usr/sharee file che possono essere modificati /varo /usr/varsignifica che le misure di sicurezza possono essere utilizzate per imporre che nulla sia eseguibile shareo vareseguibile (usando i noexecflag per i loro supporti); che nulla al di fuori varpuò essere modificato (su un sistema che utilizza dm_verityo misure simili per generare supporti firmati e di sola lettura); ecc.
Charles Duffy,

3

Quello che vedi come un moderno sistema simile a Unix non è davvero tradizionale.

Normalmente, ci sarebbero abbastanza minimal /e /usrgerarchie con solo utility di sistema, e i programmi sarebbero quindi installati separatamente in una sottodirectory di /usr/local, e quindi resi disponibili creando collegamenti simbolici.

Una configurazione molto tipica per il software GNU era la compilazione e l'installazione

./configure
make
make install prefix=/usr/local/DIR/program-1
cd /usr/local/DIR
stow program-1

L' utilità di stivaggio GNU crea collegamenti simbolici per rendere disponibile il software sul percorso standard, senza dover aggiungere alcuna directory alla variabile PATH (come fa Windows, e la cruft tende ad accumularsi lì).

Le moderne distribuzioni Linux tuttavia spediscono tutto come pacchetti già pronti, quindi i programmi sono diventati parte del "sistema". Poiché il gestore pacchetti si occupa dell'installazione, non sono necessari collegamenti simbolici e la separazione dei programmi non ha alcuno scopo utile (ma rallenterebbe l'avvio del programma poiché molte piccole directory dovrebbero essere sottoposte a scansione).

Se vuoi installare il software nella tua home directory, ti suggerisco di usare anche GNU stow per questo - questo ti permetterà di mantenere separati i tuoi programmi, il che è ragionevole se non stai usando un gestore di pacchetti.

La mia configurazione tradizionale per quella è una directory in ~/software/DIRcui installo i programmi, quindi uso stow all'interno DIRper creare ~/software/bin, ~/software/shareecc. Ciò significa che devo solo aggiungere ~/software/binalla variabile PATH per ottenere tutto il mio software installato.

Uso:

./configure --prefix=~/software
make
make install prefix=~/software/DIR/program-1
cd ~/software/DIR
stow program-1

da installare se il programma segue le convenzioni GNU.


2

Sembra che tu stia parlando dello stile di divisione dei singoli file per scopo ( /usr/binper eseguibili, /usr/liblibrerie) piuttosto che per pacchetto applicativo (compilatore C ++ in una directory, programmi di modifica delle immagini in un'altra). Mentre nei sistemi Unix gran parte della ragione di questo storico, ci sono anche forze di oggi che tendono a rendere i sistemi simili a Unix inclini a questo: gestori di pacchetti che gestiscono la maggior parte dei programmi su un sistema.

Su Windows, storicamente e ancora oggi, le applicazioni sono state responsabili della fornitura del proprio programma di installazione e, soprattutto, del programma di disinstallazione, e anche ora spesso non si registrano in alcun elenco di applicazioni centrale. In una situazione come questa è generalmente meglio per un'applicazione avere la propria "propria" directory per il maggior numero possibile di file. Ciò consente di evitare conflitti con altre applicazioni, sebbene ciò non sempre funzioni (in particolare nel caso delle DLL ).

I sistemi Unix, d'altra parte, dagli anni '90 hanno generalmente avuto un unico gestore di pacchetti accettato e un gruppo che forniva una grande quantità di software comunemente usato attraverso questo gestore di pacchetti. (I gestori di pacchetti ufficiali per vari Unices includono yume aptper sistemi Linux, pkgsrcper NetBSD e portsper FreeBSD. Spesso anche i sistemi Unix commerciali finiscono con un gestore di pacchetti non ufficiale ma ampiamente accettato, come brewper MacOS.)

Questi gestori di pacchetti hanno il vantaggio di poter tracciare ogni file sul sistema nelle varie sottodirectory che "possiedono". Poiché un singolo gruppo sta assegnando qui il nome e il percorso di ogni file, tutti possono utilizzare un piccolo set di directory condivise tra loro. Ciò offre vari vantaggi, in particolare nelle aree di condivisione di file tra applicazioni e di mantenere basso il numero di percorsi necessari per la ricerca di librerie e file eseguibili.

Detto questo, esiste una lunga tradizione di installazione di "directory separate per applicazione" anche in Unix, di solito nella /optdirectory.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.