FSF updates its "fully free" distribution list [LWN.net]

FSF updates its "fully free" distribution list

Posted Sep 14, 2009 17:59 UTC (Mon) by mdomsch (guest, #5920) [Link] (15 responses)

If the difference between "fully free" and "completely nonfunctional on virtually any hardware", I'll forego the "fully free" moniker gladly. CPU microcode and NIC firmware are necessities, at least on the CPUs and NICs available on the market.

FSF updates its "fully free" distribution list

Posted Sep 15, 2009 14:06 UTC (Tue) by jebba (guest, #4439) [Link] (14 responses)

This is simply false. The only NIC, last time I checked, in the kernel that uploaded firmware is TG3 and it is only needed for some features--it can be used without the firmware. There was an Intel NIC too that used firmware, but there was a second driver in the kernel that didn't require it (eepro100 v e100 iirc).

The only big category of hardware that most users encounter that need firmware is wifi drivers. Other than that, there is really very little hardware in use on most systems that needs firmware uploaded to it by the kernel.

-Jeff

FSF updates its "fully free" distribution list

Posted Sep 15, 2009 14:31 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (13 responses)

bnx2 requires firmware. tg3 requires it on certain chips, as does e100 - eepro100 was removed from the kernel. You're not terribly likely to be hit, but it is a risk.

There's more of a problem with graphics. You won't get accelerated 2D, let alone 3D on radeon without firmware - the same's true for nouveau. Intel's the only option if you prefer your firmware burned-in rather than loaded at runtime.

FSF updates its "fully free" distribution list

Posted Sep 15, 2009 19:23 UTC (Tue) by leromarinvit (subscriber, #56850) [Link] (9 responses)

...if you prefer your firmware burned-in rather than loaded at runtime.

This, to me, shows how idiotic the anti-firmware argument really is. Modern hardware is going to require some kind of firmware, whether it is executable code for a built-in microcontroller or an FPGA bitstream. Any moderately complex piece of hardware is likely going to be designed that way. And with runtime loading, at least it can be easily exchanged if it is buggy and the manufacturer cares enough to fix it. With built-in firmware storage, you still have the same proprietary code running behind the scenes. It can have the same bugs, and to fix it, you'll have to use a special flasher, which will probably be proprietary and Windows or DOS only. If it's upgradeable at all.

FSF updates its "fully free" distribution list

Posted Sep 15, 2009 20:34 UTC (Tue) by jebba (guest, #4439) [Link] (5 responses)

> ...the anti-firmware argument...

It's not anti-firmware. It's anti-unfree software. There is free software firmware. Your kernel doesn't have to be non-free. Why should the firmware have to be non-free? This file details the licenses of the firmware shipped with the linux kernel:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-...

FSF updates its "fully free" distribution list

Posted Sep 15, 2009 20:41 UTC (Tue) by dlang (guest, #313) [Link] (1 responses)

in my opinion, if you were really anti-unfree software you would be more opposed to firmware that's not loaded from the OS because it's harder to change.

instead you consider such firmware acceptable and claim that you would be happy if all devices worked that way.

to the extent that your fussing has an effect it's as likely to drive vendors to make the firmware more fixed as it is to get them to open the source. and I defiantly consider the move from a firmware blob loaded by the OS to a firmware blob that requires more effort to change a step in the wrong direction.

FSF updates its "fully free" distribution list

Posted Sep 15, 2009 21:19 UTC (Tue) by jebba (guest, #4439) [Link]

> instead you consider such firmware acceptable and claim that you would be happy if all devices worked that way.

I did? When/where?

FSF updates its "fully free" distribution list

Posted Sep 15, 2009 20:46 UTC (Tue) by leromarinvit (subscriber, #56850) [Link] (2 responses)

I agree that open source firmware is even better - hackable hardware is fun and has many of the same advantages as free software. But why is it okay to have non-free firmware on a flash chip where you never see it, but not okay to load the same firmware at runtime?

FSF updates its "fully free" distribution list

Posted Sep 15, 2009 20:52 UTC (Tue) by dlang (guest, #313) [Link] (1 responses)

or firmware on a flash chip that requires a windows-only program to update it.

FSF updates its "fully free" distribution list

Posted Sep 15, 2009 21:52 UTC (Tue) by nix (subscriber, #2304) [Link]

... and if the update goes wrong you are terminally buggered, as opposed
to load-every-time firmware, where you're not buggered at all.

Firmware vs. loadable/flashable "firm"ware

Posted Sep 17, 2009 12:27 UTC (Thu) by anton (subscriber, #25547) [Link] (2 responses)

Unchangeable firmware is unlikely to have the same bugs as loadable "firm"ware, because the manufacturer cannot afford to replace the hardware in order to fix a critical bug. So they will be more careful during development and testing to ensure that no critical bugs are in the firmware (and catch a lot of other bugs along the way), just like they are for hardware, whereas loadable "firm"ware costs as much to replace as software and will therefore be developed to the standards of proprietary software.

Another way to look at it is that free "firm"ware gives the user the same options as the manufacturer of the software. The same is true for unchangeable firmware (each party can decide to (offer to) replace the hardware at their own cost). But with proprietary loadable firmware the manufacturer gets options to change the firmware that the user doesn't have.

And even if I restrict my view to short-term convenience, unchangeable firmware that just works (as has always been the case in my experience) is certainly more convenient than having to download and possibly even flash new "firm"ware. The worst experience I had with firmware and "firm"ware was with the bcm43xx and b43 "firm"ware where I had to manually download some Windows driver and extract the "firm"ware, twice.

Firmware vs. loadable/flashable "firm"ware

Posted Sep 17, 2009 14:14 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

There's several notable examples to the contrary - look at the problems with the Seagate 1TB drives, for example. The situation with difficult to upgrade firmware is different in that people are more likely to attempt to put workarounds in the driver to deal with the issues, whereas a loadable firmware update can be pushed out as easily as a driver update (and, often, the two will go hand-in-hand).

Broadcom is something of an edge case in terms of their wireless firmware. There's plenty of loadable firmware distributed in the linux-firmware tree and installed by default with most distributions, so in the vast majority of cases the user will see no difference whatsoever.

Firmware vs. loadable/flashable "firm"ware

Posted Sep 17, 2009 14:39 UTC (Thu) by foom (subscriber, #14868) [Link]

> But with proprietary loadable firmware the manufacturer gets options to change the firmware that the user doesn't have.

You talk as if you think unchangeable firmware and non-persistent loadable firmware are the only two options.

But you forgot the option that actually gets used most often as an alternative to non-persistent loadable firmware: flash memory. As the parent comment noted: "you'll have to use a special flasher, which will probably be proprietary and Windows or DOS only"

But if you consider system security, persistent user-modifiable firmware starts looking like a really bad idea. E.g. the recent hack where someone modified the firmware in their Apple Keyboard to add a keylogger. So what will the likely result of that be? I'm willing to bet that fairly soon, all hardware with flash firmware will do signature checks on all firmware uploads.

Realistically, the only techically acceptable options are:

1) Persistent flash firmware, with a signature check on upload to ensure non-malicious firmware. That is: not user modifiable, at all, source code available or not.
2) Non-persistent loadable firmware.

At least with 2, it's possible for a user to modify and load unauthorized firmware into the device, even if the source isn't provided. I know I'd prefer that...

FSF updates its "fully free" distribution list

Posted Sep 15, 2009 21:37 UTC (Tue) by nix (subscriber, #2304) [Link] (2 responses)

OK, please point to the firmware for accelerated 2D on radeon. There's the
AtomBIOS, but that's *on the card* and interpreted by the CPU, thus is no
more 'firmware' than ACPI tables. If by 'firmware' you mean something
which has to be uploaded to the card to do accelerated 2D, I can't find it
in a hunt through the xf86-video-ati tree. So, er, where is it?

FSF updates its "fully free" distribution list

Posted Sep 15, 2009 22:10 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (1 responses)

It's in the DRM layer - accelerated 2D on r300 and later uses the command processor on the card, which requires DRM and therefore the firmware.

FSF updates its "fully free" distribution list

Posted Sep 16, 2009 0:03 UTC (Wed) by nix (subscriber, #2304) [Link]

Ah, right, I didn't look at that. I guess that means my r770 here is
entirely unaccelerated, as it doesn't have a DRM layer yet. I had no idea:
it does everything I ask of it instantaneously (except for 3D of course).
Even hi-def textured video...

... bloody 'ell this modern kit is nippy.

FSF updates its "fully free" distribution list

Posted Sep 14, 2009 18:00 UTC (Mon) by mheily (subscriber, #27123) [Link] (1 responses)

Great. Just what the world needs: another quirky little distro maintained by a handful of people, with no interesting features or reason for existence. This latest distro is a derivative of Slackware, so perhaps it should be called "Slackware--". I wonder when the official GNU operating system will finally be released :)

FSF updates its "fully free" distribution list

Posted Sep 14, 2009 18:53 UTC (Mon) by tzafrir (subscriber, #11501) [Link]

In case you haven't noticed: the new distro is both a Gnu OS and Gnu/Linux .

Source based?

Posted Sep 14, 2009 18:21 UTC (Mon) by leromarinvit (subscriber, #56850) [Link] (2 responses)

For optimal performance with minimal bandwidth requirements, it uses a packaging system called 'ports' that downloads programs as source and builds them automatically.

Huh? Aren't source packages normally larger than binary ones?

-rw-r--r-- 1 foo bar 61494822 10. Sep 04:45 linux-2.6.31.tar.bz2
-rw-r--r-- 1 foo bar  5249892 12. Sep 12:42 linux-doc-2.6.31_2.6.31-10.00.Custom_all.deb
-rw-r--r-- 1 foo bar  6168812 12. Sep 12:35 linux-headers-2.6.31_2.6.31-10.00.Custom_i386.deb
-rw-r--r-- 1 foo bar 15344920 12. Sep 12:36 linux-image-2.6.31_2.6.31-10.00.Custom_i386.deb
-rw-r--r-- 1 foo bar     2132 12. Sep 12:42 linux-manual-2.6.31_2.6.31-10.00.Custom_all.deb

The kernel is probably a bad example, as it contains code for lots of architectures and devices, only a subset of which ends up in the binary. But compare this

OOo_3.1.1_LinuxIntel_install_en-US_deb.tar.gz	00:20 27-08-09	161603641

to this

OOo_3.1.1_src_binfilter.tar.bz2			00:21 27-08-09	6500967
OOo_3.1.1_src_core.tar.bz2			00:22 27-08-09	185952495
OOo_3.1.1_src_extensions.tar.bz2		00:22 27-08-09	14820645
OOo_3.1.1_src_system.tar.bz2			00:23 27-08-09	53316228

So, how does being source based help bandwidth requirements?

Source based?

Posted Sep 14, 2009 21:55 UTC (Mon) by proski (subscriber, #104) [Link]

I guess the diffs are shorter. I don't know for sure if ports uses diffs, as "ports" is a poor name to search for, there is no obvious way to download the ports code or documentation on the Kongoni site, and I won't download the Kongoni ISO image from Africa just to be sure.

Source based?

Posted Sep 14, 2009 22:01 UTC (Mon) by elanthis (guest, #6227) [Link]

Why do you assume these people have any idea what they're talking about? They just
pointlessly redeveloped a ports based Linux with the sole bullet point addition of "RMS
approves". Either they're technically disinclined they're more interested in politics than facts.
Either way, it's in their interest to just make wild technical claims without bothering to back
them up with facts.

"fully free" distros

Posted Sep 15, 2009 12:48 UTC (Tue) by dbruce (guest, #57948) [Link] (2 responses)

IMHO, the only role for these "fully free" distros like NewSense is as a sort of benchmark to see what issues are left with respect to things like firmware, binary-only drivers, codecs and so forth. NewSense could be shown to hardware manufacturers to tell them "If you are serious about selling Linux-friendly machines, make sure everything in it is supported in this distribution".

For people who want to install GNU/Linux on hardware they *already* own, it strikes me as obtructionist and paternalistic to make it difficult for the user to employ whatever less-than-ideal workarounds are needed.

Linux Newbie: "Can you help me get my laptop's wireless working with your distro?"

Mint: "You mean you had to ask? Sorry, thought we did that for you."
Ubuntu: "That requires non-free firmware, which you should know is a problem, but click here and we'll take care of it for you."
Debian: "You need the non-free repository. Go there and figure it out - you're smart."
NewSense: "I don't know what you're talking about. RTFM"

"fully free" distros

Posted Sep 15, 2009 13:58 UTC (Tue) by tzafrir (subscriber, #11501) [Link]

The kernel patching done in gNewSense and similar is over-aggressive, AFAIK.

"fully free" distros

Posted Sep 15, 2009 22:55 UTC (Tue) by AndreE (guest, #60148) [Link]

You mean:

Mint: sorry we've been sued out of existence