[ Home | Liste | F.A.Q. | Risorse | Cerca... ]


[ Data: precedente | successivo | indice ] [ Argomento: precedente | successivo | indice ]


Archivio: Ottobre 2001 ml@sikurezza.org
Soggetto: Re: Linux, Stabilit? e sicurezza.
Mittente: antirez
Data: 23 Oct 2001 15:55:32 -0000
On Tue, Oct 23, 2001 at 11:17:30AM +0200, Igor Falcomata' wrote:
> Da tempo, molto tempo stavo incominciando a pensare che linux stesse
> diventando un succedaneo di windows per quanto riguarda stabilità e
> sicurezza.
> Mio malgrado, col passare del tempo, sto sempre più prendendo atto del fatto
> che ho ragione.
> 
> Basta vedere "la magra figura" che gli sviluppatori hanno fatto col kernel
> 2.4.11, ma non solo... io ho notato un notevole calo di stabilità con un
> repentino aumento di oops e kernel panic, sia sulla configurazione
> "portatile per casa mia" ma anche sulla versione "server da produzione".
> 
> Sinceramente mi fa ridere il pensiero di dover dire "è uscito un kernel
> nuovo ma devo tenere quello vecchio perchè è più stabile" mi chiedo... che
> diavolo è uscito a fare il kernel nuovo se funziona peggio di quello
> precedente??
> Se non ho stabilità da un sistema operativo, che me lo tengo a fare?
> ....

[snip]

> Federico Egopfe<at>ircnet

Ciao Federico,

In effetti e' vero. Il modello di sviluppo di linux sembrava funzionare
meglio in passato, ultimamente ho letto molto la linux kernel ml,
ecco le mie conclusioni:

Forse quello a cui si sta assistendo oggi, ovvero un kernel
stabile (il 2.4) che sembra in beta da molti punti di vista, e' una
diretta conseguenza del fatto che il modello di sviluppo di linux
e' cambiato. Questo cambiamento, secondo me, e' iniziato in qualche
momento nello sviluppo di linux 2.2, non e' una cosa che riguarda
strettamente il 2.4. Alcuni dei problemi potrebbero essere i seguenti:

- il nuovo modello di sviluppo coinvolge troppi sviluppatori
- molti sviluppatori sono pagati da societa' che hanno delle priorita'
  diverse.
- c'e' troppa divisione dei compiti e delle ml in cui si discute
  solo di un determinato sottosistema, una buona cosa, se non fosse che
  a questa divisione non corrisponde una API chiara di tutti i sotto
  sistemi, non in tutti i casi almeno.
- la VM di linux e' sviluppata da due diverse persone
  contemporaneamente, ambedue si avvalgono troppo poco della letteratura
  sull'argomento e c'e' poca voglia di guardare alle implementazioni
  di sistemi operativi che funzionano molto bene attualmente.
  E' un peccato perche' questi sviluppatori sembrano capaci
  e avrebbero bisogno fondamentalmente di essere guidati meglio.
- non c'e' una vera coordinazione tra gli sviluppatori, ne un
  processo di sviluppo conservativo, per 'stadi', definito.

Secondo me l'ultimo problema e' il piu' pesante, aggravato dal primo
(troppi sviluppatori). Ad esempio provate ad utilizzare i kernel
della serie ac, scoprirete che funzionano meglio in generale.
In effetti i kernel -ac sono un vero e proprio fork. Utilizzano
una diversa VM, hanno cose in piu' e cose in meno, le scelte sul
"cosa mettere dentro" sono piu' ponderate. Il risultato e' un sistema
che funziona meglio sotto carichi normali ed e' piu' stabile,
anche se attinge alla stessa fonte di codice.

Poi... a me sembra che non ci sia molta voglia di spendere 6
mesi a fare pulizia del codice, chiarire le api, insomma fare
le cose in maniera conservativa. Tutto sommato molti non sono
direttamente pagati per farlo, e vanno piu' in cerca di fama,
che si ottiene avendo dentro qualcosa che sviluppi tu e che
funziona gia'.

Ora la sparo grossa: secondo me una cosa che farebbe molto bene
a linux potrebbe essere la nascita di un fork che tenta di
andare piu' lento ma di fare le cose meglio. Si puo' sempre
greppare dall'attuale tree, ma si puo' fare una selezione
e anche un buon lavoro di pulizia dei sotto sistemi.
Grazie a CVS si puo' rimanere in sync con tutte le parti
che vogliono essere replicate, con qualche sforzo.

Se fai qualcosa che funziona meglio per alcuni e ottieni
un successo discreto magari gli altri sono costretti a
ripensare sulle loro scelte, e a seguirti.

L'altra soluzione e' quella di passare ad un kernel diverso.
Tutto sommato la scelta e' l'arma dell'utente. Se vuoi fare
un server metti un BSD, e vedi se le cose migliorano.
Linux e' solo una scelta, non una catena :)

Un problema diverso riguarda l'architettura sulla quale
fai girare linux. Attualmente scrivere un kernel per PC e'
diventato un incubo. Ci sono 60000 bios, periferiche, processori,
e cosi' via. Le interazioni "a sorpresa" iniziano a diventare
tante, ci sono un sacco di driver da scrivere e testare.
Ai tempi del 2.0.36 c'era molto meno hardware da
supportare e questo rendeva le cose piu' stabili automaticamente,
e c'era piu' tempo per guardare e sviluppare con cura le poche
cose che era necessario sviluppare, non c'erano sistemi MP e via di seguito.

Forse e' solo un caso, ma sul mio P133 non c'e' kernel
che non fa un uptime di mesi :) . Il 2.4.9 e' tristemente
famoso per creare casini, la VM funziona molto male, eppure:

# uname -a
Linux nano 2.4.9 #2 Sat Sep 8 17:20:24 CEST 2001 i586 unknown
# uptime
  3:11pm  up 44 days, 21:43,  2 users,  load average: 0.00, 0.00, 0.00

Questo PC mi fa da server, c'e' il POP, il firewall, la scheda
ISDN, e tutto funziona bene. Gli unici problemi che ho avuto
in passato riguardano appunto la scheda ISDN perche' il driver
era troppo giovane e troppo poco testato, ma ora hanno risolto.
Devo ammettere che il carico a cui e' sottoposto e' davvero basso.

Tutto sommato questo dovremmo averlo gia' imparato da tempo,
dalla sicurezza informatica: le cose semplici sono piu' robuste
e riservano meno sorprese.

Una strada e' il microkernel. Se non puoi rendere
le cose semplici, almeno dividi tutto e dai una chiara interfaccia
grazie alla quale tutte le parti comunicano.
Microkernel o meno questo si puo' fare in ogni caso, e' solo
che ti rallenta ogni volta che crei un nuovo sotto-sistema,
ma dopo poco tempo vedi solo vantaggi, IMHO.

ciao,
antirez

-- 
Salvatore Sanfilippo <antirez@invece.org>
http://www.kyuzz.org/antirez
finger antirez@tella.alicom.com for PGP key
28 52 F5 4A 49 65 34 29 - 1D 1B F6 DA 24 C7 12 BF

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List




[ Home | Liste | F.A.Q. | Risorse | Cerca... ]

www.sikurezza.org - Italian Security Mailing List
(c) 1999-2005