Cosa intendeva Linus Torvalds con la sua citazione sulla portabilità? [chiuso]

In un dibattito con Andrew Tanenbaum sul microkernel e sull'architettura monolitica del sistema operativo, Linus Torvalds ha affermato:

La portabilità è per le persone che non possono scrivere nuovi programmi.

Cosa voleva dire con ciò?

Come scrive Linus nel dibattito, è con la lingua sulla guancia (cioè non essere preso troppo sul serio).

Quindi, continua spiegando che mentre la portabilità è una buona cosa, è anche un compromesso; il codice non portabile può essere molto più semplice. Cioè, invece di rendere il codice perfettamente portatile, basta renderlo abbastanza semplice e portatile ("aderire a un'API portatile"), e quindi se deve essere portato, riscriverlo secondo necessità. Rendere il codice perfettamente portatile può anche essere visto come una forma di ottimizzazione prematura - spesso più dannosa che positiva.

Naturalmente questo non è possibile se non puoi scrivere nuovi programmi e devi restare fedele a quello originale :)

Penso che significhi che ogni programma dovrebbe essere scritto specificamente per l'hardware e il sistema operativo su cui gira.

Penso che ciò che sta guidando sia che il codice generico che può essere eseguito su più piattaforme sia meno efficiente o più soggetto a errori rispetto al codice scritto appositamente per e su misura per una piattaforma. Ciò significa, tuttavia, che quando si sviluppa in questo modo è necessario mantenere diverse righe di codice.

Ai tempi in cui Linux era stato scritto per la prima volta, utilizzava funzionalità disponibili solo sulla CPU i386, che all'epoca era piuttosto nuova e costosa.

Questo è esattamente ciò che fa Linux: usa solo un sottoinsieme più grande delle 386 funzionalità di quanto sembrino fare altri kernel. Ovviamente questo rende il kernel proprio non portabile, ma rende anche un design / molto / più semplice. Un compromesso accettabile e uno che ha reso possibile Linux in primo luogo.

Con l'entrata nel 21 ° secolo, le caratteristiche che hanno reso unica l'i386 sono diventate totalmente mainstream, consentendo a Linux di diventare molto portatile.

Come qualcuno che ha fatto molta conoscenza di Java e ha sperimentato il fenomeno "scrivi una volta, esegui il debug ovunque" su base settimanale per anni, posso riferirmi completamente a questo.

E Java è probabilmente un lieve esempio. Non riesco nemmeno a immaginare cosa attraversano le persone che provano mentre si trova una base di codice portatile in un linguaggio / toolkit che non è nemmeno stato progettato per essere portatile di per sé.

Proprio ora al lavoro, stiamo studiando l'idea di scrivere una versione lite di uno dei nostri prodotti per dispositivi mobili. Ho fatto alcune ricerche su come realizzarne una versione portatile sia per J2ME che per Android - che tenta di condividere il maggior numero possibile di codebase (ovviamente non può essere completamente "portatile" di per sé, ma è una filosofia simile ). È un incubo.

Quindi sì, a volte è davvero bello essere in grado di pensare (e fare) in termini di utilizzo degli strumenti forniti per quel determinato lavoro. vale a dire svilupparsi liberamente contro un'unica piattaforma / ambiente monolitici. E scrivendo solo versioni separate e pulite per ciascuno.

Sebbene alcune persone considerino / trattino la portabilità, seguendo gli standard, ecc., Come moralmente superiore, o qualcosa in quell'ordine, ciò a cui si riduce veramente è l'economia.

La scrittura di codice portatile ha un costo in termini di impegno per rendere il codice portatile e (spesso) rinunciare ad alcune funzionalità che non sono disponibili su tutti i target.

Il codice non portatile ha un costo in termini di sforzo per il porting del codice quando / se ti interessa una nuova architettura e (spesso) rinunciare ad alcune funzionalità che non sono (o non erano) disponibili sul target originale.

Il grande qualificatore è "quando / se ti interessa una nuova architettura". La scrittura di codice portatile richiede uno sforzo iniziale nella speranza di un eventuale payoff di poter utilizzare quel codice su architetture nuove / diverse con uno sforzo minimo o nullo. Il codice non portatile ti consente di ritardare tale investimento nel porting fino a quando non sei (almeno ragionevolmente) sicuro di dover davvero effettuare il porting su un determinato target.

Se sei sicuro in anticipo che porti a molti obiettivi, di solito vale la pena investire in anticipo per ridurre al minimo i costi di porting a lungo termine. Se non sei sicuro di quanto (o anche se) dovrai trasferire il codice, la scrittura di codice non portatile consente di ridurre al minimo il costo iniziale, ritardando o eventualmente addirittura evitando del tutto il costo di rendere il codice portatile.

Penso che valga anche la pena notare che ho parlato di "portatile" e "non portatile" come se ci fosse una netta divisione tra i due. In realtà, questo non è vero: la portabilità è un continuum, che va da completamente non portatile (ad esempio, codice assembly) a estremamente portatile (ad esempio, Info-zip) e ovunque nel mezzo.

Tanenbaum sottolinea che gran parte di Linux è scritto in modo non modulare per sfruttare la CPU 386, allo stato dell'arte al momento, invece di rendere l'interazione della CPU un componente, e quindi facilmente sostituibile. Tanenbaum crede essenzialmente che il fatto che il kernel sia così monolitico e legato alla CPU 386 lo rende molto difficile,

• Porta Linux stesso su un'altra piattaforma CPU (ovviamente errato, AMD64, PowerPC, ecc.)
• Programmi port scritti per Linux x86 su un'altra architettura CPU (anche errata)

Il campo di Linux mette in evidenza diversi punti, tra cui:

• Linux offre un file system multithread come parte del progetto
• Il microkernel, sebbene interessante e intuitivo, non è molto performante
• L'adesione all'API portatile rende il problema della portabilità più o meno complicato rispetto a un blocco.

Se vuoi scrivere un codice portatile, devi scrivere un codice portatile.

Cosa intendo con questo?

Il design deve riflettere lo scopo. Se la lingua è C, ad esempio, progettala in modo tale che il numero minimo di righe di codice debba cambiare affinché funzioni. Ciò significherebbe spesso separare il display dal calcolo, che è comunque una buona filosofia di progettazione (MVC). La maggior parte del codice C può essere compilata ovunque, purché tu abbia accesso a un buon compilatore. Sfruttalo e scrivi il più possibile per essere generico.

A proposito, questa risposta si applica solo per le applicazioni. Il sistema operativo e incorporato sono completamente un altro animale.

Interpreta questa affermazione "letteralmente" così com'è.

In un'altra delle citazioni di Linus ha detto: "Il C ++ sta cercando di risolvere tutti i problemi sbagliati. Le cose che il C ++ risolve sono cose banali, estensioni quasi puramente sintattiche di C piuttosto che risolvere un vero problema profondo".

Sempre nella sua biografia, Linus "Just For Fun", mentre citava i micro-kernel, diceva che per un problema con complessità 'n' se si divide il problema in '1 / n' parti uniche .. allora la complessità totale dello sviluppo di un tale sistema sarebbe essere 'n!' questo è di per sé un fattore sufficiente per non tentare una cosa del genere, ed estrarre efficienza da un sistema così complesso sarebbe molto difficile.

Devi tenere conto del fatto che durante questi dibattiti, Linux era molto nuovo ed era in gran parte un 386 solo OS. Penso che se avessi chiesto a Linus oggi, avrebbe un'opinione diversa. Forse non è così estremo come Tannenbaums, ma probabilmente annuirà a Hime e dirà che aveva ragione su alcune cose.

Linus e gli altri sviluppatori del kernel hanno sofferto molto per rendere Linux portatile, ma poi Linux non sarebbe mai esistito se Linus avesse dovuto renderlo portatile per cominciare.

Significa che le persone che sanno scrivere buoni programmi non hanno bisogno di cose per essere portatili, perché possono lavorare da zero.

Sono i programmatori meno dotati che vogliono "importare" altri programmi (portabilità) nell'attuale.