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

Come Linus scrive nel dibattito, è con la lingua in bocca (vale a dire non essere preso troppo sul serio).

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

Ovviamente non è possibile se non puoi scrivere nuovi programmi e devi rimanere con quello originale:)

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

Penso che quello che sta guidando è che il codice di uso generale che può essere eseguito su più piattaforme è meno efficiente o più soggetto a errori rispetto al codice scritto specificamente e adattato a una piattaforma. Tuttavia, significa che quando sviluppi in questo modo devi mantenere diverse linee di codice.

Indietro quando Linux è stato scritto per la prima volta, utilizzava funzionalità disponibili solo sulla CPU i386, che era abbastanza nuova e costosa al momento.

That is exactly what linux does: it just uses a bigger subset of the 386 features than other kernels seem to do. Of course this makes the kernel proper unportable, but it also makes for a /much/ simpler design. An acceptable trade-off, and one that made linux possible in the first place.

Quando siamo entrati nel 21 ° secolo, le funzionalità che hanno reso l'i386 univoco sono diventate completamente mainstream, permettendo a Linux di diventare molto portabile.

Come qualcuno che ha fatto un sacco di Java, e ho sperimentato il fenomeno "scrivi una volta, fai il debug di tutto il mondo" su base settimanale per anni, posso completamente collegarmi a questo.

E Java è probabilmente un esempio mite. Non riesco nemmeno a immaginare cosa passano le persone che cercano di utilizzare una base di codice portatile in un linguaggio / toolkit che non è stato nemmeno 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 realizzare una versione portatile sia per J2ME che per Android - che cerca di condividere il maggior numero di basi possibile (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 dati per il dato lavoro. Ovvero sviluppando liberamente contro una piattaforma / ambiente unico, monolitico. E basta scrivere versioni separate e pulite per ciascuna.

Sebbene alcune persone considerino / considerino la portabilità, gli standard, ecc., come moralmente superiori, o qualcosa di simile, ciò che in realtà si riduce è l'economia.

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

Il codice non portabile ha un costo in termini di sforzo per eseguire il porting del codice quando / se ti interessa una nuova architettura e (spesso) di 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 un codice portatile richiede uno sforzo immediato nella speranza di un eventuale pagamento di essere in grado di utilizzare quel codice su architetture nuove / diverse con uno sforzo minimo o nullo. Il codice non portabile ti consente di ritardare l'investimento nel porting fino a quando non sei (almeno ragionevolmente) sicuro di aver davvero bisogno di effettuare il porting su un determinato target.

Se sei sicuro che stai per raggiungere un sacco di obiettivi, di solito vale la pena investire in anticipo per ridurre al minimo i costi di porting a lungo termine. Se sei meno sicuro di quanto (o anche di) sarà necessario eseguire il porting del codice, la scrittura di codice non-portatile consente di minimizzare i costi iniziali, ritardare o addirittura evitare completamente il costo di rendere il codice portatile.

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

Tanenbaum sottolinea che gran parte di Linux è scritta in un 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 molto facilmente scambiabile. Tanenbaum essenzialmente crede che il fatto che il Kernel sia così monolitico e legato alla CPU 386 rende molto difficile,

• Porta Linux a un'altra piattaforma CPU (ovviamente non corretta, AMD64, PowerPC, ecc.)
• Port Programmi scritti per linux x86 su un'altra architettura della CPU (anche errata)

Il campo linux fa diversi punti, tra cui:

• Linux offre un filesystem multithread come parte del design
• Microkernel, mentre interessante e intuitivo non sono molto performanti
• L'aderenza API portatile rende il problema della portabilità più o meno problematico rispetto a un blocco.

Se vuoi scrivere codice portatile, devi scrivere codice portatile.

Che cosa intendo con questo?

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

A proposito, questa risposta si applicherà solo per le applicazioni. OS e embedded sono completamente un altro animale.

Interpretare 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 C ++ risolve sono cose banali, estensioni quasi puramente sintattiche a C piuttosto che risolvere qualche vero problema profondo ".

Anche nella sua biografia, "Just For Fun" linus mentre citava sui microkernel ha detto che per un problema con la complessità 'n' se si divide il problema in parti univoche '1 / n' .. quindi la complessità totale di sviluppare tali un sistema sarebbe "n!" questo è di per sé un fattore sufficiente per non tentare una cosa del genere e l'estrazione di efficienza da un sistema così complesso sarebbe molto difficile.

Devi tener conto del fatto che durante questi dibattiti, Linux era molto nuovo ed era in gran parte un 386 solo sistema operativo. Penso che se hai chiesto a Linus oggi, avrebbe un'opinione diversa. Forse non così estremo come Tannenbaums, ma probabilmente farà un cenno con la testa e dirà che aveva ragione su alcune cose.

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

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

Sono programmatori meno dotati che vogliono "importare" altri programmi (portabilità) in quello corrente.