Vegeta
2004-04-12 16:38:54 UTC
Durante i giorni passati si sono visti diversi messaggi in
risposta a Ginopilotino sul fatto che Linux non è un OS
desktop.
Devo dire questo: non condivido il modo in cui Ginopilotino
ha tenuto la discussione. Troppo stringato ed in certi
momenti non si riusciva neanche a capire il perchè di certe
affermazioni.
Devo dire invece, che sono purtroppo d'accordo con le
affermazioni generali: Linux non è un OS desktop. E se
le cose continuano ad andare in questo modo, non penso
che lo diventerà mai. Così come sono d'accordo sul fatto
che il modello di sviluppo non è esattamente il migliore per
fare diventare Linux un OS che possa rispondere a quel
target.
Stando così le cose, è perfettamente inutile che si continui
ad aggredire Redmont: non si può contestare ad una società
che il suo prodotto ha il 99% del mercato desktop in pugno,
se poi non si è in grado (o non si vuole) creare un prodotto
che fornisca maggiore usabilità di Windows a costi più
bassi. E' l'atteggiamento irrazionale del linuxista: "Non vedo
perchè Linux debba diventare come Windows.". Ottimo.
Nemmeno io. Ed allora non vi lamentate se il 90% degli
utenti continua a scegliere Windows.
Di recente ho installato la SUSE 9. Per la prima volta, dopo
i fallimenti Mandrake 9.1 (schifezza) e RedHat (più curata ma
comunque poco usabile), ho visto quello che dovrebbe essere
una distribuzione Linux che voglia tentare di favorire la
migrazione da Windows.
Tutte le configurazioni si fanno dal Centro di controllo di KDE.
I moduli di YAST2 sono scritti senza bug (a differenza di MDK),
e sono integrati con il Centro di controllo di KDE.
Le applicazioni sono suddivise nel menù di KDE per tipologia,
e non esiste che di ogni applicazione vengano fornite due o tre
versioni.
Tutto viene eseguito via interfaccia grafica. Il winmodem e lo
scanner sono stati subito riconosciuti e configurati. Certo, è
più spartano di Windows, ma comunque si vede l'impegno
di creare un buon OS, alla portata di tutti.
Provo ad aprire un MP3, e viene subito richiamato XMMS
che esegue senza problemi (non come in MDK, che richiama
Noatun salvo poi bloccarsi se hai una vecchia soundblaster ISA,
o in RH che ti chiama XMMS solo che ti aggiunge il file alla
playlist). Un buon sistema, almeno all'apparenza.
I guai sono arrivati dopo. Precisamente quando ho cercato di
installare Xine e poi MPlayer....
Tornando a noi, perchè Linux non è ancora adatto per il
desktop? E perchè il modello GPL non è esattamente il
massimo per raggiungere questo obiettivo?
I motivi principali sono a mio parere questi.
1) Innanzitutto manca uno standard per l'installazione degli
applicativi.
Sotto Windows le applicazioni contengono già in un unico
package tutte le librerie di cui hanno bisogno. Infatti, il
tipico utente Windows scarica un file .EXE da Internet,
fa doppio clic, e dopo un pò si trova il nome del programma
nel menù avvio pronto ad essere eseguito.
E' vero che in alcuni casi viene richiesto di scaricare
preventivamente alcuni pacchetti (tipo i file del Visual Basic,
o l'ultima versione di DirectX), ma si tratta di dipendenze
che si fermano al primo livello.
Non c'è niente di male se qualche pacchetto mi chiede di
scaricare le DirectX. Si tratta di un solo pacchetto.
Quello che invece è snervante è un pacchetto X1.RPM che
mi chiede di scaricare i pacchetti X1.1.RPM e X1.2.RPM
con a sua volta X1.2.RPM che mi chiede X1.2.1.RPM
ecc. ecc.
A quel punto, meglio realizzare un unico package da
scaricare che contiene al suo interno quanto necessario,
e che semplicemente non installa nel sistema le librerie
che già sono installate in una versione più recente (o
le installa in una directory riservata al programma che
installo, ben distinti dalle librerie "common" che sono
invece comuni a tutto il sistema).
Altra cosa assolutamente sbagliata poi è questa. Ogni
pacchetto ha almeno dieci versioni, una per ogni
distribuzione.
E questo non è assolutamente accettabile, perchè rivela
ciò che c'è dietro al sistema: il caos più completo.
Scaricati i pacchetti di SUSE direte voi. E' un discorso
stupido perchè intanto per una applicazione ci sono
pacchetti per SUSE 9, SUSE 8 ecc. ecc. (sono
compatibili? se non trovo un pacchetto per SUSE 9
posso usare quello per SUSE 8?).
Ma soprattutto è un discorso stupido perchè rivela ciò
che c'è dietro: la mancanza totale di uno standard, percui
si devono fare pacchetti diversi perchè RedHat mette i
file in un posto, mentre SUSE in un posto leggermente
diverso, ed infine Mandrake in un posto diverso ancora.
Un sistema operativo desktop dovrebbe essere perfettamente
standardizzato: chi realizza gli applicativi sa che ci sono
dei sottosistemi software standard che saranno presenti
in qualsiasi nuova installazione, e le diverse librerie dovrebbero
essere inserite in un unico pacchetto.
Ma questa standardizzazione chi la fa? E' qui che il modello
GPL diventa fallimentare, perchè da inevitabilmente origine
ad una proliferazione incontrollata di dialetti.
I modelli centralizzati invece si dimostrano superiori perchè
c'è un produttore (IBM, Corel ecc. ecc.) che stabilisce degli
standard inseriti in un documento ufficiale, e chi scrive
applicazioni per quel sistema operativo **deve** seguirli
(perchè altrimenti l'applicativo non viene installato).
Altra cosa assurda, poi, è che non esiste neanche uno standard
comune per la distribuzione dei pacchetti. RedHat lanciò RPM,
mentre Debian utilizza APT. Il chè è totalmente privo di senso
perchè se si vuole creare un OS desktop si crea un unico
standard che supporti tutte le features necessarie e che si
utilizza con un unico strumento. Insomma, si crea un formato
che supporta installazione, compressione, compilazione dei
sorgenti, aggiornamento del menù di KDE, e risoluzione
automatica delle dipendenze via internet ecc. ecc.
Si consideri poi che i vari pacchetti sono anche differenziati
per piattaforma (i386, i586, iK6, i686 solo per citare le
piattaforme Intel compatibili) per aumentare ancora di
più il caos generale.
Finchè Linux non avrà dei precisi standard, percui di ogni
applicazione esista un unico package (al limite distinti per
piattaforma, non di più) ed un preprocessore provvede
a leggere un listato all'inizio ed a eseguire tutti i
controlli e le operazioni necessarie per l'installazione *in
modo totalmente automatico e trasparente all'utente*
non ci sarà mai possibilità di battere Windows.
2) Manca uno standard per i drivers di sistema e per i
codec. In generale i drivers di sistema hanno una qualità
mediocre.
In generale a questa obiezione si risponde che i driver
di sistema devono essere scritti dai produttori e che se
non vengono rilasciate le specifiche non è possibile
scrivere driver per un certo dispositivo.
Le cose non stanno esattamente a questo modo, però.
L'assenza dei driver sotto Linux nasce anche dal fatto
che manca una strategia industriale che faciliti le cose.
Immaginiamo per un attimo che Linux sia prodotto
da una ipotetica LinuxCorporation, ossia da un'azienda
con un nome ed un indirizzo. LinuxCorporation potrebbe
fare una serie di cose:
a) innanzitutto uniformare a precise specifiche il
comportamento dei driver. Stabilire che tutti i driver delle
schede grafiche devono fornire un set preciso di
funzioni, che tutti i driver delle stampanti devono
fornire un set preciso di funzioni ecc. ecc.
Scrivere specifiche sul modo in cui devono essere scritti
i driver (devono essere tutti moduli caricabili dal kernel,
le impostazioni del driver si trovano in **questi** (e solo
questi) file di **questa** cartella, le istruzioni estese devono
essere usate in questo modo ecc. ecc. ecc.).
b) Poi, poichè molte periferiche si comportano in modo
simile, diventa possibile scrivere delle classi di drivers,
che riutilizzano più volte il medesimo codice (per esempio,
una volta scritto un driver di stampa per un modello di
stampante, è possibile scrivere i driver anche per altri
cento modelli, cambiando solo le parti del codice che
inviano i comandi al modello specifico di stampante ecc.
ecc.).
Questo modello per alcune periferiche (come scanner,
stampanti o modem) può anche funzionare. Naturalmente
non funziona più con periferiche che richiedono bassa
latenza ed elevate performance come schede grafiche
o schede audio. In quel caso conta l'ottimizzazione del
chipset, eventuali registri interni della periferica non
documentati, e l'utilizzo di codice compilato con un
compilatore estremamente veloce e che usi tutte le
istruzioni estese.
c) LinuxCorporation potrebbe, in teoria, pagare Nvidia, Matrox,
Ati (per citare i maggiori produttori attuali di schede grafiche),
per scrivere drivers a bassa latenza ed elevate prestazioni.
Anche qui, il modello centralizzato offre dei vantaggi sul
modello della GPL: una multinazionale può prendere accordi
con un altra per produrre dei drivers ottimizzati; diversamente
un hacker che scriva da sè i drivers non potrà mai raggiungere
il medesimo risultato.
d) I drivers per Linux dovrebbe essere distribuiti in un package
apposito e perfettamente standardizzato (diverso da quello
delle applicazioni).
Anzi, tutti i drivers disponibili per Linux dovrebbero essere
inseriti in un apposito sito web, dove possono essere
scaricati in un clic.
I drivers dovrebbe poi essere tutti caricabili automaticamente
con un meccanismo simile a modprobe: ciò significa eliminare
la possibilità di incorporare il codice per i dispositivi nel
kernel (tranne che per alcune periferiche "essenziali" e per
i file system).
3) Il sottosistema grafico X è troppo lento.
Ci sono delle scelte di architettura fatte su linux che determinano
la lentezza di questo sistema operativo per usi multimediali.
Se non credete che sia così, prendete un bel Pentium 233 MMX,
installateci sopra Windows 98 e poi installate Linux + KDE 3.2.
Quale dei due è più veloce? Provate a riprodurre un file AVI e
poi mi saprete dire. In genere, coloro che dicono che Linux è
più veloce di Windows lo fanno con processori molto veloci,
dove il divario si riduce.
Perchè esiste una differenza di velocità? Il primo problema
consiste nella scelta di tenere l'interfaccia grafica in user mode,
e non in kernel mode. Questa scelta è stata fatta per migliorare
la stabilità del sistema. Infatti, un bug nell'interfaccia non può
bloccare l'intero sistema.
Tuttavia, un OS desktop ha bisogno di routine per l'accesso al
video a bassa latenza, proprio perchè il suo utilizzo sono anche
i videogiochi, i dvd, i divx ecc. ecc. Ed è questo l'uso che viene
fatto di Windows da una parte del **mercato consumer**.
All'utente medio non gliene può fregare di meno del fatto che
Linux è meglio perchè il nuovo kernel 2.6.0 con la patch xx
e la patch yy, supporta il multitasking preemptive ecc. ecc.
All'utente medio può interessare che con il nuovo Linux i
DVD non li vedi a scatti, i Divx neanche ed i giochi vanno
più veloci perchè le nostre routine di emulazione ed astrazione
dell'hardware sono più efficienti di quelle Microsoft DirectX.
Che possa piacere o meno, quell'utente (e non utonto) è
**mercato**, fa **mercato** ed anzi è il mercato dominante.
Se la risposta a quell'utente è qualcosa tipo: "Linux non è
per te. Comprati la PSX per giocare.", la risposta dell'utente
sarà sempre "Papà, papà, me lo compri quel Windows XP
di quel monopolista (ih ih ih!!!) di B.Gates?". La risposta
dei produttori di software videoludico sarà invece
"Linux, vaff..."
Senza contare che esistono studi precisi che contestano
l'efficienza di XFree (che tralaltro le distribuzioni non ricompilano
al momento dell'installazione in modo da supportare le
istruzioni estese del processore, e che sarebbero importantissime
per migliorare le performance del sottosistema grafico).
XFree è la versione GPL del protocollo X-Windows, un
protocollo che è stato ideato per consentire la comunicazione
dei client con i server indipendentemente dall'effettiva ubicazione
di questi ultimi. In locale (come viene usato nel 95% dei sistemi
desktop) è un approccio che da più svantaggi che vantaggi
e quindi non ha senso usarlo.
La soluzione potrebbe essere quella di un server che è specializzato
ed ottimizzato per lavorare solo in locale ed un server che invece
lavora in remoto. Una nuova versione reingegnerizzata delle
librerie QT e delle librerie GTK (compilate appositamente),
verificano quale server è attivo nel socket utente e eseguono
le loro chiamate in base al server locale o al server remoto.
Così come, in un OS Desktop, non ha poi molto senso l'idea che
l'interfaccia grafica debba stare a ring 3.
Io penso che il codice di KDE e GNOME possa stare in user
space, ma almeno i nuovi server grafici (locale e remoto), le
librerie QT e le librerie GTK dovrebbero girare in kernel mode,
sempre per massimizzare le performance.
Concludo osservando che il codice che gira sotto Linux è
compilato quasi tutto per GCC, e che questo compilatore
sembra non essere il non plus ultra tra i compilatori in
commercio (il compilatore che produce il codice più
efficiente sembra essere l'ICC di Intel: tale codice è circa del
20% più veloce del codice generato da GCC).
Anche qui c'è una evidente questione di costi. Progettare un
OS compilato per il 60% con l'ICC (ed ottimizzato per le
istruzioni estese) significa sopportare dei costi (GCC è gratuito),
e questo non è possibile a meno di non volere fare di Linux
un prodotto commerciale.
Ci sarebbero altre cose da osservare ma per adesso
mi astengo.
Saluti
Vegeta
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.593 / Virus Database: 376 - Release Date: 20/02/04
risposta a Ginopilotino sul fatto che Linux non è un OS
desktop.
Devo dire questo: non condivido il modo in cui Ginopilotino
ha tenuto la discussione. Troppo stringato ed in certi
momenti non si riusciva neanche a capire il perchè di certe
affermazioni.
Devo dire invece, che sono purtroppo d'accordo con le
affermazioni generali: Linux non è un OS desktop. E se
le cose continuano ad andare in questo modo, non penso
che lo diventerà mai. Così come sono d'accordo sul fatto
che il modello di sviluppo non è esattamente il migliore per
fare diventare Linux un OS che possa rispondere a quel
target.
Stando così le cose, è perfettamente inutile che si continui
ad aggredire Redmont: non si può contestare ad una società
che il suo prodotto ha il 99% del mercato desktop in pugno,
se poi non si è in grado (o non si vuole) creare un prodotto
che fornisca maggiore usabilità di Windows a costi più
bassi. E' l'atteggiamento irrazionale del linuxista: "Non vedo
perchè Linux debba diventare come Windows.". Ottimo.
Nemmeno io. Ed allora non vi lamentate se il 90% degli
utenti continua a scegliere Windows.
Di recente ho installato la SUSE 9. Per la prima volta, dopo
i fallimenti Mandrake 9.1 (schifezza) e RedHat (più curata ma
comunque poco usabile), ho visto quello che dovrebbe essere
una distribuzione Linux che voglia tentare di favorire la
migrazione da Windows.
Tutte le configurazioni si fanno dal Centro di controllo di KDE.
I moduli di YAST2 sono scritti senza bug (a differenza di MDK),
e sono integrati con il Centro di controllo di KDE.
Le applicazioni sono suddivise nel menù di KDE per tipologia,
e non esiste che di ogni applicazione vengano fornite due o tre
versioni.
Tutto viene eseguito via interfaccia grafica. Il winmodem e lo
scanner sono stati subito riconosciuti e configurati. Certo, è
più spartano di Windows, ma comunque si vede l'impegno
di creare un buon OS, alla portata di tutti.
Provo ad aprire un MP3, e viene subito richiamato XMMS
che esegue senza problemi (non come in MDK, che richiama
Noatun salvo poi bloccarsi se hai una vecchia soundblaster ISA,
o in RH che ti chiama XMMS solo che ti aggiunge il file alla
playlist). Un buon sistema, almeno all'apparenza.
I guai sono arrivati dopo. Precisamente quando ho cercato di
installare Xine e poi MPlayer....
Tornando a noi, perchè Linux non è ancora adatto per il
desktop? E perchè il modello GPL non è esattamente il
massimo per raggiungere questo obiettivo?
I motivi principali sono a mio parere questi.
1) Innanzitutto manca uno standard per l'installazione degli
applicativi.
Sotto Windows le applicazioni contengono già in un unico
package tutte le librerie di cui hanno bisogno. Infatti, il
tipico utente Windows scarica un file .EXE da Internet,
fa doppio clic, e dopo un pò si trova il nome del programma
nel menù avvio pronto ad essere eseguito.
E' vero che in alcuni casi viene richiesto di scaricare
preventivamente alcuni pacchetti (tipo i file del Visual Basic,
o l'ultima versione di DirectX), ma si tratta di dipendenze
che si fermano al primo livello.
Non c'è niente di male se qualche pacchetto mi chiede di
scaricare le DirectX. Si tratta di un solo pacchetto.
Quello che invece è snervante è un pacchetto X1.RPM che
mi chiede di scaricare i pacchetti X1.1.RPM e X1.2.RPM
con a sua volta X1.2.RPM che mi chiede X1.2.1.RPM
ecc. ecc.
A quel punto, meglio realizzare un unico package da
scaricare che contiene al suo interno quanto necessario,
e che semplicemente non installa nel sistema le librerie
che già sono installate in una versione più recente (o
le installa in una directory riservata al programma che
installo, ben distinti dalle librerie "common" che sono
invece comuni a tutto il sistema).
Altra cosa assolutamente sbagliata poi è questa. Ogni
pacchetto ha almeno dieci versioni, una per ogni
distribuzione.
E questo non è assolutamente accettabile, perchè rivela
ciò che c'è dietro al sistema: il caos più completo.
Scaricati i pacchetti di SUSE direte voi. E' un discorso
stupido perchè intanto per una applicazione ci sono
pacchetti per SUSE 9, SUSE 8 ecc. ecc. (sono
compatibili? se non trovo un pacchetto per SUSE 9
posso usare quello per SUSE 8?).
Ma soprattutto è un discorso stupido perchè rivela ciò
che c'è dietro: la mancanza totale di uno standard, percui
si devono fare pacchetti diversi perchè RedHat mette i
file in un posto, mentre SUSE in un posto leggermente
diverso, ed infine Mandrake in un posto diverso ancora.
Un sistema operativo desktop dovrebbe essere perfettamente
standardizzato: chi realizza gli applicativi sa che ci sono
dei sottosistemi software standard che saranno presenti
in qualsiasi nuova installazione, e le diverse librerie dovrebbero
essere inserite in un unico pacchetto.
Ma questa standardizzazione chi la fa? E' qui che il modello
GPL diventa fallimentare, perchè da inevitabilmente origine
ad una proliferazione incontrollata di dialetti.
I modelli centralizzati invece si dimostrano superiori perchè
c'è un produttore (IBM, Corel ecc. ecc.) che stabilisce degli
standard inseriti in un documento ufficiale, e chi scrive
applicazioni per quel sistema operativo **deve** seguirli
(perchè altrimenti l'applicativo non viene installato).
Altra cosa assurda, poi, è che non esiste neanche uno standard
comune per la distribuzione dei pacchetti. RedHat lanciò RPM,
mentre Debian utilizza APT. Il chè è totalmente privo di senso
perchè se si vuole creare un OS desktop si crea un unico
standard che supporti tutte le features necessarie e che si
utilizza con un unico strumento. Insomma, si crea un formato
che supporta installazione, compressione, compilazione dei
sorgenti, aggiornamento del menù di KDE, e risoluzione
automatica delle dipendenze via internet ecc. ecc.
Si consideri poi che i vari pacchetti sono anche differenziati
per piattaforma (i386, i586, iK6, i686 solo per citare le
piattaforme Intel compatibili) per aumentare ancora di
più il caos generale.
Finchè Linux non avrà dei precisi standard, percui di ogni
applicazione esista un unico package (al limite distinti per
piattaforma, non di più) ed un preprocessore provvede
a leggere un listato all'inizio ed a eseguire tutti i
controlli e le operazioni necessarie per l'installazione *in
modo totalmente automatico e trasparente all'utente*
non ci sarà mai possibilità di battere Windows.
2) Manca uno standard per i drivers di sistema e per i
codec. In generale i drivers di sistema hanno una qualità
mediocre.
In generale a questa obiezione si risponde che i driver
di sistema devono essere scritti dai produttori e che se
non vengono rilasciate le specifiche non è possibile
scrivere driver per un certo dispositivo.
Le cose non stanno esattamente a questo modo, però.
L'assenza dei driver sotto Linux nasce anche dal fatto
che manca una strategia industriale che faciliti le cose.
Immaginiamo per un attimo che Linux sia prodotto
da una ipotetica LinuxCorporation, ossia da un'azienda
con un nome ed un indirizzo. LinuxCorporation potrebbe
fare una serie di cose:
a) innanzitutto uniformare a precise specifiche il
comportamento dei driver. Stabilire che tutti i driver delle
schede grafiche devono fornire un set preciso di
funzioni, che tutti i driver delle stampanti devono
fornire un set preciso di funzioni ecc. ecc.
Scrivere specifiche sul modo in cui devono essere scritti
i driver (devono essere tutti moduli caricabili dal kernel,
le impostazioni del driver si trovano in **questi** (e solo
questi) file di **questa** cartella, le istruzioni estese devono
essere usate in questo modo ecc. ecc. ecc.).
b) Poi, poichè molte periferiche si comportano in modo
simile, diventa possibile scrivere delle classi di drivers,
che riutilizzano più volte il medesimo codice (per esempio,
una volta scritto un driver di stampa per un modello di
stampante, è possibile scrivere i driver anche per altri
cento modelli, cambiando solo le parti del codice che
inviano i comandi al modello specifico di stampante ecc.
ecc.).
Questo modello per alcune periferiche (come scanner,
stampanti o modem) può anche funzionare. Naturalmente
non funziona più con periferiche che richiedono bassa
latenza ed elevate performance come schede grafiche
o schede audio. In quel caso conta l'ottimizzazione del
chipset, eventuali registri interni della periferica non
documentati, e l'utilizzo di codice compilato con un
compilatore estremamente veloce e che usi tutte le
istruzioni estese.
c) LinuxCorporation potrebbe, in teoria, pagare Nvidia, Matrox,
Ati (per citare i maggiori produttori attuali di schede grafiche),
per scrivere drivers a bassa latenza ed elevate prestazioni.
Anche qui, il modello centralizzato offre dei vantaggi sul
modello della GPL: una multinazionale può prendere accordi
con un altra per produrre dei drivers ottimizzati; diversamente
un hacker che scriva da sè i drivers non potrà mai raggiungere
il medesimo risultato.
d) I drivers per Linux dovrebbe essere distribuiti in un package
apposito e perfettamente standardizzato (diverso da quello
delle applicazioni).
Anzi, tutti i drivers disponibili per Linux dovrebbero essere
inseriti in un apposito sito web, dove possono essere
scaricati in un clic.
I drivers dovrebbe poi essere tutti caricabili automaticamente
con un meccanismo simile a modprobe: ciò significa eliminare
la possibilità di incorporare il codice per i dispositivi nel
kernel (tranne che per alcune periferiche "essenziali" e per
i file system).
3) Il sottosistema grafico X è troppo lento.
Ci sono delle scelte di architettura fatte su linux che determinano
la lentezza di questo sistema operativo per usi multimediali.
Se non credete che sia così, prendete un bel Pentium 233 MMX,
installateci sopra Windows 98 e poi installate Linux + KDE 3.2.
Quale dei due è più veloce? Provate a riprodurre un file AVI e
poi mi saprete dire. In genere, coloro che dicono che Linux è
più veloce di Windows lo fanno con processori molto veloci,
dove il divario si riduce.
Perchè esiste una differenza di velocità? Il primo problema
consiste nella scelta di tenere l'interfaccia grafica in user mode,
e non in kernel mode. Questa scelta è stata fatta per migliorare
la stabilità del sistema. Infatti, un bug nell'interfaccia non può
bloccare l'intero sistema.
Tuttavia, un OS desktop ha bisogno di routine per l'accesso al
video a bassa latenza, proprio perchè il suo utilizzo sono anche
i videogiochi, i dvd, i divx ecc. ecc. Ed è questo l'uso che viene
fatto di Windows da una parte del **mercato consumer**.
All'utente medio non gliene può fregare di meno del fatto che
Linux è meglio perchè il nuovo kernel 2.6.0 con la patch xx
e la patch yy, supporta il multitasking preemptive ecc. ecc.
All'utente medio può interessare che con il nuovo Linux i
DVD non li vedi a scatti, i Divx neanche ed i giochi vanno
più veloci perchè le nostre routine di emulazione ed astrazione
dell'hardware sono più efficienti di quelle Microsoft DirectX.
Che possa piacere o meno, quell'utente (e non utonto) è
**mercato**, fa **mercato** ed anzi è il mercato dominante.
Se la risposta a quell'utente è qualcosa tipo: "Linux non è
per te. Comprati la PSX per giocare.", la risposta dell'utente
sarà sempre "Papà, papà, me lo compri quel Windows XP
di quel monopolista (ih ih ih!!!) di B.Gates?". La risposta
dei produttori di software videoludico sarà invece
"Linux, vaff..."
Senza contare che esistono studi precisi che contestano
l'efficienza di XFree (che tralaltro le distribuzioni non ricompilano
al momento dell'installazione in modo da supportare le
istruzioni estese del processore, e che sarebbero importantissime
per migliorare le performance del sottosistema grafico).
XFree è la versione GPL del protocollo X-Windows, un
protocollo che è stato ideato per consentire la comunicazione
dei client con i server indipendentemente dall'effettiva ubicazione
di questi ultimi. In locale (come viene usato nel 95% dei sistemi
desktop) è un approccio che da più svantaggi che vantaggi
e quindi non ha senso usarlo.
La soluzione potrebbe essere quella di un server che è specializzato
ed ottimizzato per lavorare solo in locale ed un server che invece
lavora in remoto. Una nuova versione reingegnerizzata delle
librerie QT e delle librerie GTK (compilate appositamente),
verificano quale server è attivo nel socket utente e eseguono
le loro chiamate in base al server locale o al server remoto.
Così come, in un OS Desktop, non ha poi molto senso l'idea che
l'interfaccia grafica debba stare a ring 3.
Io penso che il codice di KDE e GNOME possa stare in user
space, ma almeno i nuovi server grafici (locale e remoto), le
librerie QT e le librerie GTK dovrebbero girare in kernel mode,
sempre per massimizzare le performance.
Concludo osservando che il codice che gira sotto Linux è
compilato quasi tutto per GCC, e che questo compilatore
sembra non essere il non plus ultra tra i compilatori in
commercio (il compilatore che produce il codice più
efficiente sembra essere l'ICC di Intel: tale codice è circa del
20% più veloce del codice generato da GCC).
Anche qui c'è una evidente questione di costi. Progettare un
OS compilato per il 60% con l'ICC (ed ottimizzato per le
istruzioni estese) significa sopportare dei costi (GCC è gratuito),
e questo non è possibile a meno di non volere fare di Linux
un prodotto commerciale.
Ci sarebbero altre cose da osservare ma per adesso
mi astengo.
Saluti
Vegeta
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.593 / Virus Database: 376 - Release Date: 20/02/04
