Perché i programmi non sono distribuiti in formato compilato?

Ma danno istruzioni come

cd downloaded_program
./configure
make install

Questo crea l'ELF necessario e probabilmente alcuni file .so.

Perché non mettere quelli all'interno di un file zip per il download, come con le app di Windows? C'è qualche motivo per cui devono essere compilati dall'utente?

Analizziamo i fattori ...

Analisi :

DIPENDENZE SECONDO LA PIATTAFORMA : Vi sono alcuni problemi che sorgono in un ambiente in cui gli sviluppatori stanno creando e mantenendo diverse varianti specifiche dell'architettura di un'applicazione:

• Per diverse varianti è necessario un codice sorgente diverso. Diversi sistemi operativi basati su UNIX possono utilizzare funzioni diverse per implementare la stessa attività (ad esempio, strchr (3) vs. index (3)). Allo stesso modo, potrebbe essere necessario includere diversi file di intestazione per diverse varianti (ad esempio string.h vs. strings.h).

• Sono necessarie diverse procedure di compilazione per diverse varianti: le procedure di compilazione per piattaforme diverse variano. Le differenze potrebbero riguardare particolari come posizioni del compilatore, opzioni del compilatore e librerie.

• Le build per diverse varianti devono essere mantenute separate: poiché esiste un singolo albero di origine, è necessario assicurarsi che i moduli oggetto e gli eseguibili per un'architettura non vengano confusi con quelli per altre architetture. Ad esempio, l'editor di collegamenti non deve tentare di creare un eseguibile IRIX-5 utilizzando un modulo oggetto creato per SunOS – 4.

• Ogni sistema operativo ha il proprio schema di gestione dei collegamenti e deve preparare il file ELF (formato eseguibile e collegamento) di cui ha bisogno.

• Il compilatore genererà una build che è una sequenza di istruzioni e architetture distinte significano serie di istruzioni diverse ( Confronto di architetture di set di istruzioni ). Quindi, l'output del compilatore è diverso per ogni architettura (es: x86, x86-64, ARM, ARM64, IBM Power ISA, PowerPC, Motorola 6800, MOS T 6502 e così tanti altri )

SICUREZZA :

• Se scarichi un file binario, non puoi essere sicuro che faccia quello che dice, ma puoi provare a controllare il codice sorgente e utilizzare un file binario autocompilato nel tuo sistema. Nonostante ciò, l'utente Techmag ha fatto un buon punto nel suo commento, l'auditing del codice richiede programmatori esperti e competenti per valutare il codice e non è una garanzia di sicurezza.

MERCATO : In questa sezione ci sono molti fattori, ma cercherò di riprenderlo:

• Non tutte le società mirano a raggiungere tutte le piattaforme, dipende dal mercato, dalla popolarità delle piattaforme e da cosa vogliono vendere.

• Il software libero ha lo spirito di rendere il software il più ampiamente possibile disponibile, ma ciò non implica che il software sia progettato per ogni piattaforma, dipende dalla comunità che lo supporta.

Conclusione :

Non tutti i software sono progettati per ogni piattaforma. Fornire file binari per tutte le architetture e le piattaforme implica compilarlo, testarlo e mantenerlo per tutte le piattaforme. È più lavoro che a volte è troppo costoso e può essere evitato se l'utente lo compila nella propria piattaforma. Inoltre, l'utente sarà consapevole di ciò che sta eseguendo.

Esiste una tale varietà di piattaforme e ambienti software sia * nix che altri , su cui il software può essere eseguito, che consentire di creare un'applicazione (o una libreria da utilizzare con le applicazioni) è l'unico modo realistico per supportare molte combinazioni di quei componenti come un "buon" software fanno. Naturalmente, licenze come la GPL richiedono che il codice sorgente sia disponibile , quindi anche se il software non funziona correttamente è di solito possibile (anche se potrebbe essere difficile comprendere cosa è sbagliato e come risolverlo) per l'utente o di terze parti per immergersi e correggerlo anche se il creatore non / non può / non esiste più per farlo.

Permette anche la distribuzione di software come codice sorgente una verifica indipendente del fatto che il software faccia ciò che afferma e non fa qualcosa di brutto al posto di o anche - il che, nonostante la riduzione del livello di fiducia che uno deve avere nel creatore, lo migliora effettivamente!

Innanzitutto, la tua domanda si basa su una premessa errata. I programmi sono distribuiti in formato compilato!

Il modo normale di installare software su Ubuntu, come sulla maggior parte delle altre distribuzioni Linux, e più in generale sulla maggior parte delle varianti Unix, è installare un pacchetto. Su Ubuntu, apri il centro software o qualche altro gestore di pacchetti e sfogli il software disponibile. Quando si seleziona un pacchetto per l'installazione, i file binari (se il pacchetto contiene un programma) vengono scaricati e installati sul computer.

Per impostazione predefinita, il gestore pacchetti offre pacchetti creati dai manutentori della distribuzione. Puoi anche trovare fonti di pacchetti di terze parti; Ubuntu offre PPA come metodo standardizzato per terze parti per offrire pacchetti.

Il download del software dall'autore in forma compilata è l'ultima risorsa. Devi farlo solo se il software non è abbastanza popolare per essere impacchettato, o se hai assolutamente bisogno dell'ultima versione che non è stata impacchettata. La maggior parte delle persone non ha mai bisogno di farlo.

Quando il software non è impacchettato per una distribuzione, è spesso distribuito in forma sorgente anziché in forma binaria. Ci sono due ragioni principali per cui ciò accade spesso nel mondo Linux, ma raramente nel mondo Windows. Uno dei motivi è che la percentuale di programmi open source su Linux è molto più elevata. Ovviamente, se il codice sorgente di un programma non è disponibile, l'unica forma di distribuzione è un binario. L'altra ragione è che il mondo Linux è molto più diversificato. Diversi binari sono necessari per ogni set di versioni di libreria incompatibili, il che spesso significa binari diversi per ogni versione di ogni distribuzione. Windows "risolve" ciò facendo in modo che ciascun autore del pacchetto distribuisca le librerie che usano insieme al programma (conseguenza: il tuo computer memorizza molte copie di ciascuna libreria, una per programma che la utilizza; se un bug viene corretto in una libreria, ogni programma che lo utilizza deve spedire un aggiornamento) e rilasciando una nuova versione del sistema operativo solo ogni tre anni circa. Unix ha molta più diversità e abitudini di correzione dei bug molto più tempestive e risolve i problemi di distribuzione delle librerie costruendo binari diversi per diverse distribuzioni.

Linux funziona su più di una sola piattaforma CPU. Se hai distribuito file ELF (o qualsiasi altro tipo di eseguibile non elaborato), ci sarebbe la possibilità che alcune versioni di Linux non fossero in grado di eseguire il software. Nello spirito di rendere il software il più ampiamente possibile disponibile, è preferibile utilizzare il codice sorgente. Ad esempio, Linux funziona su Sparc, Intel, AMD, ARM e altri tipi di processori.

Se il file ELF era destinato specificamente ai processori Intel, ad esempio, altri tipi di hardware non potevano eseguire il software. ELF è indipendente dalla piattaforma, ma il codice che ospita deve essere conforme al codice macchina di una piattaforma. Noterai quante distribuzioni hanno pacchetti simili (ad es. Pacchetti _386 e _586 quando supporta processori diversi) - devi installare il file ELF corretto per ottenere il corretto funzionamento.

Allo stesso modo, se decido di creare una versione Linux personalizzata che utilizza diversi interrupt, linker, ecc., Ho ancora bisogno del codice sorgente per compilare il codice. Anche se il codice sorgente non ha istruzioni di compilazione specifiche della piattaforma, ogni piattaforma è diversa e potrebbe non eseguire un ELF da un sistema diverso.

Il motivo originale per la distribuzione come fonte era sicuramente la diversità della piattaforma; la comunità Linux ha continuato quella metodologia sia per quello che per ragioni nuove, parzialmente politiche.

Diversamente da Windows, Linux non si è mai preso la briga di mantenere stabile l'ABI (interfaccia binaria dell'applicazione) per lunghi periodi di tempo - mantenendo la possibilità di innovare su aspetti come formati eseguibili, API delle librerie e supporto per nuove piattaforme hardware importante.

I sistemi operativi commerciali raggiungono la compatibilità delle applicazioni a lungo termine essendo molto disciplinati rispetto all'innovazione; è necessario aggiungere sempre una nuova interfaccia software / funzionalità IN AGGIUNTA a una vecchia, che richiede due cose da mantenere e il prezzo di modifica di qualsiasi cosa dopo il rilascio deve essere considerato molto elevato. In alternativa, puoi abbracciare il fatto dell'obsolescenza delle applicazioni pianificata insieme a chiunque scriva software per il tuo sistema operativo (questo non è un suggerimento per MS ma un altro fornitore di sistemi operativi).

Il raggiungimento di una piattaforma stabile a lungo termine per software distribuito in forma solo binaria (al di fuori di una determinata distribuzione Linux) sarebbe persino considerato indesiderabile da alcuni elementi della comunità Linux. Come utente non dispiaciuto di entrambe le piattaforme, non sto dicendo che sia buono o cattivo; è come è.

In molti casi (almeno nel mondo * nix), il codice sorgente è la versione più portatile del software. Avere il sorgente garantisce che il software condiviso funzionerà su ogni piattaforma che potrebbe eventualmente supportarlo (che in molti casi significa semplicemente conforme POSIX). Il rilascio dei binari garantisce solo la compatibilità con le piattaforme (sia software che hardware) per i quali tali binari sono stati rilasciati.

Considera che su Windows, i binari sono il modulo più conveniente e portatile per la condivisione del software. Poiché la compilazione dei sorgenti non fa parte del solito modello di distribuzione del software Windows, Microsoft ha fatto di tutto per assicurarsi che i binari funzionino su più versioni del loro sistema operativo: http://www.joelonsoftware.com/articles/APIWar.html

La maggior parte dei software Linux è software libero. Distribuendo il codice sorgente con alcune istruzioni di compilazione anziché binarie, hai la possibilità di rivedere o persino modificare il codice sorgente prima di compilarlo. In questo modo, puoi essere molto sicuro di ciò che fa effettivamente il programma e che non è dannoso.

Il motivo principale per cui personalmente non mi piace semplicemente ottenere un eseguibile di un programma è perché mi piace prima controllare cosa sta realmente facendo il codice sorgente (principalmente perché mi piace solo guardare il codice degli altri) ma conosco molti altri che controlla anche il codice sorgente per codice dannoso.

Molte risposte hanno affermato che nella maggior parte dei casi i software sono distribuiti in formato compilato. Sono d'accordo con questo assunto. Tuttavia vedo un caso in cui distribuire un software dalla sua fonte è meglio che distribuirlo in formato compilato.

Non sono sicuro che sia vero, ma immagino all'inizio di Internet, poiché la larghezza di banda della rete era cattiva, a volte potrebbe essere più veloce distribuire un software dalla sua fonte rispetto al formato compilato. Poiché le fonti di codice sono solo testo semplice, spesso sono più piccole del software in formato compilato. Quindi, distribuire un software con codice sorgente sembra essere un modo migliore per condividerlo, a condizione che gli utenti siano in grado di compilarlo.

A parte il fatto che ci sono molti sistemi unix che funzionano su molte piattaforme diverse, basta considerare i problemi che il software Windows deve affrontare da questa distribuzione modale, anche se devono davvero preoccuparsi solo di una versione di Windows e di una piattaforma (il PC ).

Anche con solo il PC di cui preoccuparsi, ci sono ancora due architetture: 32 bit e 64 bit. Se noti, la stragrande maggioranza del software Windows ignora semplicemente 64 bit e spedisce solo software a 32 bit, lasciandoti con un software non ottimale se hai un sistema a 64 bit. Quindi ci sono librerie. Un fornitore di software non vuole che tu abbia strani errori nel tentativo di eseguire il loro programma se non hai già installato la libreria corretta, quindi includono semplicemente la libreria con il loro programma (ingrandendo il download, anche se hai già questa libreria ). Un secondo programma fa la stessa cosa, ma con una versione diversa della libreria. Nel migliore dei casi, il programma B contiene una versione più recente della libreria compatibile con le versioni precedenti, quindi se si installa il programma B dopoprogramma A, le cose funzionano, ma installarle nell'ordine inverso ti lascia con la versione precedente della libreria e quindi il programma B si rompe. Spesso, tuttavia, il fornitore della libreria apporta modifiche che non sono compatibili con le versioni precedenti e non si preoccupa di cambiare il nome della libreria, quindi, indipendentemente dall'ordine in cui si installano i due programmi, il primo si interromperà. Questo si chiama "inferno dll".

Purtroppo, per evitare ciò, la maggior parte dei software Windows ha fatto ricorso alla spedizione di tutte le librerie nella propria directory di programma anziché in una directory condivisa, quindi ogni programma ha tutte le sue librerie private e non condividerà mai tra loro, il che sconfigge il tutto punto di DLL in primo luogo e finisci per usare molto più spazio RAM e disco e tempo scaricando tutte le librerie duplicate.

Questo è il motivo per cui il software open source viene pubblicato in formato sorgente e i fornitori di sistemi operativi hanno creato gestori di pacchetti che risolvono i problemi di dipendenza e scaricano solo i binari precompilati di cui hai effettivamente bisogno, senza duplicare le librerie ovunque. Questo riguarda anche il fatto che ci sono molti sistemi unix diversi che girano su molte piattaforme diverse.