| |||||||||||||
GNU Linux-libre 3.5-gnu: Free and a halfGNU Linux-libre 3.5-gnu: Free and a halfPosted Jul 24, 2012 1:00 UTC (Tue) by vrfy (subscriber, #13362)Parent article: GNU Linux-libre 3.5-gnu: Free and a half
Maybe they could name it Linux-brainfree, that would make an even better headline.
(Log in to post comments)
Speak about brainfree Posted Jul 25, 2012 12:38 UTC (Wed) by man_ls (subscriber, #15091) [Link] Many people do not get the point of Free software. They laugh at "purity" and "freedom"; but they later complain about their iPhones being jailed, their Androids not promptly updated, and their devices not doing what they want. As Heraclitus the Obscure used to say, most of us live like in a dream, not knowing the reasons of the things that happen to us.
Speak about blobfree Posted Jul 26, 2012 6:42 UTC (Thu) by gmatht (guest, #58961) [Link]
There has been no shortage of GNU evangelists on LWN to explain the point of free software. I suspect they know exactly why their android phone lacks frequent updates, but still don't see the advantage of using an OS that doesn't boot and by design doesn't tell you why over an OS that doesn't boot and mentions that the reason it doesn't boot is that there presently is no free implementation of a particular blob.
Speak about blobfree Posted Jul 26, 2012 19:53 UTC (Thu) by man_ls (subscriber, #15091) [Link] I am not sure I really understand your message. The point is that even if the FSF (and "GNU evangelists" as you call us) explain why software should be Free, the anti-FSF camp insists that freedom is not really necessary, with a variety of arguments. They reject the GPLv3 and its anti-tivoization provisions, sometimes even reject the GPLv2 (some time ago ESR, recently Rob Landley), and their discourse is often that "the market" will tend towards Free software even if it is BSD-licensed.Then, when Free software is subverted to run on iOS or other locked devices these people are sheepishly surprised. When Android phones are locked, or not often updated, they are sadly disappointed. When TiVOs obey their true masters they look the other way. Hint: "the market" is not going to fix anything, and specially it will not fix lack of freedom -- it will only gravitate towards low prices. It is up to us, the technologically savvy, to reject locked computers and to make sure that our code is not subverted to run on them, and to demand Free drivers for all devices. The FSF is already one step ahead of everyone and fighting the next battle: closed microcode. If we choose to let companies sell us their locked chips with their opaque blobs then we cannot really complain when things stop working. Or, we can blame the FSF and feel smugly superior once again.
Speak about blobfree Posted Jul 26, 2012 20:48 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
> The FSF is already one step ahead of everyone and fighting the next battle: closed microcode.
If the FSF was really campaigning against closed microcode we would not be having this discussion.
But the FSF is not campaigning against closed microcode, only against closed microcode that the OS loads into the device.
And they are doing so to the point that they are saying that closed microcode that CANNOT be replaced is BETTER than closed microcode that CAN be replaced.
And it's when they make this statement that many people call them out over it.
I, (and many others) believe that the situation from best to worst is
1. Open microcode with open, easy ways to load it to the device
The FSF re-orders this to the following (leaving the original numbers in place to show the difference)
1. Open microcode with open, easy ways to load it to the device
If the user has the ability to replace the firmware on the device, the device is more free than if they don't have the ability to replace the firmware on the device. Even if the existing firmware is not open, it's still possible to hack the binary, or write a free replacement. If the firmware cannot be replaced, it can never be made free.
The FSF also tries to confuse two issues.
1. binary blobs that are running on your main CPU as part of the OS
There are a LOT more people who will agree that #1 is bad and advocate running systems free of such blobs than will agree that #2 is a feasible problem to attack.
note that many of the people disagreeing with the FSF over this issue would prefer to buy and use components with open firmware, they just aren't willing to call an OS non-free if it doesn't.
Speak about blobfree Posted Jul 26, 2012 21:11 UTC (Thu) by man_ls (subscriber, #15091) [Link] Thanks for putting it so beautifully. Note how the FSF ordering lists all "open" options above all "closed" options, while your personal order seems to favor a working device.Following your analysis it is clear that the FSF puts freedom (in this case in the form of openness) above convenience, as they have always done. That is what we should expect from them. At this point in time we don't need anyone to tell us how to achieve convenience, but sadly we need the FSF to remind us what freedom looks like. The GPLv2 has one funny clause, sometimes called "Liberty or death". It eminently puts freedom over convenience: if you cannot give others the freedoms in the GPL then you cannot redistribute, at all. The point of view that a ROM is better than closed firmware is similarly non-yielding. About conflating microcode and code, I don't think the FSF is trying to confuse anyone. Why should the main CPU should be given a special status over the host of GPUs, microcontrollers, general- and special-purpose processors on a modern computer? There may be some convenience there, but logic dictates that software is software no matter where it runs. Where would you draw the line anyway, GPU, printer, hard drive, network card, detached, semi-detached and self-powered? Are we willing to win a battle but lose the war? Note that the FSF does not force you to use anything at all, contrary to what the anti-FSF camp wants to make you think. The FSF are just not shy about calling things non-free if they feel they are, and endorse only what they feel to be really free. I am a card-carrying member of the FSFE, yet I regularly run non-free software. However, when given the choice I sometimes choose freedom; not because I feel smug about it, but because I think it is the right thing to do. Feel free to make your own choices.
Speak about blobfree Posted Jul 26, 2012 21:30 UTC (Thu) by nybble41 (subscriber, #55106) [Link]
The point was the order of the closed options, with the FSF irrationally preferring most difficult / least functionality over least difficult / most functionality. There are no "open" options for microcode at this time, and moreover there likely never will be any "open" options for microcode for existing CPUs, so it doesn't matter where they appear in the list.
Rational preferences:
1. Closed microcode with open, easy ways to load it to the device
FSF preferences:
1. Closed microcode with no way to update the device.
Speak about blobfree Posted Jul 26, 2012 21:37 UTC (Thu) by man_ls (subscriber, #15091) [Link] There was hardly any "Free" software back in 1991, and some people said there would never be any substantial "Free" software since closed commercial software was so powerful. You underestimate the power of Free software.
Speak about blobfree Posted Jul 26, 2012 21:42 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
If you prefer hardware that you can't load any software on over hardware that you can load software on, how are you going to do any development and testing of your free software?
Speak about blobfree Posted Jul 26, 2012 21:55 UTC (Thu) by man_ls (subscriber, #15091) [Link] The old convenience-over-freedom conundrum rears its ugly head again. My personal favorite would be to wait until the manufacturer releases source code and toolchain as Free software and lets us play with the device with full rights.Let me ask you a question: if the manufacturer for a network card suddenly forbids redistribution of their binary blob, perhaps because they want you to update to a new model, what would you do? Pressure the manufacturer? Then please pressure the manufacturer to release source code for the binary blob now. It has been done before (with binary drivers), it can be done once again.
Speak about blobfree Posted Jul 26, 2012 22:00 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
> Let me ask you a question: if the manufacturer for a network card suddenly forbids redistribution of their binary blob, perhaps because they want you to update to a new model, what would you do?
What if the new model has no Linux driver support and no documentation?
Speak about blobfree Posted Jul 26, 2012 22:06 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
If a manufacturer trys to break existing users by deciding that firmware can no longer be distributed for hardware that I own, I will not lobby them to change their mind, I will instead do one of two things.
1. scrap the hardware and never buy from this untrustworth vendor again
or
2. ignore their new license policy (to the point of going to court over it if they sue me) because I purchased the device and now, after purchase, they are trying to disable the device I purchased.
Drivers and Firmware are not the same thing, trying to treat them as the same thing leads to confusion and illogical conclusions.
Speak about blobfree Posted Jul 26, 2012 22:27 UTC (Thu) by man_ls (subscriber, #15091) [Link] They are not illogical conclusions, they are just paradoxical on the outside. Just like preferring a license which is less free (GPL) over another which is more free (BSD), in order to increase the amount of free software; not only it follows from the premises, but in practice it works, and GPL projects seem to thrive while BSD projects stagnate. Or the freedom or death clause: apparently it would lead to less GPL software, but in practice it seems to have acted as a deterrent of legal attacks against GPL software, or at least it has no practical consequences.In this case the FSF prefers code in ROM to closed code in a blob; apparently it is paradoxical but if you look closely it follows from the premises. Don't just reject the premise because the conclusion looks paradoxical to you; try to work out the reasons. And this line of reasoning might seem to lead to less Free software, but the FSF hopes that it will produce Free microcode. We still don't know which will it be, but I think it is worth a try. It has worked before.
Speak about blobfree Posted Jul 26, 2012 22:42 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
how is anyone going to develop free software if they are encouraged to buy hardware that cannot be modified?
you are eliminating the big strength of free and open software, the motivated user who wants to do something different. Instead you are requiring that people become passive and have their only power being to vote with the wallet.
And even the voting with their wallet is encouraging the wrong thing. Hardware listed as "acceptable to the FSF" is harder to modify than hardware that is listed as "non-free", so you if people avoid purchasing the hardware that has the non-free blobs loaded by free software, they are instead encouraging hardware that requires proprietary software to modify instead.
They should be encouraging people to buy hardware that's easier to modify, the easiest hardware to modify is hardware that comes with source for the firmware, but hardware that can be have firmware loaded with free software should be preferred over hardware that requires proprietary software to modify, and hardware that requires special hardware to modify should be even lower on the list.
Convenience over freedom again Posted Jul 26, 2012 22:48 UTC (Thu) by man_ls (subscriber, #15091) [Link] They should be encouraging people to buy hardware that's easier to modifyThey probably would, if their intent was to encourage people to tinker with their hardware. As it is, their goal is to make software Free (in case you have not noticed), and their path strikes me as more viable than yours. After all we have had hardware with blobs for many many years, and the proportion that has been reverse-engineered is minuscule.
Convenience over freedom again Posted Jul 26, 2012 22:56 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
> After all we have had hardware with blobs for many many years, and the proportion that has been reverse-engineered is minuscule.
and the number of devices that have had the firmware made free is zero, miniscule is better than zero.
hardware that allows the firmware to be loaded with free software is relatively new, we should be encouraging it as a step in the right direction, not trying to kill it off.
Convenience over freedom again Posted Jul 26, 2012 23:40 UTC (Thu) by nybble41 (subscriber, #55106) [Link]
> After all we have had hardware with blobs for many many years, and the proportion that has been reverse-engineered is minuscule.
And the proportion which included free firmware from the beginning is...? At least if the firmware is in flash, or even loaded at initialization, it remains _possible_ to reverse-engineer it and maybe come up with a free replacement. Devices with firmware in ROM are a clear loss for the free software community compared to both of the available alternatives.
If the proprietary parts really bother the FSF so much, their time and money would be better spent developing free firmware, and if necessary, hardware to support it. They may be the Free _Software_ Foundation, but if the problem is proprietary firmware, and they can't replace the firmware with a free version without also changing the hardware, then the right choice is to branch out into hardware design, not cripple existing free software by removing references to the proprietary firmware.
Convenience over freedom again Posted Jul 26, 2012 23:48 UTC (Thu) by man_ls (subscriber, #15091) [Link] All the necessary points from my part have been made, I think; I have no new arguments to add. Thanks everyone for a most agreeable discussion! It is hard nowadays to find this level of civility, even here on LWN. Now if someone else wants to carry the torch for awhile...
Convenience over freedom again Posted Jul 27, 2012 0:27 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
> At least if the firmware is in flash, or even loaded at initialization, it remains _possible_ to reverse-engineer it and maybe come up with a free replacement.
Also, if the firmware can be replaced, it's possible for the vendor to then open the software after the initial product release.
you can't really do that if the software cannot be replaced without modifying the hardware.
Speak about blobfree Posted Jul 27, 2012 9:58 UTC (Fri) by mpr22 (subscriber, #60784) [Link] I think that giving people a 90% Free software stack that works on the hardware they already have at least as well as the not-Free-at-all software stacks currently available for that hardware is morally superior to giving them a 100% Free software stack that will only work as well as their existing software stack if they replace half their (still-working) hardware.
Speak about blobfree Posted Aug 1, 2012 8:27 UTC (Wed) by valhalla (subscriber, #56634) [Link]
In 1991 there was little free software, but there were computers which could easily run said software, even if it meant having to run a mixed free/non-free system.
Today you can choose between a system where you could write a free firmware, easily load it onto the device and run it, or one where you are forced to keep using the same non-free blob that came with your device, unless you manage to desolder a flash chip.
The FSF claims that the point is moot because nobody has ever reverse engeneered a blob, so you can't really load a free one, but IMHO it would be better to start a project to do it, rather than campaigning for hardware that prevents it from happening.
I know that you can't really expect to rewrite all of the blobs everybody needs, but with device drivers having some working reverse engeneered ones did succeed in giving at least some companies a reason to open their own drivers.
Speak about blobfree Posted Aug 1, 2012 9:09 UTC (Wed) by man_ls (subscriber, #15091) [Link] I don't have to tell you that if your analysis takes you to a different conclusion than the FSF, you can start your own campaign. An effort to reverse-engineer a blob might be interesting, although it might just lead to blob-signing (and even blob encryption).
Speak about blobfree Posted Jul 26, 2012 21:35 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
> Thanks for putting it so beautifully. Note how the FSF ordering lists all "open" options above all "closed" options, while your personal order seems to favor a working device.
I see it differently
a device with "open" firmware that I can't replace is not open as far as I am concerned, even if the code is available under the GPL.
if you agree with that definition, then both I and the FSF place all open options above all closed options.
All the closed options work, the difference is that among the closed options, I rate the ones where I as a user have a possibility of replacing the closed firmware above the ones where I don't. The FSF would prefer that I have a device that I cannot modify the firmware on instead of a device that I load a closed blob on now, but could load open firmware on later (if such firmware is written)
> Why should the main CPU should be given a special status..
In large part because the FSF doesn't object to the closed binary blob if it's not loaded by the OS.
Every device you plug into a computer nowdays has it's own processor, and that processor is running software.
To use a trivial example, a $14 USB Serial adapter has a processor in it, and software running on that processor. But the FSF doesn't object to this because it's "hardware" and there is no method provided by the manufacturer to replace the software on this device. But if a manufacturer were to add a feature that would allow for the software on the device to be replaced, suddenly the FSF would classify this device as "non-free", even if the only difference is the added ability to replace the software.
If you think you are running a computer that is not running closed software on any of the various special-purpose processors, you just don't know enough about what is going on in your system. It's not possible to buy or build a system that doesn't have closed software somewhere on it.
Speak about blobfree Posted Jul 26, 2012 21:47 UTC (Thu) by man_ls (subscriber, #15091) [Link] I think the FSF prefers to have freedom for every piece of software in a computer, even those burned in ROM. But as a matter of fact, they have chosen to campaign for blobs that are redistributed by users themselves, often unwillingly. It is not the case that the FSF doesn't object to closed ROMs, just that the ethical issues for users are not the same as for firmware blobs.Let me quote the FSF itself: The ethical issues of free software arise because users obtain programs and install them in computers; they don't really apply to hidden embedded computers, or the BIOS burned in a ROM, or the microcode inside a processor chip, or the firmware that is wired into a processor in an I/O device. In aspects that relate to their design, those things are software; but as regards copying and modification, they may as well be hardware. The BIOS in ROM was, indeed, not a problem.If that is your only problem with the position of the FSF then I think we are arguing about the color of the shed, really.
Speak about blobfree Posted Jul 26, 2012 22:14 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
> The ethical issues of free software arise because users obtain programs and install them in computers; they don't really apply to hidden embedded computers...
the users don't really obtain and install the firmware that the OS load into these same hidden embedded computers.
Many of these hidden embedded computers that Linux-libre supports do have a way to modify their firmware, it just requires special software to load the updates.(frequently software that only runs on DOS)
So it's not really a matter of hardware that can be modified vs hardware that cannot be modified, and the FSF is telling us that they prefer that users use hardware that's harder (or impossible) to load new software on over hardware that free software can load the software on.
Speak about blobfree Posted Jul 27, 2012 13:08 UTC (Fri) by khim (subscriber, #9252) [Link] But as a matter of fact, they have chosen to campaign for blobs that are redistributed by users themselves, often unwillingly. Right. And that is where they turned from “sensible guys who fight for freedom” to “raving lunatics who spend time and effors tilting at windmills”. If that is your only problem with the position of the FSF then I think we are arguing about the color of the shed, really. Unfortunatelly this “color of the shed” is the only thing which justifies waste of resources on Linux-libre. Note that this is not the first time they've hit this dilemma. In fact they hit it right from the start! And back then, quarter century ago, they did a sinsible choice. Remember? However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. That's what FSF wrote back then when they still acted in the interest of people instead of the interest of pointless rules. If you'll apply this approach to the OS kernel it'll become something like However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (CPU, HDD, network card, and so on) of the hardware system on which the executable runs, unless that component itself accompanies the executable - and this same approach which FSF itself invengted quater-century ago will suddenly turn Linux-libre from the “valliant effort to fight against world conspiracy” back to what it is - “useless waste of scarce resources”. I can understand the idea behind separation of “true sources” and “binary blobs” but when the FSF itself happily distributes binary blobs when it suits them yet for some reason tries to make lives of other people miserable for some dogmatic reason… I don't know when and why FSF lost all their marbles but their track record says for itself: before they turned “Don Quixote of XXI century” they were a force to be reconed with, after that point… they are just a laughing stock. It's depressing really and I don't really understand why they did that to themselves, but I'm happy that we no longer need sane FSF to push for the solftware freedom: there are other, more sensible groups around. FSF is still valuable for it's insight as for the possible threats for freedom, but it's campaigns have lost their efficiency once they stopped caring about people. Really, what achievements can you name which hapened in last ~15 years from all the FSF's efforts? All their successes happened long ago, when they understood that people's needs and wants trump the needs and wants of a code (in fact any code is just a sequence of bytes, it has no free will thus it has no needs or wants at all). Think about it: they cripple Linux to promote their strange rules yet they refuse to cripple, e.g., Emacs or GCC in the same way… why exactly?
+1 (except that FSF distributes sources) Posted Jul 28, 2012 13:32 UTC (Sat) by gmatht (guest, #58961) [Link]
I largely agree with what you said, and particularly with the comment linux-libre is a distraction from more vital projects. However, specifically with regard to your comment that the FSF distributes binary blobs for sed, I don't think this is relevant. The FSF also distributes sources to GNU sed, and the FSF has never opposed distributing binaries provided Free source code is available.
Speak about blobfree Posted Jul 27, 2012 18:51 UTC (Fri) by ldarby (subscriber, #41318) [Link]
> don't see the advantage of using an OS that doesn't boot and by design doesn't tell you why over an OS that doesn't boot and mentions that the reason it doesn't boot is that there presently is no free implementation of a particular blob.
Right, I don't see that advantage. Is there one?
|
|||||||||||||