Ritorna una di quelle discussioni che, periodicamente, si presentano nel mondo del software libero: lo schema di numerazione dei rilasci. In questo caso l’interessato sarebbe proprio sua maestà il kernel (Linux) e l’autore della proposta di passare ad uno schema anno.numero_di_rilascio.numero_di_rilascio_minore è nientepopodimeno che Greg Kroah-Hartman.
Ovviamente, come nella migliore tradizione del software aperto, non sono mancante obiezioni, critiche ed altre idee (per esempio uno schema basato solo su due numeri).
Voi cosa ne pensate? Attribuite importanza alla numerazione dei rilasci? Optereste per una particolare soluzione o preferireste che ci si concentrasse su altri aspetti del kernel? Fateci sapere cosa ne pensate.
FrAnKHiNrG
18 ott 2008 - 10:08 - #1Ma perchè perdere tempo con queste masturbazioni mentali???? La numerazione attuale è la più sensata.
Sono sempre stato un sostenitore dell’opensource ma debbo ammettere che a volte ci si ingrippa su argometi davvero stupidi…
Scusate lo sfogo :)
hellview
18 ott 2008 - 10:26 - #2imho come adesso va benissimo, chiaro e semplice.
xtech
18 ott 2008 - 10:47 - #3La numerazione delle versioni non è una pippa mentale, è molto importante e deve essere fatta correttamente.
Per gli utenti finale puo sembrare una sciocchezza ma per chi ci sviluppa è importante che sia fatta bene.
Se quella di adesso va bene o no no lo so, lasciamolo decidere a chi ci lavora senza accusarli di essere dei perditempo.
alc0r
18 ott 2008 - 11:04 - #4Il sistema di numerazione dei rilasci e’ importante, ma una volta deciso un sistema funzionale e ordinato mantenere quello.
Quello attuale per quanto possa sembrare cervellotico e’ ordinato e comprensibile.
Martinux
18 ott 2008 - 11:20 - #5La proposta è se passare da un sistema basato sul contenuto del software ad uno basato sulla data di rilascio del software.
Non saprei, sicuramente con il secondo sistema si sa se si sta utilizzando un kernel “vecchio”, ma con il primo è + facile capire a che punto delle sviluppo siamo…
Poi in fondo è tutta qustione di abitudine…
Morpheu5
18 ott 2008 - 11:24 - #6Boh, io non trovo niente da obiettare con l’attuale. Identifica chiaramente quale branch e quale versione si usa e uno sa che questo e quello funzionano o meno in questa e quella release. Fine. Riconosco che si possano scegliere schemi diversi, eventualmente migliori, ma la soluzione basata sull’anno o su soli due numeri mi sembra un po’ fuorviante dal punto di vista dello sviluppatore e un po’ troppo orientata all’utente finale: il kernel non è un software per l’utente finale.
Teo Teti
18 ott 2008 - 11:39 - #7Anno-numero non mi pare poi male come idea. Esiste per caso una roadmap per una branch 2.8 o 3.0? Stiamo con la 2.6 da cinque anni…
gp42
18 ott 2008 - 11:48 - #8@Teo: credo non ci sia nessuna roadmap. Al momento, allo stato attuale Linus è soddisfatto di questo kernel. Imbattersi in qualcosa di nuovo non so quanto possa essere sensato. Lui stesso lo ha dichiarato. Si andrà avanti di bub-fix, nuove implementazioni per arricchirlo ed aggiustamenti di sorta. Rivoluzioni no.
gp
mosa
18 ott 2008 - 11:48 - #9OT
Vi prego ditemi dove posso prendere quel pelouche!!!!!!!!!!!
progalba
18 ott 2008 - 12:27 - #10ma penso che per l’utenza inesperta, coloro che si approcciano per le prime volte a linux, sia meglio qualcosa che capiscono, li rende più partecipi, quindi meglio numerazione a data.
Però anche vero che ora è inutile cambiare sistema…
Personalmente preferirei avere tutto con versione in data, come ubuntu, semplice facile diretto e veloce.
Pizzuco
18 ott 2008 - 12:56 - #11Vorrei aggiungere solamente la riflessione che non è molto frequente, secondo la mia modesta esperienza, che un qualunque pezzo di software che passi da una release 2.6.26 ad una 2.6.27 abbia profonde differenze!!!
Nel kernel di linux, invece e a quanto mi pare, ciò avviene e con “intensa” verità.
Se un cambiamento di nomenclatura deve esserci, forse ci si dovrebbe interrogare sul fatto che faccia meglio capire che si tratti di grandi cambiamenti (api e quant’altro).
Ricordo un editoriale di Patrizio Tassone (Linux & C.) sul continuo cambiamento delle “api/interfacce” del kernel e sulla conseguente necessità di ricompilazione… Questo a supporto di quanto da me qui affermato. Forse questa frase non è precisissima, ma penso abbiate colto il concetto…
Carlo
vad
18 ott 2008 - 13:03 - #12L’utente finale non sa cosa sia un kernel (ed è giusto che sia così, io non so nel dettaglio come funziona un’automobile, ma la uso ugualmente).
Quindi chissenefrega di trovare una numerazione “più semplice da capire”. Se si passasse al numero dell’anno, poi come si potrebbe fare distizione tra branch nuovo e vecchio (ma stabile e magari ancora ben sviluppato, come è stato a lungo con 2.6 vs 2.4?). L’attuale sistema va benissimo, poche mene.
Fabioo
18 ott 2008 - 13:05 - #13Non è solo una pippa mentale, ma anche questione di marketing.
Ad esempio, Sun da java 1.5 ha iniziato a chiamarlo anche java 5.
Penso che lo schema anno.major.minor sarebbe più chiaro.
ohmygod
18 ott 2008 - 13:37 - #14Il fatto è che con il ciclo di sviluppo attuale è difficile immaginare che ci sia qualcosa che giustifichi un salto alla 2.8 (o 2.7 visto che il vecchio metodo non vale più) tantomeno ad una 3.0. Quindi se si prospetta un eterno 2.6.xx.yy tanto vale eliminare il 2.6 e continuare solo con il xx.yy come suggerisce H. P. Anvin. Il metodo anno.versione.stable mi sembra poco pratico perché nessuno sa, ad apertura della merge window, quando cadrà il rilascio della final (ad esempio, il 2.6.28 sarà il 2008.3 o il 2009.1?).
Andrea Stani
18 ott 2008 - 14:16 - #15Un numerazione che leghi la numerzione di rilascio alla rispettiva data di rilascio sarebbe terreno fertile per una psicosi newbie nella cacccia alla distrbuzione più aggiornata.
Ache serve un kernel nuovissimo su di un computer dalle caratteritiche hardware datate e già supporate da un kernel più vecchio e snello?
Ma poi a cosa serve unire l’informzione temporale alla numerazione?
groucho_nt
18 ott 2008 - 14:21 - #16un sistema di numerazione anno/mese/giorno potrebbe non essere sufficiente in caso di versioni rilasciate a distanza di poche ore, quindi la numerazione andrebbe estesa a anno/mese/giorno/ora… ah chiaramente, si dovrebbe considerare la timezone, perchè un conto sono le 8pm a londra e un conto le 8pm a chicago….
scherzi a parte, qual è il problema con la numerazione attuale?
se io uso un kernel 2.6.21 so che è “vecchio” rispetto ad un 2.6.22 e questo mi basta
lasciamo le date agli esperti di marketting (la doppia t non è un errore di battitura)
khelidan
18 ott 2008 - 16:02 - #17la time zone non sarebbe un problema sempre e comunque UTC come si fa in aeronautica
hackgeek
18 ott 2008 - 17:14 - #18Mi sembra un ottimo metodo..chiaro…nessun problema….
Beppe.r
18 ott 2008 - 18:12 - #19perche non usare un serial come i DNS.
PsychoPandax
18 ott 2008 - 18:45 - #20Sicuramente un problema importante, ma cambiare così, in corso d’opera credo possa generare solo incomprensione.Io piuttosto aspetterei una major in modo da porre un punto fermo e chiaro.
nicsco
18 ott 2008 - 19:11 - #21non capisco una cosa: perché chiamarle 2008.xx, 2009.xx …. c’è l’idea di andare già al 3000????
si potrebbe chiamare linux 8.10 (se fosse rilasciato questo mese), 9.01 (se fosse a gennaio prossimo) !
ommioddio
19 ott 2008 - 12:03 - #22@groucho_nt et alii:
Forse non avete capito qual è la proposta. Nessuno ha parlato di mese o giorno. Solo di anno.
@nicsco
Con due cifre non ci si ferma al 3000 ma al 2100. Per il resto vedi sopra.
ice
19 ott 2008 - 19:07 - #23io vorrei un ritorno al passato
ma vi ricordate quando c’erano 2 rami per il kernel
il 2.3.xx per lo sviluppo e il 2.2.xx per le versioni stabili
Diminuire le versioni creerebbe problemi di precisione quando si indica la compatibiliità….già adesso ci sono release diverse della serie 2.6.27.xx prevalentemtnete di bugfix
/V
19 ott 2008 - 22:09 - #24Un sistema basato sulle date mi pare inutile, dal momento che il kernel linux non ha, al contrario di ubuntu, un vincolo sulle date di rilascio (i.e. non ci sono impegni impleciti od espliciti a rilasciare una versione del kernel ogni 3/6/9 mesi).
Ricordiamo poi che di solito alle 3 cifre della versioe si aggiungono ALTRE informazioni a seconda della distribuzione, delle patch, dei bugfix etc etc.
Cambiare tutto questo ecosistema in corso d’opera mi pare introduca piu’ vantaggi che svantaggi. Non saro’ un tecnico ma la cosa mi sembra talmente lapalissiana che sprecare anche solo un post per discuterne mi sembra una perdita di tempo devastante.
lascoltodelvenerdi
20 ott 2008 - 07:16 - #25Non è male come idea…ma ha delle ricadute di “marketing” non indifferente!
Già mi pare di sentire certa gentaglia con battute tipo: “Linux? Quello col kernel del 2005 vecchio di 3 anni?”
Vi pare bello?
Meglio rimanere legati ai numeri e lasciare gli anni ai nomi delle distro.
marmo51
20 ott 2008 - 12:11 - #26Il formato del numero di versione deve ispirarsi a criteri di facile comprensione e di marketing.
Si di marketing. Vogliamo o no che Linux si diffonda sempre più?
L’utente poco esperto deve capire al volo quale sia il kernel installato sul suo sistema.
Prima o poi dovrà aggiornare il sistema, manualmente o via update automatici, indipendentemente dalla distribuzione usata e si troverà il numeretto davanti.
Quindi è importante semplificare.
Semplificare sacrificando anche informazioni utili oggi a molti utilizzatori di Linux ricavabili dall’attuale formato.
Il come semplificare è un problema successivo in cui l’intelligenza e qualche intuizione sicuramente daranno un nuovo bellissimo formato al kernel.
Una nuova sfida.
Ricordatevi, il nome è i m p o r t a n te!!! pensate se Linux avesse il nome che gli aveva data Linus all’inizio…
Solo un nuovo formato di versione potrebbe far arrivare nuovi utenti, che è sempre la cosa più importante per il pinguino.
O no?
Vogliamo c o m p e t e r e con gli altri sistemi operativi! O no?
bertello
22 ott 2008 - 16:06 - #27in 2 post su 3, i primi in ordine cronologico, si è fatto riferimento alla masturbazione mentale
detto tutto, e straquoto in pieno il primo
ma ’sta gente non ha altro di meglio da fare nella vita ?
tipo rimboccarsi le maniche e LAVORARE no
?!!
sono convinto che fior di cervelli (che potrebbero fare ben altro per il FS), stanno ad accapigliarsi su una questione così inutilmente teorica