"Nel mondo Unix, la gente tende ad interpretare 'utente non-tecnico' col significato di qualcuno che ha scritto solamente un driver di dispositivo ". | ||
--Daniel Pead |
Prima di tutto, è importante sapere che sono disponibili molte architetture di computer. Molte di esse hanno un design più pulito e caratteristiche più robuste dei Personal Computer Intel compatibili che sono lo standard odierno, un certo numero delle quali esisteva prima che il PC fosse "inventato".
Quest'elenco di altre architetture di uso generale (oltre all'Intel-compatibile), dovrebbe includere Motorola 68000 (m68k), Sun Microsystems Sparc (sparc), Digital Equipment Alpha (alpha), Motorola/IBM PowerPC (ppc o powerpc), Silicon Graphics/DEC MIPS (mips e mipsel), Intel IA-64 (ia64) e AMD 64 (amd64). Questo elenco non ha la pretesa di essere completo, è solo una selezione casuale di architettute già supportate da Debian GNU.
Così, date differenti architetture che non hanno compatibilità binaria (cioè, in cui i programmi non sono compatibili oltre ai confini dell'architettura), come si fa ad avere lo stesso software che gira su tutte? Noi naturalmente siamo interessati al riutilizzo di applicazioni esistenti, quelle che hanno una tradizione, più caratteristiche e più ore in produzione di qualsiasi cosa che potremmo creare per conto proprio. La chiave del problema è cioè il porting; modificare la base di codice esistente in un modo che funzioni per la nuova piattaforma obbiettivo (in posti dove è necessaria qualsiasi modifica). Una volta fornita l'adeguata educazione, scrivere software portabile è facile; il "porting" ("fare funzionare" il software esistente), tuttavia, può essere una fonte di grande disperazione: alcune volte si devono fare i conti con pratiche di programmazione inaccettabilmente mediocri e progettazioni sbagliate, prima ancora di arrivare agli aspetti di portabilità.
Andiamo a vedere cosa si deve fare se si possiede una nuova architettura completamente utilizzabile, per la quale non sono ancora stati sviluppati kernel e programmi di alto livello. (Non possiamo prendere l'architettura PC come tipico esempio di porting perché questo caso speciale dovrebbe comprendere viaggi nel tempo e hardware in forma di fucili. )
Il primo passo per rendere il software funzionante sulla propria ipotetica architettura sarebbe in pratica il porting del kernel (prima parte implementata in software e non hardware) di un sistema operativo esistente, così che il kernel sia in grado di riconoscere i componenti base del sistema e di inizializzare i sotto-sistemi dipendenti dall'hardware. Quando questo sia stato fatto, dovremmo scrivere driver del kernel per supportare hardware aggiuntivo, come schede di rete, audio e video o la propria scheda madre. I kernel moderni supportano moduli del kernel caricabili (LKM) i quali possono essere caricati nel kernel avviato, così che questo compito non debba essere così pressante come se si dovesse mettere ogni cosa in una sola immagine del kernel, ma ciò nonostante il sistema non risulta molto utilizzabile senza di essi.
Una volta fatto quanto detto sopra, dovremmo far sì che la catena costruttiva (strumenti di sviluppo) sia supportata per una piattaforma, o non saremo in grado di avere nessuna applicazione utente funzionante. (In realtà, questo passo dovrebbe essere probabilmente in cima all'elenco.) E una volta fatto tutto ciò ci sarebbe ancora molto lavoro che ci attenderebbe per i programmi software individuali. Dovremmo provare a compilarli (convertendoli in una forma binaria, in grado di girare sulla macchina) sul nuovo hardware. A seconda di quanta cura nei riguardi della portabilità abbiano avuto gli autori originali, questo potrebbe essere un compito facile, difficile o impossibile. Qualche volta effettuare una completa riscrittura (ed evitare altri errori progettuali fatti dagli autori originali), è più facile che insistere su codice base che era stato scritto da programmatori mediocri o in un periodo in cui non erano ancora largamente usate tecniche standardizzate di portabilità.
Per riassumere, c'è molto di più nella programmazione oltre all'atto fisico di sedersi davanti ad un computer e spingere delle lettere. (Anche se tutti noi probabilmente conosciamo una persona o due che paiono utilizzare la propria esistenza per dimostrare il contrario.)
Quando si comprenderanno le basi dell'hardware del computer, Unix comincerà ad apparire come l'unica ragionevole e naturale estensione dell'hardware, e i suoi concetti ed elementi progettuali saranno facili da capire.