| |||||||||||||
FSFLA: Linux kernel is "open core"FSFLA: Linux kernel is "open core"Posted Nov 11, 2010 2:27 UTC (Thu) by dwmw2 (subscriber, #2063)In reply to: FSFLA: Linux kernel is "open core" by lxoliva Parent article: FSFLA: Linux kernel is "open core"
"The fundamental difference is that it doesn't *ask* the user for any of these pieces of software. The moment it does is the moment it induces the user to give up their freedom."So it's OK to have this closed, undebuggable, unfixable crap as long as you aren't asked about it? If you look at it like that, then your goals are entirely out of sync with mine because you aren't going anywhere near far enough :) I do care about the problems caused by crappy system BIOS code which we can't fix, and which the vendors usually don't bother even to test competently. And about broken device firmware like the Marvell wireless abomination that I had to deal with for OLPC which was so unreliable that we had to hook up an extra GPIO line to the module's reset pin. I care about these things regardless of whether they're loaded from flash or whether they're loaded through the kernel. To me, that seems like an arbitrary and pointless distinction. I really don't understand why clever, savvy people would accept that these instances of non-free software are acceptable, as long as they aren't asked about it. I find it astonishing that a crappy piece of closed-source firmware becomes more acceptable to you if it's flashed into the hardware such that you can't replace it with a free reimplementation. If the Broadcom b43 devices were like that, we'd never have got OpenFWWF.
"When the kernel doesn't say give me this piece of non-Free Software, but rather just works with whatever is on the system it's running, there isn't any problem."The kernel never says that. The kernel says "give me a piece of software which drives this device" and cares not about the licensing. It doesn't care whether it's using the Broadcom b43 firmware or the OpenFWWF version, for example (except to the extent that the different firmware has different behaviour which it has to adapt to). Only if you choose to give it a non-free version will it use it.
(Log in to post comments)
FSFLA: Linux kernel is "open core" Posted Nov 11, 2010 3:54 UTC (Thu) by lxoliva (subscriber, #40702) [Link]
> So it's OK to have this closed, undebuggable, unfixable crap as long as you aren't asked about it?
No, it's not ok at all, and it surprises me that you're bringing up this straw man again. We've already covered it, both in this discussion, and in our personal conversations.
What is ok is for a program (even the kernel) to interface and work with the environment in which the user started it. If the user decided to run the kernel on a machine that has a crappy non-Free BIOS, well, too bad, it can lament for the user but still do the best it can to work, even without telling the user anything about it.
However, the moment the kernel runs request_firmware(), it's asking for something. If this something is known to be non-Free Software, it's not OK for the kernel to ask for it, even though it would be ok (but unfortunate) for the user to ask the kernel to use it and for the kernel to then use it.
> It doesn't care whether it's using the Broadcom b43 firmware or the OpenFWWF version, for example
Except that, indeed, it does. It doesn't just use different pathnames to ask for one or the other, it also tests properties of the user-supplied file to figure out which one it got.
If it didn't have to tell the difference, then Linux-libre would make the request and just take whatever the user gave it, for it would be indistinguishable from an inducement perspective, i.e., the kernel would not be inducing the user to give up her freedom. From the point of view of the kernel, it would be just as indistinguishable as a hardware device that is implemented entirely as hardware circuits or driven by a piece of software stored in ROM or non-volatile RAM, in that no inducement is involved.
FSFLA: Linux kernel is "open core" Posted Nov 11, 2010 10:37 UTC (Thu) by cesarb (subscriber, #6266) [Link]
> However, the moment the kernel runs request_firmware(), it's asking for something. If this something is known to be non-Free Software, it's not OK for the kernel to ask for it, even though it would be ok (but unfortunate) for the user to ask the kernel to use it and for the kernel to then use it.
"The moment the kernel runs pci_enable_device(), it's asking for something. If this something is known to be non-Free hardware or hardware with non-Free firmware, it's not OK for the kernel to ask for it, even though it would be ok (but unfortunate) for the user to ask the kernel to use it and for the kernel to then use it."
(I do not know if this variation on your argument is a good one or even if it makes sense, but it sounded too good to let it pass.)
FSFLA: Linux kernel is "open core" Posted Nov 11, 2010 11:41 UTC (Thu) by lxoliva (subscriber, #40702) [Link]
It doesn't even begin to make sense. pci_enable_device() doesn't ask the user to install a device, so there's no inducement to error involved.
FSFLA: Linux kernel is "open core" Posted Nov 11, 2010 10:45 UTC (Thu) by dwmw2 (subscriber, #2063) [Link] This is pure sophistry. When I bought my laptop, it arrived with a bunch of closed firmware for the devices it contains. Some of that firmware was present in various flash chips, and some of it was encoded in magnetic patterns on spinning rust.And you're telling me it's OK to use one but not the other, just because the kernel is slightly more involved in getting the latter into the correct place in device RAM? On the basis that if you can stick your fingers in your ears and sing 'la la la' and ignore it, it's not really happening? Quite frankly, we have much better things to be doing.
FSFLA: Linux kernel is "open core" Posted Nov 11, 2010 12:42 UTC (Thu) by lxoliva (subscriber, #40702) [Link]
No, that's not what I'm saying.
What I'm telling you is that your kernel can't tell that this is your case, it can't tell whether there's any non-Free firmware in the devices that are present in the system, but it does know about devices that require non-Free firmware, and it wouldn't be right for it to induce you to install this additional non-Free Software on your system.
What I'm also saying is that it's not the kernel business to tell you what is or isn't ok, but it is the business of any freedom-caring program to avoid inducing users to install non-Free Software. If you want to install them and use them, it shouldn't stop you from doing so, but it shouldn't encourage you to install them.
Sadly, the request_firmware interface is designed in such a way that the kernel can't tell whether a certain piece of non-Free Software is available without actually asking for it, so it needs to be disabled until we can implement some alternate interface that enables testing without inducing (e.g. as described in the 2.6.33-libre announcement). But for firmware that is present in flash chips that need not even be visible to the kernel, the kernel doesn't ask for the firmware it doesn't even know about, so it may as well assume the user has already made the decision to use it (if it's there at all) and proceed to use it.
I can understand that you don't agree with the notion that freedom-respecting programs shouldn't induce users into non-Free traps, but I don't think it's such a hard notion to understand either. There's no reason for you to resort to name calling and other disrespectful behavior just because you don't agree with someone else's opinion. If you have honestly failed to understand it, I'll be happy to try to explain further, but I'm not really interested in your verbal abuse.
FSFLA: Linux kernel is "open core" Posted Nov 11, 2010 13:54 UTC (Thu) by dwmw2 (subscriber, #2063) [Link] "What I'm telling you is that your kernel can't tell that this is your case, it can't tell whether there's any non-Free firmware in the devices that are present in the system, but it does know about devices that require non-Free firmware "Kind of true and yet still so wrong. Yeah, the kernel can't tell whether my hard drive has non-free firmware, or whether my Prism2 PCMCIA wireless card does, etc. But we know they do, we even detect certain revisions or features of the firmware and behave accordingly. And the kernel can't tell whether a given firmware which it asks for with request_firmware() is free or not, either. The developer might have a-priori knowledge, just as they do in the firmware-in-flash case, but why's that any different? In addition, in the case of a loadable firmware it's actually possible that it could be replaced by a free reimplementation, even if there was only a non-free version available when the driver was first written.
"I can understand that you don't agree with the notion that freedom-respecting programs shouldn't induce users into non-Free traps, but I don't think it's such a hard notion to understand either."You are mistaken; I understand that completely and I even sympathise to a certain extent¹. I just think that you're going about it the wrong way. You're pushing a policy decision into the kernel where it doesn't belong, when the kernel doesn't even have access to the information it would need to enforce that policy. I even understand, syntactically and semantically, your argument against doing this in the technically-appropriate place; in the userspace firmware loader where the request could be silently ignored without the user ever knowing or being "induced" to do anything. But I think it's entirely specious. ¹ when I say I sympathise "to a certain extent", I mean only until I reach the realisation that your "no inducement" policy really seems to translate into silent failure without letting the user know why something isn't working. If there's anything that really annoys me, it's crappy error handling where the user has to jump through hoops and rebuild things to debug and work out why they didn't work the first time. And that's what you seem to be advocating. And then I realise that the long-term effect of what you're trying to do would actually induce users to favour the "Tivoised" devices which have firmware built-in on flash, over the devices where it's easier to replace the firmware because it's loaded through the OS. And by that time I really don't have much sympathy left for your position at all.
FSFLA: Linux kernel is "open core" Posted Nov 12, 2010 4:16 UTC (Fri) by lxoliva (subscriber, #40702) [Link]
> But we know they do, we even detect certain revisions or features of the firmware and behave accordingly.
That's kind of fine as far as the kernel is concerned: it's not inducing users to install or accept it, just assuming the user has accepted it.
It's completely unlike *asking* the user to install (or update an EEPROM) firmware.
Because, again, the point is not to *prevent* people from using non-Free Software, it's to avoid *inducing* them to do so.
It might make sense to add a run-time option to the kernel for drivers that somehow detect or know about non-Free firmware in devices they drive to fail, issue a warning or silently proceed depending on how the option is set. Do you have other examples of such drivers?
FSFLA: Linux kernel is "open core" Posted Nov 12, 2010 14:45 UTC (Fri) by dwmw2 (subscriber, #2063) [Link] I gave some examples hard drives and ACPI. Those drivers could reasonably by marked by your CONFIG_NONFREE option too.Going back to my laptop I don't see why it's reasonable to assume that I've accepted the non-free firmware which is built in; I may not even know that it's there. Many people don't even think about firmware as a separate entity; they know only of the operating system, and the hardware. On the other hand, my laptop was also delivered with non-free firmware for the wireless card, which was bundled within binary driver in the preinstalled operating system. You can tell that I've accepted that, because otherwise I wouldn't have run the b43-fwcutter tool, and the firmware blob wouldn't be present in my /lib/firmware directory. What you're doing is trying to make the kernel NOT EVEN LOOK at the latter case where I have clearly and explicitly accepted the non-free firmware, while still blindly accepting the former case where you only have a fairly dubious assumption that I'm OK with it. If I run your kernel, you are preventing me from using that wireless firmware that was already in my system when I bought it; you're not just avoiding the inducement. Really, if it's just about the *inducement* then all you need to do is disable the automatic PackageKit trigger which makes it go looking for a firmware file that it can't find locally. You don't need to break the kernel so that it can no longer use firmware blobs that the user has installed on their system. And you don't need to push policies into the kernel where they don't belong, and where the information required to implement them is not available.
FSFLA: Linux kernel is "open core" Posted Nov 12, 2010 18:59 UTC (Fri) by lxoliva (subscriber, #40702) [Link]
I agree it's important to inform users about the non-Free firmware built into their computers. I'll give some thought about how to do that.
As for the b43 non-Free firmware, I think it's presence is not an indicator that you're even aware of it either. I mean, Free and nearly-Free distros aren't normally permitted to bundle it, but I suppose a computer vendor would obtain a license to ship the b43 firmware pre-installed along with a GNU+Linux distro of its choice, and would presumably silence any warnings to that effect that we might have put in upstream :-(
Now, your characterization of what I'm trying to make is unfair. I'm not tryign to make the kernel not even look; I'm rather trying to avoid a situation in which the kernel issues a request for it without knowing whether it's there. There's more than one way to improve the situation that doesn't involve completely disabling the firmware request.
One example is the hash-based implementation suggested in the 2.6.33-libre announcement. Another is to have userland pre-register available pieces of firmware, and have the kernel only issue requests for those that have been pre-registered. Both of these would remove the inducement without disabling functionality.
Would you help get either of these, or some other solution that accomplishes the same within the kernel, into upstream?
FSFLA: Linux kernel is "open core" Posted Nov 12, 2010 19:10 UTC (Fri) by jebba (✭ supporter ✭, #4439) [Link] Lets say that by 2.6.38 the firmware/ directory is gone (ignoring for the moment the fact that there appears to be more non-free blobs remaining). At that point linux-2.6.38.tar is clean in terms of containing only GPL code.So the kernel can say "I need firmware for $foo" and it becomes a userspace issue. Userspace can hand the kernel a proprietary blob, a FLOSS blob, or say it has nothing.
In this scenario it seems the best place for stopping the "inducement" would be in userspace. That way it can have a nice list of free and non-free firmware images (via sha1sums or somesuch). So if you want to have a system which doesn't pester you with non-free software, you could launch it (hypothetically), like: Just a suggestion. I hesitate to make it. ;)
FSFLA: Linux kernel is "open core" Posted Nov 12, 2010 19:34 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
I'll point out that trying to maintain a list of free sha1 signatures defeats the purpose of the firmware being free because if the user modifies it, the sha1 won't match anymore.
FSFLA: Linux kernel is "open core" Posted Nov 12, 2010 21:08 UTC (Fri) by dwmw2 (subscriber, #2063) [Link] We don't need the list of signatures. If we do this the sensible way in the userspace firmware loader, we have the proper licensing information; in the WHENCE file or the more machine-readable thing which will shortly replace it.It's only if we try to do this in the kernel where it doesn't belong that we end up with broken hacks like the sha1 hashes.
FSFLA: Linux kernel is "open core" Posted Nov 12, 2010 21:12 UTC (Fri) by foom (subscriber, #14868) [Link]
> I agree it's important to inform users about the non-Free firmware built into their computers. I'll give some thought about how to do that.
It would be useful for someone to start cataloging what non-free firmware there is, and which alternative hardware you can purchase instead (if any) that has free firmware available. There is currently essentially *no* information about this problem available currently.
Things I can think of with Flash-based (upgradable!) non-free firmware in my computer for which there are to my knowledge zero devices with free firmware available:
Things that come with non-free firmware that people have started working on a replacement for:
And I bet there's more that I forgot about.
I think it would greatly increase the credibility of linux-libre if it also advised users of the danger of using non-free firmware in all the above devices, as well as the devices that require firmware to be uploaded at boot. I bet most people don't even think about the dangers of the non-free OS running in their hard drive.
FSFLA: Linux kernel is "open core" Posted Nov 12, 2010 22:30 UTC (Fri) by jebba (✭ supporter ✭, #4439) [Link]
I think the Lemote Yeeloong would fit most or all of the above. At least it has free wifi, ethernet, video, and BIOS.
http://www.lemote.com/en/products/Notebook/2010/0310/112....
FSFLA: Linux kernel is "open core" Posted Nov 14, 2010 4:50 UTC (Sun) by foom (subscriber, #14868) [Link]
That's great! I was unaware that such a freedom-supporting laptop was available for sale. Clearly it could use more prominent mention whenever people talk about non-freeness of firmware.
I do wonder about its card reader, keyboard, and touchpad, however...
And I'm *sure* its Hard Drive has non-free firmware in it. They could fix that part, at least, by putting raw flash chips in instead, and using one of Linux's raw-flash filesystems like JFFS2 or UBIFS.
FSFLA: Linux kernel is "open core" Posted Nov 12, 2010 21:16 UTC (Fri) by dwmw2 (subscriber, #2063) [Link] I think you misunderstood the situation with the b43 non-free firmware.Broadcom are not giving permission for anyone to distribute that firmware for use with Linux, because of their crack-inspired concerns about regulatory stuff. Its presence in /lib/firmware is an indicator that the user has manually extracted it from a Windows or Mac OS driver and installed it there. When I talked about it coming with the hardware, that's because it was in the preinstalled copy of OS X. Not because it would ever be found in any pre-installed Linux system. No, I won't help you get any of your suggestions into the upstream kernel. As I've already said, it doesn't belong in the kernel. It can be done in the userspace loader so much more easily, where the licensing information is actually available.
I just don't agree with your claim that the simple udev event which triggers the userspace firmware loader is equivalent to inducing the user to use non-free software. I find it completely insane. It would be perfectly acceptable just to refuse the firmware request in userspace where we have the required licensing information and can implement the policy the user desires. And whatever you said, unless I'm missing a technical detail your scheme has actually broken the drivers. I could no longer use my b43 wireless card without actually rebuilding the kernel to undo your damage. Seriously, Alexandre, just do it in udev.
FSFLA: Linux kernel is "open core" Posted Nov 13, 2010 7:55 UTC (Sat) by lxoliva (subscriber, #40702) [Link]
> Broadcom are not giving permission for anyone to distribute that firmware for use with Linux
Interesting... I'm pretty sure I've seen laptops with b43 WiFi and GNU/Linux preinstalled for sale. I wonder if the laptop vendors actually ship this stuff without functional WiFi. That would be... surprising.
> unless I'm missing a technical detail your scheme has actually broken the drivers
it looks lke you are indeed missing something, for I have proposed *3* options, and only one of them is currently implemented: the one that indeed refrains from asking for the non-Free b43 blob, asking for /*(DEBLOBBED)*/ and discarding the userland response instead.
The two other options are:
- have the kernel ask for a unidirectional hash of the blob name, and have udev look for a blob whose name hashes to the same value (as proposed in the 2.6.33-libre announcement)
- have userland register with the kernel available firmware names early in initrd, and right after switch_root, so that the kernel (optionally) won't even ask for names that aren't registered. This won't just make such requests faster: it can also enable pieces of firwmare built into the kernel to be updated from userland, something that can't be done ATM AFAIK.
Now, you'll see that both of these are actually orthogonal to the licensing of the blobs: they're just ways to enable the kernel to tell whether a certain file is available without inducing users to go get them, in one case, by refraining from naming the blobs so they can't be identified unless you have them; in the other, by having them named at first, so the kernel knows it's not asking for something that the user doesn't want to be bothered about.
FSFLA: Linux kernel is "open core" Posted Nov 13, 2010 9:55 UTC (Sat) by dwmw2 (subscriber, #2063) [Link] "Interesting... I'm pretty sure I've seen laptops with b43 WiFi and GNU/Linux preinstalled for sale."If that's true, then those devices wouldn't be using the normal kernel driver for b43; they'd be using the illegal binary-only one which has the firmware built in to it. And thus the same point applies for the user to have extracted that firmware and placed it into /lib/firmware requires a deliberate effort on their part. "Now, you'll see that both of these are actually orthogonal to the licensing of the blobs: they're just ways to enable the kernel to tell whether a certain file is available without inducing users to go get them"Alexandre, this is getting stupid and I'm getting bored. DO IT IN USERSPACE A simple upcall from kernel to udev with a filename such as cpia2/stv0672_vp4.bin is NOT an inducement to the user to use non-free software. Not even if the user is currently running udev-monitor to watch for such things. That's just a stupid thing to say. It's almost as if you're confusing "userspace" with "the user". The process which handles the request in userspace is in a much better position to do what you want. It has the licensing information, and can easily implement the policy you desire which seems to be a silent failure without inducing the user to know why their hardware isn't working. Or you could do the filtering in modprobe instead you could look at the MODULE_FIRMWARE tag in the module, then refuse to load the module at all if it is going to ask for a firmware file that you cannot provide. And that way you do get to avoid the request_firmware() call that you are so bizarrely concerned about.
FSFLA: Linux kernel is "open core" Posted Nov 13, 2010 12:37 UTC (Sat) by foom (subscriber, #14868) [Link]
+1: exactly what I was going to say. A RPC call from kernel->udev is not inducing the *user* (a person, who receive RPC calls!) in any way.
FSFLA: Linux kernel is "open core" Posted Nov 14, 2010 22:15 UTC (Sun) by lxoliva (subscriber, #40702) [Link]
> The process which handles the request in userspace is in a much better position to do what you want
This just shows that you don't have any idea of what I want.
I believe computers should obey their users. This userspace program you suggest could do nothing but accept or reject software that users have installed on their computers. IMHO, that doesn't make sense. If users chose to install certain software on their computers, the computers had better obey when users command run it or install it. Anything else is, erhm, defective by design, if you get what I mean.
If you're assuming that myself or Linux-libre have any intention of taking this control away from users, of, like, protecting users from themselves, you'd be wrong, because the assumption is wrong. The goal is rather to help users defend themselves from the luring by unethical vendors that tempt them into giving up control over their computers, giving up freedom and betraying their community; unethical vendors that try to fool them into thinking of it all as ok, even desirable.
Now, you may get as bored and stupid as you wish, and rationalize that a request might be hidden from the user by userland programs, and that ignorant users wouldn't know to look at log files to investigate and troubleshoot why their devices aren't working, and that they wouldn't know to search for the log filename in a web search engine and find the file along with a message that is biased towards accepting it without questioning or even thinking about it. If you assume users wouldn't do that, you'd again be mistaken, because the assumption is wrong.
Now, let's look at your statement that a userland program is in a much better position to do what I want. Even if the userland program could indeed clean up the log messages from a local machine, it can't go back in time and prevent the kernel from having issued the request, so it can't do what I want.
Setting aside this key problem, that you'd surely qualify as irrelevant, I can see how a hotplug program could look at a request from the kernel (or a module's firmware requirements) and decide whether or not to satisfy the request, for firmware files that are installed on the system. But then, why would you want to deny loading of modules that the user installed? That doesn't make sense! It's obvious to me that you're trying to solve a different problem.
It gets even more interesting when you get to a module that is *not* installed. The userland program can't possibly know anything about it, but the developer of the kernel module that asks for it knows everything there is to know. So how can you say that the userland program is at a better position to decide how to inform the user about the problem in a way that makes it clear that the hardware vendor is trying to take her freedom away? That's demonstrably false for precisely the cases that matter, and you state that the one piece of software whose developer holds the relevant knowledge is the wrong place to encode it?!?
Finally, you suggest that some other piece of software even prevents modules from being loaded if their meta-information says they might request some unavailable or undesirable module. That's a terrible suggestion. A number of modules request firmware only for specific variants of the hardware they drive, while other variants work just fine without any firmware. For others, the firmware may provide fixes or additional functionality, but the hardware still works fine (sometimes without loss of functionality) without it. See? It doesn't even begin to make sense! Userland just doesn't *have* the information it takes to make even the sort of decision you want it to make. It's the module that knows what it expects.
Also, you mention licensing information. That's only one of the dimensions of the software freedom problem. A number of blobs are under licenses that qualify as Free Software licenses, but since they are missing source code, they are non-Free. I suspect (but can't prove) that they were provided under such licenses so as to fool kernel developers that have a fixation on license-compatibility issues without realizing that X11-licensed code is only compatible with the GPL when you can offer the corresponding sources also under the GPL. Without it, redistributing the binaries as part of a work licensed (even if partially) under the GPL from a third party amounts to copyright infringement. And that's just one of the ways in which fake contributors to the kernel keep other kernel developers legally hostage, and that shows why knowing licensing information is also insufficient.
What userland has that the module doesn't have is a good way to interact with the user and display useful information. That's why Linux-libre is not the best place for that, but it still conveys to userland the information needed to display a useful message. The /*(DEBLOBBED)*/ firmware name was designed that way so that it never matches a real file, and so that hotplug scripts can match in the slow path and send an informative message to users through a graphical interface. This string also makes to logs, so that users can immediately find out there's something wrong with the blob that's being asked for, when they web-search for this string they found in their logs.
So, your design is pointless for my goals, and even for yours it uses insufficient information, it misses even that at cases that matter, and the proposed improvement breaks it further. All of this because you seem *DETERMINED* to do it at a place other than the one that has all the relevant information. I *will* let you do that, Dave ;-), but since that will do nothing to accomplish my goals, I'll have to keep on doing what needs to be done at the place where it can actually be done. Your shouting and misrepresentation (out of misunderstanding?) of my goals won't change that.
FSFLA: Linux kernel is "open core" Posted Nov 14, 2010 23:13 UTC (Sun) by anselm (subscriber, #2796) [Link] Now, you may get as bored and stupid as you wish, and rationalize that a request might be hidden from the user by userland programs, and that ignorant users wouldn't know to look at log files to investigate and troubleshoot why their devices aren't working, and that they wouldn't know to search for the log filename in a web search engine and find the file along with a message that is biased towards accepting it without questioning or even thinking about it. If you assume users wouldn't do that, you'd again be mistaken, because the assumption is wrong. Just so I get this right: You'd prefer if the Linux kernel was generally modified to the effect that the fact that driver X missed firmware blob Y not be logged in the first place, just so a clever Linux user won't go out of their way to obtain blob Y in order to make their system work. So your proposal is, in effect, to keep users ignorant of their options. They do not get the chance to make a conscious decision towards freedom because you have decided that this decision isn't really theirs to make, since you have made it already on their behalf without bothering to consult them as to their actual preference. I'd say feel free to put together and publish a Linux distribution that works exactly like you describe. Those Linux users who are truly freedom-minded (in the sense of the FSFLA) will surely flock to it and it will thrive. But leave it to the rest of us to make our own conscious decisions as to what level of »freedom« we want to accept on our systems. Thank you.
FSFLA: Linux kernel is "open core" Posted Nov 15, 2010 2:30 UTC (Mon) by lxoliva (subscriber, #40702) [Link]
> You'd prefer if the Linux kernel was generally modified to the effect that the fact that driver X missed firmware blob Y not be logged in the first place
No, but that's one of the favorite straw men against Linux-libre.
We do log a message, and we intend to keep on logging messages, just not messages that sound like please get me file blobname.bin so that device works, but rather more along the lines of missing Free firmware for device.
FSFLA: Linux kernel is "open core" Posted Nov 15, 2010 11:32 UTC (Mon) by anselm (subscriber, #2796) [Link] but rather more along the lines of “missing Free firmware for device” I don't think this will keep people from checking the Internet to find out exactly what file they are missing, and installing that – so this is no more or less an »inducement« than posting the full name of the missing file. Your only real alternative is to post nothing at all, which I believe is ethically unsound because it tries to keep people from knowing their options. Speaking as somebody who keeps Linux servers running for money, I would much rather see the kernel tell me exactly what a problem (any problem, not just loading firmware blobs) was in order to make it easier to fix, rather than post cryptic messages to the log that make me do extra detective work. If the missing firmware blob in question is non-free, let me decide whether I want it installed, and don't make my life more difficult by having me perform extra detective work in order to find out what it even is. (It would be naive to assume that little obfuscation games like hashing the file names would make a big difference here.) As I said (and as you didn't reply to), feel free to publish a Linux distribution that adheres to your concept of »freedom« and see how you get on – but don't try, by getting the standard kernel changed, to force your concept of »freedom« on to those of us who can make our own decisions, thank you very much.
FSFLA: Linux kernel is "open core" Posted Nov 15, 2010 19:37 UTC (Mon) by lxoliva (subscriber, #40702) [Link]
Telling you that there isn't Free firmware to run a certain device, to me, is a complete description of the problem. Now, I'm not suggesting the standard kernel to do that, not even by default. All I'm asking for is an *option* to have it do that. But even that is denied. It's clear who's forcing whom, isn't it?
As for publishing a Linux distribution that adheres to this concept of freedom, I've already done that. This announcement refers to precisely that: it's a Free and bait-free version of the Linux distribution published by Mr Torvalds.
Now, it might be that you mistakenly believe that Linux is a complete system. It isn't. Mr Torvalds himself said so when he first announced his kernel, noting that, to get a functional system, you'd need a number of core components of the GNU operating system.
So, if you meant a GNU/Linux distro (or rather a GNU/Linux-libre distro, since it's the GNU system running on top of the Linux-libre kernel), I'm not sure what the point of my creating yet another such distro. The Linux-libre page already refers to a number of distros that have adopted Linux-libre. Just yesterday I learned of one more. It's spreading!
Now, would I prefer that Linux itself offered them this option? Of course! I'd even gladly help Linux get there. But Linux is unfortunately a project that prefers to sacrifice long-term convenience and freedom for short-term convenience, so we software freedom advocates end up having to maintain our own version of it. That's unfortunate, but it's understandable.
FSFLA: Linux kernel is "open core" Posted Nov 15, 2010 21:02 UTC (Mon) by kfiles (subscriber, #11628) [Link]
Holy moly! COuld you two please take your personal dispute to private mail?
I read the LWN comments through the RSS feed, and the noise from your bitter thread has shouted down the rest of the wonderful signal on LWN (well, to be fair, you and the Florian Muller thread).
The rest of us would just like to read our tech news, please.
using the comment filter Posted Nov 15, 2010 23:00 UTC (Mon) by biged (subscriber, #50106) [Link]
I hope it's not too impolite to recommend that subscribers use the Comment Filtering preference. Even if you read with RSS, so it doesn't help you directly, it's a form of voting which might be useful to the editors. (I had to abandon RSS: I now use the Unread Comments page instead. It buries most of these annoying arguments.)
FSFLA: Linux kernel is "open core" Posted Nov 16, 2010 14:31 UTC (Tue) by vonbrand (subscriber, #4458) [Link] How the heck is the kernel to know there is no free firmware for some random device?!
FSFLA: Linux kernel is "open core" Posted Nov 18, 2010 6:11 UTC (Thu) by lxoliva (subscriber, #40702) [Link]
That, it won't know. But the developers of the driver will know what firmware is recommended to work with it (it was written and tested to work with), and whether it's Free.
As soon as Free firmware is developed for a hardware component (and any driver adjustments are made for it, as in b43), the kernel will likely be the first component to know about it.
(I use quotes because anthropomorphizing programs is a bad idea: they don't like when we do that ;-)
FSFLA: Linux kernel is "open core" Posted Nov 15, 2010 20:11 UTC (Mon) by wookey (subscriber, #5501) [Link]
To be fair - if you've installed the linux-libre kernel variant then it's fairly clear that you don't want any non-free blobs so getting a 'deblobbed' log message in this case seems fair enough.
FSFLA: Linux kernel is "open core" Posted Nov 14, 2010 23:19 UTC (Sun) by dwmw2 (subscriber, #2063) [Link] "I believe computers should obey their users. This userspace program you suggest could do nothing but accept or reject software that users have installed on their computers. IMHO, that doesn't make sense. If users chose to install certain software on their computers, the computers had better obey when users command run it or install it. Anything else is, erhm, defective by design, if you get what I mean."And yet you're still peddling an implementation which is broken by design in precisely this way. If I run your linux-libre kernel but I do still need my wireless to work using the firmware which was present in my laptop when it arrived, your current implementation does "protect me from myself", because it won't load that firmware even when I deliberately extract it from the OSX driver and place it in /lib/firmware in my Linux system. That used to work, and you have broken it even for the user who has made an informed choice. "Even if the userland program could indeed clean up the log messages from a local machine, it can't go back in time and prevent the kernel from having issued the request, so it can't do what I want."I do understand what you want; I just think it's fundamentally misguided. What you now claim you want is pointless, and no longer directly related to the originally stated goals. Your argument that a call from kernel to udev is inducement is just nonsense. I don't know why you're fixating on it, but there seems to be no valid technical reason. You might just as well argue that the call from the driver into the core kernel is similarly inducing the user to use the specified firmware (if, of course, said firmware happens to be only available in a non-free form today). And thus even your version would be inducing the user to use non-Free software. You have chosen to draw the technical line in a completely arbitrary place, and you now seems to be making up arguments to support your implementation instead of trying to come up with an implementation which makes more technical sense. That's your prerogative, but don't pretend it's because we don't understand what you want. To me, this argument is not about the ethical issue; the fact here is that you have made a technically poor decision and you're trying to back it up with transparently empty rhetoric instead of discarding your precious implementation and doing something more sensible. "All of this because you seem *DETERMINED* to do it at a place other than the one that has all the relevant information."This is also completely incorrect. The kernel does not have all the relevant information. It is only userspace which can know the current licence status of the firmware which is available for download from the various package repositories, not the kernel. In the kernel we can only have an out-of-date idea of the last known status; we can't know if there has been a free reimplementation in the last few days. And as you say, the kernel developers aren't always completely on the ball when it comes to licence status. The distributions are far better at labelling things correctly. Only by leaving the kernel unbroken and handling the full request in userspace can we actually achieve what you said was your technical goal. Anything else is disingenuous. And if you do plan to rely on the out-of-date knowledge of the author of the kernel driver, then it is doubly disingenuous to do so in the case of devices which load their firmware through the OS, but not in the case of devices which load their firmware from built-in storage. There is no excuse for breaking one but not the other, if you're claiming that the most up-to-date licensing information is from the kernel authors. So unless your next version of the linux-libre patch also removes support for hard drives on the basis that there are no known devices with fully free firmware, I call you a fraud. ¹ I note with interest that you don't include the option of looking for, or even implementing, a free version of the firmware for the device in question. That's what we should be encouraging, but you seem to have entirely missed what I and many others think should be the point. You are being destructive, not constructive.
FSFLA: Linux kernel is "open core" Posted Nov 15, 2010 2:46 UTC (Mon) by lxoliva (subscriber, #40702) [Link]
> And yet you're still peddling an implementation which is broken by design in precisely this way.
Not quite. You said you had to build your own kernel for it to work, but you could have just built a driver. Which, I agree, is still undesirable, which is why we've been discussing other possibilities to make it even easier. Oddly, *none* of the freedom-caring users seems to have voiced any support for the proposal, which to me sounds like they don't need that anyway.
> I do understand what you want
Then why do you keep on insisting I want something else, and that I implement it in a way that will not just fail to solve the problem I want to solve, but that will also just not work at all on Free distros?
> You might just as well argue that the call from the driver into the core kernel is similarly inducing the user to use the specified firmware
If the driver was distributed separately, I'd make this very call. Since itś part fo the same component, and that one component will take care of buffering the inducement from the user, I think that's acceptable.
> Only by leaving the kernel unbroken and handling the full request in userspace can we actually achieve what you said was your technical goal
Sorry, can you please remind me what my technical goal was? From what you say, I get the impression that I forgot it, but in fact I think I remember it, and it was to avoid requesting non-Free Software. I still don't see how userland could go back in time and stop the kernel from issuing the request it already did and got userland to decide it shouldn't have happened. And clear the logs that were already transmitted to a separate machine that recorded them in append-only media.
I agree the kernel driver may have an out-of-date notion, which is why userland should get a chance to tell users about what's going on, just not in a way that sounds like give me blobname.bin or else. And then, as I wrote (but you seem to have chosen to ignore it), how could userland possibly know better than the kernel driver when the driver asks for a firmware that userland (including repositories) know nothing about? How could userland know better and give decent advice, when the distro chooses to leave out the non-Free blobs?
Your solution appears to be once again geared towards making more blobs more easily forced into distros and users, rather than helping solve the social problem at hand, that requires users to realize the blobs are a problem.
FSFLA: Linux kernel is "open core" Posted Nov 15, 2010 13:10 UTC (Mon) by foom (subscriber, #14868) [Link]
lxoliva clearly believes that the kernel asking udev for a firmware filename is equivalent to inducing the user to use non-free software, while dwmw2 (and I, for that matter) think that's crazy. It seems pretty useless to continue this discussion further, since it's just going around in circles now.
And I really hope that simply posting a filename is never ever counted as "inducement to infringe" in a *legal* sense: that'd be a huge pain in the ass...
FSFLA: Linux kernel is "open core" Posted Nov 15, 2010 20:11 UTC (Mon) by lxoliva (subscriber, #40702) [Link]
I have little hope of convincing dwmw2. I just want the records to show that we're trying to solve different problems, and that whatever solution he seems to think and impose on me won't solve the problem I'm trying to solve. A number of people got out of the previous round of discussions about Linux and Linux-libre with the mistaken impression that his proposed solution then would do anything to advance Linux-libre's goals, in spite of my attempts to show it didn't. I'd like to avoid a recurrence of this error.
Now, I don't want to turn this into a debate on legal issues, but I'd like to point out that Red Hat legal advises the Fedora project to refrain from as much as mentioning Free Software projects that apparently read on certain patents. That would be considered a material legal risk, with liability arising out of contributory infringement claims IIUC.
Now, baiting users towards non-Free Software, or even providing them with the poison, doesn't break any laws (except for those pieces of firmware for which no license can be found, that is ;-). It's an ethical and social issue. It's just good to see clearly where one's priorities are. I wish ethical hazards would get at least as much attention as legal ones.
FSFLA: Linux kernel is "open core" Posted Nov 18, 2010 14:10 UTC (Thu) by mpr22 (subscriber, #60784) [Link] I can think of at least one approach to this matter which is both technically correct and avoids the behaviour you regard as unethical "baiting". Don't break the drivers that depend on being able to receive non-Free firmware from the userland firmware daemon; remove them.
FSFLA: Linux kernel is "open core" Posted Nov 18, 2010 15:48 UTC (Thu) by lxoliva (subscriber, #40702) [Link]
This was the approach taken by gNewSense in its first release. Their cleaned-up kernel eventually became Linux-libre and the approach evolved in response to problems and changes in Linux.
One major problem was that some drivers would work just fine, or in a degraded way, without the blobs. Some were patched, but others were removed taking out useful functionality (video capture and graphics come to mind).
The changes in Linux were the widespread adoption of request_firmware(). We had already developed technology to selectively remove parts of drivers that contained blobs, and since moving firmware about didn't make any difference as to the ethics of providing or using them, we figured we'd be better off retaining the same functionality that we had when the blobs were part of the drivers. This implied disabling the blob requests.
However, instead of simply logging an error, like we did before, we figured we could use the hotplug interface to notify userland about the lack of Free firmware for that driver, so that's what we did. It's arguably better than silent (or quieter) failure to work, and it doesn't stop anyone who wants to use the blob from installing a driver that will take it.
That's where we are now, with a couple of plans to enable users to use blobs without having to install alternate drivers.
|
|||||||||||||