Pensi che i sistemi operativi gestiti siano una buona idea? [chiuso]

I sistemi operativi gestiti come Microsoft Singularity e JNode sono un concetto piuttosto interessante. In sostanza, il sistema operativo viene avviato con il codice scritto in un linguaggio di basso livello (C / C ++ / Assembly), che implementa essenzialmente una macchina virtuale. Il resto del sistema operativo (e tutte le app per l'utente) vengono eseguiti sulla macchina virtuale. Ci sono alcune cose fantastiche al riguardo. Ad esempio, improvvisamente si rendono obsoleti i puntatori arbitrari. E se ben scritto, ti sbarazzi di un sacco di roba legacy che la maggior parte dei sistemi operativi moderni ha attualmente.

Tuttavia, come svantaggio, sei molto più lontano dall'hardware e, come sviluppatore, perdi la capacità di scendere a un livello inferiore di astrazione e sporcarti le mani.

Quali sono le tue opinioni a riguardo?

Penso che questo sia un altro caso in cui "dipende".

Se stai scrivendo applicazioni come browser Web, elaboratori di testi, ecc. In cui prestazioni fulminanti non sono necessariamente un problema, questo approccio ha i suoi meriti. Utilizzando questo approccio puoi offrire ai tuoi clienti un'esperienza più sicura e controllata. Non solo stai limitando il danno che può essere causato dal malware, ma stai anche eseguendo in un ambiente più coerente.

È come la differenza tra giochi per console e giochi per PC. I primi sanno esattamente con quale hardware devono lavorare, quindi possono sfruttare queste conoscenze mentre i secondi devono essere in grado di far fronte a una più ampia varietà di schede grafiche, schede audio, velocità del disco rigido ecc.

Tuttavia, ci saranno applicazioni (come i giochi!) Che richiedono l'accesso a basso livello e dovranno comunque essere eseguite "nativamente".

Come le lingue gestite, dovrai utilizzare lo strumento appropriato per il lavoro.

Generalmente penso che siano una buona idea, ma dal momento che non ce ne sono molti in giro o vicini al forno, è molto difficile dire come si sarebbero esibiti nel mondo reale. Vorrei che MS avesse aggiornato il progetto Singularity in modo che potessimo vedere dove stava andando, ma la mia ipotesi è che alcuni di questi siano stati elaborati in alcune versioni di Windows

Penso che i vantaggi di un sistema operativo completamente gestito siano enormi e potrebbe davvero essere il futuro, ma ci vorranno molti anni.

Un buon sistema operativo gestito ti fornirà tutti i punti di accesso gestiti di cui hai bisogno per fare tutto ciò di cui hai bisogno, a prescindere dalla gestione: acquisizione di interruzioni ed esecuzione dell'I / O con i dispositivi. C # consente anche un codice non sicuro (gestione dei puntatori) ma sarà consentito solo nei "driver di dispositivo" (che sarà solo un altro tipo di processo isolato dal software).

I vantaggi in termini di sicurezza, uniformità, portabilità e soprattutto affidabilità supereranno sicuramente qualsiasi inconveniente delle prestazioni. Quindi un sistema completamente gestito è sorprendentemente veloce, poiché non è più necessario cambiare contesto.

I sistemi operativi gestiti sono probabilmente in qualche modo simili ai microkernels: sacrifichi le prestazioni in nome della sicurezza.

Potrebbero esserci problemi simili in quanto richiede la suddivisione del codice in 2 parti:

• Kernel di basso livello scritto in C / assemblatore
• Kernel di livello superiore scritto in linguaggio gestito

A seconda del costo per entrare / uscire dal linguaggio HL in modo sicuro, ciò potrebbe comportare problemi simili ai microkernels - forse un po 'più veloce (lasciare HL è più veloce del cambio di contesto completo, ma IIRC per esempio JNI è piuttosto costoso).

Anche l'applicazione utente avrebbe probabilmente bisogno di contesti separati poiché molte app sono scritte su altre piattaforme (ad esempio C, Java o .Net). Negli stessi casi, le applicazioni possono essere associate alla CPU (compilatori, convertitori di musica, ecc.) E richiedono anche l'ottimizzazione dell'assemblatore per funzionare con una velocità sufficiente. Inoltre - la protezione MMU implementata in linguaggio HL probabilmente non sarà veloce come quella hardware anche se potrebbe essere molto più perfezionata.

Anche il linguaggio HL non è competente nelle operazioni di basso livello. Mentre il software di solito è progettato con "buone" pratiche di codifica, i driver non sono necessari. Non credo che proteggeranno almeno da alcuni errori, poiché i kernel richiedono a volte memoria per la gestione manuale.

Infine, non penso che un tale sistema operativo richiederebbe una VM completa. Poiché il sistema operativo non può essere costruito con i linguaggi HL di compilazione una volta eseguiti ovunque ovunque (anche con GC & co.) Sarebbe il candidato migliore.

Ad esempio, improvvisamente si rendono obsoleti i puntatori arbitrari.

Il sistema operativo è intrinsecamente di basso livello. Si passa all'hardware non solo un "puntatore arbitrario" ma probabilmente un indirizzo fisico piuttosto che uno virtuale. Alcuni DMA possono gestire solo i primi 16 MiB di memoria. Sebbene tale sistema operativo possa semplificare molto, non eliminerà gli indirizzi.

E se ben scritto, ti sbarazzi di un sacco di roba legacy che la maggior parte dei sistemi operativi moderni ha attualmente.

1. Ci sono molti hardware legacy. Molto di più quindi nel software. Innanzitutto si avvia in modalità reale, quindi si abilita il gate A20 (non chiedere) per passare alla modalità protetta, quindi alla modalità lunga.
2. La compatibilità API / ABI è buona. Supponiamo che abbiano scritto un tale sistema operativo: cosa faresti con esso? Firefox - no (C e C ++ usando WinAPI). Java - probabilmente doveva essere trasferito o presentava alcuni problemi minori tramite ikvm - a meno che non fosse felice di usare JNI. Immagino che MSSQL (e sicuramente Oracle, MySQL, Postgresql ...) non sia scritto in un linguaggio gestito, quindi non sarebbe adatto al server.
3. Anche la compatibilità dei bug è "buona". AFAIK MS impiega molto tempo a testare e verificare se alcuni software non utilizzano l'API in modo intelligente (lettura errata). Come il problema dell'utilizzo del puntatore dopo freeche Windows ha effettivamente iniziato a liberare memoria.

Immagino che guadagnerà popolarità nello stesso periodo dei microkernels.

Personalmente, penso che l'idea di un sistema operativo gestito sia un po 'come il comunismo: buono in teoria, ma poco pratico da implementare.

Il problema è che non vedo alcun modo per far funzionare il sistema operativo gestito senza riscrivere completamente il sistema operativo da zero (e spero che qualcuno possa dimostrarmi sbagliato in questa parte). Inoltre, come si inseriscono decenni di codice non gestito in un sistema operativo gestito?

I kernel dei SO più popolari là fuori sono testati in battaglia e sono maturati nel corso di un paio di decenni. Non li riscrivi semplicemente per capriccio. Per non parlare del fatto che la storia è piena di esempi di progetti di processori e architetture del kernel che sono stati innegabilmente migliori ma non sono mai stati in grado di convincere nessuno che valessero il costo di cambiarli.

Infine, in che modo un'azienda come Microsoft o Apple venderà un sistema operativo gestito ai clienti? L'utente medio si preoccuperà anche se il suo sistema operativo è gestito o non gestito?

Quanto sopra notato, spero di sbagliarmi e che i sistemi operativi gestiti diventeranno realtà. Ma sono scettico. Se mai lo vedremo, probabilmente non sarà per un altro decennio o due.

Il codice gestito è solo un'estrapolazione di ciò che la protezione della memoria virtuale ti acquista oggi, ovvero la capacità del computer di negare l'accesso alle risorse.

IBM lo fa già sui loro sistemi mainframe (lo chiamano semplicemente qualcos'altro), quindi secondo me è solo una questione di tempo prima che ciò accada sui sistemi disponibili al pubblico.

Ti importerebbe se un laptop Google (che esegue Chrome e praticamente nient'altro) funziona con codice gestito o no?

Tuttavia, come svantaggio, sei molto più lontano dall'hardware e, come sviluppatore, perdi la capacità di scendere a un livello inferiore di astrazione e sporcarti le mani.

Questo non è in realtà vero. In JNode, ad esempio, esiste una Unsafeclasse (e altre) che consente di accedere a posizioni di memoria e così via. Ci sono anche alcune classi / metodi "magici" che vengono tradotti in istruzioni privilegiate dal compilatore JIT. L'accesso a queste classi / metodi è (o sarà) limitato dal gestore della sicurezza, dal compilatore JIT e così via. Ma se stai scrivendo codice che viene eseguito a livello di sistema operativo, queste funzionalità sono a tua disposizione.

L'avvertenza è (ovviamente) che un uso errato Unsafee le classi correlate possono causare arresti anomali del sistema operativo immediatamente o lungo la pista.

Dubito della loro utilità per i computer desktop. Ma il tempo potrebbe dimostrarmi sbagliato su questo punto.

Ma un potenziale interessante ai miei occhi è come un sistema operativo server, più specificamente come sistema operativo guest in un ambiente virtualizzato. Non è mai andato bene con me installare un'installazione completa di Windows Server in un ambiente di server virtuale, sapendo quanti servizi non necessari esegue, inclusa la GUI completa.

Ora installare qualcosa come Singularity su un server virtuale per l'hosting di applicazioni ASP.NET, ha più senso. Supponendo che possano mantenerlo un sistema operativo leggero.