| |||||||||||||
Yup - this will finally clear any doubt...Yup - this will finally clear any doubt...Posted Nov 8, 2010 23:38 UTC (Mon) by khim (subscriber, #9252)In reply to: FSFLA: Linux kernel is "open core" by jebba Parent article: FSFLA: Linux kernel is "open core"
As I understand it, this whole firmware/ directory is likely moving out around 2.6.38, so all the non-free binary blobs that are currently in the kernel will be gone. What? Will they remove it? Well, gone to a file outside of linux-2.6.xx.tar. RSN, the Linus tree will be free of non-free software. :) Ah. So this will finally clear any and all doubts. As was pointed out by authors of the article Free Bait, or Open Core as first coined by Andrew Lampitt, is a licensing strategy that combines Free and non-Free Software: the distributor offers, under non-Free terms, premium features that are not available in the Free, typically copyleft, core. And after this big cleanup we'll have two packages: Linus's tree (which contains only free software) and tarball with "premium features" (and the first tarball will conveniently include hooks for the second one which are useless without it). Classic, textbook execution of open core strategy! If anything the article is a little early: today Linux kernel mixes free software and proprietary software so it's not obvious that it's open core, after this cleanup it'll be quite easy to see.
(Log in to post comments)
Yup - this will finally clear any doubt... Posted Nov 9, 2010 0:11 UTC (Tue) by bojan (subscriber, #14302) [Link]
> Classic, textbook execution of open core strategy!
Feel free to not download or strip the non-free bits. Which, of course, will turn a whole lot of your hardware into bricks.
Does anyone seriously believe that Linus and other kernel developers wouldn't prefer NOT to ship binary blobs, if they could? Most of them spent their life releasing their source to general public. What possible motivation would they have for "bait-and-switch" here? Money? Fame? Power? Please.
I think members of FSFLA should do themselves and all of us a favour by rewriting all those binary blobs as free software. Yeah, I know - not as easy as writing a trashy press release, bashing folks that work hard on REAL problems every day.
Well, this is better... Posted Nov 9, 2010 0:34 UTC (Tue) by khim (subscriber, #9252) [Link] Does anyone seriously believe that Linus and other kernel developers wouldn't prefer NOT to ship binary blobs, if they could? Most of them spent their life releasing their source to general public. What possible motivation would they have for "bait-and-switch" here? Money? Fame? Power? Please. Well, the offenders here are usually hardware vendors and I'm not sure what drives them, but I suspect all three factors play a role. But the linux developers condone this situation so even if they are not actual felons they certainly can be counted as participators. I think members of FSFLA should do themselves and all of us a favour by rewriting all those binary blobs as free software. Yeah, I know - not as easy as writing a trashy press release, bashing folks that work hard on REAL problems every day. That it's not as easy is not a problem - harder things were done. That it's not as effective is a problem: if there are thousands of people who are contributing to the problem and only few who are fixing it then it'll never be fixed. Non free components are increasing faster than they're being replaced as was corectly pointed out...
Well, this is better... Posted Nov 9, 2010 1:00 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
many of the core linux developers are very clear that they are not worried aobut firmware blobs.
I would be very surprised if Linus made a change that caused the tarballs that he ships to be unusuable without some other tarball. He is willing to have the firmware reorganized so that a distro can easily remove it if they want to do so.
Well, this is better... Posted Nov 9, 2010 1:17 UTC (Tue) by bojan (subscriber, #14302) [Link]
> Well, the offenders here are usually hardware vendors and I'm not sure what drives them, but I suspect all three factors play a role. But the linux developers condone this situation so even if they are not actual felons they certainly can be counted as participators.
Felons? Offenders? Please. What crime has been committed?
Really nice that FSFLA is dragging Linus' name through the mud for a problem he and other developers cannot fix all by themselves (not even close). All the while Linus and Co are contributing ALL of their work to free software. Talking about hypocrisy...
> That it's not as easy is not a problem - harder things were done.
Yeah, and that's why I run Hurd.
If FSFLA want do something for REAL, they should then talk to the hardware manufacturers to free those firmwares. Or reverse engineer it. Or whatever else that WORKS.
Whinging about Linus being the bad guy just makes them look like spoilt kids that didn't like the latest toy they received.
Yup - this will finally clear any doubt... Posted Nov 9, 2010 0:48 UTC (Tue) by gus3 (guest, #61103) [Link]
As soon as they get corporate permission, or the legal right, to reverse-engineer the devices, the firmware can be disassembled and then modified. And then we can also reverse-engineer nVidia's 3D acceleration.
Wait a minute. Didn't Linus rail against nVidia's using GPL'd API's a few years ago? Rather than outright banning the "nvidia" module, the kernel team added the "tainted" kernel flag, so that kernel crashes could be flagged as "unsupported stuff here".
How is the Intel microcode any different?
Yup - this will finally clear any doubt... Posted Nov 9, 2010 1:28 UTC (Tue) by bojan (subscriber, #14302) [Link]
> How is the Intel microcode any different?
Kernel doesn't link to it?
Yup - this will finally clear any doubt... Posted Nov 9, 2010 3:21 UTC (Tue) by gus3 (guest, #61103) [Link]
In the sense of the kernel object code in core, yes, that's true.
In the sense of affecting the behavior of the CPU, the only difference I see is that object code is external, where microcode is internal to the CPU. You can verify that the object code under the GPL doesn't run counter to your intentions, and you can also improve it or tailor it to your purposes. Why can't you do the same with microcode? It is also executable, just on a different level.
I'm not necessarily arguing for opening up Intel's microcode format (although dang, that would be sweet for my curious mind). I'm simply saying Linus is a bit two-faced for arguing against nVidia's proprietary module, but including Intel's microcode.
Yup - this will finally clear any doubt... Posted Nov 9, 2010 3:48 UTC (Tue) by bojan (subscriber, #14302) [Link]
> I'm simply saying Linus is a bit two-faced for arguing against nVidia's proprietary module, but including Intel's microcode.
That is one interpretation.
Mine is that because Linus writes Linux (and not Intel microcode) and nVidia drivers are linked into the kernel, the traces of such crashed kernel become next to useless, because nobody can see the source of such linked-in modules (and they could be causing the crash). Ergo, nVidia and others were put on the "tainted" list, so that users don't expect help if they come to Linus with a "tainted" trace.
Sure, if Intel provides dodgy microcode, your machine will be just as screwed. But at least this is not something Linus is supposed to support in any way, shape or form, because it really is outside the kernel.
Yup - this will finally clear any doubt... Posted Nov 9, 2010 6:43 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
you may not be aware that when the kernel loads, it includes microcode that it loads into the CPU. the is just the same as loading firmware into an external device.
however, in the nvidia driver situation, the code is being loaded into kernel space and can mess with other, seemingly unrelated things (if by no other way thatn by not following all the locking needed to make access to something safe)
Yup - this will finally clear any doubt... Posted Nov 9, 2010 13:47 UTC (Tue) by lxoliva (subscriber, #40702) [Link]
The microcode is actually not part of the kernel. The kernel supports loading it, but the actual microcode is separate.
As for tainting, I really don't understand why a driver that has access to DMA, system memory, buses and all on the primary CPU taints the kernel, but a blob that runs on a separate CPU and has access to DMA, system memory, buses and all doesn't taint it.
Yup - this will finally clear any doubt... Posted Nov 9, 2010 14:11 UTC (Tue) by hmh (subscriber, #3838) [Link]
You'd need to taint anything that is SMM-capable.
You'd also need to taint anything that lacks an IOMMU configured in such a way that NO device can access non-exclusive memory, and where a device cannot attack other devices in the same bus.
I.e. it would be useless.
Yup - this will finally clear any doubt... Posted Nov 10, 2010 7:28 UTC (Wed) by Los__D (guest, #15263) [Link]
Then I guess you'd taint any device that we don't have complete HDLs for?
Yup - this will finally clear any doubt... Posted Nov 10, 2010 7:34 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
don't forget the requirement for the installation tools for the software, so that would mean that they would not only have to provide you with the HDL for the chips, they would also have to provide you with the ability to produce a modified chip and put it on the board.
Yup - this will finally clear any doubt... Posted Nov 9, 2010 3:06 UTC (Tue) by jebba (✭ supporter ✭, #4439) [Link]
> Feel free to not download or strip the non-free bits.
Which is exactly what the announcement is--a version you can download with non-free bits removed.
> Which, of course, will turn a whole lot of your hardware into bricks.
That is incorrect, actually. Most devices don't draw from non-free software in the kernel. The linux-libre kernel will run 100% fine on many systems. Wifi is the big exception--often (but not always) that requires uploading non-free firmware.
Yup - this will finally clear any doubt... Posted Nov 9, 2010 3:11 UTC (Tue) by bojan (subscriber, #14302) [Link]
> Wifi is the big exception--often (but not always) that requires uploading non-free firmware.
Who needs it anyway, eh? It's not like there are networks and apps out there you can connect to... :-)
Yup - this will finally clear any doubt... Posted Nov 9, 2010 5:09 UTC (Tue) by jebba (✭ supporter ✭, #4439) [Link]
> Who needs it anyway, eh? It's not like there are networks and apps out there you can connect to... :-)
...
> But at least this is not something Linus is supposed to support in any way, shape or form, because it really is outside the kernel.
Except that these things are *in* the kernel (tarball) at the moment, in some cases. It seems most Intel wifi firmware is outside (in fedora, for example, it's a separate RPM), but some wifi blobs are in the kernel tarball proper. Do you think the Intel firmware should be moved *in*? If not, why not have the other non-free blobs moved *out*? At least, for starters....
Yup - this will finally clear any doubt... Posted Nov 9, 2010 7:00 UTC (Tue) by bojan (subscriber, #14302) [Link]
Outside the kernel in the sense that it doesn't really run as part of it. Same as other firmware. Kernel just treats it as data that needs to be pushed somewhere.
I'm guessing the distribution together with the rest of the kernel source is just a convenience thing.
Yup - this will finally clear any doubt... Posted Nov 9, 2010 15:11 UTC (Tue) by dmk (subscriber, #50141) [Link]
I think you are right. So, I now think open core is good. Thx for enlighten me.
Yup - this will finally clear any doubt... Posted Nov 9, 2010 21:07 UTC (Tue) by dwmw2 (subscriber, #2063) [Link] Yes, we agreed at the Kernel Summit last week that we're going to remove the legacy firmware/ directory from the kernel. It's just confusing now, since most distributions have already stopped shipping its contents and are instead shipping the separate linux-firmware.git repository which contains a lot more firmware for different devices.I was tempted to send a patch the same day we agreed it, but then decided to wait for 2.8.38 I want to make the transition slightly easier for those who were using CONFIG_FIRMWARE_IN_KERNEL, by doing something that'll look for MODULE_FIRMWARE tags in the drivers which are built into the kernel, and try to pull those firmware images in automatically.
Yup - this will finally clear any doubt... Posted Nov 10, 2010 1:42 UTC (Wed) by dmarti (subscriber, #11625) [Link] Is anyone doing any security audits on that firmware, or are all hardware vendors trusted with DMA access to everywhere? Just wondering.
Yup - this will finally clear any doubt... Posted Nov 10, 2010 1:47 UTC (Wed) by dwmw2 (subscriber, #2063) [Link]
This is what we have an IOMMU for.
|
|||||||||||||