# [Discussione] Sviluppo del kernel: c'è qualcosa che non va

## GhePeU

http://www.ussg.iu.edu/hypermail/linux/kernel/0408.2/0441.html

 *Quote:*   

> 
> 
> [...]
> 
> If Linux believes that there should be enhanced security similar to Solaris and
> ...

 

questa email, di cui riporto la parte IMHO più significativa, è stata scritta da Jörg Schilling, lo sviluppatore di cdrecord, probabilmente la più importante e diffusa applicazione per masterizzare usata nei sistemi unix

personalmente, e con me moltissimi altri utenti, ho avuto molti problemi nella masterizzazione dei cd dopo aver aggiornato il kernel all'ultima release "stable" 2.6.8, e sono stato obbligato a girare per mailing list e bugzilla vari cercando di scoprire cosa fosse successo; riassumendo, nel passaggio dal 2.6.8 rc4 al 2.6.8 è stato introdotto un nuovo modello di sicurezza che ha provocato seri problemi a cdrecord e ad alcuni suoi frontend (anche molto diffusi, come k3b)

so che schilling ha avuto altre "questioni" con gli sviluppatori del kernel e che non ama particolarmente linux, ma in questo caso mi sento di dire che ha pienamente ragione, non è possibile che un cambiamento tanto importante sia introdotto così di punto in bianco, senza preavvertire almeno gli sviluppatori delle applicazioni più importanti.

niente di così grave, non dubito che ci sarà una soluzione in arrivo entro breve, ma visto che più o meno lo stesso si era ripetuto con lm-sensors qualche mese fa, la mia sensazione è che i "kernel hackers" comincino a dimenticarsi che il kernel da solo non serve a niente... e comincino a dimenticare anche che un minimo di dialogo con gli altri sviluppatori è necessario

----------

## Cagnulein

condivido però mi tocca aggiungere un paio di cosette. 

Stiamo parlando del kernel 2.6.8.1 che è come dice il portage un sorgente in corso di sviluppo e quindi non viene utilizzato "sul lavoro", ma bensì deve essere testato da appassionati e non.

Bene, questi appassionati possono sia essere come me gente che ha voglia di scoprire quali potenzialità stanno dietro a nuove release, ma possono e SONO gente che sviluppa programmi che girano su di esso.

Per me (e direi non solo per me) il kernel è la radice di tutto, e l'albero che soprastante deve adattarsi di conseguenza....

Ricapitolando, io immagino che un miglior rapporto tra sviluppatori-kernel e sviluppatori-programmigenerale dovrebbe esserci, ma non vedo dall'altra parte, neanche tutto questo dramma..in fondo lo si sa che installando una nuova versione del kernel qualcosa potrebbe non andare  :Wink: 

chiaramente questa è la mia opinione  :Smile: 

----------

## randomaze

 *GhePeU wrote:*   

> so che schilling ha avuto altre "questioni" con gli sviluppatori del kernel e che non ama particolarmente linux, ma in questo caso mi sento di dire che ha pienamente ragione, non è possibile che un cambiamento tanto importante sia introdotto così di punto in bianco, senza preavvertire almeno gli sviluppatori delle applicazioni più importanti.
> 
> 

 

Questo peró equivale a definire cosa sono le "applicazioni piú importanti", e chi deve avvisare cosa... Linus dovrebbe avvisare Gnome e KDE che comunicano a xcdroast e k3b che comunicano con cdrecord?

Oppure il contrario?

Sinceramente trovo che la via di "avvisare" possa generare non pochi casini... meglio se Linus apre il ramo 2.7 e lo usa, come é sempre stato, per il testing delle nuove feature

----------

## randomaze

 *Cagnulein wrote:*   

> condivido però mi tocca aggiungere un paio di cosette. 
> 
> Stiamo parlando del kernel 2.6.8.1 che è come dice il portage un sorgente in corso di sviluppo e quindi non viene utilizzato "sul lavoro", ma bensì deve essere testato da appassionati e non.

 

Non concordo. Stiamo parlando di un kernel con subversion pari, quindi si parla di un qualcosa che "dovrebbe essere stabile e testato", a meno di qualche errore di gioventù (cosa normale ed acettabile quando arriva una nuova subversion).

Tuttavia la gioventù del 2.6 mi sembra veramente molto lunga...

Certo, qualcuno potrebbe aver deciso di cambiare modello di sviluppo e quindi invalidare la regoletta del pari e dispari. Beh, basta che lo dica, altrimenti dovrebbe rispettarla!

----------

## GhePeU

il 2.6.8.1 è "development" solo per il portage, se vai su www.kernel.org risulta "stable", e la serie 2.4 già da qualche settimana è stata ufficialmente accantonata e d'ora in avanti non comprenderà più nuove features ma solo aggiornamentti di sicurezza e bugfix, esattamente come la 2.2 e la 2.0.

la maggior parte delle distro prevede il 2.6 già da mesi e nel giro di pochi mesi la maggior parte dei pc linux desktop userà kernel della serie 2.6, a questo punto non è accettabile che il modello di accesso alle periferiche scsi venga rivoluzionato passando da una rc4 a una final

si sa che "qualcosa può non andare", ma qui si parla di una modifica, per quel che ne so  neppure passata nel tree -mm, che ha fatto smettere improvvisamente di funzionare il software di masterizzazione usato dal 95% degli utenti e il suo frontend più completo e diffuso

----------

## Cagnulein

avete ragione...sarà perchè noi al lavoro (non gestisco io il server) abbiamo ancora il 2.4 e quindi vedo ancora il 2.6 come un qualcosa di nicchia...

----------

## GhePeU

 *randomaze wrote:*   

> 
> 
> Questo peró equivale a definire cosa sono le "applicazioni piú importanti", e chi deve avvisare cosa... Linus dovrebbe avvisare Gnome e KDE che comunicano a xcdroast e k3b che comunicano con cdrecord?
> 
> Oppure il contrario?
> ...

 

sarebbe bastata un'email a schilling... le dipendenze di cdrecord sono queste:

DEPEND="virtual/libc"

finito. non si sta parlando di un'applicazione che dipende da un'altra che dipende da un'altra, ma di qualcosa che sta appena sopra il kernel.

bene o male, se domani si decidesse di rivoluzionare da un giorno all'altro (perchè questo è successo) la gestione delle periferiche agp qualcuno dovrebbe pensare di mandare un'email agli sviluppatori di xorg... o si pensa di aspettare che qualche decina di migliaia di utenti dopo aver aggiornato si trovino con X che non parte più?

----------

## randomaze

 *GhePeU wrote:*   

> la gestione delle periferiche agp qualcuno dovrebbe pensare di mandare un'email agli sviluppatori di xorg... 

 

Beh, pur non condividendo la licenza direi che in quel caso bisognerebbe avvisare anche i tizi di XFree, e quelli di NVidia, ATI, VIA... magari anche quelli degli X server commerciali, poi non dimentichiamo che forse anche SDL, DRI, DirectFB potrebbero avere dei problemi....

Oltretutto al momento gli utenti di cdrecord hanno riscontrato dei problemi, ma sei sicuro che sia la sola applicazione che ha smesso di funzionare?

Non discuto che è stata una mossa sbagliata, tuttavia continuo a pensare che il ramo di sviluppo sarebbe la cosa migliore, inviare mail potrebbe generare casini, e chi viene "dimenticato" avrebbe ragione di arrabbiarsi anche se la sua applicazione ha un modesto share del 1%

----------

## n3m0

 *randomaze wrote:*   

> continuo a pensare che il ramo di sviluppo sarebbe la cosa migliore, inviare mail potrebbe generare casini, e chi viene "dimenticato" avrebbe ragione di arrabbiarsi anche se la sua applicazione ha un modesto share del 1%

 

Sono d'accordissimo. Per queste virate brusche ci vuole il ramo unstable su cui testare e poi, eventualmente, backportare.

Non si può pretendere di fare modifiche del genere senza pensare alle conseguenze. Che ce ne facciamo di un nuovo kernel, per quanto migliorato che possa essere, se poi vengono a mancare le apps?

Sinceramente, la mossa non mi è piaciuta affatto. Era evitabilissima.

----------

## midall

Scusate ma io di casini non ne vedo o meglio..

se si parla di dare maggiore maturità alla serie 2.6 del kernel gli sviluppatori ce la stanno mettendo tutta e se questa features, che ha fatto incazzarre 

schilling, servirà per dare maggiore rosbustezza/sicurezza/velocità al kernel ben venga...

Ricordiamoci che poco tempo fa quando venne inserito l'opzione dei 4stacks nel kernel i driver nvidia non funzionavano + ma dopo poco tempo gli sviluppatori NVidia hanno "buttato" fuori una release compatibile con i 4stacks.. 

Quindi se schilling al posto di perdere tempo ad incazzarsi si fosse subito messo al lavoro per una nuova versione di cdrecord ora noi avremmo un kernel aggiornato ed un programma di masterizzazione funzionante.. 2 piccioni con un fava!!!

----------

## n3m0

 *midall wrote:*   

> se questa features, che ha fatto incazzarre 
> 
> schilling, servirà per dare maggiore rosbustezza/sicurezza/velocità al kernel ben venga...

 

Le features che pongono cambiamenti sostanziali e/o radicali devono passare per una fase di testing e vanno rilasciate le specifiche di tali modifiche prima della loro release stable per permettere agli sviluppatori delle applicazioni del livello sovrastante di mettersi al passo.

 *midall wrote:*   

> Ricordiamoci che poco tempo fa quando venne inserito l'opzione dei 4stacks nel kernel i driver nvidia non funzionavano + ma dopo poco tempo gli sviluppatori NVidia hanno "buttato" fuori una release compatibile con i 4stacks..

 

Ricordiamoci che quel parametro era configurabile e bastava compilare il kernel in modalità compatibile coi driver nVidia e tutto andava ok. 

La questione ora è diversa.

 *midall wrote:*   

> Quindi se schilling al posto di perdere tempo ad incazzarsi si fosse subito messo al lavoro per una nuova versione di cdrecord ora noi avremmo un kernel aggiornato ed un programma di masterizzazione funzionante.. 2 piccioni con un fava!!!

 

Punto 1: se pensi che sia così facile perchè non lo modifichi tu?

Punto 2: l'applicazione di Schilling potrebbe non esseer l'unica a soffrire del cambiamento, quindi il problema resta

Punto 3: agli sviluppatori del kernel non costava niente rendere note le loro intenzioni in tempo utile affinchè tutti i developers interessati si potessero mettere al passo senza doversi spezzare l'osso del collo perchè ci sono persone come te che pretendono di avere tutto subito e pronto, come se i developers fossero i loro schiavi.

----------

## randomaze

 *n3m0 wrote:*   

> agli sviluppatori del kernel non costava niente rendere note le loro intenzioni in tempo utile affinchè tutti i developers interessati si potessero mettere al passo senza doversi spezzare l'osso del collo

 

Aggiungo che i soliti developers potrebbero essere dei volontari, che dedicano parte del loro tempo libero allo sviluppo dei programmi open.

E che oggi avrebbero potuto andare al mare a giocare con i figli invece di cercare soluzioni urgenti...

----------

## Cazzantonio

 *randomaze wrote:*   

> 
> 
> Aggiungo che i soliti developers potrebbero essere dei volontari, che dedicano parte del loro tempo libero allo sviluppo dei programmi open.
> 
> E che oggi avrebbero potuto andare al mare a giocare con i figli invece di cercare soluzioni urgenti...

 

Questo è più che vero... comunque bisogna anche ammettere che ormai linux è diventato troppo grosso per poter essere considerato ancora un hobby di pochi appassionati (se funziona bene, sennò ci siamo divertiti lo stesso a provare)

Intorno ci gira un mondo troppo vasto perchè si possa dire che comunque gli sviluppatori non sono tenuti a sviluppare nulla...

Per dire che l'opensource è un modello davvero di successo bisogna metterlo a confronto con le dimensioni reali di un ambiente in crescita... altrimenti godiamoci il nostro prodotto di nicchia ma non speriamo di arrivare mai ad intaccale la supremazia di colossi come microsoft.... loro si fanno pagare e producono un prodotto che, male, ma funziona. Se noi non siamo capaci di fare di meglio e free è inutile farsi tante seghe mentali sul futuro dell'opensource

----------

## codadilupo

 *Cazzantonio wrote:*   

> Per dire che l'opensource è un modello davvero di successo bisogna metterlo a confronto con le dimensioni reali di un ambiente in crescita... altrimenti godiamoci il nostro prodotto di nicchia ma non speriamo di arrivare mai ad intaccale la supremazia di colossi come microsoft.... loro si fanno pagare e producono un prodotto che, male, ma funziona. Se noi non siamo capaci di fare di meglio e free è inutile farsi tante seghe mentali sul futuro dell'opensource

 

e qui siamo al solito dilemma:

un prodotto, é meglio:

- free, ma scarso

- proprietario, ma scarso

- free e ottimo

- proprietario e ottimo

 :Question: 

ai real-coders, anche proprietario, purché sia ottimo; i "poveri illusi" lo vogliono libero, anche se fa meno, e peggio; gli GNUcchi ( :Laughing: ) insistono a dire che, per il solo fatto che é libero, fa anche di piu' e meglio del proprietario; e, infine, i piccoli giocatori di monopoli, che lo vogliono proprietario e sperano diventi una killerapplication.... a ognuno il suo, ragazzi ... ma non c'entra nulla, imho, con il problema del come si devono introdurre le modifiche radicali  :Wink: 

Coda

P.S.: io sono un povero illuso  :Wink: 

----------

## Cazzantonio

 *codadilupo wrote:*   

> 
> 
> P.S.: io sono un povero illuso 

 

Anche io mi considero un povero illuso... 

Non voelvo criticare in alcun modo l'operato degli sviluppatori del kernel verso i quali anzi mi considero in debito

Volevo solo dire che per quanto bello sia l'opensource, se ci si blocca in piccole inefficenze di comunicazione difficilmente possiamo sperare di fare tanto meglio di questo livello attuale

----------

## GhePeU

 *midall wrote:*   

> 
> 
> Quindi se schilling al posto di perdere tempo ad incazzarsi si fosse subito messo al lavoro per una nuova versione di cdrecord ora noi avremmo un kernel aggiornato ed un programma di masterizzazione funzionante.. 2 piccioni con un fava!!!

 

questa mi sembra la cosa più ingenerosa che si possa dire. questa feature è stata introdotta praticamente "di sorpresa", e non in una rc, ma nella final, quella che il 90% della gente scarica e installa

dai un'occhiata a questo link, e controlla le date: http://bugs.kde.org/show_bug.cgi?id=87211

sebastian trueg, che è il mantainer di k3b, sabato sera e domenica mattina era lì a cercare di capire insieme ad altri utenti perchè il programma avesse smesso di funzionare

cose come questa, e cose come le informazioni comparse sulla mailing list del kernel, le patch scritte al volo per ripristinare la situazione precedente, quelle in via di sviluppo (anche da parte di persone che normalmente non lavorano sul kernel) per consentire di masterizzare anche agli utenti comuni (vedere il thread http://www.ussg.iu.edu/hypermail/linux/kernel/0408.2/0025.html ) mi rendono felice, ma mi viene anche da pensare che proporre la modifica, mappare i comandi da accettare e quelli da rifiutare e solo dopo introdurre effettivamente il nuovo modello, magari nella 2.6.9 rc1, sarebbe stata la cosa migliore

----------

## .:deadhead:.

mah... sti benedetti fijoli devono parlarsi d+, e capire che cooperare fa bene a tutti, e ficcarsi un po' del loro ego dove non batte il sole... x fortuna di kernel ce ne è uno solo...Già fanno i fork dei fork dei fork per i programmi normali, figuratevi voi se i kernel hacker iniziassero a fare le bambine capricciose... Davvero l'unica cosa che sarebbe da chiedersi è cosa aspettano lor signori ad aprire il ramo 2.7  :Question:   :Question: 

----------

## n3m0

 *Cazzantonio wrote:*   

> ormai linux è diventato troppo grosso per poter essere considerato ancora un hobby di pochi appassionati (se funziona bene, sennò ci siamo divertiti lo stesso a provare)

 

D'accordo. Proprio per questo non si possono permettere di farsi venire i capricci per ficcare dentro il kernel una feature che introdotta così a volo non serve proprio a niente. Se avessero avvisato, anche il loro lavoro sarebbe stato più fruttuoso, poichè i software sarebbero già stati pronti a supportare le modifiche imminenti.

E invece hanno perso solo tempo, IMHO.

 *Cazzantonio wrote:*   

> Intorno ci gira un mondo troppo vasto perchè si possa dire che comunque gli sviluppatori non sono tenuti a sviluppare nulla...

 

Ti posso dare ragione, ma in parte. Ciò che dici non vale per tutto.

Dietro al kernel di Linux ormai c'è l'OSDL. Tutti si aspettano grandi cose, tutti premono per grandi cose.

Linux è ormai ammiccato maliziosamente dalle grandi aziende.

Ma c'è ancora software che non gode di questo occhio "di riguardo" e che nonostante tutto per un utente normale è vitale. E credo che il software di Schilling sia tra questi.

----------

## antenore

Scusate, ma mi sembra che vi stiate perdendo due pezzi importanti...

1. Vuoi essere aggiornato su cosa accade nello sviluppo del kernel?

Iscriviti alla ml del kernel!!!

Lì c'è scritto tutto...

Il kernel è del ramo stable, ma è giusto che venga testato, è normale che vengano fuori delle schifezzine   :Very Happy: 

Gli sviluppatori del kernel devono preoccuparsi di fare un buon lavoro e non di far sapere a tutto il mondo, con mail dirette, che stanno facendo delle modifiche sostianziali. Ti scarichi gli archivi della ml e te la leggi!!!

2. Quali sono i software principali?   :Shocked: 

Di applicazioni ce ne sono migliaia, occorrerebbe avvisare tutti, no 10 a scelta. 

GNU/Linux è bello perchè è vario!!!

Hai il tuo kernel e poi quello che vuoi tu!!! Anche null'altro!!!

Un'applicazione non funziona? Sbattiti e stai tranquillo che anche qualcun'altro si sbatterà per risolvere il problema.

Ultima notina... Se si vuole una scatolina chiusa in cui tutto funziona come in un orologio svizzero... Beh allora ci sono altri sistemi operativi, dove il confine tra kernel e applicazione è quasi inesistente.

[/b]

----------

## Cazzantonio

 *antenore wrote:*   

> 
> 
> 1. Vuoi essere aggiornato su cosa accade nello sviluppo del kernel?
> 
> Iscriviti alla ml del kernel!!!
> ...

 

Ok, ma siccome questa nuova feature è stata introdotta all'improvviso difficilmente anche avendolo saputo il giorno prima ci si sarebeb potuto fare qualcosa

In ogni caso il kernel da solo serve a ben poco... se si pensa che lo sviluppo del kernel possa procedere per strade non concordate con gli sviluppatori delle applicazioni allora si pensa male a mio giudizio

E poi le applicazioni principali è semplice individuarle... sono convinto che sia la mia che la tua gentoo condividono un buon 70% di applicazioni, e questo vale per qualsiasi distribuzione linux; quelle sono le applicazioni principali....

----------

## n3m0

 *antenore wrote:*   

> 1. Vuoi essere aggiornato su cosa accade nello sviluppo del kernel?
> 
> Iscriviti alla ml del kernel!!!

 

Tutto quanto stato detto (almeno da me), è stato fatto ipotizzando, ovviamente, l'iscrizione alla ML.

Ma, per quanto mi risulta, sta feature è apparsa dal nulla nella 2.6.8 final. Non c'era nemenno nelle RC!  :Shocked: 

 *antenore wrote:*   

> Il kernel è del ramo stable, ma è giusto che venga testato

 

Appunto. Venga testato. Sta cosa non è stata testata (o meglio, di sicuro non è stata testata in un contesto di applicazioni ampio, il che equivale, IMHO, a non averla testata). E' stata rilasciata e basta.

 *antenore wrote:*   

> è normale che vengano fuori delle schifezzine

 

Questo è normale quando capita di commettere errori, ed errare è umano. Ma è inacettabile farlo di proposito. Non è che il mondo crollava se loro aspettavano un po' per questa feature e intanto manifestavano apertamente le loro intenzioni.

 *antenore wrote:*   

> Ti scarichi gli archivi della ml e te la leggi!!!

 

Come già detto, non credo che sta cosa sia comparsa nella ML. Finora non ho mai visto una feature comparire da nulla in una final senza passare per le RC.

----------

## midall

 *Quote:*   

> Punto 1: se pensi che sia così facile perchè non lo modifichi tu?
> 
> Punto 2: l'applicazione di Schilling potrebbe non esseer l'unica a soffrire del cambiamento, quindi il problema resta
> 
> Punto 3: agli sviluppatori del kernel non costava niente rendere note le loro intenzioni in tempo utile affinchè tutti i developers interessati si potessero mettere al passo senza doversi spezzare l'osso del collo perchè ci sono persone come te che pretendono di avere tutto subito e pronto, come se i developers fossero i loro schiavi.

 

Punto1: io non penso che sia facile, però per Schlling non è una cosa proibitiva adattarsi ad una nuova features del kernel

Punto2: se non è l'unica applicazione a soffrirne allora anche gli altri si adattino perchè se mettimao in discussione l'operato di Torvalds ed il kenrel allora facciamo il gioco di Microsft a far morire Linux

Punto3: sulla ml del kernel ci sono le modifiche che stanno apportanto allora mi chiedo: visto che non costa niente anche a schlling a leggere le ml del kernel non poteva farlo senzas fare troppe polemiche..

E poi:

 *Quote:*   

> 
> 
> ci sono persone come te che pretendono di avere tutto subito e pronto, come se i developers fossero i loro schiavi

 

io non pretendo niente date che sono 8 anni che uso linux e con grande entusiasmo ho vosto i passi da gigante che ha fatto..

Molte volte ho aspettato con pazienza ed in "silenzio" le novità o il rilascio di programmi e non ponedomi mai come obbiettivo di avere sempre l'ultimo kernel installato o l'ultima versione di un prg.

Morale se il kernel 2.6.8 introduce ben tante novità da comportare radicali cambiamenti nel normale utilizzo allora aspettimao che i developers si allignino con quello che è il kernel....

Ripeto non facciamo il gioco di M$; non mettiamoci anche noi linuxiani a criticare l'operato di Torvalds e del kernel Team!

----------

## GhePeU

coperti e allineati, si prega di non disturbare il manovratore?

 *Quote:*   

> SG_IO and security Alan Cox (Thu Aug 12 2004 - 08:20:43 EST)
> 
> Linux v2.6.8 Linus Torvalds (Sat Aug 14 2004 - 01:08:05 EST)

 

chiaramente qualcuno ha commesso quantomeno un "errore di valutazione", e non mi sembra ci sia niente di male a dirlo

----------

## n3m0

 *midall wrote:*   

> Ripeto non facciamo il gioco di M$; non mettiamoci anche noi linuxiani a criticare l'operato di Torvalds e del kernel Team!

 

Per me, ha sbagliato.

In fase di RC dovrebbe esserci sia il feature freeze che il code freeze. E quello che fa? fa uscire una final con una feature che non era in RC? Ma per favore. E mo ci stiamo tutti zitti così Torvalds fa quello che gli pare.

Torvalds non è l'essere perfetto. Se sbaglia gli va detto. Le critiche che gli vengono dall'interno della comunità non possono essere altro che costruttive.

----------

## .:deadhead:.

 *midall wrote:*   

> Ripeto non facciamo il gioco di M$; non mettiamoci anche noi linuxiani a criticare l'operato di Torvalds e del kernel Team!

 Mmh   :Rolling Eyes:  le critiche se sono costruttive e servono a migliorare sono come un bugreport, DEVONO essere registrae e poi ci si pensa su...

Indipendentemente dalle esternazioni del tipo di cui sopra, se è stata modificata una parte importante del kernel e nessuno ne sapeva niente, è giusto che glielo si dica a linus.

Non mi piacerebbe arrivare a situazioni tipo il kernel hurd, dove un devel dopo aver criticato alcune scelte di RMS si è visto defenestrato dall'ogi al domani...

Foccalabindella, siamo una comunità, ed una comunità si parla e si discute e se si fanno scelte sbagliate è giusto farlo notare, non per crocefiggere chi le ha fatte ma per evitare di ripeterli.

.:deadhead:.

----------

## n3m0

 *.:deadhead:. wrote:*   

> Non mi piacerebbe arrivare a situazioni tipo il kernel hurd, dove un devel dopo aver criticato alcune scelte di RMS si è visto defenestrato dall'ogi al domani...

 

Non sia mai. RMS è sempre esagerato. 

 *.:deadhead:. wrote:*   

> siamo una comunità, ed una comunità si parla e si discute e se si fanno scelte sbagliate è giusto farlo notare, non per crocefiggere chi le ha fatte ma per evitare di ripeterli.

 

Ipse dixit.

----------

## X-Drum

bah nulla d nuovo,

non è la prima volta che Schilling si comporta in questo modo:

ogni volta che linux (inteso come kernel ovviamente) va in una direzione che a suo dire non è quella migliore, si rivolge ai diretti interessati in maniera un po brusca.....che ci volete fare è carattere  :Razz: 

cmq vi ricordo:

 Schilling vs ide-scsi

 Schilling vs dvd patch su cdrecord

...e in quei casi aveva ragione,anche se forse è un po "brusco" nell'esporre le proprie idee

----------

## .:deadhead:.

vi posto un messaggio che ho trovato su un ng che potrebbe chiarire un po' le cose. L'ID del post è questo pan.2004.08.18.10.18.15.102871@skullkrusher.net

L'Andrew di cui si parla è Andrew Morton, mantainer della serie -mm del kernel

 *it.comp.os.linux.software wrote:*   

> 
> 
> For those who weren't here, the basic scoop is this:
> 
> - 2.6 is doing great, despite the fact that (by Andrew's reckoning) some
> ...

 

----------

## randomaze

 *.:deadhead:. wrote:*   

> L'Andrew di cui si parla è Andrew Morton, mantainer della serie -mm del kernel

 

E' anche il manutentore della 2.6 ufficiale.

 *it.comp.os.linux.software wrote:*   

> 
> 
> Andrew's vision, as expressed at the summit, is that the mainline kernel
> 
> will be the fastest and most feature-rich kernel around, but not,
> ...

 

Devo dire che la cosa non mi piace molto  :Sad: 

----------

## n3m0

 *randomaze wrote:*   

>  *it.comp.os.linux.software wrote:*   
> 
> Andrew's vision, as expressed at the summit, is that the mainline kernel
> 
> will be the fastest and most feature-rich kernel around, but not,
> ...

 

Cioè, se ho capito bene, della serie: "Noi facciamo il kernel, e voi vedete se e' stabile e se non lo e', lo stabilizzate voi"

 :Confused: 

----------

## randomaze

 *n3m0 wrote:*   

> Cioè, se ho capito bene, della serie: "Noi facciamo il kernel, e voi vedete se e' stabile e se non lo e', lo stabilizzate voi" 

 

Si, la ho capita anche io nello stesso modo... posso solo sperare che sia colpa del mio inglese.

----------

## shev

 *randomaze wrote:*   

> posso solo sperare che sia colpa del mio inglese.

 

O che si sia espresso male Andrew o stesse scherzando ed astraendo la frase dal contesto faccia un'altro effetto. O che chi ha riportato la frase l'abbia "aggiustata". Oppure... tristezza...  :Crying or Very sad: 

----------

## motaboy

A parte che credo che quello che ha detto Andrew Morton non sia legato a ció che ha fatto Mr Alan Cox introducendo la patch il giorno prima della release del kernel.

Credo che Mr Morton abbia ragione quando dice che il 2.6 non puó essere il piú stabile possibile visto che se vuoi che la gente testi delle cose allora  devi per forza metterle nel kernel ufficiale e non in quelli di sviluppo. Tanto che piú queste cose sono giá passate nel mm tree. Questa cosa da quello che ho capito non é successa con questa patch sui permessi.

Ed ha ragione quando dice che sono le distribuzioni che devono dare la stabilizzazione finale. Visto che queste (vedi Fedora, Suse, Mandrake e anche Gentoo) mettono 100 patch in un kernel, non credo che una in piú faccia male, per esempio la patch che inverte quella di Alan Cox sui permessi.

Perció io approvo questo modello di sviluppo che ha appunto lo scopo di aumentare la crescita del kernel ed il numero di testers. E poi é proprio questo il bello di linux, ricordatevi che i problemi ci sono ovunque, solo che qua hai la possibilitá di correggerli...

----------

## randomaze

 *motaboy wrote:*   

> A parte che credo che quello che ha detto Andrew Morton non sia legato a ció che ha fatto Mr Alan Cox introducendo la patch il giorno prima della release del kernel.

 

Morton é il manutentore della serie 2.6, ergo la patch di Cox é stata messa perché lui la ha acettata.

 *motaboy wrote:*   

> Credo che Mr Morton abbia ragione quando dice che il 2.6 non puó essere il piú stabile possibile visto che se vuoi che la gente testi delle cose allora  devi per forza metterle nel kernel ufficiale e non in quelli di sviluppo.

 

Non sono assolutamente daccordo, se una cosa é "stabile" equivale a dire che deve essere tale. 

Se con i kernel 2.4 si poteva (anzi, spesso si doveva) aggiornare il kernel alle macchine di produzione ad ogni nuovo rilascio dopo queste affermazioni si capisce che chi ha lasciato la vecchia serie in produzione ha fatto bene.... e fa bene a tenersela stretta.

 *Quote:*   

> Ed ha ragione quando dice che sono le distribuzioni che devono dare la stabilizzazione finale. Visto che queste (vedi Fedora, Suse, Mandrake e anche Gentoo) mettono 100 patch in un kernel, non credo che una in piú faccia male, per esempio la patch che inverte quella di Alan Cox sui permessi.

 

Assolutamente no. Se il kernel di una distro prima poteva rivelarsi instabile in determinate condzioni a causa di una delle 100 patch aggiunte dalla distro adesso potrebbe rivelarsi instabile perché "la distro non ha corretto il bug introdotto dal manutentore del kernel"... e a me sembra una follia.

 *Quote:*   

> ha appunto lo scopo di aumentare la crescita del kernel ed il numero di testers

 

windows insegna dunque.

----------

## motaboy

Secondo me l'errore é di Linus perché é ancora lui il manutentore del 2.6, Morton lo diventerá nel caso aprano il tree di sviluppo. Per adesso Morton mantiene il tree mm che puó essere considerato una specie di sviluppo visto che al suo interno ci sono centinaia di patches che cambiano e anche di molto i comportamenti di alcune parti del kernel.

E comunque a parte questa "cazzata" tutto il resto che hanno fatto é per me molto stabile. Come saprai NORMALMENTE le cose devono passare per il tree mm e quindi sono abbastanza testate.

In un server di sviluppo in cui non ti servono assolutamente USB, Masterizzatori o altre cose multimediali il 2.6 é stabilissimo.

Visto peró che esso deve funzionare anche su un desktop qua la stabilitá dell'ultima versione non credo sia obbligatoria, visto anche che gli utenti desktop sembrano che vogliano spesso l'ultimissima funzione, questo é ció che gli sviluppatori cercano di fare. 

Comunque sono visioni diverse del problema, per adesso questo modello mi sta soddisfacendo visto che ha velocizzato e non di poco l'aumento delle feature del kernel.

Quello di questa patch finita dentro all'ultimo istante credo sia un'episodio sporadico che non capiterá piú visto l'allarmismo che vi si é creato attorno.

----------

## randomaze

 *motaboy wrote:*   

> Secondo me l'errore é di Linus perché é ancora lui il manutentore del 2.6, Morton

 

Comunque é stata una cappellata... al pari dell'NFS che ha obbligato l'uscita immediata del 2.6.8.1

 *Quote:*   

> In un server di sviluppo in cui non ti servono assolutamente USB, Masterizzatori o altre cose multimediali il 2.6 é stabilissimo.

 

Una settimana fa la frase sarebbe stata:

In un server di sviluppo in cui non ti servono assolutamente USB o altre cose multimediali il 2.6 é stabilissimo.

Nel 2.6.9 (o 2.6.8.2) ci sarà da aggiungere qualcos'altro?

 *Quote:*   

> Visto peró che esso deve funzionare anche su un desktop qua la stabilitá dell'ultima versione non credo sia obbligatoria, visto anche che gli utenti desktop sembrano che vogliano spesso l'ultimissima funzione, questo é ció che gli sviluppatori cercano di fare. 

 

Fattibilissimo usando la serie -mm da te citata oppure i 2.7, e non includendo funzioni sperimentali o non testate su qualcosa che mi dicono sia "stabile".

 *Quote:*   

> Quello di questa patch finita dentro all'ultimo istante credo sia un'episodio sporadico che non capiterá piú visto l'allarmismo che vi si é creato attorno.

 

Ribadisco, quella era una cappellata e alle volte capita, ma se l'intenzione é quella di mettere le feature sperimentali nella serie "stabile" per testarle meglio stiamo andando verso un metodo di sviluppo alla Micro$oft, e la cosa non mi piace per nulla.

----------

## motaboy

 *randomaze wrote:*   

> 
> 
> Comunque é stata una cappellata... al pari dell'NFS che ha obbligato l'uscita immediata del 2.6.8.1
> 
> 

 

Grande cappellata.

 *randomaze wrote:*   

> 
> 
> Una settimana fa la frase sarebbe stata:
> 
> In un server di sviluppo in cui non ti servono assolutamente USB o altre cose multimediali il 2.6 é stabilissimo.
> ...

 

 :Laughing: 

 *randomaze wrote:*   

> 
> 
> Fattibilissimo usando la serie -mm da te citata oppure i 2.7, e non includendo funzioni sperimentali o non testate su qualcosa che mi dicono sia "stabile".

 

Vero. 

 *randomaze wrote:*   

> 
> 
> Ribadisco, quella era una cappellata e alle volte capita, ma se l'intenzione é quella di mettere le feature sperimentali nella serie "stabile" per testarle meglio stiamo andando verso un metodo di sviluppo alla Micro$oft, e la cosa non mi piace per nulla.

 

Anch'io spero che non capiti piú e soprattutto mi meraviglio che sia successa da parte di uno come Alan Cox che dovrebbe saperne abbastanza di come si sviluppa un kernel.

----------

## randomaze

 *motaboy wrote:*   

> soprattutto mi meraviglio che sia successa da parte di uno come Alan Cox che dovrebbe saperne abbastanza di come si sviluppa un kernel.

 

Come detto le cappellate capitano... poi Cox potrebbe aver fatto la proposta senza sapere che l'avrebbero messa in produzione un minuto dopo (ma non so...), tra l'altro dato che si parla di un if (almeno a guardare la "contropatch") decisamente può sfuggire faclimente.

BTW la contropatch dovrebbe essere la seguente:

(trovata qui)

```
--- linux-2.6.8/drivers/block/scsi_ioctl.c~   2004-08-16 14:16:57.000000000 +0200

+++ linux-2.6.8/drivers/block/scsi_ioctl.c   2004-08-16 14:36:22.562908552 +0200

@@ -196 +196 @@

-   if (verify_command(file, cmd))

+/*   if (verify_command(file, cmd))

@@ -198 +198 @@

-

+*/

-
```

----------

## MoRPh3uSz

A mio parere, la decisione di rendere il kernel stable (2.6 in questo caso) un po' meno stable a favore di nuove features, lasciando la stabilizzazione alle varie distribuzioni, la dice lunga sul fatto che non è più possibile permettere che linux arrivi in ritardo sulle innovazioni che si susseguono giorno per giorno nel mondo dell'informatica.

Basta pensare all'acpi che nel kernel 2.4 (che abbiamo usato tutti fino alla fine del 2003) era poco supportato, o cmq non supportato per tutte le schede madri quando invece tutte le schede madri degli ultimi 2 anni lo supportavano senza problemi.

Non vedo così tragica la cosa, in fondo basta pensare che non bisogna più scaricare il kernel da kernel.org, ma installare (ricompilando con le features che più ci piacciono) i source del kernel modificati da chi ha in gestione il kernel nelle varie distro; su sistemi di produzione molti già lo fanno, basta pensare al kernel super patchato di una debian stable.

Naturalmente le patch create si interscambiando fra varie distro, visto che si parla di software libero, e poi, una volta che si sa che fanno il loro lavoro a dovere, vanno a finire nel kernel "ufficiale".

Mi sembra poco chiaro il fatto che non è che da oggi in poi nel kernel vanilla si butteranno le patch senza provarle, ma si metteranno patch un po' meno testate; se fra 2 mesi uno viene fuori con una idea che sconvolge decisamente la struttura del kernel e che si renderà necessaria la nascita di un 2.7 penso che ne Linus ne Andrew si faranno tanti scrupoli ad aprire il nuovo ramo.

Ritornando alla patch che ha modificato il comportamento di cdrecord, non è che Alan Cox se la è inventata, ma è stata inserita per coprire un problema di sicurezza (su cui non mi sono informato più di tanto), siccome a me interessa un po' meno la sicurezza nel più stretto termine del significato e e un po' più masterizzare, ho preso i sorgenti, reversato la patch e adesso masterizzo di nuovo senza problemi.

----------

## yardbird

 *MoRPh3uSz wrote:*   

> A mio parere, la decisione di rendere il kernel stable (2.6 in questo caso) un po' meno stable a favore di nuove features, lasciando la stabilizzazione alle varie distribuzioni, la dice lunga sul fatto che non è più possibile permettere che linux arrivi in ritardo sulle innovazioni che si susseguono giorno per giorno nel mondo dell'informatica.
> 
> Basta pensare all'acpi che nel kernel 2.4 (che abbiamo usato tutti fino alla fine del 2003) era poco supportato, o cmq non supportato per tutte le schede madri quando invece tutte le schede madri degli ultimi 2 anni lo supportavano senza problemi.
> 
> Non vedo così tragica la cosa, in fondo basta pensare che non bisogna più scaricare il kernel da kernel.org, ma installare (ricompilando con le features che più ci piacciono) i source del kernel modificati da chi ha in gestione il kernel nelle varie distro; su sistemi di produzione molti già lo fanno, basta pensare al kernel super patchato di una debian stable.
> ...

 

Perfettamente d'accordo. D'altronde è da vari mesi (se non erro addirittura dai tempi delle ultime release 2.5.x) che i kernel dev sostengono che la serie 2.6 è la più stabile da linux 1.2, il che la dice lunga sull'efficacia del "nuovo" metodo di sviluppo.

Poi bisogna intendersi sul significato di stabile. E' ovvio che la serie 2.6.x ha alcuni problemi con device driver più o meno esotici, ma questi sono difetti di "gioventù" che hanno sempre afflitto le prime release delle nuove serie. I driver vanno aggiornati se le API del kernel cambiano, e questo aggiornamento può risultare più o meno lungo e/o indolore. Ciò non toglie che il cuore del 2.6 non solo è "rock-solid", ma anche straccia in performance il 2.4 e i *BSD.

Mi ricordo della gente che si stracciava le vesti quando venne  introdotto NPTL negli ultimi 2.5.x ("Ma come, cambiare il modello di threading così vicini ad un rilascio stabile?"), oppure quando vennero introdotte le modifiche di Andrea Arcangeli alla VM nei primi 2.6 ("Ma come, cambiare la VM nel ramo stabile?"). I fatti hanno poi dato ragione ad Andrew e Linus. 

Far "sedimentare" le nuove feature nel tree -mm mi sembra più efficace che non aprire un nuovo ramo. Poi è chiaro che se si decide di stravolgere la struttura di tutto il kernel occorra passare per un 2.7.x, ma questa eventualità è tutto fuorchè scontata. Addirittura si parla di un ramo 2.7 "a perdere" da usare come sandbox e che potrebbe tranquillamente essere cestinato nel caso le nuove idee si rivelassero inadeguate.

Da una parte è vero che i kernel "di sviluppo" permettono di effettuare cambiamenti drastici, ma dall'altra soffrono di alcuni problemi non indifferenti. Come già detto da qualcuno la base dei tester è piuttosto ridotta. Poi, come si è già verificato nel 2.5.x, molti sviluppatori tendono a procastinare, col risultato di una valanga di patch nelle ultime release di sviluppo e conseguente instabilità delle prime release della serie stabile. Il kernel che esce da un tree di sviluppo, infine, è spesso una bestia completamente diversa dal kernel da cui origina; ciò pone ulteriori difficoltà nel porting dei device drivers, perchè molto spesso gli sviluppatori non hanno tempo/voglia di seguire tutto lo sviluppo del nuovo kernel e si fanno cogliere impreparati.

Infine non capisco chi collega le recenti querelle riguardo NFS e cdrecord con il nuovo modello di sviluppo. Il baco di NFS non è dovuto a qualche feature esotica introdotta all'ultimo momento, è un semplice typo (l'avete vista la patch?). Riguardo cdrecord, come già detto da morpheus è stata una patch introdotta per motivi di sicurezza, quindi dal mio punto di vista perfettamente giustificabile. Poi se uno non riesce a masterizzare va su google e in 2 minuti si trova la patch che riporta tutto come era prima. Francamente non vedo il problema.

Linux non è nato per essere un sistema di "produzione". Il fatto che riesca bene anche in questo è un indice della validità del progetto e della abilità degli sviluppatori. Linux fondamentalmente è nato più come progetto di ricerca accademico, e mantiene ancora molte caratteristiche di questo modello. Lo sviluppo aperto, ma anche la propensione ad evolversi verso qualcosa che non sia solo un clone di Unix (al contrario dei BSD, per esempio).

Io dico che prima di criticare il nuovo modello di sviluppo occorre aspettare. Finora ha funzionato bene secondo me, ma se non andasse non sarebbe un problema aprire un ramo di sviluppo e tornare al vecchio sistema. Linus sa quello che fa. E se combina cazzate rimane sempre il fork  :Smile: .

----------

