AMD e Intel proseguono sulla strada della virtualizzazione

Sospettavo che se ne infischiassero della multiutenza... Non è che tutto si riconduce a quelle librerie? Magari se le sovrascrivono a vicenda e sovrascrivono la chiave in shareddlls (mi pare il minimo per incasinare tutto, poi sta a vedere quali altre chiavi si fregano a vicenda... ma sono così simili sti programmi?). In generale penso che un po' di problemi relativi al registro si potrebbero risolvere se i programmi non potessero scrivere dove gli pare, ma venissero create delle tabelle e delle chiavi per legare ogni altra chiave all'applicazione che l'ha creata e la usa: si eviterebbero un po' di conflitti, si eviterebbe di lasciare immondizia nel registro dopo una disintallazione (ma questo credo che non piacerebbe a chi usa questo meccanismo per impedirti di reinstallare una versione a tempo), forse sarebbe più facile caricare in memoria solo le parti che servono, quando servono (per le librerie condivise sarebbe un po' più complicato, ma qualcosa si potrebbe fare).




Si, ho presente la bestiola... un miliardo di file per gestire una licenza a chiave hw (efficacissima...). Ma ve l'hanno fatta registrare online, oppure la vostra versione usa un altro meccanismo (non per farmi gli affari della tua azienda, eh! )? Immagino lo usi il cad (lo dico perchè ne conoscono uno per progettare e programmare circuiti che usa proprio FlexLM, se non ricordo male lavora su roba tipo pal, pla, rom varie e device con funzionalità di "base" da "assemblare" e integrare su vasta scala - magari e lo stesso). Sarebbe il colmo se lo usassero entrambi e la causa di tutto fosse proprio la protezione...

e' piu' o meno questa la mia visione..

non scordiamoci che sicuramente non e' e non sara' gradito l'uso di altri tipi di OS da parte delle software house, forse tollerato, ma sinceramente credo che se avessero voluto una cosa in tal senso, ad esempio, il bootloader di winXP sarebbe stato ben diverso.
percio' e' piu' ipotizzabile uno scenario dove c'e' un supervisorOS di marca XYZ che "aiuta" l'istalazione di un OS-applicazione, dove gli OS in oggetto sono la copia di se stessi di marca XYZ, depauperati dell'inutile.
in uno scenario del genere ecco che nel momento dell'istallazione di una generica applicazione, o tipo di applicazione (si potrebbe ricorrere a divisioni di marketing, categorizzando le applicazioni in base all'uso, tipo: office, game, image-processor ecc.., visto che se te ne serve un tipo probabilmente ne servira' anche un'altra dello stesso tipo che coadiuva il lavoro, es word-excel, o excel-access.. le classiche suite.. ora riprendo il filo del discorso...), all'istallazione viene richiamato il setup del OS, dove ci sara' una sorta di wizard che rendera' l'utente in grado di scegliere che caratteristiche dovra' avere l'OS adibito all'applicazione; wizard che potrebbe essere guidato in parte dallo stesso creatore dell'applicazione tramite un .ini, in pratica: per funzionare mi serve questo, questo, e quest'altro, a te la scelta se lo vuoi piu' elaborato o meno.
In questo scenario, effettivamente, si potrebbe assimilare il concetto di OS a microkernel che coopera con server-moduli (i migliori OS, anche se bisogna essere altro che power user per ora), ma sostanzialmente e' differente, perche' effettivamente gia' oggi, in un "tipico" OS, se viene richiesto un servizio da diverse applicazioni, questo potrebbe essere comunque ricaricato come nuova copia nella ram, separandone le istanze dal precedente, ed anche se usano le stesse librerie, queste potrebbero essere richieste replicate e distinte, se caricate in ram (alla faccia della condivisione delle dll!).
quindi, e' preferibile separare anche, come dovrebbe avvenire, la ram... ma allora perche' ci sono tutti questi bufferoverflow? ci sono troppi bug?
e si, rendiamoci conto che il codice, per quanto curato possa essere, ha sempre errori, e che anche se in virtualizzazione si separano gli ambienti di lavoro, nessuno promette che l'applicazione non possa andare in crash, ma ci va' d sola, senza intralciare il lavoro delle altre macchine virtuali!

veniamo alla quetione dei driver:
oggi ho un PC con 5 schede di rete, tutte uguali, tutte su PCI; grazie all'emulazione degli IRQ siamo sicuri che funzioneranno tutte superando la numerazione di sole 16 periferiche degli obsoleti PC.
hanno indirizzi virtuali diversi, ed e' questo che le fa' funzionare, gestiti dal driver IRQ streaming.
hanno pero lo stesso driver caricato e replicato 5 volte; infatti nei registri si fa' riferimento al loro indirizzo virtuale, ed ognuna puo' avere la propria configurazione personalizzata; logicamente, a livello superiore, si appoggiano sui driver di rete, o meglio sui protocolli, uguali per tutte, ma anche questi con istanze separate, ossia, durante l'uso di uno di questi, viene ricaricato il protocollo (non tutte le librerie, d'accoro); c'e comunque da dire che una sorta di servizzi base del supervisorOS sarebbe auspicabile.
non vedo molta differenza nel caricare piu' driver virtuali su diversi OS-client che fanno uso dello stesso HW, controllati da un piu' evoluto IRQ streaming.
D'altronde, gia' in VMware si fa' uso di ethernet AMD 10/100 emulata sulle varie macchine emulate, per creare una NET virtuale, e questa volta gli oggetti sono virtuali, e non emulati; oltretutto, sempre per il discorso "comunicazione intermacchina", gia' oggi, con 2 ethernet integrate, una IEEE1394 ed un modem, winXP chiede gia' di per se se si vuole condividere tutte le connessioni; e quello non e' un router e un gateway emulato?

in pratica la difficolta' e' essenzialmente dei produttori di HW per proporre driver per specifice categorie, o di produrre driver modulari.
si, lo so', e' gia' difficile che facciano un driver decente, chiedegliene 5 o 6.. li farebbero con i piedi
pero', quando uscirono le API (che altro non sono che driver virtuali), tutti si adeguarono, fossero glide o directX, se volevano vendere quelle erano e il loro HW e SW doveva corrispondere a quei requisiti.

il fatto della pesantezza di piu' OS-applicazione + supervisorOS e' pressante, ma oggi, non scordiamoci che l'anno prossimo si va' sui quad e i 2GB di ram saranno la norma.

Perche' complicarsi la vita cosi', quando un multitasking/multiutenza potrebbe bastare?

bhe', forse per semplice evoluzione..
gia' da diverso tempo ho preferito separare i compiti a diverse macchine piuttosto che avere una supermacchina ultra oveclockata capace di tutto; questo perche' pur utilizzando OS multitasking/multiutenza, alcuni lavori richiedono macchine a se per essere eseguiti senza intralcio, o la sicurezza di certi ambienti d'evessere protetta da altri, o la semplicita' di alcuni compiti potevano essere assolte da macchine piu' piccole, silenziose e "leggere".
In quest'ottica mi sono abituato ad usare le varie macchine da istanze remote, in desktop remoto (ecco perche mi piaceva tanto il TS), o da semplice consol terminal.
Ad esempio ho un PC adibito alla navigazione, che prende i vari "preferiti" dal serverino, e mi consente di spostarmi in rete senza preoccuparmi di alcun pericolo, e all'occorrenza uso una ghost per ripristinare il tutto (addirittura prima utilizzavo un caricamento sulla ram e senza disco!), leggero, e su una macchina paurosamente lenta per oggi, un P2, ma adeguata al compito;
per l'home-banking e altre operazioni in ambiente controlato e sicuro ho un PC blindato, anche questo un semplice P2, ho un client di posta ordinaria sul primo e un client di posta "seria" sul secondo, ed opero da finestra dal desktop "un-po'-per-tutto".
ho un HTPC, leggero e dinamico (quasi...), e gestisco il serverino 24/24-365.
sul PC "un-po'-pe-tutto" posso volendo giocare, navigare, fare home-banking, scaricare, rippare, lavorare... tutto, ma in maggior parte lavorano altri PC avviati all'occorrenza.. crasha il PC "un-po'-per-tutto" (un vero puxxanaio, ultimamente)? riavvio, riapro l'istanza del desktop remoto e mi rimetto a fare quello che facevo..
il 90% di questi compiti lo potrebbe fare una sola macchina media odierna, ma solo se virtualizzata, mantenendo la stessa sicurezza e flessibilita' operativa (tranne per i lavori gravosi, ovvio).
in piu', sul server, potrei abilitare sessioni remote per qualsiasi utente, crossover o in qualsiasi altra modalita';
Ma se una macchina odierna potrebbe farlo, allora, perche' non fare un VERO server casalingo "un-po'-per-tutto" a cui si collegano semplici "gadget"?
la Xbox360 puo' comunicare con un server WMP e diventare uno pseudo HTPC... ok, ma non usa HW del server, usa IL server, come faccio ora io con il TS.
una periferica PCI-ex potrebbe essere usata da un altro PC (..fantasia che circolava qualche anno fa'), ma se questo e' un "gadget" che apre un'istanza sul server virtuale e abilita all'uso di una mega scheda grafica che accellera, compatta e rimanda al "gadget", il quale spara sul TV da 60"? mi stufo, vado in camera, apro un'altro "gadget" e virtualizzo da li?
1 sceda grafica, 1 server, 2 gadget distinti, steso risultato: fruibilita' e flessibilita'.

insomma, si, e' complicato, ma e' l'evoluzione dell'informatica, della domotica, di un nuovo tipo di bit-generation, quella che vive con l'informatica spalmata addosso (ed avvolte anche dentro di se, tipo i chip RFF), non certo dalla nostra bit-geneation, una generazione informatica di primo pelo, dove ci gasiamo nel riuscire a far funzionare un PC..

ok... ho degenerato dal discorso, e come al solito mi sono perso in altri..
che stavamo dicendo?

sono driver base per VGA, con accellerazione semplice in 2D e nessuna in 3D; tutti i prodotti "certificati" devono supportare tali caratteristiche; un po' come l'audio AC'97 (designazione INTEL), dove le schede audio devono poter supportare un driver generico SB16bit.
diciamo che prima, sulla scatola dell'HW,se trovavi il marchietto "engenering for WIN", e significava che supportava i driver generici di win (per winXP il video e' 800x600).
come vedi, loro danno le guide, e i produttori si devono adeguare;
questo e' sia un bene che un male del "monopolio" e della standardizzazione.

quello che dici sul fatto che i produttori hanno riluttanza a customizzare i loro driver e' un discorso ASSOLUTO, ma qui non stiamo parlando dei driver di Ati per supportare linux, ma di interesi economici alquanto marcati.