Gli sviluppatori Fedora discutono su come implementare il supporto ARM. Nel thread aperto da Matthew Garrett viene posto il problema di determinare le condizioni entro le quali ritenere una piattaforma come primaria. Sembra che al momento ARM non verrà considerata alla pari di x86 e x86_64.
Più in dettaglio, la discussione ha avuto come punto focale la metrica e la qualità che sarebbero necessarie ad una architettura qualora venisse promossa allo status di “piattaforma primaria”. Attualmente se ARM venissa trattata come piattaforma primaria gli effetti sull’attuale flusso di lavoro interesserebbero diverse aree in termini di tempi di correzione bug, accesso all’hardware dedicato al testing e quantità di macchine disponibili per la compilazione. L’hardware attualmente a disposizione non consente di effettuare il passaggio senza incidere pesantemente sul lavoro di routine. Si sta quindi valutando un approccio che diminuisca la latenza e l’impatto sul ciclo di sviluppo principale.
Jon Brendan ha inoltre sottolineato la necessità di creare gli strumenti necessari per la correzione e la manutenzione dei pacchetti specifici per ARM. Quello che si deduce dalla discussione è la volontà di dare specifiche esatte per la promozione della piattaforma. Il sentimento generale è quello che non ha senso promuovere ARM se poi non potrà ricevere lo stesso trattamento delle altre architetture. L’integrazione deve essere totale.
Quindi se da un lato non sembra esserci lo stesso entusiasmo dimostrato da Canonical dall’altro si riconosce la necessità di seguire la tendenza ARM con i dovuti standard, senza compromessi. Nel frattempo i rilasci verranno effettuati modificando un flag di Koji e i bug critici non costituiranno motivi di ritardo per il rilascio ufficiale di Fedora.
Via | Phoronix
]]>
Zif è un package manager, alternativo a YUM, che si basa su 
Lumberjack è la risposta, probabilmente definitiva, alla molteplicità di servizi esistenti per il logging di sistema su Linux. Quando Lennart Poettering – il creatore di 
oVirt è, sostanzialmente, un’interfaccia web per la gestione delle macchine virtuali. Patrocinata dalla società del “cappello rosso”, è integrata in Red Hat Enterprise Virtualisation (RHEV): una distribuzione dedicata. Nonostante il numero, la versione 3.0 è il primo rilascio ufficiale del progetto e prevede altrettanti componenti.
Fedora Packages è l’ultimo risultato degli sforzi della comunità di Red Hat per arricchire la documentazione esistente. Proposto tuttora in via sperimentale, è – come s’intuisce dal nome – un elenco dettagliato dei pacchetti installabili sulla distribuzione: equivale agli omonimi disponibili per Debian e Ubuntu, ma sembra migliore.
Ceylon ha raggiunto il rilascio della prima “pietra miliare”, che era stata annunciata il mese scorso: il linguaggio – sviluppato da Red Hat – è un’alternativa a Java, compatibile con qualunque JVM. In settimana seguirà la distribuzione dell’estensione per Eclipse, disponibile in anteprima. Ceylon M1, AKA “Newton”, non è completo.
Circa due mesi fa, la notizia dell’acquisizione di Gluster da parte di Red Hat aveva posto l’attenzione sulle nuove tecnologie per l’ottimizzazione in ambito storage. Razionalizzare ed abbattere i costi, queste sono le priorità per la società del “cappello rosso”. In questo senso, anche il rilascio di RHEL 6.2 ha denotato questa chiara vocazione.
Sebbene RHEL 6.2 non venga considerata dagli ingegneri Red Hat una major release, questo rilascio porta importanti novità per quanto riguarda il supporto di nuove tecnologie hardware. I concetti chiave per questa versione sono: miglioramento delle prestazioni dello storage enterprise, affidabilità e riduzione dei costi.
Fedora 16 è stata rilasciata soltanto dieci giorni fa, eppure sono già emersi alcuni problemi piuttosto rilevanti. In particolare l’installazione con Anaconda presenta una gestione sui generis dell’interfaccia di I/O. Il difetto riguarda Extensible Firmware Interface (EFI): no, il Secure Boot e Microsoft questa volta non c’entrano.