back

Non sono convinto al 100% che questo stesso sia il modo migliore per trattare i firmware, e ovviamente sarebbe meglio avere il codice sorgente per tutto. Tuttavia, come già descritto nel testo che accompagna la votazione, dovremmo smettere di impedire ad alcuni utenti di installare Debian del tutto se loro hanno sistemi che richiedono tali firmware durante l'installazione. È stato proposto che dovremmo preparare un sezione "firmware" separata nell'archivio e includere tale sezione nei CD di installazione ecc. per aiutare questi utenti, ma i dettagli precisi di questa implementazione saranno lasciati da parte fino ai risultati della votazione. Infine, l'intero progetto ha fatto una scelta diversa e quindi non abbiamo approfondito di più tutto questo (vedi http://www.debian.org/vote/2008/vote_003.

You're asking about a very controversial discussion that we've had within Debian, as I'm sure you know. As part of the vote that was called on this [1], I seconded a proposal that would allow us to relax our requirmements for certain code, specifically firmware. To quote that proposal: "Firmware is data such as microcode or lookup tables that is loaded into hardware components in order to make the component function properly. It is not code that is run on the host CPU."

I'm not 100% convinced that this itself is the best way to treat firmware, and it would of course be even better to have the source for everything. However, as also described in the text that accompanied the vote, we may end up stopping some users from installing Debian at all if they have systems that require such firmware during installation. It was proposed that we might set up a separate "firmware" section in the archive and include that section on installer CDs etc. to help these users, but the exact details of that implementation would be left until after the vote result. In the end, the project as a whole made a different choice so we didn't explore this any further.


Aver "accettato" il codice esadecimale dei firmware nel kernel (o perlomeno averlo accettato come codice sorgente) è un primo passo verso una debian meno libera?

Having accepted the hexadecimal code of the firmware in the kernel (or at least as source code) could be seen as the first step towards a less free Debian?

No, non credo. Stiamo continuamente migliorando Debian in tutti i modi che possiamo, anche dal punto di vista della libertà. Il team del kernel sta ancora lavorando a monte per rimuovere o rimpiazzare le parti con firmware non-free quando possibile e Squeeze sembra sarà meglio di Lenny in questo, proprio come Lenny è stata meglio di Etch prima.

No, I don't think so. We're continuing to improve Debian in all the ways we can, including in terms of freedom. The kernel team are still working with upstream to remove or replace the non-free firmware blobs wherever possible, and Squeeze looks like it will be better than Lenny here, just like Lenny was better than Etch before it.


Cosa ne pensa del kernel "linux-libre" di Robert Millan? C'è una possibilità che per la futura squeeze sia questo il kernel linux di riferimento?

What do you think about the "linux-libre" kernel suggested by Robert Millan? Is it possible that it will be the kernel of the future Squeeze?


Qualche links

La Homepage di Steve: http://www.einval.com/~steve/

Il Blog di Steve: http://blog.einval.com/

Wikipedia: Steve McIntyre

back