erlug
[Top] [All Lists]

Re: [Erlug] Prime impressioni sul 2.4.20

To: erlug@xxxxxxxxxxxxxx
Subject: Re: [Erlug] Prime impressioni sul 2.4.20
From: Davide Bolcioni <db_erlug@xxxxxxxx>
Date: Mon, 02 Dec 2002 23:10:55 +0100
Maurizio Lemmo - Tannoiser wrote:
perche` temo, che il problema non sia solo nel "kernel", ma in tutto
quello che comporta. Prendi il 2.4. a memoria mia, un kernel cosi`
"sfigato" non si era ancora visto: device scsi che "saltano" da una
versione all'altra, un kernel "do-not-to-use", un cambio di vm in un
tree stable... insomma, fino al 2.4.18 ho trovato il 2.4 pressocche`
inusabile.

Perche`? perche` bisogna introdurre supporto per una serie di
periferiche che, diciamolo, fanno un po` ridere, il piu` delle volte.

Beh, consoliamoci con Nietzsche: le difficoltà a cui sopravviviamo ci
rendono più forti ... così come il famigerato benchmark di Mindcraft ha
dato la spinta necessaria per superare alcune limitazioni nel design del
kernel, l'esigenza di far funzionare periferiche "strane" sta avviando
un discorso cominciato con devfs e la cui fine ancora non è in vista ma
che promette di introdurre modalità veramente innovative di gestione dei
device.

L'importante, secondo me, sta nel difendersi da coloro che pensano di
poter fare uno Unix desktop facendolo come Windows. Penso ad esempio a
GConf che, con riserva dovuta al fatto che non ho studiato la cosa a
fondo, mi sembra tanto una reintroduzione del Registry - il problema del
Registry, come per tanti altri casi, non sta nel fatto che in Microsoft
non sono capaci di scrivere il codice, ma nel fatto che non sanno fare
un progetto decente (o più probabilmente che quelli che decidono non
sono quelli che lo saprebbero fare).

E non ci si ferma solo li. c'e` poi tutto il problema di "reinventarsi"
un architettura che funziona, e bene, ma su "idee" diverse.

Qui sta la vera scommessa, secondo me. Se si riesce a introdurre
un'architettura desktop a) assai diversa dalle architetture esistenti,
in particolare in grado di rendere radicalmente congeniale la
costruzione di applicazioni desktop alle modalità dello sviluppo open
source e b) che funziona bene, si è ottenuto un bel risultato. Come per
tanti altri aspetti dello sviluppo software, finchè non ci si prova è
difficile dire se riuscirà o no - ma come per tutte le imprese nel
campo della conoscenza, un solo successo pagherà per tutti i fallimenti.

Ripeto, non e` che "tecnicamente" non si possa fare, e` che non ne vale
davvero la pena.

Tocca agli zii saggi come te dire agli sviluppatori: questa soluzione
non va bene. Gli sviluppatori dovrebbero avere l'umiltà di reagire con
"allora cerchiamone una migliore" invece che con "stai zitto vecchio
bolso sysadmin retrogrado". Per quanto ho visto io, un sysadmin è più
qualificato di uno sviluppatore per dire "non va bene", ha visto un
mondo più variegato, ma meno qualificato per proporre qualcosa di nuovo
 - tende a riproporre le solide soluzioni dei bei vecchi tempi.

E non e` solo un problema hardware. pensa alla gui. pensa ai video game.
direct x. tutta roba che funziona perche` e` possibile "saltare" il
sistema operativo e scrivere "direttamente" sulla memoria della scheda
video.

Altrettante sfide. Sviluppatori: ci serve un'architettura per i giochi
che offra prestazioni superiori a DirectX senza cedere di un pollice sul
controllo di accesso da parte del sistema operativo e minimizzando la
quantità di codice eseguito in kernel mode. Fatevi sotto.

Guarda, per come la vedo io, per l'utente desktop, anche windows, o
macos sono "difficili". Io sono un teorico di una vecchia idea di sun,
le "net-station". thin client totali, su cui non dovevi _mai_ installare
un programma.

Altro discorso meritevole di un thread distinto, secondo me.

Davide Bolcioni
--
Paranoia is an afterthought.


<Prev in Thread] Current Thread [Next in Thread>