Btrfs, sulla cresta dell’onda

Arrivata l’estate, e il caldo, sembra ci sia sempre bisogno di qualche nuova moda. Ora sembra essere il momento di btrfs.
Ottimo articolo di vaurora su LWN, subito slashdottato, cui seguono una marea di articoli, tweet e segnalazioni; how-to a volontà, e pure Marco Bellumori sul planet italiano. Nonostante tutto, io ci andrei coi piedi di piombo.

Capiamoci: adoro btrfs. Seguo da diverso tempo il progetto ed effettivamente non mi azzarderei ad usarlo per niente altro rispetto a quello che viene consigliato: testing e benchmarking. E no, convertirci la root della propria workstation non mi sembra un grande idea, nemmeno se lo fa Linus in persona (per poi toccare con mano il risultato).

Attualmente a btrfs manca ancora molto per  essere un filesystem anche solo lontanamente utilizzabile e per soddisfare tutte le promesse che (l’ottima)  progettazione lascia intendere (ENOSPC, gestione degli snapshot, un RAID meno incasinato per citarne alcuni). Per non parlare della parte userland, che oserei definire ancora parecchio abbozzata. Non posso quindi che mettere in guardia gli utenti/smanettoni/saccenti  dell’ultima ora e nel contempo invitare chi ha voglia di mettere mano al codice a dare un’occhiata e perdere qualche ora sopra a questo preogetto, a mio parere molto promettente. Per conto mio, continuo a studiarmi il design e sistemare piccoli buchi di volta in volta.

Ah, se nonostante tutto siete riusciti a incasinare la vostra installazione, qui ci sono dei dischi live che vi potrebbero tornare utili per recuperare i dati.

Btrfs, sulla cresta dell’onda

You got it all… wrong

A volte capita, qualche incomprensione o qualche passaggio perso nella traduzione in lingua. Il problema è quando inizia a venire ripresa una notizia sbagliata, o senza le condizioni al contorno, e ben presto si trasforma in tutt’altra cosa. Intervengo quindi, mio malgrado a gamba tesa, sul post di Pollycoke (che è già stato ripreso almeno qui e qui, ma ho paura si spargerà presto oltre), metto per un momento il mio cappello da Debian Developer e cerco di chiarire ciò che non è stato compreso, condendo il tutto con qualche buon link.

Intanto, la discussione non riguarda per nulla i firmware proprietari o driver o cose simili nella loro definizione classica (so che stan già tutti pensando ai driver Nvidia o ai firmware delle schede wifi Intel), quelli non ho la più pallida idea di come sian stati tirati in ballo perchè non hanno a che fare con questa votazione.
Poi, non non è nulla di «clamoroso» perchè scelte simili eran già state effettuate per le vecchie release (per diversi firmware inclusi nel kernel, e ora altri ne sono stati aggiunti upstream). Inoltre, l’ex-segretario Manoj non si è dimesso per la scelta finale (infatti ha dato le dimissioni prima della fine della votazione e prima  che si conoscesse l’esito) ma per alcuni malumori su come era stata impostata la votazione.
Infine, l’esito della votazione è, citando testualmente: «Daremo priorità al rilascio imminente di Lenny piuttosto che sinstemare ogni singolo tassello; per questa ragione la rimozione dei firmware senza sorgente sarà un processo al meglio dei nostri sforzi, e in Debian Lenny saran distribuiti quei firmware per cui ci è legalmente possibile farlo E che sono distribuiti dall’upstream sotto una licenza che rispetti le DFSG.» (Proposal E, punto 4, traduzione e enfasi mie)
Fin qui, solo le necessarie correzioni.

Scendendo nei dettagli, l’oggetto della discussione sono quei pezzi di firmware distruibiti dall’upstream (Linus e kernel.org, nello specifico caso) sotto una licenza che rispetti le DFSG (GPLv2 nel caso del kernel Linux, da cui il titolo di questo risultato) che sono attualmente inseriti come buffer di codice esadecimale all’interno dei sorgenti C del kernel (comunemente detti blob). Ci sono vari bug-report aperti in proposito, nonchè una pagina del wiki un po’ più discorsiva. In estrema sintesi, questi pezzi di binari sono dati da caricare nei dispositivi per l’inizializzazione affinché i componenti funzionino correttamente e non è semplicissimo definire quale ne debba essere l’effettivo formato sorgente preferito.
Secondo molti kernel hacker la questione non è troppo poblematica, tuttavia altri sviluppatori (upstream e non) stanno lavorando affinchè si possa non averli direttamente distribuiti dentro al kernel, senza arrecare troppi problemi agli utenti. Il progetto GNU ha un’iniziativa mirata alla rimozione completa di questi firmware. Debian si trova a metà, tra l’incudine e il martello, tra gli utenti e l’upstream (e vincolata dalle DFSG) in posizione assai più delicata.

L’esito della votazione rispetta le DFSG e il Contratto Sociale, perché tiene conto del nostro impegno verso gli utenti E il software libero e perché (legalmente) il firmware distribuito in forma esadecimale (blob) nei sorgenti di Linux ricade a tutti gli effetti sotto la licenza stessa del prodotto distribuito (per il kernel GPLv2 ove non altrimenti specificato).

In conclusione, con questa votazione il progetto Debian ha stabilito che per Lenny rispetterà le scelte dell’upstream (del kernel) di definire tali blob come effettivamente coperti da GPL (e quindi nella loro forma di sorgente preferito), pur non ritenendo ottimale la situazione attuale, dovendo dare priorità al prossimo rilascio stabile e lasciando a metà la soluzione di questa problematica (rimettendola agli sforzi dei singoli o a una futura decisione).

Aggiungerei solo che questo post è frutto di quanto è di mia conoscenza, senza addentrarmi troppo nelle discussioni più sottili o nei tecnicismi e cercando di restare oggettivo. Posso chiaramente avero perso alcuni punti interessanti/non-banali per strada o commesso qualche imprecisione, per cui i commenti costruttivi/non-frivoli sono benvenuti.

P.S. sì, cit. The Hives 🙂

You got it all… wrong

Rebootless Linux kernel security updates

Some of you may have already read of ksplice, a recently announced hot-patching system for Linux kernels. Given the actual kernel source tree and a security patch to be applied (which shouldn’t include semantic changes), it can build a kernel module with the fix which would introduce a trampoline to the bug-fixed object. The mechanism, along with other limitations, is described more deeply in the accompanying paper.

An RFP was reported a couple of days ago, for which I’ve put an initial rough packaging under collab-maint with git (both source package and i386 binary are already available). All the things are still a bit unripe, thus before allowing it into unstable I’d like to find a co-maintainer (preferably with a good kernel knowledge 🙂 ). So, if you found it useful and want to help, feel free to drop me a note.

Rebootless Linux kernel security updates