Guest post by The Debian project will release the new stable version of debian – Debian 6.0 “Squeeze” – with a completely free Linux kernel. Binary-only firmware and other non-free kernel components will only be available via the non-free repositories and the project is actively encouraging vendors that have not done so already to release their firmware in a form compatible with the Debian Free Software Guidelines.
How about adding a requirement to install a package from the non-free repository before allowing non-free firmware in ROM to be used as well? You wouldn’t want to be accidentally using non-free firmware that way either after all. 😛
When I read the teaser, I thought “is Debian ‘big’ enough to be producing a ‘Debian Free Software Guidelines’ that vendors are supposed to follow?”. It still holds in light of your comment.
Debian doesn’t hold anyone outside the project to anything. This is simply the culmination of an effort of many years to remove from the Debian Linux kernel anything that is not in compliance with the the Debian Free Software Guidelines. Achieving this is an important ideological milestone for Debian but doesn’t mean much for anyone who doesn’t care about ideology–except that certain hardware won’t work out of the box and will require extra steps.
What has held up this, AFAIR, is that when Debian initially wanted to perform this removal the only way to do it was to completely remove the associated drivers, which lead to a crippled kernel. Pragmatically this was not an option so the non-free bits remained in the kernel and every so often someone would complain. The technical solution was to separate things out and make the firmware loadable from a file, then update all drivers that needed non-free firmware to do this. It’s all a lot of boring, mundane work that is now (finally) done.
The rest of the world can go and hang, Debian will always do it’s own thing its own (IMO correct) way.
So now that it’s technically feasible, other distros will follow, right?
Jokes aside you are making a very valid point, more and more software is being used on our machines (think about SSD controllers firmware) and we have no control over it, nor the source is available. This exposes us to two problems:
– support, if the vendor responsible for your hardware decides that it isn’t worth to keep old firmware up to date you might end up with bugs which will never be fixed
– security, bugs in those firmwares could be responsible for new vulnerabilities and attack vectors and again you’d have no control over it nor the possibility to fix them unless the vendor issues an update
All in all I think that Debian’s choice is not ideological, it’s very pragmatical and involves on-board firmwares too. Not being able to control them leaves us exposed to all the problems involved with proprietary code and closed architectures.
Finally we have already seen quite a bit of firmware-based differentiation lately, with performance or feature caps enforced by software. I expect more to come in the future and that’s why it is in the user’s best interest to be able to control what they buy and do what they want with their hardware.
Again, ill need to have the .deb packages of Broadcom Nextreme II, or Qlogic disks. ¬¬
grab the non-free driver package, drop it on a usb flashdrive, plug it in then boot off the install disk. Debian installer looks at the usb flashdrive and goes “cool, extra drivers.. let me install that for you”. For my servers, Etch had the NIC drivers where Lenny didn’t so I learned how to include them from removable media.
Mind you, my personal preference would be a non-free installer. Months back when I last did a Squeeze install the ftp had two images (aprox):
debian-6-netinst.iso
debian-6-netinst-nonfree.iso
Having done a squeeze install yesterday with most recent installer; no “nonfree.iso” available. Luckily the machine’s wired NIC is supported so the wifi didn’t need to be setup until after the first reboot.
We all should praise the return to openness.
Back to knowing what is there, in the kernel, as the fundamental piece for security in face of unreliable “trust”. It is a matter of principle, but security too.
Any “extras” should be less security privileged loadable drivers. And the Kernel SHOULD, and MUST take that in consideration. Or it will only be one step beyond “other” OSs, instead of a full leap ahead.
Well, Linux is not the OS to look at if you want less privileged drivers. All the drivers loaded into the Linux kernel run with full kernel privileges.
You would want a micro-kernel OS. Genode might be what you are looking for.