Il 25 Dicembre "Babbo Natale" Linus ha rilasciato il kernel 2.6.28.
Come al solito, il migliore riferimento per capire cosa c'è di nuovo senza essere dei kernel hacker è sul sito Kernel Newbies.
In particolare segnalo:
Il filesystem ext4 è stato dichiarato stabile (incluso in Fedora 10)
GEM, un nuovo memory manager per la memoria delle schede video
Supporto per il parcheggio immediato delle testine degli HD (protegge i dati in caso di caduta del PC)
Tracing del boot: renderà più facile individuare i colli di bottiglia per migliorare i tempi di avvio.
Di solito, i nuovi kernel stabili arrivano come update in Fedora dopo 2/3 settimane. Per gli impazienti, il 2.6.28 è già disponibile in rawhide e si può installare con: yum --enablerepo=rawhide update kernel
A causa del problema con dbus mi sono trovato con un portatile che non poteva essere aggiornato neanche dalla linea di comando con su -c "yum update" perchè NetworkManager non riusciva a controllare la connessione WiFi.
Per fortuna avevo in casa un altro PC funzionante con Fedora 10 e allora ho collegato i due PC con un cavo ethernet e condiviso la rete con NetworkManager in pochi semplici operazioni:
1. Dal menu System->Preferences->Internet And Network selezionare "Network Connections" 2. Nella dialog, selezionere la tab "Wired" e premere "Add" per creare una nuova connessione 3. Configurare la connessione come segue e premere "Apply"
4. Attivare la nuova connessione selezionandola dalla icona di NetworkManager sul system tray
A questo punto dal secondo PC sono riuscito a connettermi ed effettuare l'update
Máirín Duffy, leader del Fedora Art Team, ha lavorato alla creazione di una etichetta per Fedora 10 da usare con i masterizzatori LightScribe, peccato non averne uno per provare...
Qualche giorno fa su IRC c'era un utente che lamentava l'assenza del driver binario per le scehde video ATI (fglrx) nel repository RPMFusion. Effettivamente, pare che il driver attualmente disponibile non funzioni con Fedora 10 e quindi non c'è molto che si può fare, tranne aspettare che la ATI si svegli; alla stessa persona, che malediva il giorno in cui aveva comprato una PC con scheda ATI, vorrei solo ricordare che quando è uscita Fedora 9 il driver binario NVIDIA non ci funzionava, ovvero siamo tutti nella stessa barca...
E comunque, non è che oggi si stia molto meglio: per esempio, ecco un paio di schermate di totem con un fermo immagine di un DVD, prese sul mio PC dotato di una NVidia Quadro 130M; in una avevo attivo il driver binario, nell'altra quello open; non credo di dover indicare quali siano...
Ricordo che, quantomeno nel caso di ATI, le implementazioni open supportano anche il 3D per molte schede; da notare che ci sono al momento due diversi driver: "radeon" disponibile in tutte le installazioni ed attivato automaticamente da xorg, e "radeonhd" per cui bisogna installare il pacchetto xorg-x11-drv-radeonhd e poi selezionare radeonhd come driver in "System->Administration->Display"
Molti utenti di Fedora (ma anche di altre distribuzioni che hanno iniziato ad usare PackageKit) hanno lamentato di recente un errore cercando di installare oppure aggiornare i pacchetti:
A security policy in place prevents this sender from sending this message to this recipient, see message bus configuration file (rejected message had interface "org.freedesktop.PackageKit.Transaction" member "Cancel" error name "(unset)" destination "org.freedesktop.PackageKit")
Ovviamente, non è che sia il messaggio più facile da capire al mondo, quindi spendo due righe per spiegare il fatt(acci)o.
Nel corso del tempo, molti programmi hanno iniziato ad appoggiarsi a D-Bus, un sistema semplice e leggero che permette la comunicazione tra applicazioni. Ovviamente, la sicurezza in ogni sistema di comunicazione è importante, e D-Bus implementa una serie di metodi per definire chi e quando può comunicare con una data interfaccia (per un esempio pratico, si veda questo articolo di Red Hat Magazine).
A causa di un recente problema di sicurezza con le regole di default, la update alla versione 1.2.8 di dbus non è passata attraverso il repository updates-testing come avrebbe fatto normalmente, ma è stata promossa direttamente a update "stabile"; in questo modo gli utenti si sono ritrovati con la vulnerabilità risolta, ma diversi programmi non più funzionanti tra cui, purtroppo, PackageKit.
Se siete in questa situazione, la soluzione per uscirne è dare, da una shell, il comando: su -c "yum update"
Non ho ancora finito di leggere le recensioni su Fedora 10 che bisogna proporre un nome per Fedora 11... Per non intasare la mailing list fedora-devel questa volta le proposte saranno collezionate su una apposita pagina del wiki.
Solo quelli con account Fedora possono editare la pagina e fare la propria proposta, per cui se pensate di avere una buona idea ma non avete un account, fatemelo sapere che la aggiungo io.
Ricordo (se ce ne fosse bisogno) le REGOLE che il nome proposto deve rispettare:
Ci deve essere un collegamento con il nome della 10 (Cambridge)
Il collegamento non può essere lo stesso che legava la 9 (Sulphur) e la 10
Il collegamento è rappresentato da un "qualcosa" che sia lo stesso nei due casi:
Cambridge è un "qualcosa""
"nuovo nome" è un "qualcosa"
Il collegamento tra "Sulphur" e "Cambridge" era: entrambe sono città.
The Register ha pubblicato oggi un articolo sul rilascio di Fedora 10 che ho molto apprezzato per la precisione e puntualità delle informazioni riportate. Da non perdere.
Con una mail alla lista fedora-devel-announce, il release engineer di Fedora Jesse Keating ha annunciato che la release è stata composta, e le directory che ne fanno parte hanno iniziato ad essere inviate ai mirror sparsi nel mondo.
Alla stesso tempo, anche le prime update "zero day" (circa 200 pacchetti) a Fedora 10 hanno preso la via dei mirrors.
La lista completa dei mirrors (aggiornata ogni ora) è disponibile a questa pagina.
Durante l'installazione è possibile attivare repository diversi da quelli ufficiali, rendendo così possibile creare una installazione "full optional" in una sola operazione; ovviamente, è necessario avere a disposizione una connessione internet attiva.
Fino ad ora il boot di Fedora era gestito da rhgb (Red Hat graphical boot), che presentava graficamente lo stato di avanzamento dell'avvio. Purtroppo, rhgb rallentava (anche di diversi secondi, provate a disattivarlo per credere...) la partenza del sistema operativo a causa del numero di librerie grafiche che era necessario caricare, senza contare la scarsa "estetica" delle transizioni fra avvio del kernel->partenza rhgb->partenza gdm ognuna caratterizzata da uno (o più) cambi di modalità video.
Così, il maintainer di xorg Adam Jackson, coaudivato dal kernel hacker Dave Airlie hanno lavorato sulla feature Kernel mode setting che permette di superare i problemi di rhgb facendo settare la modalità video direttamente all'avvio del kernel e poi usando tale modalità durante tutto il boot fino alla login nel sistema.
Questo ha permesso di sostituire rhgb con un nuovo e più moderno progetto (plymouth), dotato di una architettura a plugin per le diverse visualizzazioni (grafica, testo, dettagli, etc) e migliorato drasticamente il lato estetico del boot.
Purtroppo, al rilascio di F10 gli unici che potranno godere appieno dello "spettacolo" sono i possessori di schede ATI visto che il driver Intel non è ancora pronto (ma non dovrebbe tardare molto) mentre, come al solito, NVidia non è pervenuta...
Dettagli e possibili workaround per le schede non supportate, nelle release notes
Come segnalavo a luglio, nel kernel 2.6.26 è stato incluso il supporto per un grosso numero di webcam. Quello che ho omesso è che il lavoro (ovviamente proseguito nella 2.6.27 che troviamo in Fedora 10) è stato portato avanti nell'ambito della feature "Better Webcam Support" da Hans de Goede, "famoso" per essere il mantainer di più di 100 pacchetti in Fedora con _zero_ bug aperti in bugzilla.redhat.com...
E così ho tirato fuori da un cassetto una vecchia webcam da 9.90€ , che non aveva praticamente mai funzionato con le applicazioni GNOME e stavolta ekiga me l'ha riconosciuta al volo!
E come effetto collaterale, ora Hans è stato assunto dalla Red Hat...
NetworkManager è un altro degli strumenti, inizialmente concepito in Fedora, che ha poi trovato spazio e supporto dalle altre distribuzioni, tanto che oggi moltissime lo installano ed attivano di default.
Per chi non lo sapesse NetworkManager si propone di gestire in modo "invisibile" le connessioni alla rete, evitando di fatto all'utente la necessità di manipolare file di configurazione o eseguire comandi dalla shell.
Dopo che in Fedora 9 è stato aggiunto il supporto alle connessioni mobili (per esempio, mediante adattatori USB o cellulari) la principale modifica in Fedora 10 riguarda la condivisione della connessione.
In pratica, è possibile creare in pochi click una nuova rete wireless (protetta o non) alla quale altre periferiche si possono connettere. Inoltre è estremamente migliorata sotto l'aspetto della usabilità l'interfaccia di gestione delle connessioni, con la possibilità di rendere globale (cioè disponibile a tutti gli utenti) l'accesso a determinate reti.
Una dimostrazione della feature, fatta dall'ideatore Dan Williams, è disponibile qua
Di NetworkManager ha parlato di recente Red Hat News
Ho già letto diversi diversi report sulle nuove features presenti in Fedora 10 ma pochi mettevano in evidenza quella denominata "Gstreamer dependencies in RPM".
Effettivamente, il nome è un po' oscuro ma si tratta della possibilità di riconoscere l'assenza di una dato codec sul sistema e quindi di proporne l'installazione; ovviamente, prima di provare la procedura è necessario configurare il repository RPMFusion.
Per esempio, ho provato a scaricare il trailer formato quicktime dal sito di Big Buck Bunny e al doppio click ecco il risultato:
A questo punto cliccando su "Search" viene invocato PackageKit e i pacchetti necessari vengono scaricati ed installati. La stessa procedura si applica anche nel caso in cui il filmato sia visualizzato direttamente in streaming.
Non solo questo ci mette finalmente in pari con altri distribuzioni in quanto a facilità di utilizzo, ma anche un pelo avanti, visto che il sistema si interfaccia con PackageKit, il tool sviluppato* per rendere l'interfaccia di installazione dei pacchetti uniforme sulle varie distribuzioni.
* Dimenticavo, sviluppato dalla comunità Fedora...
Dopo uno sforzo costato diversi mesi di lavoro (dalla definizione degli obiettivi alla messa a punto della infrastruttura fino al trasfermiento effettivo dei pacchetti) il nuovo repository RPMFusion ha annunciato ufficialmente la sua nascita.
RPMFusion consolida in un unico repository i pacchetti disponibili in precedenza da:
e consente agli utenti Fedora di accedere facilmente a tutti quei software che non possono essere distribuiti direttamente da Fedora.
Ricordo che Fedora include esclusivamente software open source con licenze approvate dalla Free Software Foundation e dalla OSI, escludendo esplicitamente tutti i software:
proprietari (es. adobe flash, drivers binari NVidia e ATI)
legalmente dubbi (es. decoder CSS per i DVD)
che implementino algoritmi coperti da patent (es. MoonLight, decoder MP3)
Per attivare il repository è sufficiente seguire le istruzioni
Parte del successo di Fedora come base per costruire distribuzioni specializzate si deve alla introduzione (in Fedora 7) del tool pungi, che affianca quello per la creazione dei LiveCD Il tool si occupa di:
Collezionare i pacchetti richiesti dai repository configurati
Eseguire anaconda (buildinstall) sulla collezione
Suddividere la collezione in blocchi della dimensione desiderata
Creare immagini iso dei blocchi
Controllare la correttezza della collezione.
Le spin ufficiali sono elencate in una pagina dedicata Alcuni esempi di Spin esistenti o in fase di sviluppo:
I have found out in the Rodriguez & Urlocker blog that chances are EBay would sell Skype (actually, I did not understand why they bought it in the first place...)
Now the question is: can Red Hat, Novell or anyone else with enough quids in the pocket (Mark, are you listening?!?) and the right Open Source attitude buy it and make it finally open?
Sembra che dopo tutto non sia il solito caso di "Che vuoi che ne sappiamo noi di un sistema operativo usato si e no da un utente su cento": nel forum delle Pagine Gialle c'è chi si lamenta che non funziona neanche con Windows...
A questo punto la domanda diventa: ma visto che la prima beta di Flash 10 era uscita a maggio, è possibile che alla SEAT in cinque mesi non se ne sia accorto nessuno?
PackageKit mi avverte che c'è un aggiornamento - controllo di cosa si tratta - ah! - è uscito Flash 10 per Linux - ma pensa te, stavolta si sono degnati di farlo uscire assieme alla versione Windows e Mac - via installo - peggio del vecchio non può essere - oppure si?
Ritorno sull'argomento boot con un po' di ritardo, anche per fare in modo che l'articolo di LWN che ne parla sia accessibile a tutti (appena usciti sono riservati agli abbonati).
Per prima cosa, un chiarimento doveroso: a meno di "miracoli", è improbabile che i nostri laptop riusciranno a fare un boot in 5 secondi (e neanche in 10...) troppo presto; le modifiche apportate ai vari componenti del sistema lo hanno reso un Eee-PC da Formula 1, e come (purtroppo) sappiamo, non tutte le meraviglie che si trovano nelle monoposto da F1 sono trasportabili nelle macchine di serie.
Detto questo, vediamo alcuni dettagli. Per iniziare, gli sviluppatori hanno investigato i tempi di boot del sistema con diverse distribuzioni, utilizzando il tool Bootchart.
La prima scoperta è che i tempi originali, per la cronaca intorno ai 45-50 secondi, sono appesantiti da voci quantomeno "curiose": as esempio, Fedora spende due secondi per far partire sendmail e altri 5(!!!) per il demone setroubleshootd. Ubuntu non è da meno, bruciando 2.5 secondi di sola CPU per mostrare l'immagine di sfondo per GDM e altrettanti per caricare il tool di gestione dei driver proprietari.
In ogni modo è chiaro che anche risolvendo questi problemi il target dei 5 secondi è inarrivabile senza un approccio radicalmente diverso. L'idea è stata quella di invertire l'approccio, assegnando a priori un "budget" ad ogni componente del boot e lavorando poi sulle componenti per rientrare in quanto stabilito.
La ripartizione è: un secondo per caricare kernel, un altro secondo per gli script di init, un secondo per X e due per l'ambiente desktop.
Per raggiungere tale risultato le principali modifiche hanno interessato:
kernel, compilando i driver necessari non come modulo
kernel, patch per l'inizializzazione asincrona di alcuni sottosistemi
kernel, salvataggio della lista dei blocchi letti al boot (per sReadAhead)
sReadAhead, che permette di creare una cache dei dati letti al boot da usare nei successivi
Per la cronaca sReadAhead è già in review e speriamo entri presto in Fedora, per le patch del kernel pare che dovremo aspettare la 2.6.28 (a meno che i maintainer del kernel non decidano di includere la patch nell'RPM).
In un thread sulla mailing list fedora-devel dedicato al test di una nuova versione di readahead (il tool dedicato alla analisi e caching dei files letti durante il boot allo scopo di velocizzarlo), Arjan van de Ven ha annunciato che alla Linux plumbers conference terrà una presentazione su un sistema per fare modo che il boot duri 5 secondi!!! non vedo l'ora di sapene di più...
We simply refuse to accept that booting a netbook needs to take more than five seconds. We bite our nails and pull our hair every time we boot a Linux desktop system and wait for minutes before it's usable. We're so annoyed that between the time of submission and the plumbers conference, we will make our netbooks boot in 5 seconds, and even talk about how we did it.
From a post on fedora-devel by Lennart Poettering, PulseAudio maintainer and developer, a recipe to diagnose PA problems:
On Sat, 30.08.08 14:58, Ahmed Kamal wrote:
> Hi, > This is probably a bug. My laptop luckily suspends to disk and wakes up > fine. However, after waking up there is no sound. I found pulseaudio not > running. I started it manually and sound was there again. However, a second > suspend/wakeup, and pulseaudio is still running, however there is no audio > output too! Let me know if I need to run some experiments to get this fixed
This usually means that the driver is not following the ALSA suspend/resume protocol correctly.
Please terminate PA by running "pulseaudio -k". Then, start pa in a terminal via "pulseaudio -vvvv". Then suspend/resume, paste the output of PA in that terminal.
Già già, è di nuovo tempo di scegliere il nome di una release, il ciclo di rilascio a sei mesi è proprio incalzante...
I nomi tra cui scegliere questa volta erano:
Cambridge
Farnsworth
Mississippi
Nile
Nitrate
Saltpetre
Terror
Water
Whiskey Run
E ci sono stati 390 votanti su 1900 potenziali aventi diritto.
La votazione è avvenuta con una nuova applicazione scritta con il solito TurboGears dall'ottimo infrastructure team. In pratica ad ogni votante sono presentate le varie opzioni con associato un voto da 0 a 9; in questo modo si può indicare una preferenza pesata e multipla: se A e B mi sembrano validi, li posso votare entrambi ma dare un peso maggiore ad A rispetto a B.
E a proposito di Linux, avendo appena finito di leggere una intervista a Linus Torvalds, non posso fare a meno di notare che ha installato Fedora 9 sulle maggior parte dei computer che usa ( si, si, dice anche che Ubuntu gli piace... )
Trovo estremamente condivisibile la parte in cui commenta il sistema delle patent che, al contrario delle intenzioni originali del legislatore, oggi sono usate come mezzo per impedire la competizione, e senza competizione c'è poca (o nulla) innovazione.
In definitiva lo trovo un bell'articolo; mi dispiace solo che non mi pare ci sia nessuna frase che possa entrare nell'olimpo delle citazioni di Linus; la mia preferita?
Intervistatore: Out of curiosity, do you have anything to say to hardware manufacturers who refuse to release datasheets or specifications about the functioning of their hardware so it could operate with the Linux kernel?
LT: Is "I hope you all die a painful death" too strong?
WOW, quasi due mesi di silenzio sul blog... per fortuna non pare che sia mancato a molti :)
In ogni modo, è stato rilasciato il kernel 2.6.26, che come al solito contiene un discreto numero di modifiche.
In particolare, mi pare valga la pena notare come sia stato aggiunto il supporto per le periferiche UVC ( USB Video Device ), ovvero lo standard seguito da un discreto numero di webcam, telecamere e altre perfiferche di cattura video ( TV tuner, etc ). Ora ci manca solo l'applicazione per sostituire skype...
Interessante anche l'aggiunta del supporto ACPI per i possessori di Eee PC; dato il successo del piccoletto di casa ASUS, ci saranno molti utenti soddisfatti...
A proposito, per chi volesse Fedora su Eee, un articolo su Red Hat Magazine di qualche tempo fa presentava il progetto Eeedora.
Sul wiki del progetto Fedora è invece tracciato lo stato del supporto di Fedora su Eee PC
Ho constatato parlando con diverse persone che le memorie flash sono considerate praticamente indistruttibili. Effettivamente, se si parla di resistenza meccanica una memoria flash è difficilmente danneggiabile, ma se parliamo di durata nel tempo non siamo messi molto bene...
Infatti, molti sembrano ignorare che ogni blocco di memoria in una flash può sopportare solo un certo numero di cicli di cancellazione/riscrittura prima di diventare inservibile.
Qualcuno mi ha detto: non c'è problema, tanto io di solito lo uso quasi come un CD (per esempio, storage per file musicali), quindi sto a posto: ecco, non è proprio così...
Dopo un certo numero di oprazioni di lettura diventa comunque necessario un "rinfresco", cioè un ciclo di cancellazione/riscrittura dei dati e quindi anche l'utilizzo in sola lettura in realtà accorcia la vita delle flash.
Per approfindire l'argomento, provate questo interessante articolo che descrive l'anatomia di alcuni file system Linux dedicati alle memorie flash.
Pur essendo uscita da pochi giorni Fedora 9, sulla mailing list degli sviluppatori è già iniziata la discussione per la scelta del nome di Fedora 10; chiunque può fare la sua proposta rispettando le seguenti "regole":
Deve esistere un link tra il nome della 9 (Sulphur) e il nuovo nome. Più specificamente, entrambi devono avere in comune lo stesso "è un"
il link fra Sulphur e il nuovo nome deve essere diverso da quello che c'è fra Werewolf (Fedora 8) e Sulphur. Il link era: "sono entrambe cose che reagiscono malamente all'argento"
Fra tutti i nomi proposti che passeranno il vaglio del team di legali della Red Hat, un ballottaggio deciderà quello definitivo.
Da un lato è un peccato che si sappia subito qual'è la connessione, fino alla Fedora Core 4 scoprire cosa legava i nomi in codice era un discreto passatempo...
I was in need of profiling a PHP application I use to hack on (Mantis issue tracker) to determine how a certain page was eating more than 16Mb (my PHP memory limit) to load.
This turned to be very easy; for a start, I installed the xdebug package with:
yum install php-pecl-xdebug
then I edited the configuration file /etc/php.d/xdebug.ini and added:
xdebug.auto_trace = On xdebug.show_mem_delta = On
Now I reloaded the page in the browser and got a shiny detailed report about memory consumption during the code execution in /tmp:
From that kind of report it is quite easy to spot big memory hoggers; in my case, I discovered about half of the peak memory usage (about 29Mb) is used for composing a single form control...
Con perfetto timing, ho sostituito il glorioso laptop ASUS M6Ne che mi ha servito egregiamente negli ultimi anni con un massiccio Toshiba Tecra S5-141. Quale miglior momento per fare l'upgrade a Fedora 9?
Già che c'ero, ho installato al versione 64bit, per cui ora mi ritrovo con una serie di questioni "interessanti" da risolvere, ovviamente per lo più legate a prodotti proprietari...
Per esempio, la Adobe distribuisce il pacchetto flash sotto forma di rpm (bene), fornendo anche un repository yum (bene), dal quale poter regolarmente aggiornare con uno yum update (bene).
Il problema è che è disponibile _solo_ la versione i386 (MALE), per cui per poter usare flash in Firefox, e magari anche sentire qualcosa (youtube?) è necessario eseguire i seguenti comandi (soluzione trovata sulla ML fedora-devel)
E' stato rilasciato il kernel 2.6.25 (che per la cronaca, è già stato incluso in Fedora 9).
Tra le molte feature interessanti, da notare l'ingresso del driver ath5k per le schede di rete con chipset Atheros, che si trovano sia versione PCI, USB, nonchè come primo equipaggiamento nei portatili, tra i quali il MacBook Pro.
Questo, assieme al fatto che uno dei principali sviluppatori del driver ath5k è stato assunto dalla Atheros per continuare lo sviluppo, apre ottime prospettive al supporto di questo chipset, che fino ad ora si poteva usare solo con i driver esterni al kernel presenti in livna
Jesse Keating, il release manager di Fedora, ha annunciato che è stato deciso di far slittare il rilascio di due settimane, principalmente a causa della necessità di avere più tempo per risolvere alcuni bug ed eseguire altri test sulla distribuzione
La buona notizia è che, a tale scopo, è stata preparata una nuova preview release, quindi buon testing a tutti!
Mancano ancora diversi giorni all'uscita ufficiale, ma alcuni siti già si stanno cimentando in review della nuova Sulphur; per esempio ho trovato questa di Channel News abbastanza accurata.
Per chi fosse interessato, è disponibile sul wiki la lista ufficiale delle features aggiunte a Fedora 9.
Personalmente trovo degne di nota (in nessun ordine particolare)
gcc4.3: tutti i pacchetti sono stati ricompilati con l'ultima versione di gcc, risolvendo nel contempo i problemi di compilazione riscontrati (per fortuna in nessuno dei miei ;) )
Live Persistence: il disco live è in grado di salvare su una chiave USB il suo stato per poi ripristinarlo all'avvio successivo.
Partition Resizing: questo ci mancava proprio: il resize delle partizioni durante l'installazione
Dictionary Support: consolidamento dei diversi dizionari usati dai programmi in una singola libreria (hunspell)
Pre Upgrade: esamina il sistema, determina quali pacchetti sono da aggiornare e li scarica prima di eseguire l'upgrade Fedora N => Fedora N+1
PackageKit: unifica il frontend di gestione dei pacchetti sulle diverse distribuzioni
Per ultimo, visto che non capita spesso :P , noto con piacere che un progetto nato in Ubuntu viene integrato in Fedora: Upstart. Vedremo quali benefici se ne potranno avere.
Come molti(?) sanno, la imminente release di Fedora 9 avrà il nome in codice "Sulphur"; una volta scelto il nome, il sempre ottimo art team ha messo insieme una serie di proposte e alla fine è stato scelto il tema Waves.
La Linux Foundation ha pubblicato un articolo che raccoglie in forma ordinata una serie di dati sullo sviluppo di Linux degli ultimi 2 anni e mezzo; lo studio copre le versioni di Linux dalla 2.6.11 alla 2.6.24. Alcuni punti salienti:
nel periodo in esame c'è stato in media un rilascio ogni 2.7 mesi
il numero di linee di codice è aumentato del 50% circa
il kernel 2.6.24 ha quasi 9 milioni di linee di codice
c'è stata una media di 3.621 linee aggiunte, 1.550 rimosse e 1,425 linee modificate ogni giorno
al kernel 2.6.24 hanno contribuito più di mille sviluppatori e 186 ditte
delle 186 ditte identificate la prima per numero di contributi è la Red Hat, seguita da Novell e molto più indietro da Mandriva
In particolare questo ultimo dato è uno dei motivi per cui ho scelto di usare Fedora; si può accedere in "anteprima" alle nuove tecnologie disponibili (non solo nel kernel) e in questo modo rendere preziosi anche piccoli contributi sotto forma di testing, bug report etc.
Molto interessante è anche le sezione Why Companies Support Kernel Development in cui più o meno si dice:
Ditte come IBM, Intel, SGI, MIPS, Freescale, HP, etc. lavorano per assicurarsi che Linux funzioni bene sul loro hardwaree. Questo rende le loro offerte più attraenti agli utenti Linux e ciò aumenta le loro vendite.
Distributori come Red Hat, Novell, e MontaVista hanno un chiaro interesse nel rendere Linux il più capace possibile. Sebbene queste aziende competano fortemente fra di loro per la clientela, tutte lavorano insieme per migliorare il kernel Linux
Compagnie come Sony, Nokia, e Samsung includono Linux come componente di prodotti quali video camere, televisioni e telefoni cellulari. Lavorare nel processo di sviluppo aiuta queste compagnie ad assicurarsi che Linux continui ad essere una solida base per i loro futuri prodotti
Aggiornamento: La Red Hat ha fatto una propria press release sull'argomento
I files .spec contengono le istruzioni per creare i pacchetti RPM; al loro interno solitamente vengono usate delle "macro" in modo da semplificare la vita ai packager. Ad esempio, il file buildbot.spec contiene: Name: buildbot Version: 0.7.6 Release: 2%{?dist} Summary: Build/test automation system
Da notare come la riga Source0 (che identifica dove i sorgenti sono reperibili) usi le macro %{name} e %{version} che vengono poi espanse a "buildbot" e "0.7.6" rispettivamente.
Se uno si vuole scaricare i sorgenti, ovviamente può comporre il link facendo un po' di copia/incolla e sostituendo a mano le macro, ma ho sempre pensato ci dovesse essere un metodo più semplice... ed effettivamente c'è:
Ho trovato un interessante articolo che spiega le tre W (What, Where, When) di quei files che ogni tanto si ritrovano nell'hard disk a seguito di una update: i files .rpmnew e .rpmsave.
Per esempio, se installo dnsmasq e ne modifico il file di
configurazione (/etc/dnsmasq.conf) al primo update del pacchetto mi
ritroverò con i files /etc/dnsmasq.conf e /etc/dnsmasq.conf.rpmnew
Sebbene normalmente non sia chiaro cosa farne, in realtà sono molto utili perchè sono il risultato della cautela usata dai maintainer dei pacchetti RPM nel non sovrascrivere i files di configurazione che siano stati modificati dall'utente.
In particolare si possono avere due situazioni in cui, a discrezione del maintainer, il file modificato verrà:
usato anche dopo l'upgrade
rimpiazzato dal nuovo
La maggior parte (se non tutti) gli RPM utilizzano la prima soluzione nella quale il file di configurazione è preservato e quello nuovo viene creato come file .rpmnew.
A questo punto di solito è sufficiente un diff tool qualunque (diff, gvim -d, meld) per verificare quali differenze sono rilevanti e includerle nel file di configurazione; infine il file .rpmnew può essere rimosso.
Ho l'impressione che gli amici di Ubuntu non solo riescano a "stare al passo" di un rilascio ogni sei mesi o giù di lì (cosa che sembra facile, ma in realtà non è proprio ovvia...) ma fanno anche un gran bel lavoro dal punto di vista marketing.
Per ogni rilascio, incluse le versioni alpha, si trovano precisi e puntuali articoli di presentazione e commento sui vari siti del settore come per esempio OSNews oppure, per rimanere sul suolo nazionale, Punto Informatico, oltre a una miriade di blogger che ne recensiscono le features.
E' chiaro che il successo di Ubuntu non può essere attributo al solo marketing, ma da buon sostenitore di Fedora non posso che cercare di dare il mio piccolo contributo: visto che mi pare non ci sia troppa "copertura" in italiano di quello che succede nel mondo Fedora, cercherò di proporre in questo spazio una selezione delle notizie legate allo sviluppo della distribuzione che mi capita di leggere.
In breve, se conoscete Fedora, rimanete con noi; ma se non l'avete mai provata, fatelo!
