Linux-2.6.33-libre released [LWN.net]

Linux-2.6.33-libre released

Posted Mar 2, 2010 10:09 UTC (Tue) by eghost (guest, #63998)
Parent article: Linux-2.6.33-libre released

As someone who actually works on the boundary between software and hardware,
this all sounds a bit silly. The firmware is there to coax the recalcitrant
hardware into presenting something resembling a consistent and reliable
interface for the software to talk to. It should be considered part of the
hardware.

You can make hardware reliable and stable, as long as

a) you don't want it to do very much
b) you don't care how much power it draws and
c) you don't care how big it is

None of those things are true for modern hardware. Everyone wants more
functionality in fewer square millimetres and with lower power consumption.
The hardware is, let us not forget, quantum mechanics in action. Its
behaviour cannot reasonably be fully simulated prior to manufacture, so what
you get is a chip with unexpected behaviour. Some poor buggers in the
firmware department then undertake the task of working out how to get it to
do what it said on the tin, so that people writing software (free and
otherwise) can do something useful with the published API.

Don't expect them ever to tell you what they did; they're not used to anyone
caring.

I'm sure we'll have free hardware eventually, but currently it's at the
noble experiment stage. When all the dedicated tinkerers I know have a
micro-fab in their garage and can play with new hardware designs, that's
when it becomes possible. And FPGAs don't cut it. I'm not holding my breath.

As for the philosophy; I don't see much similarity with Saint Stallman[tm]
here. For all his sandals and extreme hair, what he did in the beginning was
"There is no proper freedom in this area so I shall create something which
has it and give it away to fill the gap." - a creative response.

What I see here is "There is no proper freedom in this area so I shall take
something that already existed anyway and remove stuff." - a destructive
response.

A response to match the ideals would be to start making free hardware.

(Log in to post comments)

Linux-2.6.33-libre released

Posted Mar 2, 2010 23:00 UTC (Tue) by rahvin (subscriber, #16953) [Link]

The best success this effort could have is to get all the firmware shoved back onto a non-upgradeable (or upgradeable using a windows tool) ROM or EEPROM. It's a step backwards IMO. Having the blob of hardware band-aids that is a typical firmware is not going to help anyone do anything, it doesn't advance freedom and it's only success would be to blackmail hardware makers into putting everything back into non-upgradable ROMS like in the old days. That way if hardware has a bug you buy new hardware rather than download a firmware with an extra bandaid for the bug in the hardware.

This is just silliness to me.

Similarity with the spirit of the GNU project

Posted Mar 3, 2010 7:17 UTC (Wed) by lxoliva (subscriber, #40702) [Link]

So, RMS set out to put together a w/holy free operating system, or die trying (of old age, presumably).

Now, you know one of the decisions of the project was to use whatever Free Software was already available to do the job, rather than writing it all, right? Such stuff as sendmail, X11, TeX, and even Mach (intended to be used as the lower layer of HURD) were already Free back then, and GNU was happy to use them.

Now, what if RMS had found out that say TeX contained some non-Free bits? Turn a blind eye to it wouldn't be honest, so they'd have to be (i) removed, and (ii) reimplemented, as people found the needed and the will to do so.

You'll notice that (ii) necessarily follows (i), even if they're mostly simultaneous, say, because some of the bits are absolutely trivial to rewrite and release under a Free Software license compatible with any other pieces it gets combined with.

However, the harder it is to reimplement the bits, the longer the time is likely to be between (i) and (ii). In any case, (i) can be a great motivator for someone who was comfortably unaware of the non-Free bits.

Unfortunately, the blobs in Linux are of the harder type to reimplement, because most often information is not available. There is progress, albeit slow. In the mean time, the Free Software community needs a Free kernel, and Linux is growing less and less Free, so Linux-libre fits.

And it fits perfectly well in the original plan for GNU: use Free Software that is already available, and implement whatever else is needed to get a w/holy Free system that people can use. If using Free Software that is already available means cleaning up nearly-Free Software, so that it becomes Free, so be it => Linux-libre.

It would be just silly to reimplement stuff from scratch, as some suggested, and it would be nonsensical to wait until all the remoevd non-Free bits are reimplemented before letting people use what is Free and perfectly usable.

Sure, you may find one component or another here and there that will adamantly refuse to serve you, but as someone else pointed out, you can always replace the component if you wish to. (and you can find a freedom-friendly replacement, and you don't find out that the hardware system vendor doesn't limit the system so that it refuses to function if you replace the WiFi cards or the hard disks or any component whatsoever with something not supplied by their salesmen or authorized repair shops)

Similarity with the spirit of the GNU project

Posted Mar 3, 2010 13:09 UTC (Wed) by nix (subscriber, #2304) [Link]

Well, obviously what RMS did with TeX was 3) declare that a project that
requires you to change its name and the name of all its font files and all
the references to such files within all documents, or requires you to add
an elaborate mapping mechanism to allow such changes without impact (which
was eventually done) *is* nonetheless free.

The TeX license is sufficiently far from free that special clauses had to
be inserted into the DFSG and other such definitions specifically to
grandfather it in.

DFSG is not the Free Software definition

Posted Mar 4, 2010 5:18 UTC (Thu) by lxoliva (subscriber, #40702) [Link]

DFSG is a bunch of rules that the Debian community came up with, in an attempt to create measuring points to indicate whether or not a piece of software complies with the Free Software Definition, i.e., whether the user of the software isn't being denied the 4 freedoms over the software. Don't mistake the shadow in the cavern for the real thing.

So let's see how the constraints posed by requirements of the TeX license get in the way of the 4 freedoms:

#0: run the software for any purpose: no conflict here

#1: study the source code and adapt it so that it does what you wish: no conflict here

#2: distribute the software, as you received it, whenever you wish: no conflict here

#3: improve the software, and distribute your improvements: gotta do a bit more work to rename the files, but that's about it, nothing significantly different from replacing easily-replaced logos and trademarks in any piece of Free Software.

So, no grandfathering as far as the Free Software definition is concerned. That the DFSG needed adjustments is just more evidence that it wasn't (and still isn't) equivalent to the FSD. That the DFSG was corrected, rather than insisting on a divergence, is a good sign that the people in charge took it for what it is (a set of heuristics), rather than as the essence.

DFSG is not the Free Software definition

Posted Mar 5, 2010 0:11 UTC (Fri) by nix (subscriber, #2304) [Link]

Er, they had to rename the files and *write a complete filename mapping
layer to compensate for that renaming*. This was *not* a small job :/ I'd
say that after that mapping layer was written, it was free and useful:
before that, it may have been free but the freedom was not much use to
anybody.

Mapping layer for compatibility

Posted Mar 5, 2010 4:42 UTC (Fri) by lxoliva (subscriber, #40702) [Link]

Please correct me if I'm wrong, but my understanding is that this remapping layer was not somethng demanded by the software license. Renaming files and fixing internal references to it would be enough to meet the requirements of the license and to distribute fully-functional software.

The catch, if you can call it that, is that pre-existing programs (documents) that referenced the file names that were no longer there would no longer just work on the modified software. They'd have to be mechanically modified as well.

I won't get into the debate of whether exposing internal implementation details as part of the public API is a good idea, even more so when these details must be modified when the progarm changes. However, nobody prevented the modifiers from implementing a script to make the needed changes, all mechanical, and the fact that it could be done in lower internal layers of the modified software, rather than as user-visible API changes, goes to support, rather than detract, from the fact that the original software was indeed Free, and I only bring this up because someone might make a successful case that, if it wasn't so, then some important freedom was missing.

Having the freedom doesn't mean its enjoyment has to be effort-free. Even the most permissive licenses carry some requirements with them, as light as keeping copyright notices intact and not removing the copy of the license. Copyleft licenses are more demanding, but none of the requirements, by themselves or taken as a whole, prevent you from enjoying any of the freedoms (although the combination of those requirements with others one might have accepted may have that effect, which makes it copyleft).

Some trademark issues have similar effects to those in TeX, but that the requirements are enough of a pain that some people set out to replace all the trademarks and logos ahead of time, to be able to keep that out of their minds in subsequent relevant modifications, is, to me, an indication that the freedom is there, just not so trivially accessible.

I like the metaphor that respecting someone else's freedom is not giving her a ride to the place she wants to go, but rather refraining from placing or keeping unsurmountable roadblocks on her way.

So I stand by my understanding that TeX is Free Software, just like Firefox is Free Software. If Debian read its heuristics in such a way that it reached a different conclusion, and (assuming) for this reason alone it set out to create IceCat, may an indication that the tide is turning, and that the essence is being lost and the heuristics taking over. If that is so, it is very sad. OTOH, it may very well also be that Debian just needed to make the changes and figured sharing it with others was the best way to go. If that is so, it is very good.

Similarity with the spirit of the GNU project

Posted Mar 3, 2010 16:56 UTC (Wed) by eghost (guest, #63998) [Link]

So presumably, since microcode patches are required for correct functioning
of Intel processors, the ability run on an Intel CPU must also be removed.
These microcode patches are downloadable firmware updates for the CPU,
pure and simple. And that's non-free, so as long as your distribution
contains the Intel Microcode Update Utility, it is not properly libre.

Some hardware has its firmware in ROM, but sometimes you need to patch that
ROM to get correct operation. I presume it will also not be permitted to use
any basically ROM-based hardware which was not perfect at manufacture.

Hardware people often think of firmware as just software, and they're wrong.
Software people who fail to think of firmware as part of the hardware are
also wrong.

If one accepts running on an Intel CPU, or any peripheral device with an
out-of-band method of updating its firmware, why does one not accept an in-
band method of updating the firmware? The important thing is that the API
for the device be published, and that all host operating systems should be
equal before it.

Now I may be wrong, but this all sounds very much to me like a bunch of
software people getting into an area where they aren't really experts.
Removing something with the intent of replacing it yourself in time, where
you have the necessary expertise, is one thing. Removing it in the hope of
annoying some unknown person into fixing it for you isn't quite the same
thing - that's just annoying people.

So out of curiosity, I wonder what *is* the plan with regard to fixing the
problem of hardware manufacturers not publishing their Verilog or VHDL or
whatever? And their manufacturing process? And detailed information on their
analogue parts (for things that deal with radio like WiFi and TV and FM). A
lot of is stuff you don't even *know* before you've got the part back from
the Fab.

That's what you'd need to write your own firmware after all. This isn't a
case of asking for an API reference.