Ho difficoltà a comprendere i formati eseguibili di Linux e i pacchetti di distribuzione del software. Esistono così tante diverse distribuzioni di Linux stesso e sembra che ogni pacchetto software sia stato compilato separatamente per ogni distribuzione. Perchè è questo? Comprendo che alcuni "pacchetti" sono fatti per l'installazione su diverse distribuzioni, ma il formato eseguibile per il software è diverso?

Inoltre, perché molti utenti Linux preferiscono le versioni del prompt dei comandi delle applicazioni rispetto alle versioni della GUI? Riesco a capire la necessità di impronte ridotte, ma anche le app GUI possono avere impronte piccole se sono codificate correttamente.

Gestori di pacchetti e dipendenze

La maggior parte delle distribuzioni Linux utilizza i gestori pacchetti per l'installazione e la rimozione del software. I gestori di pacchetti offrono alcuni vantaggi come la possibilità di utilizzare un repository centrale da cui è possibile scaricare (quasi) qualsiasi parte di software, l'organizzazione di parti di software in bundle che possono essere installati come un unico gruppo coeso e i principali vantaggi: automatico gestione delle dipendenze e tracciamento delle modifiche apportate ai pacchetti in modo che possano essere disinstallati.

Alcuni software potrebbero richiedere determinate librerie o altri programmi per eseguire compiti che sarebbero ridondanti se fosse implementato nuovamente in quel software. I pacchetti consentono l'espressione di queste dipendenze.

Differenze: formati e strategie del pacchetto

Esistono diversi gestori di pacchetti. Ognuno è stato creato perché quelli esistenti non soddisfacevano le esigenze di alcune persone. Ogni gestore pacchetti richiede pacchetti nel proprio formato.

Inoltre, diverse distribuzioni hanno requisiti diversi del software incluso. Esistono diversi software che possono avere capacità diverse a seconda delle opzioni fornite quando viene compilato dal codice sorgente in un eseguibile della macchina. Alcune distribuzioni vogliono fornire set di funzionalità complete e un'esperienza ricca, mentre altri vogliono offrire un'esperienza il più snella e semplice possibile, e c'è tutto nel mezzo. Inoltre, la distribuzione può decidere di formattare la propria struttura di directory in modo diverso o utilizzare un sistema init diverso. Potrebbero decidere di raggruppare il software in modo diverso: potrebbe esserci un pacchetto chiamato "dev-utils" in due diverse distribuzioni, ma una versione includeyaccmentre l'altro no. A causa di queste diverse esigenze, le distribuzioni scelgono di compilare il software in diversi modi.

Questo è il motivo per cui anche se si dispone di un pacchetto nel formato corretto per il proprio gestore pacchetti, potrebbe non funzionare se il pacchetto era destinato a una distribuzione diversa. Ad esempio, quel pacchetto potrebbe fare affidamento sull'installazione yacce ha espresso tale dipendenza richiedendo il pacchetto "dev-utils", ma il tuo "dev-utils" non include yacc. Ora c'è un pacchetto installato con una dipendenza non soddisfatta.

Non è davvero un problema.

Una parte importante dell'essere una distribuzione Linux consiste nel mantenere un repository software centrale. La distribuzione si occupa di mantenere tutto questo per te. Questo in realtà semplifica l'installazione del software. In genere si utilizza il gestore pacchetti per cercare e selezionare alcuni pacchetti, quindi dirgli di installarli; si prende cura del resto per te. Il processo di installazione del software Windows include la ricerca di software su siti Web di terze parti, il tentativo di individuare il collegamento di download appropriato, il download, il controllo dei virus e l'esecuzione di un programma di installazione che ti pone una serie di domande irrilevanti. L'intero pasticcio non è lo standard su Linux.

Il repository non può possibilmente includere tutto

Ora, ci possono essere casi in cui un software richiesto non si trova nel repository della tua distribuzione. I pacchetti forniti da un repository software sono una delle caratteristiche di differenziazione delle distribuzioni. Quando non riesci a trovare il software di cui hai bisogno nei repository della tua distribuzione, ci sono tre possibili strade (in realtà, due più un modo per rovinare davvero le cose).

Archivi della comunità

Molte distribuzioni hanno repository non ufficiali gestiti da persone non associate alla distribuzione. Ubuntu li chiama PPA, Fedora li chiama Fedora People Repositories. Arch Linux non ha un nome specifico per i repository di terze parti , ma ha il suo AUR, che è una raccolta di "ricette" per i pacchetti (nota: esiste solo un AUR). Potresti prima provare a installare un pacchetto da una di queste fonti poiché è facile disinstallarli se non funzionano.

Compila dalla fonte

Se non riesci a trovare un repository non ufficiale con ciò di cui hai bisogno, compilare dal sorgente non è difficile. Devi avere installato il pacchetto di sviluppo della tua distribuzione; questo include elementi di base come un compilatore, un linker, un parser e altri strumenti che sono normalmente necessari per la compilazione del software. Quindi trovi il codice sorgente del progetto (che è quasi sempre impacchettato in un .tgzo .tbz(chiamato "tarball"). Scaricalo da qualche parte nella sua directory, estrailo (usando tar -xf filename.tgze di solito vai nella directory che ha creato. quella directory può essere un file chiamato READMEo INSTALL. Se esiste, vai avanti e leggilo; la maggior parte di loro ti dice di fare la stessa cosa. I prossimi passi sono fatti da una riga di comando. Esegui lse cerca un file eseguibile chiamatoconfigure. Se esiste, eseguilo facendo ./configure; a volte possono volerci un paio di minuti. Questo di solito esegue alcuni test per capire come la tua distribuzione ha le cose impostate e assicura che tu abbia gli strumenti necessari per compilare questo pezzo di software. Il prossimo passo è correre make. Questo effettivamente compila il software e probabilmente richiederà del tempo, da qualche minuto a qualche ora a seconda delle dimensioni del software che stai compilando. Fatto ciò, corri make install. Questo installa il software, che comporta la copia dei prodotti della compilation nelle posizioni appropriate nel tuo filesystem. Successivamente, il software è disponibile per l'uso.

Questa è stata una lunga sezione, ma è sintetizzata come "README, ./configure, make, make install" . Questa è la routine da ricordare.

Installa un pacchetto da un'altra distribuzione (non farlo)

Lo elenco solo perché è e alternativa, ma quasi sicuramente non finirà bene. È possibile installare pacchetti per altre distribuzioni e potresti ritrovarti a voler farlo. Bene, non farlo. Non farlo finché non capisci molto bene il tuo sistema. In effetti, non ho intenzione di inserire qui alcun comando che mostri come farlo anche se è possibile. Se arrivi a quel punto in cui sembra che questa sia l'unica opzione, non installare il pacchetto usando il gestore pacchetti; invece, estraete le cose dal pacchetto e inseritele nel vostro sistema manualmente, insieme alle note su ciò che avete fatto in modo da poterlo annullare, se necessario.

Il bit della riga di comando

Alcune persone preferiscono la riga di comando per i vantaggi che offre loro. Questi possono essere riassunti in tre cose:

• Facilità di automazione
• Velocità (rispetto al clic su tutto il luogo in una GUI)
• espressività

Il più grande di questi è espressività; ci sono cose che possono essere fatte da una riga di comando che non sono possibili in un'interfaccia grafica.

Infine, le istruzioni da riga di comando vengono spesso fornite in forum utili come questo perché è molto più semplice comunicare le informazioni corrette piuttosto che impartire istruzioni di tipo "clicca qui-poi-là-là-là".

Ci scusiamo per la lunga risposta. Se vuoi il veloce e sporco, basta leggere il riepilogo.

Sommario

• Il formato eseguibile è lo stesso.
• Esistono diversi gestori di pacchetti che non sono compatibili, anche se lo sono i programmi confezionati. (Potresti vedere un pacchetto come file di installazione come .msifile).
• Distribuzioni / versioni sostanzialmente diverse hanno versioni diverse delle librerie core e per motivi di coerenza e stabilità è necessario creare applicazioni in base a tali versioni. (Versione Linux dell'inferno dll).
• Distribuzioni diverse fanno le cose in modi leggermente diversi e ciò può in alcuni casi essere un problema di compatibilità.
• La riga di comando può essere più veloce e la riga di comando unix è di gran lunga migliore rispetto alla riga di comando di Windows.

Gestori di pacchetti

Innanzitutto i gestori di pacchetti. Lo scopo principale di un gestore pacchetti è di mantenere un database di pacchetti installati e i file che costituiscono quel pacchetto.

I gestori pacchetti consentono una facile installazione dei pacchetti e generalmente anche una facile rimozione. Consentono inoltre ai pacchetti di specificare vari script che potrebbero dover essere eseguiti al momento dell'installazione / rimozione per mantenere la coerenza del sistema (come la registrazione del pacchetto in alcuni database relativi al sottosistema).

Diversi gestori di pacchetti

Esistono vari gestori di pacchetti diversi con diversi punti di forza e di debolezza. Esempi sono rpm e il gestore pacchetti debian (file .deb), ma ce ne sono altri. Questi gestori di pacchetti necessitano ovviamente di formati diversi e non sono quindi compatibili.

Distribuzioni o versioni diverse

Poiché la maggior parte di una distribuzione Linux è open source, il riutilizzo del codice è molto maggiore rispetto ai sistemi Windows. Un'applicazione potrebbe utilizzare un numero di librerie per varie parti della sua funzionalità. Anche quelle stesse biblioteche spesso lo fanno, a volte la stessa biblioteca.

Sfortunatamente, le librerie esistono in diverse versioni e alcune non sono compatibili (in particolare la compatibilità binaria per gli eseguibili precompilati). Versioni multiple possono benissimo coesistere sui sistemi Unix (meno inferno da quella prospettiva), ma nella maggior parte dei casi l'utilizzo di due diverse versioni di una libreria in un programma in esecuzione richiede crash.

Le distribuzioni binarie quindi aggiornano spesso la propria versione per passare a nuove versioni di vari pacchetti core (in altri casi sono necessari grandi aggiornamenti).

Altri file diversi

Le distribuzioni differiscono anche nel modo in cui si trovano determinati file e nel modo in cui viene gestita la configurazione. A seconda del pacchetto che potrebbe avere un impatto su quel pacchetto.

Riga di comando

Unix è principalmente un sistema operativo per workstation e server. Ciò significa che è progettato pensando agli amministratori di sistema professionisti. L'automazione è una parte importante della toolbox di amministrazione del sistema e gli script di shell sono il modo per farlo. Prova ad aggiungere uno dei primi 0 a 1000 nomi di file nel file manager grafico.

Poiché gli amministratori spesso amministrano molte macchine, devono fare le stesse cose su un numero di sistemi. Usando strumenti come ssh è estremamente facile eseguire l'attività su diversi sistemi in una volta sola e aspettare solo che il computer faccia il lavoro.

Specifiche, automazione e ripetibilità precise rendono la riga di comando molto migliore in termini di potenziale rispetto agli strumenti grafici per le attività di amministrazione. Unix ha anche diverse shell disponibili e questa competizione ha creato shell estremamente potenti che sono quasi incomparabili con il prompt dei comandi di Windows.

Microsoft lo ha capito bene e offre PowerShell come sostituzione della riga di comando, così come l'ultima versione di Windows Server è principalmente gestita dalla riga di comando.

I formati eseguibili sono tutti uguali tra le distribuzioni, ma gli eseguibili potrebbero richiedere software aggiuntivo aggiuntivo per funzionare correttamente. Se si considerano le distribuzioni basate su Redhat, il prodotto di installazione è un rpm, che includerà tutti i requisiti per un determinato software e non lo installerà di default a meno che i requisiti non siano soddisfatti. ( yumè un'alternativa arpmed è usato da alcune versioni basate su Redhat). Per definizione, una GUI deve avere un footprint molto più grande di un'interfaccia del prompt dei comandi. La filosofia di base di UNIX è quella di semplificare tutto in modo che un determinato compito funzioni nel modo più efficiente possibile. Ecco perché ci sono così tante utility che eseguiranno una singola attività con l'output di tale attività in grado di concatenare l'input di un'altra attività per fare qualcos'altro.

Diverse distribuzioni hanno prerequisiti di installazione diversi. Tuttavia, ci sono RPM o DEB (o altri pacchetti per altri sistemi di gestione dei pacchetti), che funzionano per più di una distribuzione. La filosofia di Linux rende prontamente disponibili i codici sorgente. Quando compili il tuo software, è praticamente la stessa routine su tutte le distro ed è sempre lo stesso .tar.gzarchivio che usi.

Gli RPM compilati sono più simili a una parte del sistema; un'applicazione stessa, come entità autonoma, è pensata per essere distribuita e compilata su ogni target.

Le tue seconde domande sono qualcosa di completamente diverso ... Beh, "molti utenti Linux" preferiscono le applicazioni CLI per molte ragioni diverse, l'ingombro della memoria ridotto è solo uno dei motivi. Quando si utilizza SSH, le applicazioni CLI hanno più senso, soprattutto quando si lavora fuori sede sui server. Il più delle volte, in quei server non sono installati ambienti grafici. Quando eseguono programmi non daemonizzati, sono molto facili da interrompere. Ctrl- ce il programma non c'è più. Inoltre, molti programmi accedono alla console, quindi è più facile eseguire il debug. Durante la programmazione, stai eseguendo la maggior parte della compilation nella console. Ha solo più senso per il debug di compilazione veloce. O quello, o leggere i file di registro, a volte, leggere la console è più veloce.

Arco. O FreeBSD, che è sviluppato nel suo insieme. (RHEL, SLES e simili sono $ rialzati nel loro insieme.)

Uso laptop: come nuovo

Hackability utilizzabile: Arch.

Hackerabilità sadica: Genoo.

Divertente hackability: LFS.

Supportabilità (server): RHEL, Ubuntu LTS, FreeBSD (diverso da Linux).