Newsgroup: it.comp.os.linux.sys
Titolo: [OT] OSDL+Torvalds, qualcosa non mi convince

Scusate l'argomento non propriamente tecnico. Posto su questo gruppo
perche` la questione riguarda direttamente Linux e poi non e` frequentato
da gente che ha un profonda avversione a tutto cio` che Linux rappresenta,
cosa che invece accade su icod :-)
Mi stavo chiedendo, ora che Torvalds e` passato a lavorare su Linux a tempo 
pieno senza piu` doversi sentire 'in colpa', come si evolvera` lo sviluppo 
del kernel.
OSDL paga Linus per coordinare e sviluppare full-time Linux.
Ora, chi controlla il lavoro di Torvalds? Quali sono gli obiettivi 
imposti a Torvalds in cambio del suo stipendio?
Finche` lo sviluppo del kernel era un lavoro 'secondario', ogni nuova 
release poteva essere vista come un 'dono' di Torvalds alla comunita`. 
Ora il dono diventa, invece, un obbligo. Anche se ormai Linux era diventato 
un lavoro a tempo pieno per Torvalds gia` quando lavorava alla Transmeta.
E` chiaro che chi sta dietro a OSDL ha un interesse diretto nello sviluppo 
del kernel. E anche su questo si potrebbe discutere della questione 
delle possibili 'influenze' sulla direzione che Linux potra` prendere in 
futuro.
In pratica siamo di fronte ad una sorta di 'mecenatismo' ed allora
tutto potra` continuare come prima (e anche meglio) o dovremo aspettarci 
prima o poi un cambiamento nella filosofia e negli obiettivi di sviluppo 
del kernel?
-- 
Vincenzo

consoco il torvalds pensiero per lo meno un po' (ho letto molti suoi 
post nonché altro in rete) e lo vedo comunque capace di non farsi 
influenzare da chi lo sfama. speriamo
-- 
Davide Corrado
to send mail, remove "no_spam_" from the address

 un lavoro a tempo pieno per Torvalds gia` quando lavorava alla Transmeta.
Affatto: Linus, alla Transmeta, faceva altro.
Addirittura, se n'è andato dalla TM perché lavorava più sul kernel che a
quello su cui doveva lavorare.
+++
[1] Le prestazioni sono peggiori rispetto agli Intel di pari clockaggio,
e non è possibile fare in modo che Linux funzioni meglio, "aggirando" il
layer di traduzione tra core e x86.
Ciao,
 Emmanuele.
-- 
Emmanuele Bassi (Zefram)           [ 
http://digilander.libero.it/ebassi/
 ]
GnuPG Key fingerprint = 4DD0 C90D 4070 F071 5738  08BD 8ECC DB8F A432 0FF4

 Non insultatemi, vi prego, e' solo una opinione.
Niente insulti, ci mancherebbe, anche se la penso in modo completamente
differente.
Lo sviluppo del kernel Linux IMHO non è poi così caotico, almeno non
quanto lo si dipinge di solito.
Forse lo era qualche anno fa, ma tra l'abbandono dei CVS e la struttura
a cerchi concentrici (non mi viene nulla di meglio, sorry :p) siamo
messi bene.
E' il supporto che manca: serve una suite di test *massiva* (cazzo è un
kernel ...) e un controllo sulle patch più stretto.
I ragazzi di BSD vanno forte, ma molto spesso non si discute, se dicono
che una cosa è così è così e basta (filesystem tipo).
0.2 cents
	nicholas

 influenzare da chi lo sfama. speriamo
Anche perchè è un consorzio di tanti: se hai fatto contenta Fujitsu,
IBM, Oracle, HP e quell'altra dozzina di megasuperaziendone ci sono
buone possibilità che hai fatto contenti anche gli utenti.

 azienda e cio' potrebbe portare ad un certo ordine ben venga
mi permetto di ribattere, ben venga "uno sviluppatore a tempo pieno in piu' 
su linux" ( ^_^ ) pero' inquadrare linux nei tempi di un azienda potrebbe 
voler dire passare da "il kernel esce quando e' pronto" a "il kernel esce 
ad ottobre e/o quando lo dicono i commerciali".
il caso e' estremo, pero' molte aziende, microsoft su tutte, funzionano in 
questo modo. tutto a scapito della qualita'.
sisi vabe' i mie due centesimi! :-)
        f.

 writes:
f> ... pero' inquadrare linux nei tempi di un azienda potrebbe voler
f> dire passare da "il kernel esce quando e' pronto" a "il kernel esce
f> ad ottobre e/o quando lo dicono i commerciali".
Nel caso  di Linux  mi pare difficile:  il numero di  soggetti coinvolti
(sia aziende che programmatori) e` tale da formare una "massa inerziale"
assai notevole e a cui e` ben difficile far cambiare drasticamente dire-
zione senza perdere pezzi (= persone e competenze).
Personalmente non  vedrei male un po'  meno baazar e un  po' piu` catte-
drale nello sviluppo  di Linux, specie se guardiamo  a certi sviluppi su
cui  non e` il  caso di  perdere terreno  (Wi-Fi e  dintorni, multicast/
multimedia/VoIP, Active  Directory et  similia...)  e che  richiedono un
controllo piu` stretto del processo di sviluppo, magari per tracciare la
strada nuova, e non solo limitarsi  a seguirla (e in ordine sparso) dopo
che "il solito Bill" l'ha tracciata e tutti gli devono andar dietro.
f> il caso e' estremo, pero' molte aziende, microsoft su tutte,
f> funzionano in questo modo. tutto a scapito della qualita'.
Si`, ma cosi` fregano la concorrenza imponendo i *loro* "standard"...
Saluti,
Luca Polo.
-- 
Luca...@gest.unipd.it
 --- 
http://www.gest.unipd.it/~jake
----------------------------------------------------------
One Ping to rule them all. One Ping to find them.
One Ping to bring down them all.
And in the darkness crash them.         [The Lord of the Pings]

 biblici pero' una via di mezzo non sarebbe male.
IMHO i tempi d'uscita deb non sono poi cosi' sbagliati. se vuoi mettere un 
server ti prendi la stabile (ultratestata) se invece ti serve una 
workstation passi alla testing che mi pare si tenga abbastanza 
aggiornata,no?
Due scopi differenti, in realta', due distribuzioni differenti.
A mio avviso e' ottimo anche il ritardare l'uscita di un kernel stabile fin 
tanto che non sia pienamente soddisfacente. Senza altre pressioni che non 
siano la qualita'.
        f.