Newsgroup: it.comp.os.dibattiti
Titolo: Linux kernel? It's crap!

"I'm sick of the kernel. It's crap. Every release breaks something new,
and every release is as poorly tested as the last. [...] The
stable tree, isn't stable. I want something that works and won't
break."
Parola di uno dei kernel mantainer di Arch Linux:
http://archlinux.org/pipermail/arch-dev-public/2007-May/000562.html
Si veda anche il commento di Eugenia Loli-Queru in merito:
http://eugenia.blogsome.com/2007/05/10/the-truth-about-the-linux-kernel/
SALUTONI,
WindoM


Non avendo una struttura di testing indipendente (no lo sviluppatore non 
sa testare il suo codice) questo e' ovvio. Mi permisi di dirlo circa 8 
anni fa e fui mangiato vivo in questo stesso newsgroup.
Vediamo che succede a distanza di 8 anni.
Saluti,
Bluff
-- 
Work is the curse of the drinking classes.
-Oscar Wilde



Beh quando lo dico io viene fuori
<cite>
BWAHAHAHAHA!!! FUCK THE MAC!!!
</cite>
o simili. Ogni citazione e` (C) dei rispettivi proprietari.
-- 
Sensei <senseiwa at Apple's mac dot com>
Basic research is what I am doing when I don't know what I am doing.
(Wernher von Braun)

 o simili. Ogni citazione e` (C) dei rispettivi proprietari.
A me interesserebbe molto conoscere le opinioni dei sostenitori di
linux sul topic testing. Chi di voi ritiene non necessario il testing
indipendente? Testing indipendente e' quello fatto da un
professionista che non e' lo sviluppatore.
Saluti

 
http://eugenia.blogsome.com/2007/05/10/the-truth-about-the-linux-kernel/
Delirante. Da parecchio l'idea di quella che non sa bene quello di cui
sta parlando. Tipo quando 'difende' MacOS X. Peccato che la difesa sia
sbagliata, non ha la minima idea di come sia fatto il Kernel di OS X (e
non ne ha idea tanto quanto quello che lo 'attacca'). 
Non so se ridere o piangere.
-- 
blog:  
http://www.akropolix.net/rik0/blogs
 | Uccidete i filosofi,
site:  
http://www.akropolix.net/rik0/
      | tenetevi riso e
forum: 
http://www.akropolix.net/forum/
     | bacchette per voi.

 professionista che non e' lo sviluppatore.
Ti aiuto a circostanziare la domanda:
1. parliamo di software 'generalista' oppure di software con parti
altamente specializzate (come un kernel, l'ottimizzatore di un
compilatore)? La risposta è chiarmente diversa nei due caso, in linea di
principio.
2. Parliamo di quello che dovrebbe avvenire, di quello che può avvenire
o di quello che avviene? Vogliamo mettere nell'analisi di quello che
avviene *anche* il software proprietario?
3. Siamo sicuri che qui il punto sia distinguere per licenza piuttosto
che per modalità di sviluppo? Ovvero: siamo sicuri che la piccola
applicazioncina o il piccolo serverino del menga open source segua
effettivamente procedure peggiori del piccolo sharewarino per Windows?
Ricordo che buona parte degli sviluppatori *non* sanno quali sono delle
buone procedure. Sono praticoni tirati su con VB o con PHP che si
arrangiano come possono.
D'altra parte i team di professionisti che sono alla base di determinati
software open *non* sono affatto peggiori di quelli alla base di
determinati sw closed. 
Per cui la differenza è fra i team e le metodologie di sviluppo e il
'tipo' di applicazione.  Senza distinguere appropriatamente ed
esplicitamente, si fa solo un grandissimo pastrocchio.
P.S. : non sono in senso proprio un sostenitore di Linux. ne sono
utente, come sono utente di altri OS. sono in senso lato un sostenitore
non fanatico del software open source, specialmente come strumento di
sviluppo.


 esplicitamente, si fa solo un grandissimo pastrocchio.
Non si fa nessun pastrocchio, io voglio sapere chi testa cosa e come.


 o simili. Ogni citazione e` (C) dei rispettivi proprietari.
no è sotto CopyLeft :B
-- 
NoWhereMan (e.v.)
-- 
http://www.nowhereland.it
-- 
http://flatpress.nowhereland.it


quando lo trova, se ci fa un fischio passiamo a quello :)
sono serio, eh?
Mah, chissà che Solaris... (che culo, un altro kernel monolitico...)
o aspettiamo tra 900 milioni di miliardi di anni HURD; o speriamo in Haiku.


 
http://archlinux.org/pipermail/arch-dev-public/2007-May/000562.html
La cosa agghiacciante, visto dall'ottica di una azienda che sta pensando di 
usare linux, e' pero' l'ultima frase:
"Users: sorry guys."
Sorry guys?? Massi', passiamo a linux, che da un giorno all'altro qualcosa 
va a puttane e ci rispondono "sorry guys". 

 Non si fa nessun pastrocchio, io voglio sapere chi testa cosa e come.
Finalmente hai ristretto il tutto: vuoi sapere *solo* del kernel di
Linux. Spero che avrai celermente la tua risposta. E temo che non ti
piacerà.


 va a puttane e ci rispondono "sorry guys". 
Questa è malafede. Stai parlando di ArchLinux, non di RedHat o chi per
lei. RedHat non ti scrive *sorry guys*.


 Non si fa nessun pastrocchio, io voglio sapere chi testa cosa e come.
Per la maggioranza delle distro testano gli sviluppatori e gli 
smanettoni che si scaricano la versione beta. KDE 4 chi lo testa? Non 
e` come Vista, non sono comparabili cosi` a buffo.
-- 
Sensei <senseiwa at Apple's mac dot com>
Java is the most distressing thing to happen to computing since MS-DOS.
(Alan Kay)

 o speriamo in Haiku.
Eugenia non ci lavora mi pare, come moltissimi altri ex-sviluppatori 
(quello di NewOS non ricordo come si chiama). Haiku e` un progetto nato 
morto.
-- 
Sensei <senseiwa at Apple's mac dot com>
Error. Keyboard not attached. Press F1 to continue...
(Real BIOS Error)

 Non so se ridere o piangere.
Eugenia Loli Queru non e` l'ultima stronza sulla terra pero` eh. Ho 
letto ma mi pare non difenda un gran che, ma magari m'e` sfuggito...
-- 
Sensei <senseiwa at Apple's mac dot com>
$ cd /pub
$ more beer

 
Per adesso mi accontenterei di una risposta


 
Qualcuno puo' confermare questa visione?
Grazie


 lei. RedHat non ti scrive *sorry guys*.
e comunque è il maintainer del kernel beyond a cui vengono applicate varie
patch; insomma arch non ci perde molt(issimo)
nota: arch NON è per utonti, è quasi una gentoo, dal mio punto di vista.


 Qualcuno puo' confermare questa visione?
Mi astengo dalla lotta (senza continuare la frase).
-- 
Sensei <senseiwa at Apple's mac dot com>
Error. Keyboard not attached. Press F1 to continue...
(Real BIOS Error)

 Vedi sopra, il mondo del software la pensa in maniera diversa da te.
No. Sei tu che tagli a piacere quello che ho scritto.


 Eugenia Loli Queru non e` l'ultima stronza sulla terra pero` eh. 
Diciamo che non ho una massima stima della persona, ecco.


 Complimenti [...] sono perfettamente d'accordo [...]
:D 
scusate la facezia :D


 Si veda anche il commento di Eugenia Loli-Queru in merito:
bah... non sono mai stato d'accordo con Eugenia e francamente anche le
sue uscite su OSNews lasciano molto a desiderare....

 sue uscite su OSNews lasciano molto a desiderare....
De gustibus.
SALUTONI,
WindoM

 morto.
dai, che nanodesktop salverà il mondo

 
http://archlinux.org/pipermail/arch-dev-public/2007-May/000562.html
fermi tutti, che cavolo è il kernel beyond?

 lei. RedHat non ti scrive *sorry guys*.
'ste cazzo di alborelle, mi rovinano tutte le esche.. 

 break."
Sarebbe bello se l'autore avesse fatto qualche esempio pratico di questo
orrendo disfacimento.
-- 
emboliaschizoide.splinder.com

 'ste cazzo di alborelle, mi rovinano tutte le esche.. 
'cusa :)


 fermi tutti, che cavolo è il kernel beyond?
è il pacchetto del kernel linux con applicate alcune patch tipo -ck
ma i casini succedono anche col vanilla :D


Bluff wrote:
:: Non avendo una struttura di testing indipendente (no lo sviluppatore
:: non sa testare il suo codice) questo e' ovvio. Mi permisi di dirlo
:: circa 8 anni fa e fui mangiato vivo in questo stesso newsgroup.
:: Vediamo che succede a distanza di 8 anni.
Aleeeeee, stasera se magna!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Enrico 'Mc Osten' Franchi wrote:
:: 3. Siamo sicuri che qui il punto sia distinguere per licenza
:: piuttosto che per modalitą di sviluppo? Ovvero: siamo sicuri che la
:: piccola applicazioncina o il piccolo serverino del menga open source
:: segua effettivamente procedure peggiori del piccolo sharewarino per
:: Windows? Ricordo che buona parte degli sviluppatori *non* sanno
:: quali sono delle buone procedure. Sono praticoni tirati su con VB o
:: con PHP che si arrangiano come possono.
Quoto
::
:: D'altra parte i team di professionisti che sono alla base di
:: determinati software open *non* sono affatto peggiori di quelli alla
:: base di determinati sw closed.
Quoto 

Sensei wrote:
:: Uno c'e` morto ad aspettarlo... scelta ottima quelli di gnu!
Si, poraccio. E pensa che era il cugino di quello morto acciso dalla cassa 
di 50.000 CD di Ubuntu 7.04.
Na traggedia.

 No. Sei tu che tagli a piacere quello che ho scritto.
Si vabbe'


 
Premesso che mi considero ancora un cane di programmetore,
nella mia limitata esperienza sono stato molto più bravo
a trovare bug nel codice altrui che nel mio...
Sono d'accordo, "occhi esterni" vedono cose su cui magari
gli occhi dell'autore "scivolano sopra".
-- 
rimuovere/remove         "Calm yourself!  Man who argue with cow
WLATOPA                      on wall is like plane without wings--
per rispondere/to reply    very soon get nowhere." (Peter Sellers)

 
Ma siamo sicuri sicuri che il problema più grosso siano magagne
temporanee del kernel, che poi ho visto in genere sempre risolte
successivamente? In pratica parliamo della classica politica di
rilascio delle versioni X.Y.0 che in realtà sono delle beta, mi
ricorda qualcosa...
Questo vagamente, sulla sola gravità del problema.
Più specificamentte sul testing: davvero, almeno per il vanilla,
non c'è nessuno che si occupa prevalentemente del testing?
(non è una domanda retorica, lo chiedo perché non lo so)
Infine: Sono l'unico che i problemi più grossi li vede nella
scarsa buona volontà di certe aziende HW riguardo ai driver?
Finora, dei problemi che ho avuto (solo uno è tuttora irrisolto),
nessuno era ascrivibile al kernel.
Alberto.


 Secondo te in agile development non ci sono testers? Ma che dici?
In primo luogo perchè tu *continui* a confondere *due* tipi di test. Ci
sono i test che dimostrano che il codice fa quello che il programmatore
intende (spesso di basso livello, tipicamente i test unitari) e ci sono
i test che dimostrano che il prodotto si comporta come il cliente si
aspetta [ e poi in mezzo i vari test funzionali, di integrazione etc etc
etc ]. Ad ogni modo il punto di XP è che si lavora tutti insieme e ci si
'passa i camici'.
 Non c'è uno che è tester e tester e basta (eccezione a questo
potrebbero essere i membri non programmatori in un team, ma il punto è
che sono gli unici che *non* programmano non che sono gli unici a fare
testing). 
Ma per il resto i programmatori sono *anche* testers. Non del codice che
hanno scritto. Davvero, se vuoi sapere quello di cui parlo, leggiti il
libro di Kent Beck.
E questo è a prescindere dal fatto che tu la consideri o meno una buona
tecnica.


 Secondo te in agile development non ci sono testers? Ma che dici?
 Ad ogni modo il punto di XP č che si lavora tutti insieme e ci si
'passa i camici'. Certo, non tutti i metodi agili sono XP. Ma diciamo
che č una delle piů diffuse, per dire.
 Non c'č uno che č tester e tester e basta (eccezione a questo
potrebbero essere i membri non programmatori in un whole team, ma il
punto č
che sono gli unici che *non* programmano non che sono gli unici a fare
testing). 
Ma per il resto i programmatori sono *anche* testers. Non del codice che
hanno scritto. Davvero, se vuoi sapere quello di cui parlo, leggiti il
libro di Kent Beck.
E questo č a prescindere dal fatto che tu la consideri o meno una buona
tecnica.
-- 


 servigi miei o meno
da dove viene fuori questo numero? 2/3 mi sembra tanto...



il 23 è dappertutto... :D


 break."
Lo è by design. D'altronde è la politica del "release early release 
often". Se ne accorge solo oggi?

 morto.
zan zan zan...
http://www.ossblog.it/post/2505/haiku-ottiene-il-supporto-ai-driver-di-rete-freebsd


 often".
Ma per un accidente. Release early release often non vuole dire release
buggy.
Non a caso se prendi un qualunque manuale che fra le pratiche consiglia
questo, te lo consiglia solo dopo che certi parametri di stabilità e di
qualità sono raggiunti. 



Stimare le risorse da allocare al testing e' una di quelle operazioni 
che puo' essere molto complicata. Il motivo e' che puo' variare 
enormemente da progetto a progetto e dipendere anche dall'esperienza 
degli sviluppatori. Se lavoro a progetto su un qualcosa di medio grosso 
io prendo 2 tester per ogni 3 sviluppatori. In altri casi 1 ogni 3 puo' 
essere sufficiente. Se poi ti trovi in un ambiente molto strutturato con 
procedure di testing che devono passare un Audit interno e, nel caso di 
societa' finanziarie, anche esterno allora 2/3 e' il minimo. Al momento, 
i team che gestisco hanno rapporto 2/3, ma siamo una banca e abbiamo 
audit di qualita' (a sorpresa) sull'80% dei prodotti.


 buggy.
allora vuol dire che si supponga che chi sviluppa in open source sia 
anche in grado di fare miracoli, perché non solo rilascia molto più 
spesso di chi sviluppa con metodi tradizionali "closed", ma deve anche 
saper garantire la stessa qualità. Riflettendoci un attimo, appare 
chiaro che la cosa non sia possibile. Suggerisco una riletta (perché 
sicuramente lo avrai letto) de "La cattedrale ed il Bazaar" 
(
http://www.apogeonline.com/openpress/cathedral
), punto 4 - 
"Distribuisci presto e spesso", che inizia nel seguente modo:
+++++++++++++++++++++++++++++++++++
4. Distribuire presto e spesso
Elemento centrale del processo di sviluppo di Linux è la rapida e 
frequente distribuzione delle varie release. La maggior parte degli 
sviluppatori (incluso il sottoscritto) aveva sempre considerato negativa 
questa usanza per progetti appena più che minimi, poiché le versioni 
iniziali sono piene di bug quasi per definizione e non pareva il caso di 
far spazientire inutilmente gli utenti.
++++++++++++++++++++++++++++++++++++
ma nel resto del paragrafo spiega come invece questa tesi sia nei fatti 
confutata, e come nel mondo OSS per la maggior parte delle persone sia 
preferibile un software rilasciato spesso anche se magari pieno di bug 
rispetto ad uno rilasciato di tanto in tanto anche se più consolidato
D'altronde, basta pensare al bacino di utenza che aveva Debian prima, 
con policy di rilascio di nuove distribuzioni ogni 2 anni circa, e 
quelli che ha Ubuntu adesso. Ma Ubuntu in fondo cosa è? Niente altro che 
una Debian, ma che rispetto alla Debian sostanzialmente ha
1) pacchetti piu' recenti, e quindi con più funzionalità, ma chiaramente 
con molti più bug
2)una policy di rilascio di una nuova distribuzione ogni 6 mesi circa, 
che la fa rinnovare in continuazione anche se questo la espone 
chiaramente a più bug e vulnerabilità.
Come vedi, alla fine una Debian (Ubuntu) rilasciata "presto e spesso", 
sebbene con molti molti più Bug rispetto alla Debian "classica", si è 
rivelata molto più attrattiva per l'utenza, a giudicare dal numero di 
utilizzatori.
Ognuno tragga le proprie conclusioni.

 "Distribuisci presto e spesso", che inizia nel seguente modo:
Ho qui il libretto (io lo ho anche *comprato*). Però è in inglese.
Tu stai andando avanti a slogan: cerca di capire quello che dice. In
alcuni punti non esplicita tantissimo (ma se ti va di leggerti anche il
libro di Beck, ti si chiariranno automaticamente).
Il punto non è 'rilasciare spesso' se queste release sono buggate. In
questo modo perdi la fiducia del cliente. A meno che queste release non
siano marcate *chiaramente* come instabili (e il cliente decide cosa
vuole fare).
Il paragrafo che si avvicina a quello che dici scrive:
"Linus was directly aiming to maximize the number of person-hours thrown
at debugging and development, even at the possible cost of instability
in the code and user-base burnout if any seriuos bug proved
intractable".
Ma attenzione: queste sono le prime fasi. Quando utenti e sviluppatori
quasi coincidono, e l'uso non è uso 'di produzione'.
In seguito tramite la numerazione viene utilizzata per distinguere
release stabili e non stabili.
E questo è accettile. Il punto è che se hai un progetto e per mantenere
un certo ritmo di rilascio ficchi bachi, peggiori il codice etc etc etc.
Stai facendo cazzate.
Poi ribadisco: release early and release often *non* è prerogativa del
software libero. È una fra tante pratiche di sviluppo che ciascun
progetto può o non può adottare.


 il 23 è dappertutto... :D
apperò, non ci avevo pensato!

 audit di qualita' (a sorpresa) sull'80% dei prodotti.
ok, ti credo. certo è che, cavolo, 2/3 in testing vuol dire spendi il
66% in test, non è che forse gli sviluppatori abbiano poca esperienza?


Aspetta non ci siamo capiti. 2 tester per 3 sviluppatori significa il 40%




Merda... mi piaceva PippaOS...
-- 
Sensei <senseiwa at Apple's mac dot com>
Basic research is what I am doing when I don't know what I am doing.
(Wernher von Braun)



Orcatroia! Stragi non documentate dalla storia... essi` che la scrivono 
i vincitori (quindi PippaOS).
-- 
Sensei <senseiwa at Apple's mac dot com>
There are 10 types of people in the world:
those who understand binary, and those who don't.

 
potevano fare la stessa puttanata di BeOS!
-- 
Sensei <senseiwa at Apple's mac dot com>
Top 10 Oxymorons:
(Retail product) "Microsoft Works"

 succede non vedo perche' bisogna gridare allo scandalo.
Perche` un conto e` cambiare il codice senza rompere nulla, cosa 
peraltro non impossibile (anzi in C poi...), altro e` sputtanare le 
API, e chiaramente rompere la compatibilita` binaria. O peggio a 
sorgente (eh lo fanno lo fanno).
-- 
Sensei <senseiwa at Apple's mac dot com>
We know Linux is the best, it can do infinite loops in five seconds.
(Linus Torvalds)

 buggy.
Almeno non necessariamente, senno` e` "crap by design".
-- 
Sensei <senseiwa at Apple's mac dot com>
Research (n.): a discovery already published by a chinese guy one month
               before you, copying a russian who did it in the 60s.

 Merda... mi piaceva PippaOS...
PippaOS deve chiedere ad Anna


 sorgente (eh lo fanno lo fanno).
sì ma lo sviluppatore di cui sopra si lamentava molto semplicemente del
fatto che ad ogni upgrade si sputtaneggiava qualcosa; non semplicemente la
compatibilità binaria. Sono il primo a dire che non avevo problemi con le
prime release del kernel di Edgy, che poi ha cominciato ad andare in
panic...



Chiedo scusa, un pò di pazienza, per ora mi accontento
dei nostri benchmark di laboratorio....
.... il mondo lo salvo lunedì, ok ?

 
ah, quindi quando scrivevi "spendono in testing circa i 2/3 di quello
che spendono in sviluppo" intendevi
spese totali = spese sviluppo  + spese test
io per spese sviluppo intendevo il tutto. Capirai, la cosa cambia e mi č
piů facile da credere.


direi che hai una discreta agenda ;-)
Dai Filippo, prendila con goliardia....

 .... il mondo lo salvo lunedì, ok ?
sì ma a che ora? :P


 panic...
Leggi 'O peggio a sorgente'. Se scambi l'ordine dei parametri sputtani 
il funzionamento senza incorrere in alcun errore tranne quando e` 
troppo tardi. Si e` rotto il cazzo e non ha torto.
-- 
Sensei <senseiwa at Apple's mac dot com>
It is a very sad thing that nowadays there is so little useless information.
(Oscar Wilde)

 troppo tardi. Si e` rotto il cazzo e non ha torto.
sul fatto che sia una rottura di palle siamo d'accordo :p
comunque credo non sia solo il fatto che continuino a smanacciare prototipi
(che comunque non aiuta), è anche il classico correggi di qua, bugga di là;
poi d'accordo, non si può avere mai qualcosa di completamente bug free, ma
magari testare un po' di più... e soprattutto chiedere di non avere
regression...


 piů facile da credere.
chiarito l'equivoco.


 regression...
Non c'entra un cazzo la questione bug. E` che non ha alcun design, la 
gente sul serio cambia le cose come gli pare, e` una accozzaglia di 
vari pezzi (*) con il 'basta che funziona'. Non e` lavorare seriamente 
cosi`, e` giocare.
(*) Vedi la storia di ISAPnP se ti vuoi divertire (o piangere)
-- 
Sensei <senseiwa at Apple's mac dot com>
Java is the most distressing thing to happen to computing since MS-DOS.
(Alan Kay)

 (*) Vedi la storia di ISAPnP se ti vuoi divertire (o piangere)
hai qualche link?


 hai qualche link?
Si, basta che ti scarichi il sorgente del kernel e leggi un po da
http://www.roestock.demon.co.uk/isapnptools/
-- 
Sensei <senseiwa at Apple's mac dot com>
The optimist proclaims that we live in the best of all possible worlds;
and the pessimist fears this is true.
(James Branch Cabell)

 scarsa buona volontà di certe aziende HW riguardo ai driver?
Come dargli torto, se l'azienda viene presa per le palle e costretta a
rilasciare i driver solo come conviene agli sviluppatori, anche io mi
rifiuterei a collaborare...
Enrico

 Enrico
-- 
Ciao.
Alessandro 
"Ubuntu" - an African word, meaning "Slackware is too hard for me".