A succedere Jared Smith sarà quindi Robyn Bergon, che da un po’ di tempo a questa parte ha saputo dimostrare il suo valore che insieme alle sue capacità l’hanno portata ad essere la figura di massima rappresentanza di una distro storica come Fedora. Smith comunque seguirà ancora per un breve periodo di tempo Bergon per aiutarla in un ruolo così importante.

Fedora in questo ultimo periodo ha incominciato un incredibile piano di riscatto, dopo un periodo un po’ fiacco, il progetto ha ripreso entusiasmo con l’annuncio di Fedora 17 Beefy Miracle.

Questa nuova versione ha portato un grandissimo entusiasmo anche sul web, che attende con impazienza questa release. Se le varie ipotesi quali il passaggio a distro rolling release e la possibile introduzione di Btrfs, dovessero essere confermate se ne vedranno delle belle. Il lavoro è iniziato, non mi resta che augurare buona fortuna al nuovo Project Leader per il nuovo incarico.

Via | Fedora-it

Nei giorni scorsi si è tenuto una riunione dei membri del Fedora Engineering Steering Committee (FESCo), dove si è discusso l’ultimo giro di features per Fedora 17. Il team oltre a lavorare a numerose altre featurs è impegnata nell’introduzione di Btrfs come file system di default. Ci sono già delle prove in atto

In origine Btrfs era destinato già ad essere il FS di default su Fedora 16, ma a causa della mancanza di un utility fsck per Brtfs l’adozione saltò. Questa utily è in procinto di essere rilasciata. Ci sono ancora ben sette bug aperti riguardanti Brtfs su Bugzilla, se questi verranno corretti in circa due settimane potremo avere questo nuovo FS di default su Fedora 17.

Via | Phoronix

Le proposte per questo ipotetico passaggio sono due: la prima consiste nel trasformare in rolling release Fedora Rawhide, non ritenuto ad ora stabile e l’altra riguarderebbe una nuova politica per i cicli di rilasci.

Se così sarà, Fedora farà a mio parere un grandissimo passo avanti. Fedora 17 è già un ottimo progetto, portato avanti dalla comunità con ottimo successo, in rete se ne parla davvero tanto e siamo sicuri che non verremo delusi da questo rilascio. Non ci resta che attendere e perché no seguire la discussione all’interno della mailing list di Fedora per captare altre novità. Voi che ne pensate di questo possibile cambio di rotta di Fedora?

Via | Fedora Mailing List

In sintesi, le cartelle /bin, /lib e /sbin di Fedora 17 saranno installate in /usr e sostituite da link simbolici. È una transizione iniziata da Oracle quindici anni fa e seguita finora da tutte le distribuzioni di Linux. Fedora 17 completerà questo spostamento, com’è avvenuto col rilascio di Solaris 11. Le motivazioni sono diverse.

La modifica è legata soprattutto all’init di sistema, ovvero – nel caso di Fedora – a systemd. Poiché esiste già il bisogno di montare /usr da initramfs, lo spostamento dei componenti fondamentali è una scelta razionale: il primo beneficio è nella possibilità d’effettuare degli snapshot dell’intero sistema, montato in sola-lettura.

Lavorando con soluzioni di rete, lo spostamento riduce la tempistica di replicazione della gerarchia per tutte le macchine da gestire e migliora la virtualizzazione. Restano nella medesima posizione, invece, quei file che non potrebbero essere condivisi sul network: nello specifico, si tratta delle cartelle /etc, /run, /tmp e /var.

Uno degli obiettivi di Hoyer e Sievers è la possibilità di passare alla nuova struttura gerarchica senza necessariamente installare un sistema ex novo. È in fase d’elaborazione uno script che permetta di spostare i percorsi esistenti, prima di ricompilare i componenti essenziali: un espediente molto utile con le altre distribuzioni.

Sebbene la scelta d’emulare la gerarchia di Solaris 11 sia, al momento, limitata a Fedora 17… il merging del sistema in /usr potrebbe essere ripreso quanto prima da altre distribuzioni. Sopratutto quelle che implementeranno systemd, da openSUSE a Gentoo (che dovrebbe sostituire OpenRC). Nei pacchetti il cambiamento influirà su RPM.

Via | Lennart Poettering

Sono stati confermati alcuni pacchetti che erano stati messi in discussione, infatti troviamo GNOME 3.4, Plasma Workspace 4.8 e Gimp 2.8, tutte versioni non ancora rilasciate ma che dovrebbero arrivare nelle prossime settimane. Altro componente importante in Fedora 17 sarà Riak e oVirt, componenti utilizzati in Red Hat Enterprise Virtualization 3, rilasciata ieri.

Fedora 17 potrebbe essere una piacevole sorpresa per questo 2012, nonostante i numerosi progressi di alcune distro maggiori come Ubuntu che con la versione 12.04 dovrebbe puntare all’affermazione definitiva come distro più popolare e Linux Mint, distro tuttofare, Fedora potrebbe ricominciare a dire la sua; i presupposti ci sono tutti ora non resta che portare a termine un ottimo lavoro iniziato con tanto entusiasmo.

Via | H Online

L’interfaccia di Fedora Packages è essenziale e orientata alla ricerca. Rispetto alle soluzioni create per altre distribuzioni, quella di Red Hat è una risorsa più completa: l’elenco dei dettagli forniti richiama piuttosto Launchpad, la piattaforma di Canonical. Il recupero dei risultati delle ricerche appare particolarmente rapido.

Oltre alle informazioni generali sui pacchetti, alle dipendenze e alle versioni disponibili, Fedora Packages elenca proprio come Launchpad le build create con successo e quelle che presentano degli errori, più le patch sottoposte a revisione. È un archivio generato da Fedora Community — l’applicazione web della comunità di Red Hat.

Fedora Packages

Via | Máirín Duffy

Nacho, è famoso per aver sviluppato e per il suo sviluppo di plugin orientati alla programmazione: gedit-latex e gedit-cossa su tutti. Il codice di gedit-code-assistance è disponibile oltre che sui repository Fedora 16, anche su GitHub. La compilazione inoltre è molto rapida ed il plugin risulta essere subito operativo.

Ho avuto modo di provare rapidamente il plugin e pare funzionare piuttosto bene, la speranza è quella che anche questo come Gedit Dash passi upstream e venga accolto in gnome-plugins. Gedit grazie all’aiuto di questi plugin diventa un prodotto sempre più orientato allo sviluppo, gli sviluppatori e apprendisti sviluppatori ringraziano.

Via | Nacho Blog

Fedora 17, che arriverà a Maggio 2012 salvo ritardi, porterà con se’ una semi-rivoluzione strutturale. Tra le features proposte presentate dal team e approvate dal FESCo c’è anche quella di memorizzare tutte le applicazioni e librerie in /usr/, questo significherebbe andare a creare una vera e propria rivoluzione strutturale del FS; ma per varie ed ovvie ragioni, la compatibilità sarà garantita tramite link simbolici.

Di conseguenza, tutte le varie cartelle come /lib/, /lib64/, /bin/ ed /sbin/ andranno sotto /usr/ e questo permetterà di montare quasi tutto il sistema operativo in read-only, farne snapshots atomici, o condividerlo tra hosts in modo da risparmiare manutenzione e spazio.

Tra le altre novità di Fedora 17, nome in codice Beefy Miracle troviamo la rimozione di ConsoleKit, l’introduzione al “multi-seat”, l’avvio di tutti i servizi attraverso systemd e la possibilità di utilizzare Gnome Shell anche su sistemi privi di accelerazione 3D.

Via | Fedora Project

Giovanni Campagna, è questo il nome del giovane ragazzo Italiano che ha smosso la mailing list di Fedora al fine di avere un software center anche su Fedora. Se su Ubuntu L’USC (Ubuntu Software Center) è uno degli elementi più adatti ai nuovi utenti, Debating potrebbe essere quello per Fedora. L’idea di Campagna era quella di effettuare un vero e proprio porting dell’USC su Fedora.

Le opinioni all’interno della discussione riguardo Debating sono principalmente due: ci sono gli sviluppatori Fedora che non sentono la necessità di avere ed utilizzare un software center o “app store” ed altri che appaiono favorevoli. Certo, questa idea di creare o avere un software center per Fedora sarebbe una grandissima cosa sopratutto per i nuovi utenti che non familiarizzano in tempi record con YUM. Si vedrà qualcosa per Fedora 17?

Via | Fedora Mailing List

La premessa è d’obbligo perché gli sviluppatori di Red Hat potrebbero fare altrettanto con journald (il demone che controlla Journal) e il nuovo formato uscirebbe con Fedora 18 o superiore. Ha significato associare Journal alla distribuzione della comunità di Red Hat, poiché al pari di systemd è sviluppato da contributori di Fedora.

Prima d’entrare nel merito di Journal occorre specificare che il nuovo formato sarà compatibile a livello predefinito con Fedora, openSUSE e Mageia/Mandriva: gli utenti di Arch, Debian e Gentoo potranno installarlo in via del tutto opzionale con systemd. Ubuntu usa Upstart e Journal non può “sostituire” rsyslog sulla distribuzione.

Tra virgolette perché Journal non sostituisce affatto né rsyslog, né syslog-ng o altri logger di sistema. È stato concepito per lavorare in autonomia oppure affiancato a uno di loro. Le intenzioni degli sviluppatori, al riguardo, sono piuttosto contraddittorie: journald intende essere uno standard, però non essere «standardizzato».

La contraddizione è evidente a partire dalla compatibilità di Journal: essendo supportato soltanto da systemd, il nuovo formato esclude il funzionamento su tutte le distribuzioni. Il punto è controverso e, a prescindere dalla lunga descrizione, gli sviluppatori non precisano se la compatibilità riguardi Journal, journald o entrambi.

Journal è un formato, journald un demone: gli sviluppatori non li distinguono perché – al momento – non esistono altre implementazioni. L’unico paragone è con syslog. Le due soluzioni condividono almeno uno dei limiti affrontati da Poettering e Sievers. I sistemi UNIX–based utilizzano più d’una risorsa per la registrazione dei log.

L’intento è quello di ridurle a una sola, cioè Journal, che è legata a systemd e non può essere utilizzata altrove. Inoltre, Poettering e Sievers non vogliono cancellare del tutto syslog. Se non è un tentativo di presentare Journal mantenendo un basso profilo per non attirarsi delle “antipatie”, non si capisce granché del progetto.

Fortunatamente, i dettagli sul nuovo formato sono molto più precisi e giustificano l’attenzione al progetto. Journal fornisce dati strutturati, anziché di solo–testo, e risolve il problema dei privilegi d’accesso: la consultazione dei log è associabile a utenti o gruppi in modo avanzato e si possono autorizzare gli accessi parziali.

Il nuovo formato è estendibile, affinché qualunque applicazione richieda la registrazione d’un log possa integrarsi con Journal. Gli sviluppatori hanno prestato una particolare attenzione ai sistemi integrati: non si potrà disabilitare journald da systemd, però il logging può essere limitato alla gerarchia di /run — che è volatile.

Al contempo, Journal può soddisfare tutte le esigenze dei super–computer. I log generati sono trasferibili da un’architettura all’altra: ad esempio, è possibile consultare il log d’un sistema integrato con ARM da un server con x86/x86_64. La dimensione dei file prevede i metadata e supera quella di syslog restando comunque ridotta.

Journal non richiede alcuna manutenzione: il demone valuta da sé lo spazio occupabile dal log, in caso di capacità ridotte, e attiva la “rotazione” quando il registro richiede l’estensione. La scelta di salvare dei dati strutturati facilita di gran lunga l’esposizione delle informazioni alle applicazioni di monitoraggio del sistema.

Insomma, l’unica controversia riguarda la compatibilità: se non è prevista la standardizzazione di Journal è proprio perché il progetto non prevede l’applicazione esterna a systemd. La nuova concezione del logger, però, è molto convincente e attribuisce (se mai ce ne fosse davvero il bisogno) un ulteriore valore aggiunto a systemd.

Via | Lennart Poettering

Normalmente, il BIOS utilizza il Master Boot Record (MBR) ed EFI la GUID Partition Table (GPT). Fedora 16 installa quest’ultima a prescindere, creando dei problemi sulle macchine che prevedono ancora il BIOS. Il sistema operativo potrebbe non essere riconosciuto e, di conseguenza, Fedora 16 risulta inutilizzabile. C’è un workaround.

La soluzione più efficace è quella d’installare Fedora 16 inserendo nogpt tra le opzioni d’avvio del LiveCD. Se il problema si presenta a installazione completata, occorre ripristinare la partizione aggiuntiva prevista da GPT con fdisk, perché il BIOS la riconosca. A evidenziare il problema è Matthew Garrett, dipendente di Red Hat.

Via | Matthew Garrett

All’interno di un post lasciato nella mailing list del progetto Fedora, gli sviluppatori hanno annunciato la fine del supporto di Fedora 14 Laughlin” per il prossimo 8 Dicembre. Da questa data in poi, la versione in questione non riceverà più aggiornamenti, niente aggiornamenti di sicurezza o correzioni di bug critici e ovviamente i pacchetti non verranno più aggiornati.

Il ciclo di rilascio sponsorizzato dalla comunità Red Hat è relativamente breve, anche a “causa” dell’arrivo di una nuova versione ogni sei mesi (circa). In accordo con la policy corrente di Fedora, ci saranno aggiornamenti fino ad un mese dopo una nuova major release. Gli utenti di Fedora 14 sono invitati ad aggiornare a Fedora 15 o Fedora 16, dato che sono queste le versioni che riceveranno aggiornamenti nei prossimi mesi.

Possiedo una macchina con Fedora 14 e rimango basito per il cessato aggiornamento di questa versione che risulta essere ancora un ottimo prodotto. A mio parere esagerato cessare il supporto ad una versione rilasciato circa un anno fa. Voi che ne pensate?

Via | Fedora Mailing List

Anche Ubuntu, già da qualche anno tiene un portale molto simile col nome di Ask Ubuntu. L’idea alla base di questo progetto è molto buona, anche a causa di alcuni problemi ai quali è difficile trovare soluzioni sulla rete; creare un portale comunitario per i vari problemi degli utenti è un’ottima idea sopratutto se adattata alla realtà Fedora, dove i portali di supporto non sono molto frequentati.

Il portale sembra andare a gonfie vele, ci sono numerosi ticket aperti e altrettante risposte a conferma del buon avvio del progetto; all’interno della pagina “Badges”, possiamo trovare anche una sorta di classifica per i collaboratori, con il badge gold come il massimo premio di riconoscimento per l’ottimo lavoro svolto all’interno.

Fedora, avendo ristabilito gli equilibri con le proprie release ha deciso di puntare su uno degli elementi fondamentali per l’open source: la comunitarietà. Ask Fedora è un buonissimo progetto che affiancato ad un buonissimo prodotto quale Verne, può solamente giovare agli utenti della distro rpm-centrica per eccellenza. Che inizi proprio da qua la risalita di Fedora?

Via | Fedora

È arrivata nella giornata odierna, puntualissima a differenza delle versioni di testing, la tanto attesa Fedora 16, nome in codice Verne. Ad annunciare il tanto atteso rilascio è il sito italiano di Fedora che ha dedicato una homepage davvero molto carina.

Le novità per questa versione sono molteplici: abbiamo un aggiornamento di tutti i più grandi ambienti desktop, la rimozione di HAL, l’introduzione di GRUB 2, un migliorato supporto alle varie tecnologie per la virtualizzazione, l’ultima versione di OpenStack e il passaggio definitivo da SysV a SystemD. Le novità di questa versione sono davvero tante, per leggerle tutte possiamo consultare la lunghissima pagina delle note di rilascio.

Oltre alla versione tradizionale con GNOME 3.2, è stato aggiornato anche tutto il comparto delle “spin” composto da KDE, XFCE e LXDE, tutti aggiornati all’ultimissima versione rilasciata. Possiamo scaricare Fedora 16 direttamente dalla pagina “Scarica” del sito ufficiale Italiano, mentre per le varie “Spin” possiamo trovarle qua.

Nonostante sia uscita da pochissimo la versione 16, si parla già della versione 17 che ha già ricevuto “l’approvazione” di un personaggio di rilievo all’interno del mondo open source: Jono Bacon. Il community manager di Ubuntu infatti, durante l’ultima serata dell’Ubuntu Developer Summit ha voluto indossare il bizzarro costume del movimento Beefy Miracle, nome in codice di Fedora 17. Sicuramente una bella bella mossa quella di Bacon, che fa crescere l’attesa per quelle che saranno probabilmente le due migliori versioni di Ubuntu e Fedora.

Via | Fedora Project

Questa possibilità non è legata esclusivamente a Fedora 16: qualunque distribuzione può optare per l’accesso a GNOME Shell col rendering via software, in assenza d’accelerazione hardware. La distribuzione della comunità di Red Hat è semplicemente l’unica a scegliere GNOME 3.x come desktop predefinito. Perché, allora, tante critiche?

GNOME Shell divide gli estimatori del desktop environment. Molti, tra i quali emerge Linus Torvalds, preferiscono un’esperienza più tradizionale: alcuni sono passati a Xfce, altri hanno preferito la modalità fallback come Antonio Ospite su Debian. Fedora 16 annullerà ogni necessità d’accedere alla sessione d’emergenza di GNOME 3.x.

Via | Adam Williamson