Kernel 2.6: Suse scopre una nuova falla

[Cimmo]

Fico su internet gia' c'e' un simpatico file c da compilare che permette di far crashare un qualsiasi kernel 2.4.x e 2.6.y con x<=26 e y<=7 sembra che non ci sia bisogno di essere root e pare pure che il kernel non faccia nemmeno in tempo a scrivere il log prima di andare in crash!
Le distribuzioni affette sono tante:
Mandrake 10.0, Fedora Core 1 e 2 tanto per citarne qualcuno...

[afterburner]

Originariamente inviato da Hal2001
Ormai il ramo del 2.6 è pronto e maturo per essere utilizzato dappertutto.

Si' e no ... il 2.6 aggiunge funzionalita' sicuramente valide per sistemi desktop tipo le migliorie fatte nella gestione usb, bletooth, wireless e non so cos'altro. Ma per sistemi server dove di usb,bluetooth e wireless non te ne fai nulla perche' e' gia' tanto che il server abbia una tastiera, secondo me puo' bastare un ottimo 2.4.26 ed e' quello che faccio sui server che gestisco .. se secondo qualcuno questa mia politica e' una cazzata me lo dica ma con motivazioni valide e grazie!

[ilsensine]

Originariamente inviato da afterburner
Ma per sistemi server dove di usb,bluetooth e wireless non te ne fai nulla perche' e' gia' tanto che il server abbia una tastiera, secondo me puo' bastare un ottimo 2.4.26

Per i sistemi server che necessitano di una scalabilità molto alta, il 2.6 è un must...

[afterburner]

Originariamente inviato da ilsensine
Per i sistemi server che necessitano di una scalabilità molto alta, il 2.6 è un must...

Mumble mumble ... la tua affermazione mi lascia perplesso. Sotto quale ramo della scalabilita' il 2.4 e' carente rispetto al 2.6? Numero utenti? Gestione LVM? Supporto di nuovo hardware (leggi athlon 64)? Spiegami meglio per favore.

[Hal2001]

Originariamente inviato da afterburner
non so cos'altro

se secondo qualcuno questa mia politica e' una cazzata me lo dica ma con motivazioni valide e grazie!

Ma potresti anche tu stesso dare delle motivazioni valide, per cui, non si dovrebbe utilizzare il nuovo ramo al posto del più collaudato 2.4. Problemi di sicurezza degni di nota? Prestazioni? Allineamento astrale?

I miglioramenti non sono stati fatti soltanto a livello di periferiche supportate o di standard, sono stati messi sotto banco di lavoro anche gli stack di rete, l'I/O.

Il tuo discorso è da applicare solo nei sistemi mission critical. Questo a mio modo di vedere le cose

[Hal2001]

Originariamente inviato da ilsensine
Per i sistemi server che necessitano di una scalabilità molto alta, il 2.6 è un must...

[afterburner]

Originariamente inviato da Hal2001
Ma potresti anche tu stesso dare delle motivazioni valide, per cui, non si dovrebbe utilizzare il nuovo ramo al posto del più collaudato 2.4. Problemi di sicurezza degni di nota? Prestazioni? Allineamento astrale?

I miglioramenti non sono stati fatti soltanto a livello di periferiche supportate o di standard, sono stati messi sotto banco di lavoro anche gli stack di rete, l'I/O.

Il tuo discorso è da applicare solo nei sistemi mission critical. Questo a mio modo di vedere le cose

Come dice il sensine puoi fare una scelta coraggiosa sui sistemi desktop (ossia sulla nostra pelle) e come dici tu il 2.4 e' piu' collaudato. Se una macchina linux mi tiene su server web e mail preferisco usarci un kernel piu' collaudato .. e' una mia politica, probabilmente abbastanza paranoica ma finora mi ha garantito il minor numero di rogne.

[Duncan]

E comunque la differenza tra 2.6 e 2.4 su server "standard" non credo sia molto marcata, la divverenza si vede su sistemi con architetture particolari o con numero di cpu maggiore di 4 credo

[ilsensine]

Originariamente inviato da afterburner
Mumble mumble ... la tua affermazione mi lascia perplesso. Sotto quale ramo della scalabilita' il 2.4 e' carente rispetto al 2.6? Numero utenti? Gestione LVM? Supporto di nuovo hardware (leggi athlon 64)? Spiegami meglio per favore.

Principalmente, lo scheduler (entrambi i process scheduler e i/o scheduler). Poi per altri motivi (minore latenza, context switch a frequenza più alta, maggiore scalabilità in memoria, migliore gestione dei thread...)
Un server di medio/piccole dimensioni può usare tranquillamente il 2.4, ma uno che deve gestire migliaia di programmi/thread, molti processori, svariati GB di memoria, è bene che si affidi al 2.6.

[pdepon]

fedora core 2 usava il 2.6.5 che è aggiornabile (da diversi mesi) al 2.6.8

[cdimauro]

Originariamente inviato da RaouL_BennetH
Ora però la domanda mi sorge spontanea.... con la speranza di non essere frainteso e di non scatenare flame:

Dato che la Suse è stata la "prima" a "trovare" questo bug, come è possibile che, vista la natura open-source dei sorgenti del kernel, migliaia di esperti che leggono il codice sorgente non se ne siano accorti prima? E non mi riferisco a tutti i bug che vengono scovati sul kernel e prontamente corretti, ma in particolare a questo che stimano con 9/10 di pericolosità.

Non se ne sono accorti perché sono pur sempre essere umani, e qualcosa sfugge: è normale.
Per me l'unica differenza fra open e closed per quanto concerne gestione e testing del software, sta tutto nella velocità con la quale vengono rilasciate le patch.

[cdimauro]

Originariamente inviato da afterburner
Si' e no ... il 2.6 aggiunge funzionalita' sicuramente valide per sistemi desktop tipo le migliorie fatte nella gestione usb, bletooth, wireless e non so cos'altro. Ma per sistemi server dove di usb,bluetooth e wireless non te ne fai nulla perche' e' gia' tanto che il server abbia una tastiera, secondo me puo' bastare un ottimo 2.4.26 ed e' quello che faccio sui server che gestisco .. se secondo qualcuno questa mia politica e' una cazzata me lo dica ma con motivazioni valide e grazie!

Motivazione banale: ma con linux non puoi decidere di assemblarti il kernel come ti pare? Elimini il supporto a usb, bluetooth, wireless e tutto ciò che reputi "problematico", e ottieni la tua distribuzione con kernel 2.6 "seria" (server).

Osservazione stupida: perché rilasciare un nuovo kernel se non è abbastanza testato per funzionare su una piattaforma "seria"? Si potrebbe benissimo continuare il testing e rilasciarlo in un secondo tempo, quando ha raggiunto una certa "maturità".

Osservazione meno stupida: non è che comunque un software è a rischio di bug, e certi "rischi" bisogna pur correrli?
Prima o poi un software DOVRA' essere rilasciato.
Prima o poi si troveranno dei bug, più o meno gravi.

Tutto il mondo è paese...

[Duncan]

Originariamente inviato da cdimauro
[CUT]

Osservazione stupida: perché rilasciare un nuovo kernel se non è abbastanza testato per funzionare su una piattaforma "seria"? Si potrebbe benissimo continuare il testing e rilasciarlo in un secondo tempo, quando ha raggiunto una certa "maturità".

Osservazione meno stupida: non è che comunque un software è a rischio di bug, e certi "rischi" bisogna pur correrli?
Prima o poi un software DOVRA' essere rilasciato.
Prima o poi si troveranno dei bug, più o meno gravi.

Tutto il mondo è paese...

Beh la seconda mi pare che risponda alla prima osservazione

Software esenti da bug ne esistono molto pochi... se errare è umano... i bug ci sono

Come hai fatto notare giustamente te la differenza tra open e closed source è nella velocità con cui sono rilasciate le patch, infatti stiamo disquisendo su di un bug già risolto da diverso tempo nel kernel

[LAj]

Passare al 2.6 per gestire un server è una scelta più che oculata per gestire un server.
Si sfrutterebbe il pre-emptive per lo scheduling dei processi ed altre avanzatissime features.

Avevo scritto tante altre cose ma il browser me le ha cancellate quando si mi ha ridiretto xchè non avevo fatto il login e mi scoccio di riscriverle.
Mi dispiace ma il testing funziona così ed è normale che si trovino e risolvano vulnerabilità(in breve),.

[Cimmo]

[OT x LAj] usi IE? Con Opera (e forse altri) se fai back si ricorda di quello che hai scritto nei textarea, anche se nel mentre hai fatto il login sempre nella stessa pagina.

[teogros]

Microsoft! Windows Linux

[afterburner]

Originariamente inviato da cdimauro
Motivazione banale: ma con linux non puoi decidere di assemblarti il kernel come ti pare? Elimini il supporto a usb, bluetooth, wireless e tutto ciò che reputi "problematico", e ottieni la tua distribuzione con kernel 2.6 "seria" (server).

Giustissimo, pero' prendendo un 2.6, dopo aver tolto quello che reputo problematico e inutile (per un server) tipo usb,bluetooth e altro, praticamente mi rimane un 2.4. ilsensine sostiene che sono migliorate parecchie cose sulla gestione dei thread nel 2.6 e non lo metto in dubbio ma avendone diversi da gestire non mi piace stare a compilare e patchare tutti i santi giorni un kernel nuovo. Preferisco affidarmi a cose un po' piu' vecchie magari un po' meno veloci ma collaudate.

Osservazione stupida: perché rilasciare un nuovo kernel se non è abbastanza testato per funzionare su una piattaforma "seria"? Si potrebbe benissimo continuare il testing e rilasciarlo in un secondo tempo, quando ha raggiunto una certa "maturità".

Penso per due motivi:
- il testing migliore viene fatto dalla massa della gente. E' pero' stupido mettere un nuovissimo kernel su un prodotto enterprise.
- necessita' di star dietro al nuovo: usb, firewire, bluetooth, wi-fi sono in continua evoluzione senza contare che escono nuovi standard di continuo. Purtroppo anche linux vuole starci dietro finendo col trascurare aspetti ben piu' seri che hanno fatto il suo successo tipo, in questo caso, iptables.

Osservazione meno stupida: non è che comunque un software è a rischio di bug, e certi "rischi" bisogna pur correrli?
Tutto il mondo è paese...

Ogni software e' a rischio di bug. Sta a chi lo installa valutare il rischio in base a quanto e' stato collaudato. A casa posso installare anche un kernel release candidate mentre su un server di posta di un'azienda no, altrimenti sarei la stupidita' fatta persona.

[ilsensine]

Giustissimo, pero' prendendo un 2.6, dopo aver tolto quello che reputo problematico e inutile (per un server) tipo usb,bluetooth e altro, praticamente mi rimane un 2.4

Se dovessi gestire un server con un carico di 4/5000 thread, vedi che un pò di tempo per metterci e aggiornare il 2.6 lo spenderesti
Il 2.6 è insidioso, sembra che non sia cambiato molto (anche per questo escono fuori facilmente bug nuovi, e sono d'accordo che è da introdurre nei server solo quando è necessario)

[afterburner]

Originariamente inviato da ilsensine
Se dovessi gestire un server con un carico di 4/5000 thread, vedi che un pò di tempo per metterci e aggiornare il 2.6 lo spenderesti
Il 2.6 è insidioso, sembra che non sia cambiato molto (anche per questo escono fuori facilmente bug nuovi, e sono d'accordo che è da introdurre nei server solo quando è necessario)

Si', penso proprio lo farei. Ma (e non diciamolo a nessuno!! ) patcho i kernel con OpenMosix all'insaputa di tutti cosi' chi lancia simulazioni sui linux piu' lenti frega cpu ai linux piu' veloci in azienda ... purtroppo OpenMosix esiste stable per kernel 2.4.24

[ilsensine]

Originariamente inviato da afterburner
Si', penso proprio lo farei. Ma (e non diciamolo a nessuno!! ) patcho i kernel con OpenMosix all'insaputa di tutti cosi' chi lancia simulazioni sui linux piu' lenti frega cpu ai linux piu' veloci in azienda ... purtroppo OpenMosix esiste stable per kernel 2.4.24

<ot> Parlo di thread, non solo di processi
Purtroppo OpenModix non può migrare oggetti che utilizzano la stessa memoria condivisa su differenti macchine...sarebbe follia...