AMD e Intel proseguono sulla strada della virtualizzazione

Il problema è che immagino che la ripartizione della RAM debba essere fissa e che comunque ogni VM ha il suo spazio separato: quindi doppia copia del kernel, dei drivers, ecc... Invece con un unico SO è tutto condiviso e quando una applicazione non usa della RAM può essere usata per altro... Invece così hai della RAM perennemente occupata...

dubito
l'occupazione del processore deve necessariamente esser maggiore, perchè deve tenere a bada due OS invece che uno, oltre ad entrambi i programmi, quindi si aggiunge una variabile, mica da poco
per quanto riguarda la sicurezza, questo è molto relativo. avrai un os scoperto, e uno invece a pericolo, quindi non è che cambi molto
il problema del virus mi sembra più semplicemente arginabile usando un semplice antivirus, ne esistono di free. oltretutto il rischio è tangibile solo durante la navigazione o l'apertura di eseguibili, cose che comunque non avvengono se sei impegnato a fare qualcos'altro (es: guardare il film)
l'unico campo per l'utente comune è quello della divisione effettiva delle risorse per la diversa utenza (PC di famiglia condiviso da te e i tuoi genitori), oppure una effettiva necessità di molteplici sistemi operativi (linux per passione, e xp per usare dei programmi specifici)
diciamo che in futuro non ci sarà più la scusa "ma non posso usare quel programma perchè non è per il mio OS", visto che per fruirlo basterà far partire l'OS in parallelo, come si facesse partire un eseguibile che crea il suo ambiente di lavoro

Si ma le risorse? Se un SO blocca una risorsa, come si può sperare che l'altro SO l'abbia disponibile?

E' la prima volta che sento parlare di HTPC. Soprattutto di film che scattano con gli antivirus. Ma di che si tratta?

Si ma guarda, se per spendere un pò di più in RAM non debbo comprare due macchine separate ne sono ben felice. Ti faccio un esempio: in azienda si usa un noto programma di progettazione PCB su una workstation che è costata dicamo non pochissimo. E chiaramente i files creati con questo programma devono andare archiviati nel nostro gestore PDM, che utilizza come motore database un altro notissimo programma di gestione DB.
Il problema è che questi due programmi proprio non ne vogliono sapere di digerirsi a vicenda, con problemi dell'ordine di:

- crash dell'applicazione
- reinstallazione periodica di una delle due applicazioni

Sarà anche che si tratta di applicazioni scritte in parte coi piedi, ma alla fine siamo noi che dobbiamo utilizzare due macchine, perchè comunque quei programmi costano parecchio.
Ovviamente con due VM che lavorano con due istanze di SO (e con partizioni separate) avrei potuto risparmiare una macchina.

Ok, questo è più sensato... Ma mi pare quando meno scocciante dover mettere una pezza ai sofware mediante dell'hardware (anche se lo si è fatto per l'NX bit e l'NCQ)... Basta cambiare software... Anche se in certi casi (come questo ad esempio) immagino non ci siano alternative... Quindi o così o così... In questo caso si è trovato un uso inteligente, anche se non credo che la virtualizzazione sia stata creata per risolvere questi problemi, ma piuttosoto per condivisione computer e/o per i developer che devono testare su più S.O. : infatti se vai sul sito della MS alla descrizione di VirtualPC, vedrai che il caso tipico è lo sviluppatore che sviluppa per più S.O. (MS ovviamente... ).

Ma infatti non ho mai detto che lo scopo principale sia quello, anzi.
però è un'applicazione che a qualcuno faccia comodo anche quello, così come farebbe comodo una macchina virtuale per la navigazione che rimane "isolata" rispetto al resto del sistema, e viene resettata ad ogni riavvio con conseguente riduzione dei problemi relativi al malware, e così via.
Molti software professionali sono complessi per natura, e magari sviluppati da software houses che non hanno le risorse di altre grandi multinazionali.
Pensiamo poi anche a determinati ambiti di applcazione, non solo al testing software: si potrebbero utilizzare per la progettazione programmi che sono nativi per SO differenti senza dover dedicare delle macchine allo scopo, ad esempio si potrebbero disegnare delle turbine in un CAD che lavora sotto un SO, e poi passare i parametri ad un programma di simulazione di fluidodinamica che lavora sotto un altro SO, sulla stessa macchina, magari in tempo reale.

Capisco benissimo i vantaggi che comportano un'implementazione hardware della virtualizzazione di SO. D'altra parte, invece, non sono convinto di uno dei vantaggi citati per quanto riguarda la virtualizzazione "emulata".

Ad esempio se avessi Win Xp come SO e volessi virtualizzare un'altro Xp dove tengo tutto leggero (niente antivirus, il minimo di applicazioni in background ecc..) per ottimizzare il funzionamento di alcune applicazioni (un gioco ad esempio), in questo caso il primo SO dovrà cmq girare e quindi non avrò miglioramenti se utilizzo il secondo ma sarò pesante almeno quando uso dolo il primo, o sbaglio?

Nella realtà attuale dei fatti, sia VMWare Workstation / Player sia Microsoft Virtual PC rendono migliore un Windows "nativo" ma pesante (antivirus/firewall/installazioni precedenti) che un Windows "emulato" ma leggero. C'è troppo decadimento di prestazioni, a volte i tempi per l'installazione (esempio Fedora Core 4 su VMWare Player) sono più che raddoppiati rispetto all'installare su un PC fisico.

Night82,

sbagli in parte, come tutti gli altri, perche' ti soffermi all'attuale struttura di un OS.

pensa invece ad un OS molto semplice, che occupa ridottissime risorse (anzi, quasi nulle), che gestisce l'ordine di occupazione delle risosrse HW in base alle rischieste effettuate da altri OS, piu' specifici per applicazioni precise, ossia applicazioni che si comportano come sistemi operativi; in pratica OS server e OS client.

per spiegarmi meglio posso rifarmi al tuo esempio:
ho una macchina general porpouse, sulla quale e' installato un supervisorOS, un OS che non ha bisogno nemmeno dell'interfaccia grafica, alla stregua di un piccolo kernell che gestisce il flusso delle richieste tra' HW e SW, dove pero' il SW sono gli altri OS client, piu' o meno come il BIOS e il POST di avvio.
di solito uso questa macchina per lavorare con un word processor, programma che ha gia' di per se un microkernell e dei driver atti a manovrare l'HW, che, quando gira assorbe parecchie delle risorse a disposizione, ma piu' o meno pari alle risorse di un word processor sotto un OS standard (non avendo dietro tutto il corollario di un sistema);
mi vien voglia di giocare?
metto il CD del mio giochetto che avvia da DVD un nuovo OS fatto apposta per l'HW, e il gioco vero e proprio, ne piu' ne meno come avviene per le console (almeno di penultima o terzultima generazione).
il gioco scatta un po'? e' per colpa dell'OS con il word processor che gira sotto; switch sull'altro OS (e questo potrebbe essere uno dei compiti del supervisorOS) e metto l'OS-word processor in sospensione; switch sul gioco e trovo che gira molto meglio, perche' le risosrse sono piu' libere;
a questo punto voglio giocare una partitella in rete con il gioco, ma.. la rete e' pericolosa!
ho bisogno di avere un firewall e altre protezioni per stare in rete, ed in piu' mi servono alcuni server per poterlo fare (anche se gia' potrebbe averli il gioco);
avvio una consolle remota per il supervisorOS e gli dico di avviarmi l'OS-protezione.
Ho un po' meno risorse per il gioco, ma sono protetto.
arriva un'altro utente del PC per lavorarci sopra, ma io sto giocando!
fortunatamente la virtualizzazione consente anche l'uso contemporaneo di periferiche di input, quali tastiera e mouse, ed io, avendo 2 schede video separata sul PC, una per i giochi, e una economica, alle quali sono collegati 2 diversi monitor, malvolentieri, apro una consolle sul supervisorOS e gli dico di avviare il OS-chat utilizzando la seconda scheda video, il mouse "id01" e la scheda video "id01" (io uso quelle con "id00", e magicamente si avvia l'OS sul secondo monitor, consentendo all'inopportuno utente di chattare con le amiche..

come fare e' abbastanza semplice;
basta avere un OS di base a cui poter montare i moduli e i driver necessari per operare con l'applicazione desiderata, dedicargli uno spazio proprietario sul disco (piu' o meno condiviso) ed installare l'OS-applicazione; il setup dell'installazione creera' un'istallazione OS-applicazione, magari chiedendoci che tipo di avvio deve avere, se ad esempio da periferica ottica virtualizzato totalmente in ram, o su HDD, e su quale spazio.. ne piu' ne meno che come oggi.

il vantaggio:
tu non hai un sistema, ma molteplici sistemi leggeri adibiti ad uno specifico compito, potendo contare sulla totale potenza macchina per un'esclusiva applicazione quando e'necessario;
non hai "impicci" tra' applicazione ed appicazione, o meglio ne hai di meno, perche' le richieste all'HW verranno fatte con la gestione del supervisorOS, bello, snello, e ca...uto, si spera.
e se oggi un driver di periferica, tipo di una scheda video o una scheda audio pesa centinaia di MB sul disco e decine di MB sulla ram, domani potrai scegliere se avere o meno moduli di regolazione dell'overlay o moduli per il caricamento delle librerie EAX per la scheda audio sull'OS-word-processor, cosa che trovo "leggermente" inutile, evitando anche i driver e l'applicazione di controllo di un ultrasofisticato joystick che usi per giocare, potendo scegliere che tipo di driver abilitare sull'OS-applicazione.
Ora puo' sembrare uno spreco caricare tot windowsXP con la matassa di driver con i piu' impensati gingilli che l'appesantiscono su una sola macchina, ma considera che il driver di una periferica, giusto per farla funzionare a dovere, e' costituito da poche librerie di qualche KB, non da infiniti moduli da MB;
guarda i driver di riferimento di XP per alcuni HW, come le schede video; sono di pochi KB, mentre i driver "ufficiali" sono di svariati MB.