Weekly Edition
Return to the Distributions page
| |||||||||||||
GNU Linux-libre 3.5-gnu: Free and a half
The 3.5-gnu Linux-libre kernel has been
released. The Linux-libre kernel meets the Free Software Foundation's
criteria for free software and is suitable for distributions
that aim to include only free software.
(Log in to post comments)
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 23, 2012 19:57 UTC (Mon) by blitzkrieg3 (subscriber, #57873) [Link]
What did they take out? Hasn't linux-firmware been out of the tree for some time?
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 23, 2012 21:02 UTC (Mon) by mslusarz (subscriber, #58587) [Link] They removed some left firmware files and patched out all firmware references, e.g.:
diff -ur linux.git/arch/x86/kernel/microcode_intel.c linux-gnu/arch/x86/kernel/microcode_intel.c
--- linux.git/arch/x86/kernel/microcode_intel.c 2012-07-23 22:35:28.360336765 +0200
+++ linux-gnu/arch/x86/kernel/microcode_intel.c 2012-07-22 02:07:51.000000000 +0200
@@ -412,10 +412,10 @@
const struct firmware *firmware;
enum ucode_state ret;
- sprintf(name, "intel-ucode/%02x-%02x-%02x",
+ sprintf(name, "/*(DEBLOBBED)*/",
c->x86, c->x86_model, c->x86_mask);
- if (request_firmware(&firmware, name, device)) {
+ if (reject_firmware(&firmware, name, device)) {
pr_debug("data file %s load failed\n", name);
return UCODE_NFOUND;
}
diff -ur linux.git/Documentation/arm/IXP4xx linux-3.5/Documentation/arm/IXP4xx
--- linux.git/Documentation/arm/IXP4xx 2012-07-23 22:35:26.360336729 +0200
+++ linux-gnu/Documentation/arm/IXP4xx 2012-07-22 02:07:55.000000000 +0200
@@ -35,17 +35,13 @@
See arch/arm/mach-ixp4xx/include/mach/platform.h for access functions.
- Timers (watchdog, OS)
-The following components of the chips are not supported by Linux and
-require the use of Intel's proprietary CSR softare:
+The following components of the chips are not supported by Linux /*(DEBLOBBED)*/:
- USB device interface
- Network interfaces (HSS, Utopia, NPEs, etc)
- Network offload functionality
-If you need to use any of the above, you need to download Intel's
-software from:
-
- http://developer.intel.com/design/network/products/npfamily/ixp425.htm
+/*(DEBLOBBED)*/
DO NOT POST QUESTIONS TO THE LINUX MAILING LISTS REGARDING THE PROPRIETARY
SOFTWARE.
Very helpful :/
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 23, 2012 21:15 UTC (Mon) by xorbe (subscriber, #3165) [Link]
They also spammed the latest /. Linux article.
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 23, 2012 22:30 UTC (Mon) by cortana (subscriber, #24596) [Link]
Well, at least they don't censor the fact that they are censoring references to the required firmware. :)
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 24, 2012 8:57 UTC (Tue) by mpr22 (subscriber, #60784) [Link] I'm deeply disappointed that they say "The following components of the chips are not supported by Linux" instead of "The following components of the chips are not supported by Linux-libre". It seems... somewhat frugal with the truth.
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 24, 2012 8:58 UTC (Tue) by mpr22 (subscriber, #60784) [Link] Psha. Partial parse failure on my part.
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 24, 2012 9:49 UTC (Tue) by dsommers (subscriber, #55274) [Link]
> diff -ur linux.git/arch/x86/kernel/microcode_intel.c linux-gnu/arch/x86/kernel/microcode_intel.c
> --- linux.git/arch/x86/kernel/microcode_intel.c 2012-07-23 22:35:28.360336765 +0200 > +++ linux-gnu/arch/x86/kernel/microcode_intel.c 2012-07-22 02:07:51.000000000 +0200 > @@ -412,10 +412,10 @@ > const struct firmware *firmware; > enum ucode_state ret; > > - sprintf(name, "intel-ucode/%02x-%02x-%02x", > + sprintf(name, "/*(DEBLOBBED)*/", > c->x86, c->x86_model, c->x86_mask);
So they even remove code which patches the CPU for vulnerabilities ... I see the purpose of being clean in regards to firmware related to I/O devices (GPU, RAID/HDD, NIC etc) - and I agree to that! But when also blocking updates of the CPU which may impact security issues and/or stability of the overall system, that seems a bit too strict.
A more suitable name for this kernel would probably be 'linux-sterile' - except it doesn't make the CPU sterile to issues. And it requires you to replace the CPU whenever a critical issue is found in the CPU core; which normally would have been patched via a microcode update.
But of course, there are other CPU vendors than Intel and AMD ... It just makes linux-libre less useful on Intel and AMD, IMO.
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 24, 2012 11:31 UTC (Tue) by gioele (subscriber, #61675) [Link]
> So they even remove code which patches the CPU for vulnerabilities
Are you sure that the microcode patches the CPU for vulnerabilities? http://www.mail-archive.com/package-announce@lists.fedora...
More seriously, <http://www.securiteam.com/securityreviews/5FP0M1PDFO.html>.
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 24, 2012 12:12 UTC (Tue) by dsommers (subscriber, #55274) [Link]
> Are you sure that the microcode patches the CPU for vulnerabilities?
> http://www.mail-archive.com/package-announce@lists.fedora...
Well, lets separate between microcode and firmware updates. It may feel like the same thing to the end user. However, you can easily replace almost any hardware device which doesn't have an open firmware or with another device doing the same job which doesn't require software loaded firmware at all.
Microcode updates are a bit different, as that patches the CPU. The CPU is far more difficult to replace, as that might even require you to replace the motherboard as well. You might even be able to live without a peripheral device not functioning, but if the CPU gives you headache - there's not an easy remedy to solve that, except of via microcode updates or replace the CPU.
Also, often a driver firmware is needed to be loaded to actually make it function at all. But a CPU must be able to boot without having received a microcode update.
Regarding if these updates fixes vulnerabilities ... Some years ago somebody explained this very well to me, but my memory isn't good enough to pin-point exactly which CPU this was and the errata from Intel. But the issue was related to that an "unprivileged" (user mode) operation could access memory regions it shouldn't have access to, due to the CPU failing to properly check if it was running in kernel mode or user mode. And a microcode update fixed this faulty behaviour.
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 24, 2012 16:09 UTC (Tue) by xorbe (subscriber, #3165) [Link]
Blocking cpu ucode patches is a really stupid thing to do. Unless you like occasional hangs and/or possible data corruption.
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 24, 2012 16:55 UTC (Tue) by patrick_g (subscriber, #44470) [Link]
I agree with you...but why this µcode is not under an open source license ? Currently it's an opaque blob.
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 24, 2012 17:31 UTC (Tue) by khim (subscriber, #9252) [Link] It's easy: µcode source includes large pieces of high value intellectual property which are related to the actual design of the CPU. Not something you want to ever expose for the competitors. Not even AMD/Intel staff have free access to the required data. Only some highly-trusted teams do. Note that most of the information is not used to create the actual binary blob (and thus can not be pulled from the end result). I think open-sourcing of this code will happen much later then out-sourcing Windows code. Which, of course, will happen when hell will freeze over few times, so...
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 24, 2012 23:04 UTC (Tue) by nix (subscriber, #2304) [Link] Not even AMD/Intel staff have free access to the required data. Only some highly-trusted teams do.Am I the only person who thinks this is absolutely hilarious? Microchip engineering is advanced technology, surely, but it is not Colossus. All the major chip companies are roughly on par with each other technologically: people flow between them, taking what they know (and despite ridiculous contracts of employment forbidding it, you cannot delete *experience* with a contract, and experience is what matters: these people know what will work and what does not). Keeping this stuff secret so your competitors won't know about it is ridiculous: they already do. But secrecy for secrecy's sake because Only We Have The Secret Sauce and Only We Have Real Engineers is a typical pathology of large companies. I wonder if anyone in them actually believes this stuff, or if they're all having a huge joke at our expense.
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 25, 2012 4:50 UTC (Wed) by jzbiciak (✭ supporter ✭, #5246) [Link] Not only that, it's not always true. I have sitting in my reading stack a rather interesting book: The Anatomy of a High-Performance Microprocessor: A Systems Perspective, ISBN 0-8186-8400-3 If you follow the link above, you'll see that it's apparently used as a textbook in many courses. It goes into incredible low-level detail about the AMD K6-III processor. It's very highly detailed about all sorts of low-level stuff, including bit-patterns used for the various internal microcode tables. This book is dated 1998, which made it current when that chip was still fairly "new". That said, such a book would have a fairly narrow audience, so I'm not surprised we don't see more of these. I'm willing to grant that this is book far more the exception than the rule. And, AMD is likely rather different than Intel. Everything I've heard about Intel (including from folks who worked there) is that information is highly compartmentalized. Also, I wouldn't be the least bit surprised if some of these updates are for "brown paper bag" bugs, and obscuring the updates softens the ego blow. Also in my office at work is a ~16 year old specification for a processor that didn't see production. Stamped all over it are "Strictly Private" declarations. It's at only a slightly deeper level of detail than the K6-III book above. We lost a lot of engineers when that project was canceled, and many ended up places like AMD, Centaur (remember them?), etc. You can bet they didn't forget what works and doesn't work. Indeed, one of the people we lost was a person we hired for his specific expertise and experience with the ISA this processor would run. Stepping back a bit: I think a big piece of it comes down to support. If you document something, you invite people to use it. If you invite people to use it, they expect some amount of support, even if you stamp all over it that there is no support. The support burden may be indirect: Somebody tweaks their microcode, shares it with folks who install it without realizing what they're signing up for, and machines start failing mysteriously. That puts more support calls into the channel. Microcode also has another special property: It's essentially another instruction set, and one that's highly subject to change, perhaps even between steppings of the same device. Documenting it would in some sense "fix" it. In any case, refusing to load a microcode blob into a CPU is just silly. You're no less free than if you force people to go buy a newer stepping of the CPU you already have, but which has the update in its microcode ROM already. It makes no sense. How is ROM you can't access or change more free than RAM that holds a copy of the same bits?
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 25, 2012 5:29 UTC (Wed) by raven667 (subscriber, #5198) [Link]
> How is ROM you can't access or change more free than RAM that holds a copy of the same bits?
The strict FSF position is that the difference is that it's changeable, in the way that software is, but that you don't have the rights or the tools to do so but the manufacturer does have those rights and tools so it is not an equitable arrangement. At least that's my understanding. In any of the copyleft licenses like the GPL all parties have an equal and high level of rights to the software, rights that usually only the author has, to inspect, modify, distribute, and in the case of the GPLv3, run the result on the target hardware.
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 25, 2012 20:53 UTC (Wed) by khim (subscriber, #9252) [Link] The strict FSF position is that the difference is that it's changeable, in the way that software is, but that you don't have the rights or the tools to do so but the manufacturer does have those rights and tools so it is not an equitable arrangement. Right. This is what they preach. Sadly this is not what they do. Let me remind you one fact, which is vital for the understanding of my ire: Some CPUs can boot Linux but need blobs to run it correctly. Now we have two choices:
The FSF-advocated solution (hardware without any binary blobs) no longer exist. Now, in this world, in this reality the solution where OS brings the required blob is obviously more robust (it's easier to update small microcode as compared to the whole firmware: microcode is provided by Intel where BIOS blob is provided by motherboard manufacturer and usually quite old and buggy), easier to hack (format of microcode is unknown, but it's loaded on each reboot anew thus it's safer to experiment with it) and thus better for any user (user who don't care about freedom get more robust system, user who cares about freedom gets more hackable system). But for some reason FSF pushes for the other, worse solution. Why? What's the point?
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 27, 2012 0:10 UTC (Fri) by cry_regarder (subscriber, #50545) [Link]
Because by their position, doing otherwise is aiding and abetting? You may not find their position pragmatic, but it is principled.
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 27, 2012 0:32 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
> Because by their position, doing otherwise is aiding and abetting? You may not find their position pragmatic, but it is principled.
No, we find their position unprincipled as it specifically demands that the vendors _reduce_ the control the user has over the device (unless the vendor gives complete control)
saying that devices with firmware blobs are bad is very legitimate.
saying that it's better to have devices with firmware blobs that the user cannot replace (or can only replace if they use proprietary software) than to have firmware blobs that the user can replace with free software is crossing a line that gets them called out. This is letting their rules violate the principles they claim to have.
Free Circuits Foundation Posted Jul 25, 2012 12:24 UTC (Wed) by man_ls (subscriber, #15091) [Link] How is ROM you can't access or change more free than RAM that holds a copy of the same bits?Elaborating on the above post: the Free Software Foundation believes that ROMs are similar to circuit schematics, and it is not called the "Free Circuits Foundation" (as cool as that would sound). Software is infinitely malleable, while hardware is set in stone the moment it is produced. If the firmware can be updated it is software; otherwise it is hardware. It is a very simple criterion that does not imply freedom. The point is that firmware (as software) is quite conveniently upgradeable, and that users should have the right to choose what software runs on their machines. With hardware the right to choose is exercised at the shop counter, and stops there. Answering to grandparent: industrial secrets are a problem of the manufacturer; if they place their convenience (to keep designs in secret) above mine (to choose what software I am running), there is a priority inversion somewhere.
Free Circuits Foundation Posted Jul 25, 2012 18:14 UTC (Wed) by khim (subscriber, #9252) [Link] Elaborating on the above post: the Free Software Foundation believes that ROMs are similar to circuit schematics, and it is not called the "Free Circuits Foundation" (as cool as that would sound). Software is infinitely malleable, while hardware is set in stone the moment it is produced. If the firmware can be updated it is software; otherwise it is hardware. It is a very simple criterion that does not imply freedom. Yes, this is simple criterion but this is not the criterion used in Linux-libre. Instead of supporting only hardware which does not need any non-free software it supports only the hardware which brings it's own binary blobs on it's own flash and rejects devices which keep said blobs in main OS distribution. I still fail to see how exactly removal of my ability to [potentially] tinker with a piece of of something frees me. It certainly frees my pockets (since the hardware if the first kind tends to be more expensive), but I'm not sure that's what FSF is trying to achieve. Answering to grandparent: industrial secrets are a problem of the manufacturer; if they place their convenience (to keep designs in secret) above mine (to choose what software I am running), there is a priority inversion somewhere. Not really. When you bought the hardware you knew that it'll require this binary blob to function properly. If it's fair or not is irrelevant. You've accepted the hardware and you are stuck with it. Now, again, I can understand the position "we will never support any piece of hardware which uses non-free software". This can be a "heroic" effort: reject all the HDDs, SSDs, eMMC, AMD/Intel/NVidia/Quallcom CPUs (which all require binary blobs to functions) and try to create some "new free world" on this basis. But to reject (or poorly support in case of CPU) hardware which needs some blobs while simultaneously produce good support for hardware which is literally identical but includes said blobs in flash... that's fanaticism, pure and simple. I can understand the concerns related to copyright (what if this blob is non-redistributable? big problem then), but from freedom POV that's obvious case of "redoubling the efforts when you have forgotten your aim".
Free Circuits Foundation Posted Jul 25, 2012 19:34 UTC (Wed) by gioele (subscriber, #61675) [Link]
> But to reject (or poorly support in case of CPU) hardware which needs some blobs while simultaneously produce good support for hardware which is literally identical but includes said blobs in flash... that's fanaticism, pure and simple
How is this different from binary blobs for anything else? Printers for example: most of them are paperweights without their binary blobs.
The Stallman's and FSF's point is that you should have access to the sources (and necessary build environment) of any user installable software. Regardless of the goodness of point itself, it is hard to understand why so called "firmware" is any different from normal "driver" software from this point of view. They are both collections of executable instructions compiled from sources, installed into a memory connected to a CPU and such instructions are used to drive the behaviour of an hardware component.
Free Circuits Foundation Posted Jul 25, 2012 20:30 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
>The Stallman's and FSF's point is that you should have access to the sources (and necessary build environment) of any user installable software. Regardless of the goodness of point itself, it is hard to understand why so called "firmware" is any different from normal "driver" software from this point of view.
Let's see. FSF declares 3 main freedoms:
>0. The freedom to run the program, for any purpose (freedom 0).
>1. The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this.
>2. The freedom to redistribute copies so you can help your neighbor (freedom 2).
>3. The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.
Basically, devices like network cards were never designed to run arbitrary software. So I fail to see how 3 freedoms might be violated.
Free Circuits Foundation Posted Jul 26, 2012 1:39 UTC (Thu) by jebba (✭ supporter ✭, #4439) [Link]
>>1. The freedom to study how the program works
> > you can run anything you want on your computer. The details of firmware blobs do not matter to applications running on the CPU
Incorrect.
The program the FSF is talking about in this case is the blob, not what is running on your CPU. It doesn't matter *which* chip is running the code; whether it runs on your main CPU or a chip on your network card is irrelevant.
Free Circuits Foundation Posted Jul 26, 2012 1:45 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
So do they also require VHDL/Verilog source code for the main CPU? After all, you might want to tweak it!
Firmware blobs are even with compliance with GPL since they are executed on a separate embedded computer which interacts with the main CPU using well-known industry standard protocols (signaling over PCI/PCIe/whatever).
Free Circuits Foundation Posted Jul 26, 2012 15:29 UTC (Thu) by jebba (✭ supporter ✭, #4439) [Link]
> So do they also require VHDL/Verilog source code for the main CPU? After all, you might want to tweak it!
Do you really think the FSF's four freedoms require the design code to the CPU?
> Firmware blobs are even with compliance with GPL
The firmware blobs themselves may not be GPL'd themselves though, making them non-free.
> they are executed on a separate embedded computer
Which processor they run on is irrelevant from the perspective of the FSF.
Free Circuits Foundation Posted Jul 26, 2012 20:45 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
>Do you really think the FSF's four freedoms require the design code to the CPU?
And why do they require design of network card's microcode? What's the difference?
>The firmware blobs themselves may not be GPL'd themselves though, making them non-free.
>Which processor they run on is irrelevant from the perspective of the FSF.
Free Circuits Foundation Posted Jul 26, 2012 21:44 UTC (Thu) by jebba (✭ supporter ✭, #4439) [Link]
>>Do you really think the FSF's four freedoms require the design code to the CPU?
>And why do they require design of network card's microcode? What's the difference?
Microcode/firmware is a software application with source code. The design files are to manufacture hardware, they aren't applications. I presume you know this though.
>>The firmware blobs themselves may not be GPL'd themselves though, making them non-free.
We're talking about the Free Software Foundation, not the Free Hardware Foundation.
>>Which processor they run on is irrelevant from the perspective of the FSF.
Meh, I've been bitten by a troll.
Free Circuits Foundation Posted Jul 26, 2012 21:49 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
>Microcode/firmware is a software application with source code.
Nope. Microcode is an essential part of the hardware.
>The design files are to manufacture hardware, they aren't applications.
> We're talking about the Free Software Foundation, not the Free Hardware Foundation.
> Meh, I've been bitten by a troll.
Free Circuits Foundation Posted Jul 27, 2012 2:45 UTC (Fri) by jzbiciak (✭ supporter ✭, #5246) [Link] Microcode/firmware is a software application with source code. The design files are to manufacture hardware, they aren't applications. I presume you know this though. Are you familiar at all with FPGAs and CPLDs? I'll give you a hint: The "P" stands for "Programmable." Many of these require their bitstreams to be loaded at power-up before they perform their function. This bitsteam is loaded from some other device on the board, most often some form of serial EEPROM or flash. Often, the logic that's in these same FPGAs and CPLDs will get reduced to an ASIC if the volumes are high enough, but not always. The source code for the FPGA/CPLD is the same source code used to produce the ASIC, generally. Microcode is essentially a part of the design that's been moved from the fixed-in-transistor domain (much like an ASIC) to the programmable domain. The same source code (also likely in the same sort of HDL, although perhaps a custom HDL for the purpose) underlies both. Microcode compiled to a ROM instantiated in transistors is as much an "application with source code" as the very same microcode compiled to an image loaded into the patch-RAM next to the ROM it replaces. The bright line you suggest exists doesn't. Here's an example of a microcode ROM embedded in a voice-synthesis processor. It's 2K bytes, so it's reasonable to suggest it had source code associated with it. This ROM contains control sequences for making various sounds "baked in" to the chip. The chip is sold as a product that makes specific vocal sounds listed in the datasheet. If I replaced this ROM with a RAM and required you to load a bitstream to make this processor functional, are you suddenly less free? I'd argue that because you can now receive bug-fixes, I've only increased the value of this part to you. As a matter of fact, the specific device I took that clip from has a pin that disables the internal ROM and lets you fetch that same control data from external memory. Because that's technologically possible, are you saying free software should not use this chip? Or it should only use this chip with the original baked-in ROM?
Free Circuits Foundation Posted Jul 27, 2012 2:48 UTC (Fri) by jzbiciak (✭ supporter ✭, #5246) [Link] Microcode is essentially a part of the design that's been moved from the fixed-in-transistor domain (much like an ASIC) to the programmable domain. The same source code (also likely in the same sort of HDL, although perhaps a custom HDL for the purpose) underlies both. I meant to say "Loadable microcode" above. My point is, what is so magically freeing about baking microcode into ROM vs. allowing it to be overridden by a copy in RAM? The manufacturer sells you a hardware device that only they have the capacity to modify. Just, in one case you have to buy an entirely new chip to get an update, and in the other, they can send you a field update. The line between hardware and software is often blurry, which is why terms like "firmware" exist.
Free Circuits Foundation Posted Jul 26, 2012 20:53 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
> Which processor they run on is irrelevant from the perspective of the FSF.
right, according to them what matters is if the software has any ability to be upgraded.
according to the FSF logic, they would be happy to have a system that booted from Windows in ROM (because it can't be updated by the manufacturer or the user), but are unwilling to have Linux run on a system that has a video card with the ability to update the firmware stored in flash on the video card.
Guess what, there are a lot of companies that would love to sell you a non-updateable device that you replaced every time there was a new update required.
do you really think that would be a better world?
Free Circuits Foundation Posted Jul 26, 2012 21:49 UTC (Thu) by jebba (✭ supporter ✭, #4439) [Link]
> unwilling to have Linux run on a system that has a video card with the ability to update the firmware stored in flash on the video card.
Where do you get this from? RMS himself used proprietary systems to bootstrap everything, and I bet there are plenty within FSF which may have a system which may have a part that can be flashed. I don't think they've ever said "never run a system which can be flashed". What they are doing is distributing software which removes non-free parts and references.
You are confusing their goal of systems that have free/open firmware, with a mandate that you can't use a system that isn't 100% perfect.
Free Circuits Foundation Posted Jul 26, 2012 22:03 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
If they have no objection to running things in ROM, but do have objections to the OS loading binary blobs into the processor, then they should not object to running a system with the OS in ROM, but (as this topic shows), they do object to running a system with free software that loads a binary blob into another piece of hardware (like a video card) to run on that other hardware.
The Openmoko example where they wanted to have them modify the hardware to make it impossible to replace a binary blob rather than have the identical blob loaded from the OS is a perfect example of them following their policy to it's illogical extreme.
Given two devices that are otherwise identical, they should prefer the device that has the software/firmware able to be replaced by the user over the device that the user cannot replace the software on.
Yes, it's far better if the software being loaded is open, nobody is disagreeing with that. What we are disagreeing over is the idea that hardware the user cannot load software on is better than hardware the user can load software on.
Free Circuits Foundation Posted Aug 2, 2012 12:37 UTC (Thu) by TRauMa (guest, #16483) [Link]
What I don't get is that you keep talking about the user being able to replace the blob. Replace with what? He can't create a new blob, he can't make changes to the original blob - the only thing he *can* do is replace it with another blob from the vendor.
On a system where this is possible, he can actually be coerced to "upgrade", and there may be other "functionality" baked in that he doesn't want.
On a system where this is not possible, the vendor has no easy way to make the system less free after the fact. Given this, the user is protected better.
Free Circuits Foundation Posted Aug 2, 2012 13:30 UTC (Thu) by mjg59 (subscriber, #23239) [Link]
Reverse-engineered free firmware was developed for the PCI Broadcom 802.11 devices, permitting them to be used for academic research into new wireless protocols. That would have been impossible if the firmware had been in ROM.
Free Circuits Foundation Posted Jul 27, 2012 8:51 UTC (Fri) by etienne (subscriber, #25256) [Link]
> do you really think that would be a better world?
It may become a better world, long term, because the company selling you a new hardware to fix a bug you need becomes very expensive, no one buy anything more from them, and they go bust.
Free Circuits Foundation Posted Jul 26, 2012 10:15 UTC (Thu) by khim (subscriber, #9252) [Link] The program the FSF is talking about in this case is the blob, not what is running on your CPU. It doesn't matter *which* chip is running the code; whether it runs on your main CPU or a chip on your network card is irrelevant. This is their pretence, not reality. If they were consistent then Linux-libre announce will looks somewhat like this: Here is our 100%-free version of GNU/Linux OS. To use it you need to dig i80386 CPU somewhere (80486 and newer are not supported because they need microcode and we don't have source for said microcode), find one of these ten motherboards (which are compatible with coreboot; BIOS and UEFI are not supported because they use proprietary binary blobs without source), dig out and restore dizen on RLL hard drives (IDE, SCSI and other such beasts are not supported because they include binary blobs and single RLL hard drive is not big enough to contain this version of Linux-libre), find twenty-years old Ethernet card (all the newer ones are not supported for the same reason… of course very few old ones are supported either)… and enjoy your freedom… if you can. Instead they support bazillion devices with upgradeable firmware which only exist without source. Everything which contains binary blobs in supplied flash is supported while everything where binary blob is supplied by OS is not. This is hypocrisy, plain and simple: they pretend they are fighting against binary blobs, but in reality they just sweep the problem under the carpet. The whole project is huge embarrassment for FSF - it just portrays them as hypocritical fanatics.
Free Circuits Foundation Posted Jul 26, 2012 15:37 UTC (Thu) by jebba (✭ supporter ✭, #4439) [Link]
> This is their pretence, not reality
This is outright false.
There are many network cards that don't require blobs, for instance. In fact, most don't need need firmware uploaded to them. The list of kernel drivers far exceeds the list of firmware blobs in linux-firmware.
You don't need coreboot for them to distribute a free kernel. You don't need coreboot for them to distribute a free OS. You would need coreboot if you wanted your system to be 100% free, but that is separate from what they *distribute*.
In fact, if what you were saying is true, basically no one would be able to run the linux-libre kernel, yet people do. How do you reconcile that?
Free Circuits Foundation Posted Jul 26, 2012 16:03 UTC (Thu) by nybble41 (subscriber, #55106) [Link]
> There are many network cards that don't require blobs, for instance. In fact, most don't need need firmware uploaded to them.
I think you're missing the point. These CPUs don't require microcode blobs. Their original microcode is stored in a ROM on the chip. You only need a blob if you want to _update_ the microcode. Similarly, most network cards have firmware in flash memory which _can_ be upgraded, but doesn't need to be uploaded after every reboot.
The FSF isn't removing the firmware itself (which wasn't included to begin with), or even the ability to load it. They're just censoring information about it from the kernel source and log messages, and thus preventing users from making an informed decision between keeping the non-free firmware/microcode they received with the device, or loading a different non-free firmware/microcode version which may work better. It would be rather destructive if anyone was actually forced to use their version; I certainly don't see how removing this information adds any value.
Free Circuits Foundation Posted Jul 26, 2012 16:30 UTC (Thu) by khim (subscriber, #9252) [Link] There are many network cards that don't require blobs, for instance. No. There are many cards which come with blob preinstalled on flash. In fact most PCI and probably all PCI devices need some kind of blob to even be recognizable by the host. The list of kernel drivers far exceeds the list of firmware blobs in linux-firmware. What this has to do with anything? You would need coreboot if you wanted your system to be 100% free, but that is separate from what they *distribute*. Yes. But what exactly they are distributing? The answer is obvious: system which works just fine on "car with the hood welded shut" but refuses to work with a car where hood is open but mechanics under it is unknown. Is it really the direction they want to push the industry in? In fact, if what you were saying is true, basically no one would be able to run the linux-libre kernel, yet people do. How do you reconcile that? Have you actually read what I wrote? Any system chock-full of undecipherable binary blobs is fine - as long as said blobs come preinstalled. Only systems where said blob comes from the OS (and thus available for hacking even if not in source form) are excluded. IOW: if you take Linux-libre as a stance it says basically this: Moar blobs, we need moar! Make sure they are as hard to obtain and modify as possible, remove all hope of any access to the actual hardware - and we'll be happy. PS3 firmware of 200MiB of god knows what which is required to use the thing? Yes, please: this is what we want. As long as all the stuff which makes the hardware uncontrollable by user comes preinstalled - we are happy. We don't want to ever access it, it can't hack it at all - it's even better. FSF is still fighting windmills while world moved on and we have totally different problems WRT our ability to control the hardware we own.
Free Circuits Foundation Posted Jul 26, 2012 21:57 UTC (Thu) by jebba (✭ supporter ✭, #4439) [Link]
> PS3 firmware of 200MiB of god knows what which is required to use the thing? Yes, please: this is what we want.
Really? You think that is what they want? I don't get why firmware brings out the trolls so heavily. You are obviously shoving words in their mouth that are far, far, far from what their actual goals are.
Now, you can say RMS is going about it wrong. But this is the man that made a lot of this system we are using, and has made other major contributions (e.g with wikipedia). I'll take his path over yours, as you seem quite disingenous and he has produced *many significant* real-world results.
Free Circuits Foundation Posted Jul 27, 2012 8:10 UTC (Fri) by khim (subscriber, #9252) [Link] You think that is what they want? This is what Linux-libre wants. Yes, FSF claims that PS3 is awful piece of shit, but… actions speak louder then words. And PS3 is better-supported target that other, freer systems as far as Linux-libre is concerned. I'll take his path over yours, as you seem quite disingenous and he has produced *many significant* real-world results. It's your choice. Only please, remind me what significant real-world results he produced WRT to OS kernel? AFICS he produced couple of miserable failures (HURD is technical failures while Linux-libre is ideological failure). In other ares, yes, RMS is formidable, in the area of OS kernel development… not so much.
Free Circuits Foundation Posted Jul 25, 2012 20:32 UTC (Wed) by khim (subscriber, #9252) [Link] How is this different from binary blobs for anything else? It's [mostly] the same, of course. Printers for example: most of them are paperweights without their binary blobs. Most???? Hardly. Very few of them require binary blobs to be uploaded before you can use them. What they usually require instead is very complex and heavy prepossessing done on your system. And yes, these "blobs" can frequently mess with your system and they are despised and reviled for this reason. But [rare] printers which don't need such complex dances but instead have multimegabyte blob which you can shove via USB to the device which can then be used using standard protocol (usually PostScript)… yes, these can be treated similarly to HDD or CPU. IOW: you are correct when you point out that not all binary blobs are created equal. If they are injected in your system (and especially if they are injected in your kernel) then they are dangerous. And there are grey area, too. But the dichotomy used by FSF (binary blob is Ok if it comes preinstalled on the flash but it's not Ok if it must be uploaded on system startup) makes no sense whatsoever. Think about it: RMS started with the infamous printer problem. With clear problem (printer driver was crap) and obvious solution (if it's broken you can try to fix it) which met surprising wall (source was not available and thus unhackable). The long-term solution offered was free-software: if all the software in use will come with sources then it'll be easy (or at least possible) to fix problems. This is audacious and extremely long-term solution and I can only applaud for the RMS's bravery (this is honest opinion, not sarcasm). But… let's see on the situation in XXI century, shell we? Today we have two types of hardware:
Hardware which does not require any blobs are surprisingly rare today: even "simple" things like LCD controller or Ethernet adapter nowadays include [relatively] powerful CPU and firmware blob. The Stallman's and FSF's point is that you should have access to the sources (and necessary build environment) of any user installable software. Bingo! And now, in this world, where every chip has some kind of firmware, FSF approach leads to the "solution" which is not only more expensive, but also less hackable! FSF's preferred "solution" is always, always, ALWAYS worse from the hackability POV! If the binary blob is uploaded from the host system then there are quite real possibility that someone will be able to reverse-engineer it and fix it. If blob is sealed in flash then it's unhackable. Remember the Santayana’s definition? "Fanaticism consists in redoubling your efforts when you have forgotten your aim". If this is not an example of fanaticism then what is? When you reach the stage where you push for the "solution" which makes the original problem which started the whole movement worse… I just don't know what to say after this point. Regardless of the goodness of point itself, it is hard to understand why so called "firmware" is any different from normal "driver" software from this point of view. Rilly? You don't understand? Driver is embedded in your OS execution environment. It can affect literally every aspect of your system (especially if it's kernel-level driver, but even if it's merely a binary blob executed with root privileges it's still quite invasive). Firmware, on the other hand, is executed on physically separated CPU in restricted environment. Microcode blob for the CPU is interesting corner-case: it's executed on your CPU and can, theoretically, do anything... but you can not avoid that. Without this binary blob contemporary CPU can not ever boot Linux-libre! The only difference between having microcode blob in BIOS and having it in Linux is the possibility of upgrade: it's harder and riskier to upgrade BIOS.
Free Circuits Foundation Posted Jul 27, 2012 22:43 UTC (Fri) by pabs (subscriber, #43278) [Link]
Printers run (proprietary) operating systems, some of which have had security researchers look for and find vulnerabilities. I for one want to be able to run Free Software (such as Debian) on my printer. You seem to be talking about host-side printer drivers rather than printer operating systems.
Free Circuits Foundation Posted Jul 27, 2012 23:03 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
some printers run operating systems, some are little more than a buffer driven from the main CPU (the buffer is just because the CPU allocation on the main CPU may not be stable enough.
This is very similar to the modem/winmodem split where the modems had dedicated hardware to process the data and the winmodems were little more than sound cards that could hook to a phone line.
At the low end, khim is right, at the high end, you are right.
But in any case (getting back to the topic at hand), are you really more free with a printer that you can't upgrade the software on than with one that you send a binary blob from the OS to initialize?
Free Circuits Foundation Posted Jul 28, 2012 4:46 UTC (Sat) by scientes (guest, #83068) [Link]
today even the low end printers often run full operating systems. You can bet your ass all the printers with SD slots are sure full operating systems.
Free Circuits Foundation Posted Jul 25, 2012 20:15 UTC (Wed) by jzbiciak (✭ supporter ✭, #5246) [Link] How about HDLs? Most (all?) CPUs have large components written in a hardware design language such as VHDL or Verilog, which is then compiled down to gates and ultimately transistors. The same HDL can often be compiled for an FPGA. I find the FSF's position somewhat inconsistent inasmuch as CPUs can be software, but they're not demanding the source code for the CPUs they run. The OpenCores projects at least look to change that. The position of the hardware vendors (and one that I personally find reasonable) is that they're selling you something that should be considered hardware. The fact that they have some mechanisms to fix hardware bugs without fully discarding and replacing it does not change the fact that it's hardware. It would be little different than the days when CPUs were made of discrete logic, and a technician could come and blue-wire the board or swap out a component here or there to fix/improve its behavior. Just like the kernel / user-space interface, the CPU's instruction set and registers for the CPU form the hardware/software boundary. That is, the boundary is defined by the programmer's model of the machine. Microcode is not part of the programmer's model. These microcode updates, IMHO, are on the hardware side of the boundary, and have similar semantics to the blue-wire scenario above. At the computer shop, you don't generally know what stepping CPU you're getting, so you can't crack open the processor's (usually lenghty) errata document and determine what bugs you're buying. But, microcode updates allow processor vendors to fix bugs in older steppings to address errata and make them more like newer steppings. As a result, we all get cheaper processors faster, and are insulated from bugs that might creep in. I'm OK with this. I don't see it infringing on my freedoms to write whatever software I like to run on said computer. I see it as a cheaper but semantically equivalent step to just replacing a processor with some defects with another with presumably fewer defects. Blocking microcode updates just tilts too hard at windmills for my taste.
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 24, 2012 16:37 UTC (Tue) by lindi (subscriber, #53135) [Link]
Is there a git repo for linux-libre somewhere? Their tools seem to be focused on tarballs.
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 24, 2012 21:22 UTC (Tue) by lxoliva (subscriber, #40702) [Link]
Not yet, I'm afraid. There are plans to create a deblobbed git repository tracking upstream, but we don't have the code to write a clean history so that we don't end up offering the very traps we set out to disarm.
This plan will require improvements to the deblobbing infrastructure that will enable us to fix the long-standing implementation bug that completely disables the blob-loading machinery. The intent is to avoid asking for blobs, but the Linux interface makes it hard to avoid that without also preventing users from loading the blobs if they really mean to. The solution for that is awkward, and not really achievable with the current deblobbing machinery.
There are also plans to improve git so as to enable back-and-forth merging between clean and blobful trees, to make cooperation easier without betraying our principles, but we're not there yet. We can always use help! More brains are welcome ;-P :-D
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 25, 2012 8:02 UTC (Wed) by gioele (subscriber, #61675) [Link]
> There are also plans to improve git so as to enable back-and-forth merging between clean and blobful trees,
Have you got any pointer to these plans? Such modifications to git would be very helpful to all the projects that maintain patches on top of git trees, think OpenWRT or all the Debian packages.
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 25, 2012 9:45 UTC (Wed) by lindi (subscriber, #53135) [Link]
Well I wanted git precisely to be able to observe the history. How the number of modifications to mainline change over time for example. I don't want to start unpacking hundreds of tarballs and running diff against them..
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 24, 2012 17:04 UTC (Tue) by nix (subscriber, #2304) [Link]
It's interesting that they deblob the intel microcode driver, given that the microcode it accepts is not so much 'non-free' as 'just plain unavailable'. (Unless you split up the microcode files Intel *does* make available -- by hand, as far as I can tell -- you still have to use microcode_ctl to load them. Not that those files are even slightly free, hell, there isn't even a changelog.)
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 24, 2012 21:38 UTC (Tue) by lxoliva (subscriber, #40702) [Link]
Have you actually looked at the license of the microcode blobs? It's not just that they're software without corresponding sources, the license is also quite obnoxious! Sorry, I'm about to hit the road for FISL so I don't have it handy, but it shouldn't be too hard to find the license file if you have the blob (and its userland loader) installed on your system.
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 24, 2012 23:01 UTC (Tue) by nix (subscriber, #2304) [Link]
Oh, I'm aware the license for the blobs Intel provides is obnoxious -- but the blobs Intel provides are *not* the blobs that were deblobbed from the Intel microcode driver! The blobs that driver accepts are mythical things available nowhere at all (but which rumour has it that scripts that are banging about in various places on the Internet may or may not be able to produce from the blobs Intel does provide). One wonders whether a blob that doesn't exist is somehow even less free than a blob that does who-knows-what that is provided without changelog and without indication of wtf it fixes...
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 24, 2012 1:00 UTC (Tue) by vrfy (subscriber, #13362) [Link]
Maybe they could name it Linux-brainfree, that would make an even better headline.
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?
Running it now Posted Jul 24, 2012 14:14 UTC (Tue) by coriordan (guest, #7544) [Link] Everything works.
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 27, 2012 22:42 UTC (Fri) by pabs (subscriber, #43278) [Link]
Seems to me that Linux-libre could be turned into an upstream-mergable patch set that could create a run-time or compile-time switch to cause Linux to stop advertising blobs. Is there anything else in Linux-libre?
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 29, 2012 18:11 UTC (Sun) by vonbrand (subscriber, #4458) [Link] Sorry, but a build time switch leaves the bits "advertising non free software" in the source, some minor might just see them, or ($DEITY forbid) lure somebody into selecting the ideologically impure setting and have some unsuspecting user exposed to said inmoral choices at run time. It is just much easier to (try to) neuter the software built by others than to write your own according to your views.
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 31, 2012 14:43 UTC (Tue) by ssam (subscriber, #46587) [Link]
In the early days the GNU project was pragmatic and highly successful. They wrote a set of open software that ran on closed operating systems. They had goals of fully open systems, but preferred partially open to something that did not work.
If they took today's zero-tolerance of closed _loadable_ software, then they would have been forced to give up on computers and buy games consoles (all the games are on ROMs so you dont need the source).
This would have been a terrible shame, and we would probably not have all the great open software that we have today.
I think that trying to draw a line between software and hardware is very difficult. no matter where you put it someone will find a corner case that makes you look silly (and here it is a very common case). So to draw a hard line and say that open is essential on this side of the line, and closed is fine on the other side, if going to be a difficult point to argue. if you say that you want open everywhere, but its more important at the software end of the scale, then you have a pragmatic position from which you can make progress.
I wonder when they will pull out the code that allows linux to boot on machines with closed BIOS?
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 31, 2012 16:15 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
> I wonder when they will pull out the code that allows linux to boot on machines with closed BIOS?
I wonder if anyone has pointed out to them that most motherboards nowdays have the BIOS in flash where it can be modified, but only using the closed firmware blobs, and usually only with proprietary software
GNU Linux-libre 3.5-gnu: Free and a half Posted Jul 31, 2012 17:53 UTC (Tue) by jimparis (subscriber, #38647) [Link]
It's safe to assume the people at the FSF are not stupid, which implies that of course they know that already. Here is their take on flashable BIOS: http://www.fsf.org/campaigns/free-bios.html
GNU Linux-libre 3.5-gnu: Free and a half Posted Aug 1, 2012 9:11 UTC (Wed) by ssam (subscriber, #46587) [Link]
so it looks to me like the linux-libre kernel encourages use of evil modifiable BIOSs, and hence I cannot recommend it. it should be fixed to only boot on coreboot and closed unmodifiable uninspectable ROM BIOSs.
I am going to make a windows live cdrom and glue my CD tray closed. Then I will have a completely free unmodifiable computer.
(I just want to make it clear that I am hugely grateful of the work of the GNU project and FSF. Without them computing would be in a sorry state. I donate to them. I just think they have painted themselves into the stupid corner on the hardware/software boundary.)
|
|||||||||||||
