Link alla notizia: http://news.hwupgrade.it/13430.html

Suse ha individuato una pericolosa falla presente nel kernel 2.6

Click sul link per visualizzare la notizia.

Avanti... sotto con i commenti che anche linux è bacato.. sfogatevi..

questa cosa non l'ho capita:

" Le distribuzioni vulnerabili sono Suse Linux 9.1 e Suse Linux Enterprise Server (SLES) 9; Suse Linux 9.2 non è affetta dal bug in quanto il kernel che usa, la versione 2.6.8, contiene già un fix."

Cioè, non mi è chiaro se è una falla nei kernel 2.6 antecedenti il 2.6.8, oppure è una falla di Suse, dato che sembra essere l'unica che ne soffre.

Chi mi svela l'arcano?

Originariamente inviato da RaouL_BennetH
questa cosa non l'ho capita:

" Le distribuzioni vulnerabili sono Suse Linux 9.1 e Suse Linux Enterprise Server (SLES) 9; Suse Linux 9.2 non è affetta dal bug in quanto il kernel che usa, la versione 2.6.8, contiene già un fix."

Cioè, non mi è chiaro se è una falla nei kernel 2.6 antecedenti il 2.6.8, oppure è una falla di Suse, dato che sembra essere l'unica che ne soffre.

Chi mi svela l'arcano?
E' antecedente al kernel 2.6.8, che è uscito ad agosto.
La Suse è stata l'unica a utilizzare in ambiente enterprise i primi kernel 2.6 -- una scelta affrettata e sbagliata. C'erano altri problemi, oltre questo (non necessariamente legati alla sicurezza), che sono stati sistemati nelle prime release (che in effetti erano release "di rodaggio").

Originariamente inviato da RaouL_BennetH
Chi mi svela l'arcano?

http://www.net-security.org/advisory.php?id=3515
http://www.gentoo.org/security/en/glsa/glsa-200407-12.xml

Tutte quelle che utilizzano quelle versioni di kernel nelle condizioni sopra menzionate, non solo la SuSE.

Alla Suse non si erano accorti di un fix (o patch del kernel) che con la versione 2.6.8 e' gia' incluso di base.... semplicemente la versione SuSe ne e' sprovvista per kernels antecedenti il 2.6.8, la tua versione potrebbe gia' contenere detto fix, nel caso di dubbio
cerca tra le patch per il tuo kernel (e' una patch iptables se non ho capito male) e ricompilalo, oppure
aggiornalo (io sto girando col 2.6.8-r10 che e' stabile e col 2.6.9-nitro-r2 che e' sperimentale ma
sembra tirare bene con la mia gentoo)

Originariamente inviato da DevilsAdvocate
Alla Suse non si erano accorti di un fix (o patch del kernel) che con la versione 2.6.8 e' gia' incluso di base.... semplicemente la versione SuSe ne e' sprovvista per kernels antecedenti il 2.6.8, la tua versione potrebbe gia' contenere detto fix, nel caso di dubbio
cerca tra le patch per il tuo kernel (e' una patch iptables se non ho capito male) e ricompilalo, oppure
aggiornalo (io sto girando col 2.6.8-r10 che e' stabile e col 2.6.9-nitro-r2 che e' sperimentale ma
sembra tirare bene con la mia gentoo)

No, non era per me :)

Io ho cominciato direttamente con una debian e con il 2.6.8.1.

Originariamente inviato da DevilsAdvocate
io sto girando col 2.6.8-r10 che e' stabile e col 2.6.9-nitro-r2 che e' sperimentale
<ot> che razza di ramo è il "nitro"? :D

Originariamente inviato da RaouL_BennetH
No, non era per me :)

Io ho cominciato direttamente con una debian e con il 2.6.8.1.
Quoto. Non ho montato nessun 2.6 prima di questa versione.

Originariamente inviato da ilsensine
una scelta affrettata e sbagliata

Magari coraggiosa, visto che RedHat ancora patcha il 2.4.x facendo divenire questo passaggio il più lento della storia :D

I'm joke ;)

Sicuramente Suse ha accelerato un po' troppo a mettere in ambiente enterprise i kernel 2.6 .. E la scelta di RedHat si e' dimostrata la migliore ossia tenere il kernel 2.4 inserendovi pezzi ad-hoc del 2.6. E' un vero peccato che questi kernel non li possano scaricare gli utenti non in possesso di una redhat enterprise .. o almeno cosi' mi risulta nel senso che su kernel.org si e' arrivati al 2.4.27 mentre redhat per le sue soluzioni enterprise gira con kernel tipo 2.4.quaranta e rotti.
Teoricamente qualsiasi distribuzione Linux con kernel 2.6 versione antecedente alla 8 e' vulnerabile a questo bug quindi attenti ...

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à.

Originariamente inviato da Hal2001
Magari coraggiosa, visto che RedHat ancora patcha il 2.4.x facendo divenire questo passaggio il più lento della storia :D

I'm joke ;)

solo un pazzo metterebbe un kernel relativamente nuovo come il 2.6 in un sistema in produzione... se ne puo' parlare quando si incomincera' a parlare di kernel 2.7 quando x il 2.6 usciranno solo bugfix e miglioramenti e non nuove feature come adesso...

fino ad allora il 2.4 e' la scelta obbligata, magari patchato a dovere

Originariamente inviato da afterburner
Sicuramente Suse ha accelerato un po' troppo a mettere in ambiente enterprise i kernel 2.6 .. E la scelta di RedHat si e' dimostrata la migliore ossia tenere il kernel 2.4 inserendovi pezzi ad-hoc del 2.6. E' un vero peccato che questi kernel non li possano scaricare gli utenti non in possesso di una redhat enterprise .. o almeno cosi' mi risulta nel senso che su kernel.org si e' arrivati al 2.4.27 mentre redhat per le sue soluzioni enterprise gira con kernel tipo 2.4.quaranta e rotti.
Teoricamente qualsiasi distribuzione Linux con kernel 2.6 versione antecedente alla 8 e' vulnerabile a questo bug quindi attenti ...

infatti e' stata corretta gia' da un paio di mesi a partire dal kernel 2.6.8, considera che e' uscito successivamente il 2.6.8.1 e quello attuale e il 2.6.9

Originariamente inviato da Crisa...
fino ad allora il 2.4 e' la scelta obbligata, magari patchato a dovere

Poco fa scherzavo, e l'ho pure scritto. Ma adesso ti dico seriamente che non penso che quello che dici sia saggio. Ormai il ramo del 2.6 è pronto e maturo per essere utilizzato dappertutto.

Originariamente inviato da Hal2001
Magari coraggiosa, visto che RedHat ancora patcha il 2.4.x facendo divenire questo passaggio il più lento della storia :D

I'm joke ;)
Le scelte coraggiose le condivido, ma dovrebbero essere fatte sui sistemi desktop (leggi: sulla pelle nostra :D) prima che sui server ;)

x raoul: la suse nn e' la prima visto che il problema e' stato gia' risolto...;)

Troppo ridicolo il primo post "avanti sotto con i commenti - sfogatevi", veramente troppo lol!

Originariamente inviato da Crisa...
infatti e' stata corretta gia' da un paio di mesi a partire dal kernel 2.6.8, considera che e' uscito successivamente il 2.6.8.1 e quello attuale e il 2.6.9
Giustissimo .. ma non tutte le distribuzioni scaricabili da internet dispongono degli ultimissimi kernel! Sui sistemi server uso ancora redhat9 che ha kernel 2.4 e va benissimo. Non so che kernel abbiano le Fedora core 1 e 2 ma penso che non abbiano il 2.6.9 e nemmeno il 2.6.8 .. forse con le patch arrivano a questi kernel, almeno spero ..

Il mio riferimento era a quegli utenti che si installano una distribuzione desktop a casa, non aggiornano il kernel perche' manco sanno come si fa, non scaricano le patch "perche' tanto linux e' sicuro cosi'" e poi si trovano vulnerabili a questo exploit.

il "nitro" e' un ramo sperimentale per gentoo tirato su da un tedesco che applica direttamente un quintale di patch, se usi gentoo guarda qua:
http://sepi.be/nitro.php

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...

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!

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...

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.

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 :)

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

;)

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.

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

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.

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

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.

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...

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 :D

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 ;)

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),.

[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.

Microsoft! :rolleyes: Windows :rolleyes: Linux :rolleyes:

:rotfl:

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.

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)

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 :(

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...

Originariamente inviato da teogros
Microsoft! :rolleyes: Windows :rolleyes: Linux :rolleyes:

:rotfl:

Bravo. Un bel commento, più che intelligente lo definirei utile.

afterburner & ilsensine ma di che parlate? si parla di gestire thread all'interno della stessa macchina, non di unire più nodi :D

Originariamente inviato da ilsensine
<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...

Penso di conoscerne la differenza ;) Rimane che i processi di applicazioni che usano shared memory non migrano con openmosix: in sostanza processi basati su java rimangono locali mentre processi che forkano o usano pvm riescono a migrare su altre macchine piu' potenti.
Su openmosix unofficial (http://openmosix.snarc.org/) comunque esistono gia' delle versioni di openmosix per kernel 2.6 e delle patch per migrare processi che usano shared memory.

Originariamente inviato da afterburner
Su openmosix unofficial (http://openmosix.snarc.org/) comunque esistono gia' delle versioni di openmosix per kernel 2.6 e delle patch per migrare processi che usano shared memory.
Sarebbe interessante provare. Il problema della shared memory tra più macchine è gestire la consistenza dei dati. Per non parlare del traffico di rete generato...

Originariamente inviato da Hal2001
Bravo. Un bel commento, più che intelligente lo definirei utile.

afterburner & ilsensine ma di che parlate? si parla di gestire thread all'interno della stessa macchina, non di unire più nodi :D

Non era mia intenzione scrivere qualcosa di utile o intelligente... semplicemente avevo notato troppi meno flames rispetto a quando viene scoperto qualche nuovo baco su Windows e mi sono divertito al posto di chi lo fa di solito!

Questa news è il segnale evidente che nessun software è esente da problemi, per quanto possa essere semplice o complesso, gratis o a pago, bello o brutto e così via!

Chiuque conosce l'informatica sa che i bug sono inevitabili...

Il problema è come vengono risolti...

E dal tenore della discussione si vede che sono in genere gli utenti Windows che si stracciano i vestiti per ogni bug trovato... (anche se spesso la spintarella da parte di qualcuno la ricevono :D)

Originariamente inviato da Duncan
Chiuque conosce l'informatica sa che i bug sono inevitabili...

Il problema è come vengono risolti...

E dal tenore della discussione si vede che sono in genere gli utenti Windows che si stracciano i vestiti per ogni bug trovato... (anche se spesso la spintarella da parte di qualcuno la ricevono :D)

Basterebbe usare Windows Update correttamente per evitare di doversi stracciare le vesti! Comunque sono ot, chiedo venia.

Originariamente inviato da teogros
Basterebbe usare Windows Update correttamente per evitare di doversi stracciare le vesti! Comunque sono ot, chiedo venia.

Cultura informatica... e buon senso ;)

Originariamente inviato da Duncan
Cultura informatica... e buon senso ;)

Appunto: "doti" che non sono intrinseche alla piattaforma utilizzata!

OT - Convinto che tutti quelli che hanno parlato in questa discussione sanno perfettamente quello che dicono, mi dite come un semplice utente possa mai avvicinarsi al mondo Linux se si trova di fronte a parole o sigle come queste: "kernel, compilare, thread, processo, bug, fix, distribuzioni, 2.4.x, 2.6.x, release, patch, iptables, gentoo, rami, exploit, root, log, crash, scalabilità, lvm, stack di rete, I/O, scheduler, latenza, context switch, pre-emptive, release-candidate, migrazione, nodi, shared memory, consistenza dei dati, ... ma siete tutti amministratori di rete e programmatori?

Per non parlare di termini inglesi maldestramente italianizzati: resettare è forse entrato nel dizionario, ma parole come forkare, patchare, loggare ecc. mi fanno cadere le braccia. Guardatevi questo interessante sito: http://www.attracco.it/orrori.htm

... (anche se spesso la spintarella da parte di qualcuno la ricevono )

I fanatici sono ovunque :rolleyes:


Più che di bug qui si parla di Vulnerabilità 9/10 o falla , cosa impensabile o fuori discussione in un thread dell'anno scorso su eventuali problematiche di Linux...
Ora che il S.O. sta vivendo un momento di grande diffusione e le falle/virus/vulnerabilità sono saltate fuori , il problema si è "diplomaticamente" spostato sulla velocità di correzione di tali falle .... :fiufiu:

E se si pensa che il rapporto di user fra Win/linux è ancora 1000/1 (a essere ottimisti) , si fa presto a fare 2+2...

BTW , dopo aver utilizzato entrambi , non si può non riconoscere che entrambi hanno la loro parte di pregi/difetti... e chi non capisce questo è perchè si ostina a non capirlo...

Originariamente inviato da teogros
Appunto: "doti" che non sono intrinseche alla piattaforma utilizzata!

Intrinseche no...

Ma generalmente non sono uniformemente distribuite :O

Originariamente inviato da Duncan
Intrinseche no...

Ma generalmente non sono uniformemente distribuite :O

:gluglu: :gluglu: :gluglu: :gluglu:

Originariamente inviato da nonikname
UP !!!


Più che di bug qui si parla di Vulnerabilità 9/10 o falla , cosa impensabile o fuori discussione in un thread dell'anno scorso su eventuali problematiche di Linux...
Ora che il S.O. sta vivendo un momento di grande diffusione e le falle/virus/vulnerabilità sono saltate fuori , il problema si è "diplomaticamente" spostato sulla velocità di correzione di tali falle ....

E se si pensa che il rapporto di user fra Win/linux è ancora 1000/1 (a essere ottimisti) , si fa presto a fare 2+2...

BTW , dopo aver utilizzato entrambi , non si può non riconoscere che entrambi hanno la loro parte di pregi/difetti... e chi non capisce questo è perchè si ostina a non capirlo...


Chi l'anno scorso andava dicedo cose del genere non sapeva quello che diceva :D

Anche solo perchè le tecniche di attaco ai sistemi si evolvono e non è detto che il software sritto adesso sia esente da problemi domani...

Per quanto riguarda le discussioni sulla diffusione... beh se fosse vero quello che dici da tempo vederemmo disastri, visto che su internet diversi server usano Linux ;)

Il problema non è essere esente da bug (certo codice scritto bene fin da subito sarebbe meglio ;) ) ma è la gestione della sicurezza che ci gira intorno che fa la differenza tra windows e Linux o meglio... tra il software Closed e quello Open Source ;)

Originariamente inviato da tas
OT - Convinto che tutti quelli che hanno parlato in questa discussione sanno perfettamente quello che dicono, mi dite come un semplice utente possa mai avvicinarsi al mondo Linux se si trova di fronte a parole o sigle come queste

Questo sito si chiama Hardware Upgrade e parla del mondo informatico quindi viene consultato anche da programmatori e amministratori di sistema.
Se il sito fosse stato "ricamo e uncinetto" allora potresti aver ragione.
Ricordo che anche il mondo windows ha all'incirca le stesse definizioni del mondo Linux:
kernel -> kernel
compilare -> compilare
thread,processo -> task
bug -> vulnerabilita'
fix,patch -> update
iptables -> firewall
root -> administrator
log -> visualizzatore eventi
crash -> schermata blu
Gli altri non saprei tradurli perche' non so come ragione il kernel di windows.

Per non parlare di termini inglesi maldestramente italianizzati: resettare è forse entrato nel dizionario, ma parole come forkare, patchare, loggare ecc. mi fanno cadere le braccia. Guardatevi questo interessante sito: http://www.attracco.it/orrori.htm
Hai ragione ma ormai in molti le usiamo senza farci caso. Sara' un ragionamento cinico ma preferisco farmi capire che stare a far giri di parole.

Per quanto riguarda le discussioni sulla diffusione... beh se fosse vero quello che dici da tempo vederemmo disastri, visto che su internet diversi server usano Linux

E' normale usare linux per server con software scritto appositamente per gestire le risorse hw in un determinato modo... (i 64 bit di Win Server 2003 sono lontanamente paragonabili all'efficacia di una distribuzione tarata per una determinata architettura x86-64 ...)
Comunque non parlavo di amministratori di sistema ma di utenza desktop...

Il problema non è essere esente da bug (certo codice scritto bene fin da subito sarebbe meglio ) ma è la gestione della sicurezza che ci gira intorno che fa la differenza tra windows e Linux o meglio... tra il software Closed e quello Open Source

Questo ormai è il tormentone della gestione della sicurezza Open... ma se permetti , la controparte XP , ha fatto enormi passi avanti : vengono rilasciati bugfix su bollettini settimanali , o a necessità , da molto tempo ormai (e quasi tutti riguardano compatibilità con HW o SW appena rilasciati).... senza contare che nell'ambito "automazione" winupdate è anni luce in quanto a facilità d'uso ...

Comunque , come ripeto , ogni S.O. ha i suoi pregi e difetti : non vederli non vuol dire che non esistano .... se poi parli del fatto che win XP è scritto male già in partenza vuol dire che hai visto i sorgenti ...

Pensa che c'è chi dice che XP in alcuni punti sia scritto in basic !! :sofico: ..chissa chi è che tira fuori ste Biscardate!! :rolleyes:

Originariamente inviato da tas
OT - Convinto che tutti quelli che hanno parlato in questa discussione sanno perfettamente quello che dicono, mi dite come un semplice utente possa mai avvicinarsi al mondo Linux se si trova di fronte a parole o sigle come queste: "kernel, compilare, thread, processo, bug, fix, distribuzioni, 2.4.x, 2.6.x, release, patch, iptables, gentoo, rami, exploit, root, log, crash, scalabilità, lvm, stack di rete, I/O, scheduler, latenza, context switch, pre-emptive, release-candidate, migrazione, nodi, shared memory, consistenza dei dati, ... ma siete tutti amministratori di rete e programmatori?
Uè piccola divagazione OT tra me, Afterburner e altri; ecche non si può neanche parlare? :)


Per non parlare di termini inglesi maldestramente italianizzati: resettare è forse entrato nel dizionario, ma parole come forkare, patchare, loggare ecc. mi fanno cadere le braccia. Guardatevi questo interessante sito: http://www.attracco.it/orrori.htm
You'r raight fellow ;)

Originariamente inviato da nonikname
E' normale usare linux per server con software scritto appositamente per gestire le risorse hw in un determinato modo... (i 64 bit di Win Server 2003 sono lontanamente paragonabili all'efficacia di una distribuzione tarata per una determinata architettura x86-64 ...)
Comunque non parlavo di amministratori di sistema ma di utenza desktop...


Anche io mi riferivo anche ai desktop, il mio era solo un esempio per far capire che la diffusione non è direttamente legata al numero di vulnerabilità presenti in un sistema ;)


Questo ormai è il tormentone della gestione della sicurezza Open... ma se permetti , la controparte XP , ha fatto enormi passi avanti : vengono rilasciati bugfix su bollettini settimanali , o a necessità , da molto tempo ormai (e quasi tutti riguardano compatibilità con HW o SW appena rilasciati).... senza contare che nell'ambito "automazione" winupdate è anni luce in quanto a facilità d'uso ...

Comunque , come ripeto , ogni S.O. ha i suoi pregi e difetti : non vederli non vuol dire che non esistano .... se poi parli del fatto che win XP è scritto male già in partenza vuol dire che hai visto i sorgenti ...

Pensa che c'è chi dice che XP in alcuni punti sia scritto in basic !! :sofico: ..chissa chi è che tira fuori ste Biscardate!! :rolleyes:

Distribuzioni come debian, gentoo hanno sistemi di aggiornamento molto potenti, e parlo di queste perchè sono quelle che conosco meglio...

Per quanto riguarda alla gestione della sicurezza, almeno per ora, non credo che il software Closed riesca ad avere l'efficacia del software Open ;)

Anche io mi riferivo anche ai desktop, il mio era solo un esempio per far capire che la diffusione non è direttamente legata al numero di vulnerabilità presenti in un sistema

Come lo si può definire : uovo di Colombo o Acqua calda ?? :D

Distribuzioni come debian, gentoo hanno sistemi di aggiornamento molto potenti, e parlo di queste perchè sono quelle che conosco meglio...

Per quanto riguarda alla gestione della sicurezza, almeno per ora, non credo che il software Closed riesca ad avere l'efficacia del software Open

E fu così che il muto e il sordo disquisirono per ore ;)

Originariamente inviato da tas
OT - Convinto che tutti quelli che hanno parlato in questa discussione sanno perfettamente quello che dicono, mi dite come un semplice utente possa mai avvicinarsi al mondo Linux se si trova di fronte a parole o sigle come queste: "kernel, compilare, thread, processo, bug, fix, distribuzioni, 2.4.x, 2.6.x, release, patch, iptables, gentoo, rami, exploit, root, log, crash, scalabilità, lvm, stack di rete, I/O, scheduler, latenza, context switch, pre-emptive, release-candidate, migrazione, nodi, shared memory, consistenza dei dati, ... ma siete tutti amministratori di rete e programmatori?


un semplice utente che si vuole avvicinare a linux può prendere la sua Mandrake o SuSe o quel che è, installarsela e al max smadonnare se qlc periferica non và; non è obbligato ad imparare tutta quella terminologia ( che per altro, una volta imparata fine a sè stessa non serve a niente...è come recitare un rosario senza capire il significato di quello che dici).

Poi + vai in profondità e + hai bisogno di impadronirti di un certo linguaggio specifico, che però è indipendente dalla piattaforma ( quasi sempre) che utilizzi.

Il kernel c'è in linux come Win o come MacOS, bug fix pure, exploit, processi, crash, log, patch, scalabilità ecc. ecc. ecc.
Sn concetti universali nell'Informatica.

Se uno vuole andare in profondità, possibilità ne ha quante ne vuole, in primis, gratuitamente, sfruttando la rete.



Sinceramente non capisco il succo del tuo discorso...

Allora un paio di precisazioni sparse:
il kernel 2.6.x nella sua versione "core" e' stato
tra gli altri motivi, per migliorare lo scheduling
(VITALE sui servers) attraverso uno scheduler tutto
nuovo. Il fatto che una qualsiasi distribuzione Linux
abbia kernel vecchi non significa nulla, sotto qualsiasi distribuzione si puo' aggiornare il kernel
(2.4.x passa a 2.4.y , 2.6.x passa a 2.6.y) e con alcuni accorgimenti si puo' pure cambiare il kernel
da 2.4 a 2.6 , basta leggere i consigli in rete e smanettare (ricordandosi di tenere salvato il vecchio
kernel, per ogni evenienza).

Tutta sta storia nasce dal fatto che i kernels Suse
non hanno aggiunto una patch ESSENZIALE fino al 2.6.8,
mentre altre distribuzioni potrebbero averla inserita gia' nella 2.6.2 o .3 , nulla piu'.

Originariamente inviato da nonikname
Come lo si può definire : uovo di Colombo o Acqua calda ?? :D



E fu così che il muto e il sordo disquisirono per ore ;)

ahahah :D

Originariamente inviato da ilsensine
You'r raight fellow ;)

raight....RAIGHT???? right...dimmi che ti sei sbagliato apposta...

Originariamente inviato da Duncan
Beh la seconda mi pare che risponda alla prima osservazione ;)
In effetti sono intimamente connesse... :D

Originariamente inviato da uovobw
raight....RAIGHT???? right...dimmi che ti sei sbagliato apposta...
No e' inglisch puro, qual'è il problema? :confused:

:p

Originariamente inviato da afterburner
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.
Sì, ma ilsensine t'ha già detto che il kernel 2.6 non è affato paragonabile al 2.4, anche se gli togli tutte quelle "porcherie".
Poi il lavoro di sistemazione del kernel lo fai una volta, e te lo usi per tutti i sistemi.
Penso per due motivi:
- il testing migliore viene fatto dalla massa della gente. E' pero' stupido mettere un nuovissimo kernel su un prodotto enterprise.
Allora non lo si fa uscire, questo nuovo kernel. La comunutà Linux è molto diffusa, e ci sono parecchi beta-tester: basta aspettare che finisca il loro lavoro, no? ;)
- 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.
Beh, tu stai parlando delle gestione dei dispositivi, che seppur di competenza dell'area kernel, non fa certo parte del kernel vero e proprio: è il secondo strato della "cipolla"... :D
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.
Appunto. Ma se il kernel 2.6 è stato realizzato per i server, allora perché dovremmo provarlo prima sui desktop? Sui desktop non te ne faresti niente delle sue nuove caratteristiche, per cui potresti benissimo continuare a usare il 2.4.
Sono proprio le aziende che hanno dei server da gestire che hanno tutto l'interesse ad aggiornare i loro sistemi col 2.6, per cui a me sembra giusta la scelta che ha fatto SuSE, pur con i problemi che ha avuto.
IMHO, ovviamente. ;)

Originariamente inviato da Duncan
ahahah :D

:rotfl: :rotfl: :rotfl: :rotfl: :rotfl: :rotfl:

Originariamente inviato da midian
:rotfl: :rotfl: :rotfl: :rotfl: :rotfl: :rotfl:


:confused:

Originariamente inviato da cdimauro
Sui desktop non te ne faresti niente delle sue nuove caratteristiche
Dici tu... ;)
Solo per fare un paio di esempi -- il 2.4 ha delle limitazioni anche in campo desktop (ad es. masterizza i cd audio in PIO); inoltre, il 2.6 ha un supporto migliore per il sata ed altre periferiche.
C'è tanta roba dentro il 2.6, per tutti i campi di applicazione...

Originariamente inviato da Duncan
:confused:

era x questa battuta:

Originariamente inviato da nonikname
Come lo si può definire : uovo di Colombo o Acqua calda ??



E fu così che il muto e il sordo disquisirono per ore

Ora ho capito :sofico: :p :D

Originariamente inviato da cdimauro
Beh, tu stai parlando delle gestione dei dispositivi, che seppur di competenza dell'area kernel, non fa certo parte del kernel vero e proprio: è il secondo strato della "cipolla"... :D

Non vorrei che per fare il secondo strato della cipolla bello e succulento si finisca col far marcire lo strato interno :O

Appunto. Ma se il kernel 2.6 è stato realizzato per i server, allora perché dovremmo provarlo prima sui desktop? Sui desktop non te ne faresti niente delle sue nuove caratteristiche, per cui potresti benissimo continuare a usare il 2.4.
Sono proprio le aziende che hanno dei server da gestire che hanno tutto l'interesse ad aggiornare i loro sistemi col 2.6, per cui a me sembra giusta la scelta che ha fatto SuSE, pur con i problemi che ha avuto.
IMHO, ovviamente. ;)

Continuo a sostenere che del kernel 2.6 se ne avvantaggia di piu' l'ambiente desktop che quello enterprise. E' l'ambiente desktop che ha bisogno del supporto alle ultimissime periferiche e di un hotplug valido (leggasi usb2 e firewire, non hotplug scsi).
Continuo a leggere post che sostengono il 2.6 sia un kernel realizzato per i server ma allora perche' la RedHat con la Enterprise continua con i kernel 2.4 e soprattutto perche' Oracle 10g e' certificato per distribuzioni con kernel 2.4?

Originariamente inviato da ilsensine
Dici tu... ;)
Solo per fare un paio di esempi -- il 2.4 ha delle limitazioni anche in campo desktop (ad es. masterizza i cd audio in PIO); inoltre, il 2.6 ha un supporto migliore per il sata ed altre periferiche.
C'è tanta roba dentro il 2.6, per tutti i campi di applicazione...
Come non detto. :) D'altra parte, se non ricordo male, c'è voluto più di un anno per passare dal 2.4 al 2.6, per cui le differenze non si potevano restringere solamente al lato server.
Che dire: è un must per qualunque ambito applicativo. :)

Originariamente inviato da afterburner
Continuo a sostenere che del kernel 2.6 se ne avvantaggia di piu' l'ambiente desktop che quello enterprise. E' l'ambiente desktop che ha bisogno del supporto alle ultimissime periferiche e di un hotplug valido (leggasi usb2 e firewire, non hotplug scsi).

Aggiungo inoltre che molte caratteristiche pensate per campo server, portano beneficio anche in campo desktop. Basti pensare alle ridotte latenze e alla superiore frequenza di context switch (che per la verità è un'arma a doppio taglio, se usata senza grano salis).

Originariamente inviato da cdimauro
Che dire: è un must per qualunque ambito applicativo. :)
Tranne per i sistemi a sicurezza critica, dove è preferibile un kernel ben più rodato -- altrimenti saltano fuori queste sorprese ;)

Originariamente inviato da afterburner
Non vorrei che per fare il secondo strato della cipolla bello e succulento si finisca col far marcire lo strato interno :O
Beh, questo dipende dalla bravura e dalla lungimiranza dei programmatori, oltre che da una buona preparazione in ingegneria del software. ;)
Continuo a sostenere che del kernel 2.6 se ne avvantaggia di piu' l'ambiente desktop che quello enterprise. E' l'ambiente desktop che ha bisogno del supporto alle ultimissime periferiche e di un hotplug valido (leggasi usb2 e firewire, non hotplug scsi).
Continuo a leggere post che sostengono il 2.6 sia un kernel realizzato per i server ma allora perche' la RedHat con la Enterprise continua con i kernel 2.4 e soprattutto perche' Oracle 10g e' certificato per distribuzioni con kernel 2.4?
Non chiederlo a me, ma a loro. Mi sembra che ilsensine abbia dato un quadro abbastanza chiaro della situazione: il 2.6 ha tante migliorie sia per il lato server sia per il lato client. Per cui rappresenta il passo "obbligato" da seguire per tutti.

Originariamente inviato da ilsensine
Tranne per i sistemi a sicurezza critica, dove è preferibile un kernel ben più rodato -- altrimenti saltano fuori queste sorprese ;)
Vorresti dire che il 2.6 non è stato abbastanza "rodato"? ;)
A parte gli scherzi, condivido in pieno. :) In questo settore una falla delle genere vuol dire compromettere ciò per cui il sistema è nato.

Originariamente inviato da cdimauro
Non chiederlo a me, ma a loro. Mi sembra che ilsensine abbia dato un quadro abbastanza chiaro della situazione: il 2.6 ha tante migliorie sia per il lato server sia per il lato client. Per cui rappresenta il passo "obbligato" da seguire per tutti.
Bè ho comunque aspettato il 2.6.8.1 per installarlo, sia su desktop che su server. Ho comunque ancora preferito delle soluzioni relativamente conservative (no allo stack 4k, kernel preemption disabilitato per i sistemi server). E' un giocattolo potente, ma non bisogna farsi tentare.
Ormai lo uso da diverso tempo, l'ho installato anche sui sistemi embedded su cui sviluppo, e ritengo che _ora_ sia ragionevolmente maturo per parlare di una diffusione di massa (ad eccezione dei sistemi che ho citato).
Ora è arrivato il 2.6.9, con qualche passo indiero rispetto al predecessore...vabbè ci speravo quasi... :rolleyes:

Originariamente inviato da ilsensine
no allo stack 4k, kernel preemption disabilitato per i sistemi server
E' un giocattolo potente, ma non bisogna farsi tentare.
Ora è arrivato il 2.6.9, con qualche passo indiero rispetto al predecessore...vabbè ci speravo quasi... :rolleyes:

Perchè di queste affermazioni? niente polemica, vorrei sapere solo le motivazioni.

Originariamente inviato da ilsensine
Bè ho comunque aspettato il 2.6.8.1 per installarlo, sia su desktop che su server.
Io ce l'ho installato da una settimana, ma non mi parte... :asd:
Ho comunque ancora preferito delle soluzioni relativamente conservative (no allo stack 4k, kernel preemption disabilitato per i sistemi server). E' un giocattolo potente, ma non bisogna farsi tentare.
Come per tutte le cose, bisogna saperle usare. Comunque, prima o poi mi aggiornerò anche su questo. ;)
Ora è arrivato il 2.6.9, con qualche passo indiero rispetto al predecessore...vabbè ci speravo quasi... :rolleyes:
Tipo?

Originariamente inviato da Hal2001
Perchè di queste affermazioni? niente polemica, vorrei sapere solo le motivazioni.
Quale esattamente?
Riguardo al 2.6.9, ci sono state un paio di regression che non mi sono piaciute (in particolare ad es. una certa "virulenza" dell'OOM killer, in sistemi non particolarmente potenti e sotto pressione di memoria -- incredibilmente sfuggito ai test dell'osdl). Nulla di serio, intendiamoci, ma dopo la bella sorpresa del 2.6.8.1, mi aspettavo un consolidamento dell'affidabilità raggiunta (e l'apertura del ramo 2.7 -- questo lo stanno chiedendo diverse voci).