Domanda

un dibattito con Andrew Tanenbaum su microkernel contro monolitico architettura del sistema operativo, Linus Torvalds detto,

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

Cosa voleva dire con questo?

È stato utile?

Soluzione

Come Linus scrive nel dibattito, è con ironia (cioè da non prendere troppo sul serio).

Poi, si continua a spiegare che, mentre la portabilità è cosa buona, è anche un trade-off; codice portabile può essere molto più semplice. Cioè, invece di fare il codice perfettamente portatile, basta fare le cose semplici e abbastanza portatile ( "aderire ad un API portatile"), e poi se ha bisogno di essere portato, riscriverlo, se necessario. Codice Fare lattina perfettamente portatile anche visto come una forma di ottimizzazione prematura -. spesso più male che bene

Naturalmente questo non è possibile se non è possibile scrivere nuovi programmi e devono attaccare con quello originale:)

Altri suggerimenti

Credo che significa che ogni programma dovrebbe essere scritto appositamente per l'hardware e il sistema operativo che gira su.

Credo che quello che sta guidando come è che il codice di uso generale che può essere eseguito su diverse piattaforme è meno efficiente o più soggetto a errori di codice scritto appositamente per e su misura per una piattaforma. Lo fa, tuttavia, che quando si sviluppano in questo modo si deve mantenere diverse linee di codice differenti.

Ai tempi in cui Linux è stato scritto prima, ha usato le funzioni disponibili solo sulla CPU i386, che era abbastanza nuovo e costoso al momento.

Questo è esattamente ciò che Linux fa: si utilizza solo un sottoinsieme più grande del 386 caratteristiche che altri kernel sembrano fare. Naturalmente questo rende il kernel corretta portabile, ma rende anche per un / progetto molto / più semplice. Un accettabile compromesso, e uno che reso Linux possibile nel primo posto.

Come siamo andati nel 21 ° secolo, le caratteristiche che hanno reso l'unico i386 è diventato totalmente mainstream, consentendo Linux di diventare molto portabile.

Come qualcuno che ha fatto un sacco di Java, e sperimentato la "write once, il debug ovunque" fenomeno su base settimanale per anni, posso riferire pienamente a questo.

E Java è probabilmente un esempio mite. Non posso nemmeno immaginare quello che le persone passano attraverso che cercano di mentre una base portatile di codice in un linguaggio / toolkit che non era nemmeno progettato per essere portabile in sé e per sé.

In questo momento sul posto di lavoro, stiamo studiando l'idea di scrivere una versione lite di uno dei nostri prodotti per i dispositivi mobili. Ho fatto qualche ricerca su come fare una versione portatile di esso sia per J2ME e Android - che cerca di condividere quanto del codice di base il più possibile (ovviamente non possono essere pienamente "portatile" di per sé, ma è una filosofia simile ). E 'un incubo.

Quindi sì, a volte è davvero bello per essere in grado di pensare (e fare) in termini di utilizzare gli strumenti indicati per il lavoro dato. cioè Liberamente sviluppo contro uno, singolo, piattaforma monolitica / ambiente. E proprio la scrittura, versioni separate puliti per ciascuno.

Anche se alcune persone vista / portabilità trattare, seguendo gli standard, ecc, come moralmente superiore, o qualcosa in questo ordine, ciò che realmente si riduce a è l'economia.

La scrittura di codice portatile ha un costo in termini di sforzo per rendere il codice portabile, e (spesso) rinunciare alcune caratteristiche che non sono disponibili su tutte le destinazioni.

codice non portabile ha un costo in termini di sforzo alla porta del codice quando / se vi preoccupate per una nuova architettura, e (spesso) rinunciare alcune caratteristiche che non sono (o non erano) disponibili sul bersaglio originale .

Il grande qualificatore c'è "quando / se vi preoccupate per una nuova architettura". La scrittura di codice portabile richiede uno sforzo up-front nel speranza di un eventuale vincita di essere in grado di utilizzare tale codice su nuove / differenti architetture con poco o nessuno sforzo. codice non portabile consente di ritardare che gli investimenti nel porting finché non si è (almeno ragionevolmente) che si ha realmente bisogno di porto a qualche particolare obiettivo.

Se sei sicuro up-front che si sta andando in porto a un sacco di obiettivi, di solito vale la pena di investire in primo piano nel minimizzare i costi a lungo termine di porting. Se siete meno certi su quanto (o anche se) è necessario porta il codice, la scrittura di codice non portabile consente di minimizzare i costi up-front, ritardando o addirittura completamente evitando il costo di rendere il codice portabile.

Credo che sia anche interessante notare che ho parlato di "portatile" e "non-portatile", come se ci fosse una divisione netta tra i due. In realtà, questo non è vero - la portabilità è un continuum, che va dal fondo non portabile (codice assembly per esempio) a estremamente portatile (ad esempio, Info-zip), e ovunque in mezzo

.

Tanenbaum fa il punto che gran parte di Linux è scritto in un modo non modulare di sfruttare la CPU 386, stato dell'arte, al momento, invece di fare l'interazione CPU sia un componente, e quindi molto facilmente sostituibili. Tanenbaum ritiene sostanzialmente che il fatto che il kernel è così monolitico e legato a 386 CPU rende molto difficile,

  • Port stesso Linux per un'altra piattaforma CPU (Ovviamente non corretta, AMD64, PowerPC, etc)
  • Port programmi scritti per Linux x86 a un'altra architettura di CPU (anche errato)

Il campo di Linux rende diversi punti, tra i quali:

  • offerte Linux filesystem multithreaded come parte del disegno
  • microkernel, mentre interessante e intuitiva non sono molto performante
  • L'API aderenza portatile rende la questione portabilità più o un inconveniente al contrario di un bloccante.

se siete desidera scrivere codice portabile, si deve scrivere codice portabile.

Cosa voglio dire con questo?

Il design deve riflettere lo scopo. Se la lingua è il C, per esempio, la progettazione in modo che il numero minimo di righe di codice necessità di cambiamento al fine di farlo funzionare. Ciò spesso significare che separa il display dal calcolo, che è una buona filosofia di progettazione comunque (MVC). La maggior parte del codice C può essere compilato ovunque, purché si disponga di accesso a un buon compilatore. Leverage che e scrivere il più possibile per essere generico.

A proposito, questa risposta si applicherà solo per le applicazioni. OS ed embedded sono un altro animale del tutto.

Interpreta questa affermazione "letteralmente" il modo in cui è.

In un altro di citazioni di Linus ha detto:. "C ++ sta cercando di risolvere tutti i problemi sbagliati Le cose C ++ risolve sono cose banali, estensioni quasi puramente sintattica a C, piuttosto che fissare qualche vero problema profondo ".

Anche nella sua biografia, "just for fun" Linus mentre citando su microkernel ha detto che per un problema con la complessità 'n' se si divide il problema in '1 / n' pezzi unici .. poi la complessità totale di sviluppo di tale un sistema sarebbe 'n!' questo è di per sé un fattore sufficiente per non tentare una cosa simile, e l'efficienza di estrazione da un sistema così complesso sarebbe molto difficile.

Si deve tener conto del fatto che durante quei dibattiti, Linux era molto nuovo ed era in gran parte un unico sistema operativo 386. Penso che se lei ha chiesto Linus oggi, avrebbe avuto un parere diverso. Forse non è così estremo come Tannenbaums, ma sarà probabilmente dare hime un cenno del capo e dire che aveva ragione su alcune cose.

Linus e gli altri sviluppatori del kernel ha attraversato un sacco di dolore per rendere Linux portatile, ma poi di nuovo, Linux non può mai essere esistite se Linus avesse avuto per renderlo portatile per cominciare.

Ciò significa che le persone che possono scrivere buoni programmi non hanno bisogno di cose da essere portatile, perché possono lavorare da zero.

Si tratta di programmatori meno dotati che vogliono "importare" altri programmi (portabilità) a quello attuale.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
scroll top