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

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

Se stai scrivendo applicazioni come browser web, elaboratori di testi ecc. in cui le prestazioni fulminee 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 correndo in un ambiente più coerente.

È come la differenza tra giochi per console e giochi per PC. I primi sanno esattamente di quale hardware hanno bisogno per lavorare, quindi possono usare quella conoscenza, mentre questi ultimi devono essere in grado di far fronte a una più ampia varietà di schede grafiche, schede audio, velocità del disco fisso ecc.

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

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

In generale, penso che siano una buona idea, ma dal momento che non ce n'è molta in giro o quasi completamente sfornati, è molto difficile dire come si esibiranno 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 essi vengano utilizzati in alcune versioni di Windows

Penso che i vantaggi di un sistema operativo completamente gestito siano enormi e che potrebbero davvero essere il futuro, ma richiederà molti anni.

Un buon sistema operativo gestito ti fornirà tutto il punto di ingresso gestito di cui hai bisogno per eseguire qualsiasi cosa di basso livello di cui hai bisogno, indipendentemente dalla gestione: intercettando gli interrupt e eseguendo l'I / O con i dispositivi. C # consente anche il codice non sicuro (che si occupa di puntatori) ma sarà consentito solo nei "driver di periferica" (che sarà solo un altro tipo di processo software isolato).

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

I SO gestiti sono probabilmente in qualche modo micro-kernel: 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 di entrare / uscire dal linguaggio HL in modo sicuro potrebbe imporre problemi simili a quelli dei microkernel - probabilmente un po 'più veloce (lasciando HL più veloce dell'interruttore di contesto completo ma IIRC per esempio JNI è piuttosto costoso).

L'applicazione utente probabilmente avrebbe bisogno anche di contesti separati dal momento che molte app sono scritte su altre piattaforme (ad esempio C, Java o .Net). Negli stessi casi le applicazioni possono essere vincolate alla CPU (compilatori, convertitori di musica, ecc.) E richiedono anche l'ottimizzazione dell'assemblatore per eseguire con velocità sufficiente. Inoltre, la protezione MMU implementata in linguaggio HL probabilmente non sarà veloce quanto 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 una buona pratica di codifica, i driver non sono necessari. Non credo che proteggeranno almeno alcuni errori, dato che i kernel richiedono talvolta memoria gestita manualmente.

Infine, non penso che un sistema operativo del genere richiederebbe VM completa. Dal momento che il sistema operativo non può essere costruito con i principali linguaggi HL compilabili (una volta eseguiti ovunque) (anche con GC & co.) Sarebbe un candidato migliore.

For example, you suddenly make arbitrary pointers obsolete.

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

And if well written, you get rid of a ton of legacy crud that most modern OSes currently have.

1. Ci sono molti hardware legacy. Molto più poi nel software. In primo luogo, 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. Di 'che hanno scritto un sistema operativo simile: cosa ci faresti? Firefox - nope (C e C ++ usando WinAPI). Java - probabilmente aveva bisogno di essere portato su port o aveva alcuni problemi minori via ikvm - a meno che non si accontentasse di usare JNI. Immagino che MSSQL (e sicuramente Oracle, MySQL, Postgresql ...) non sia scritto nella lingua gestita, quindi non sarebbe adatto per il 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 (leggi non corretto). Come il problema di usare il puntatore dopo free quando Windows ha effettivamente iniziato a liberare memoria.

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

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

Il problema è che non vedo alcun modo per portare il sistema operativo gestito senza dover riscrivere completamente il sistema operativo da zero (e spero che qualcuno possa dimostrarmi che non sono in questa parte). Inoltre, come si adattano 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 un capriccio. Senza contare che la storia è piena di esempi di design di processori e architetture del kernel che erano innegabilmente migliori ma non sono mai stati in grado di convincere nessuno che valeva il costo di cambiarli.

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

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

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

IBM lo fa già sui propri sistemi mainframe (lo chiamano semplicemente qualcos'altro), quindi è a mio avviso solo una questione di tempo prima che ciò accada sui sistemi disponibili al pubblico in generale.

Ti interesserebbe se un laptop di Google (che esegue Chrome e praticamente nient'altro) viene eseguito sul codice gestito o no?

However, as a disadvantage, you're that much farther away from the hardware, and as a developer, you lose the ability to drop down to a lower level of abstraction and get your hands dirty.

Questo in realtà non è vero. Ad esempio, in JNode esiste una classe Unsafe (e altre) che consente di accedere alle posizioni di memoria e così via. Ci sono anche alcune classi / metodi "magici" che sono 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 strutture sono a tua disposizione.

L'avvertenza è (ovviamente) che l'uso non corretto di Unsafe e le classi correlate possono portare immediatamente al crash del sistema operativo o alla traccia.

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 stato adatto a installare un'installazione completa di server Windows in un ambiente server virtuale, sapendo quanti servizi non necessari vengono eseguiti, inclusa la GUI completa.

Ora l'installazione di 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.