Vanishing Features Of The 2.6 Kernel 443
chromatic writes "Jerry Cooperstein has written an excellent article summarizing the features removed from the upcoming 2.6 kernel. One controversial change may be tightening restrictions on binary-only modules." And Lovechild writes with some more 2.6 news: "I recently did an inteview with famous kernel hacker extraordinare and all round nice guy Robert M. Love for Tinyminds.org, about kernel 2.6 and what can be expected for desktop Linux users, when the new kernel series is released.
oh the irony (Score:4, Funny)
bite me
rainman
They aren't gone! (Score:5, Insightful)
Binary modules (Score:5, Informative)
Pros:
Cons:
Have the kernel devs decided whether they are good or not?
Re:Binary modules (Score:5, Informative)
As a PowerPC Linux user, I'd add that they're rarely made available for non-x86 architectures.
Re:Binary modules (Score:5, Interesting)
Binary-only modules must be updated by the vendor when the kernel interface changes.
If we must have binary-only modules, I like how Cisco did it for their VPN software: you compile a small wrapper function with a provided library file to generate the module. That way you can generate one specific to your kernel version.
Re:Binary modules (Score:5, Insightful)
Re:Binary modules (Score:5, Informative)
The mouse driver is one of the simplest drivers, and most of the stuff is done in usermode anyway. But a changing interface doesn't mean that each and every piece of the interface changes, it just means that the overall interface has changed in some way.
It doesn't take much to make a change in the binary interface, a small change of a
Re:Binary modules (Score:2)
Surely there are better ways of doing it than that. Drivers don't have to resolve every symbol possible do they?
Re:Binary modules (Score:3, Interesting)
Binary-only modules must be updated by the vendor when the kernel interface changes.
That is not just a major con, it is probably the most important of all cons.
you compile a small wrapper function with a provided library file to generate the module. That way you can generate one specific to your kernel version.
Hasn't something similar been done for gfx drivers as well?
Re:Binary modules (Score:3, Insightful)
It's true that providing a binary library and a wrapper is a better solution than a completely closed binary, but there are still some large problems with this approach.
Re:Binary modules (Score:4, Informative)
I think it makes a good deal of sense, from a linux developer standpoint - they all have their own reasons to work on linux, and answering bogus bug reports caused by faulty binary modules cuts time from other development tasks.
BBK
Re:Binary modules (Score:3)
If Linux ever becomes a mass-market operating system, the kernel developers are going to have to reprioritize things. Imagine telling a company with 10,000 Linux desktops that they would have to fix, recompile, retest, and redeploy a major in-house app because a deprecated kernel interface had been removed. Linux can make these kind of changes only because it's not yet mainstream.
Re:Binary modules (Score:5, Insightful)
1. doesn't have an automated system to push updates, or
2. decides you need to upgrade to a new kernel for no apparent reason (security updates are almost universally backported), or is unable to do the kernel patching to fix things themselves, or
3. you have software that's somehow hacked into the kernel on desktops but you don't have the source to,
you're fucked. Start writing your resignation letter, you totally blew it for anyone you're responsible to. Hope you weren't there too long so you can put it on your resume as a hiatus.
Linux doesn't have to worry about backwards ABI compatibility because most vendors use the API instead...
Re:Binary modules (Score:3, Insightful)
At the risk of this sounding like flamebait, it's about power and control.
There are people who think you should not be able to download a binary-only module and use it with a GPL program. Note that I say you, and not the creators of the programs themselves. The binary only creators are not using any GPL code. The GPL code is not using the binary. It's the combination of the two that many will tell you is a "sticky area".
It's exactly the same as if Microsoft changed the Windows license to say you could not run any GPL programs under the Windows operating system. Imagine the screaming that would take place if they tried that.
I think a lot of people need to get a grip and just mind their own business. If you don't want binary-only software on your computer, then don't do it. But don't presume to tell me what software I can or can't run on my computer.
Now, it's valid to worry about whether I'm redidistributing software according to the license. But if I follow each individual software's license, then leave me alone.
Re:Binary modules (Score:5, Informative)
Microsoft are busy working on just this and it's much worse than you would imagine. See the TCPA/Palladium FAQ [cam.ac.uk].
Translations: German [hipjoint.de], Spanish [bulmalug.net], Italian [complessita.it], Dutch [wanadoo.nl], Chinese [ttv.com.tw], Norwegian [www.efn.no], Swedish [refactor.fi], Finnish [effi.org], Hebrew [penguin.org.il] and French [lebars.org]
Re:Binary modules (Score:2, Insightful)
Microsoft are busy working on just this and it's much worse than you would imagine.
No, they aren't. Palladium will NEVER stop you from running unsigned code. Never. Ever.
There is a very simple reason for this: it would break backward compatibility. No backward compatibility, then no operating systems sold.
Yes, there are people who are LYING about Palladium. Yes, LYING.
And yes, Palladium can be used for digital rights management. But that is a completely separate issue from the idiots who assert that only Microsoft-signed software will be allowed to run, which is completely absurd.
Palladium is nothing like this binary module issue.
Re:Binary modules (Score:5, Insightful)
So what if Palladium lets your GPL program run, it wouldn't matter at all. This is because your GPL program will not be able, or rather allowed to, access the Palladium infrastructure in order to get the needed cryptographic credentials to perform certain tasks. So yes, your program will run, but no, it won't be able to do anything useful for you, not for anything that requires access to Palladium. And that would be mission completed for Microsoft: GPL software rendered useless.
The easily fooled will probably be glad to hear that the full source code to Palladium will likely be made available. Again, the source code is as powerless as your GPL program, and is of no use to you - even with the source, you can not make modifications to it and run the modified version in place of the version endorsed by Microsoft.
Furthermore, Microsoft already has a license in place that exludes open source development and specifically GPL and LGPL open source, see this article by Bruce Perens [com.com]
If you are aware of any lie in Ross Anderson's TCPA/Palladium FAQ, please state what it is.
Re:Binary modules (Score:4, Insightful)
"We are all aware of the criticisms that the TCPA has received. Ross Anderson did a good job of explaining the problems in an abstract fashion, but I felt that there were some things left out (Privacy concerns)." (my emphasis).
You write:
The rest of your comment, "Reality Master 101", builds on ignoring what Anderson is actually saying and is thus just a straw man [geocities.com] argument [texas.net], with which you have apparently fooled yourself.
Re:Binary modules (Score:2)
Also, by the same token, Microsoft is well within their rights to say, "We will only allow you to run Microsoft sanctioned software under Windows". If you don't like it, you can either (1) stop using Windows, or (2) hope that the government strikes them down through the monopoly rules.
If you don't like the terms, then don't use the software, or find a way to make it work yourself. Nothing says that I must allow your software to interoperate with mine.
-- Joe
Re:Binary modules (Score:2)
I didn't say they didn't have the legal right to do it. I'm just explaining that the root of this is people who can't mind their own business and want to control the computer choices of others. It's no different than if some programmer releases a utility with a requirement that only born again Christians can use it. Does he have the right to do it? Of course. But that doesn't make the decision less idiotic and wrong.
Re:Binary modules (Score:2)
Wow, I can't think of a better way to put it. It's interesting that the GPL tries to tell you what you can do with the software, while the people who enforce it are now telling you what you cannot do. I honestly can't see any licensing reasons why I can't take two pieces of software and run them together on my computer (as you indicate).
But then... the kernel has a table of system calls, and that table can be edited to effectively pipeline calls to the binary-only modules. So a binary-only module (with the older method) can effectively replace different kernel services (maybe?). Are there any licensing issues that occur with this?
Re:Binary modules (Score:4, Insightful)
No, it's not. There is no restriction whatsoever in running any kind of application you want under Linux. Did you ignore the distinction between kernel and user mode intentionally?
It's more like Microsoft changing the Windows license to disallow any GPL code in the Windows kernel. Oh wait...
Re:Binary modules (Score:2)
I don't believe it. Assume a driver has been written and released in binary form. How could the driver become any worse by releasing the source? It couldn't, but more people might realize how badly it was written. And nVidia's is assumed responsible for a lot of the kernel crashes. If anybody reports and error on a system that has been using nVidia drivers, the kernel developers will tell the person to reproduce it without the nVidia driver or go bother nVidia.
Re:Binary modules (Score:2, Interesting)
This is just another facet of the kernel developers' jihad against binary modules. Presumption of guilt does not imply bad code, it implies prejudice(*).
(*) Please don't flame me for calling Linus a racist. I use the word prejudice because it literally means "to judge before" which is exactly what they are doing to nVidia and users of nVidia's hardware.
Yay for binary modules (Score:2)
On the downside, the module (for the Lucent winmodems) was originally released for the 2.2.x kernel. It was never updated by Lucent, but some people on the net figured out how to change the headers so it works with the 2.4.x kernels.
If it becomes impossible to use this module with 2.6, and it looks like the changes to the module interface are large enough to make the module completely incompatible, I have a few choices:
Then again, Lucent may force people to use older drivers for newer versions of Windows, like XP. Then again, Windows 98 is still supported (name one Linux distribiution which came out in 1998 which is still officially supported), and it should be possible to use a Win98 driver with XP.
Re: Better drivers (Score:2)
I don't know where you getting your info from, but that's a myth. To follow that line of thinking, all closed source software is better then opensource software(usually).
As we all know that's just not true. Being open or closed source isn't the determing factor for how good or bad a driver is. Its simple a development model. Its the actual code which determines how good or bad the driver is. I assume based on you mentioning Nvidia twice that your basing your opinion soley on their drivers from an enduser point of view. Rest assured that if Nvidia opensourced its drivers they would be just as good as the closed versions if not better due to peer review.
Re: Better drivers (Score:3, Insightful)
Most technology companies are constantly licensing other people's tech in order to make theirs better. NVidia does this in their video cards. These bits of technology come with restrictions on them from the company licensed. Usually they are either patented or considered trade secrets and a company like NVidia would be restricted from allowing a trade secret that they license from being revealed. Drivers can give you intimate details on how the insides of your hardware work. Many pieces of hardware even include microcode that can be updated when the driver is loaded, either to fix bugs or to provide new capabilities/performance. It's quite possible that NVidia's hands are tied when it comes to making Linux drivers. The alternative to revealing 'intimate' details of the hardware might be disappointing performance or missing features.
Now perhaps NVidia COULD release their current binary drivers as open source ones, but simply choose not to. I think the above is a very real possibility, though.
Re: Better drivers (Score:3, Funny)
Now perhaps NVidia COULD release their current binary drivers as open source ones, but simply choose not to. I think the above is a very real possibility, though.
If it was they case, then they could easily place those contractually-restricted bits in a binary module and open source the rest. They don't do this, so I presume the above isn't the reason.
The following three letters may help you in your search for the real reason: PHB.
About binary modules... (Score:4, Interesting)
Re:About binary modules... (Score:2)
What will we see? (Score:5, Interesting)
Restricting binary modules (Score:2, Interesting)
Please , Please do away with binary only modules.. (Score:5, Insightful)
Re:Please , Please do away with binary only module (Score:2)
Re:Please , Please do away with binary only module (Score:5, Insightful)
Windows XP, for all its faults, exports a very specific and small set of operations that a device driver is allowed to use to be 'certified', and as long as you stay within that sandbox, they claim your driver will stay compatible with subsequent releases. If Linux could make the same guarantees within, say, an even-numbered minor version release (2.2, 2.4, etc) I think you'd see a lot more vendors willing to make drivers, closed and open.
Arrogance (Score:5, Insightful)
Re:Arrogance (Score:4, Insightful)
If you read over the LKML mailing list archives, it will become quite clear to you that the kernel developers don't give a cold shit in hell about user requests or complaints. They do what they want, and fuck everyone else.
At least, that was the sense I got from the conversation..
Comment removed (Score:4, Insightful)
Beggers can't be choosers (Score:2)
Everyone can make whatever they want.
They don't owe you anything.
Re:Beggers can't be choosers (Score:5, Interesting)
Untrue. Most people are incapable of hacking kernel code, or any kind of code.
The kernel developers can use their abilities and positions to essentially blackmail the user base. New hardware drivers aren't usually backported to older kernels, so in order to get modern support for most things you have to run the latest. Want to run on modern hardware? You have to upgrade to a new kernel, with a new license, new restrictions, etc.
They don't owe you anything.
This is hilarious. You know, I once posted a rant on LKML about some particular issue (details unimportant). I essentially said that if it wasn't addressed, I might consider moving to BeOS (which was looking very good to me at the time). I have the freedom to make that choice, right? They don't OWE me anything, right? So clearly I most not owe THEM anything.
But I got several responses accusing me of BLACKMAIL, saying that I was "threatening" to move to BeOS in order to force someone to do something.
I could understand if there was some disagreement on a technical point, but by that point the conversation had degenerated into a flamethrowing competition between Andre Hendrick and the rest of the list. I was the only guy backing up Hendrick.
Anyway, I know from experience that many kernel developers are elitist, arrogant people. I guess they think that because their code runs in Ring 0 they must be somehow superior to the rest of us.
Re:Beggers can't be choosers (Score:4, Interesting)
I never said so on the list or in private to anyone. That's just how I feel about it.
The "rant" was the result of me being extremely pissed. And I believe justifiably so. There was something in the kernel that Andre considered a "defect." He had a simple piece of code to fix it. The kernel people rejected this, because "in theory, someone can get around this, so there's no point plugging a hole which someone can reopen."
At this point, I made some remark about how it would boost user morale if the patch were in place, regardless of any real technical merit. I made some statement to the effect of, "You guys should care more about what the users want, even if you think you know better than them." I didn't mean it in a combative sense. I was just growing irritated with their arrogance, and wanted to say so. I had earlier made some comment about how BeOS offered some feature that I wanted, and of course this got used as ammo against me, claiming that I was trying to blackmail the kernel developers by threatening to leave Linux -- as if my sole usership was pivotal to their existence. I'm not idiotic enough to make such a claim.
I've tried the "ya know, this really needs changing, and here's a few reasons why..." approach. The response I've gotten was "No. You're an idiot. Your idea is stupid. We'll never do that. Go away."
Kinda makes one bitter, you know...
Re:Beggers can't be choosers (Score:3, Insightful)
In theory? This was like setting a policy that if you sell a gun to an ex-con, it must be sold with the safety catch set. Sure, criminals can "in theory" turn off the safety themselves, but hey, it's better than nothing, right? At least "by default" they can't go out and start shooting people, right?
...Wait. Did you just call Andre's taskfile patch "simple"? Maybe you're one of those people who consider ACPI parsing "simple" too? Have you even read the patch, or was this just hearsay?
For those of you who weren't following along back then [zork.net], Andre wanted to provide an ioctl-based way to run vendor-specific, often undocumented hard disk commands. This would be things like "make disk read-only" or "unlock extra 10 GB of space the firmware rounded down so they could sell those excess 40GB drives as 30GB" or such. Being vendor-specific and often undocumented commands, the applications that used them might be buggy and, if buggy enough, might be able to turn a hard disk into a paperweight.
The taskfile patch was intended to provide sanity checking in the kernel to guard against buggy applications. Of course, Andre being Andre, he didn't put it that way. By the time he was done yelling, it sounded as though EVIL HACKERS WILL DESTROY YOUR HARD DISKS IN THE BLINK OF AN EYE AND IT'LL BE ALL LINUX'S FAULT. Never mind that the EVIL HACKER already needs to crack root before he gets the necessary raw hard disk access. Never mind that the taskfile patch would not prevent the EVIL HACKER from bypassing the ioctl interface and bit-banging the ATA chip directly. Never mind that, as root, there are a lot of horrible things an EVIL HACKER could do to your system, much more insidious and EVIL than crashing a hard drive, like installing backdoors and making your system fail in subtle ways that you wouldn't notice for a month. Never mind that those same EVIL HACKERS have been able to destroy these same hard disks in any version of Linux or Windows since the beginning of time (well, the beginning of ATA hard disks with these command sets) and yet somehow, remarkably, we haven't yet heard of it being done.
And never mind the whole problem that if a buggy application can destroy your disk, so can a buggy taskfile patch. (Andre tends to exude an abnormally high level of confidence in the quality of his implementations.)
In short, at the risk of sounding like I know what I'm talking about, which I don't really, it was a stupid idea. At least as initially presented on the mailing list. Some time later, the startling revelation came out that the taskfile patch actually had some other uses besides the one listed above (protecting against EVIL HACKERS DESTROYING YOUR HARD DISKS AS YOU SLEEP). And then, marvel of marvels, Linus was suddenly a lot more sympathetic to the patch.
And that, at the risk of sounding like one of your alleged arrogant pricks on linux-kernel, is idiotic too. Hard to explain what's so utterly wrong with your statement - I guess it's just one of those things - if you have to ask, you'll never know. (Now how's that for elitist?...)
Re:Arrogance (Score:5, Insightful)
After all the hard work of the kernel folks, you seem to expect them to be perfectly happy with having to support binary modules that they can't debug, and that fall in a grey area of the GPL.
How about you go create your own open-source project. Then I'll go create some hardware, and keep all the information proprietary. To tease you a bit, I'll keep all information about my hardware proprietary, so you have two choices:
1) Reverse engineer my hardware and write your own software.
2) Indicate to me that your software is valuable, and depends on my hardware, until you convince me to release sources so they'll work better with your software.
That's the position nVidia's in. They've got one of the most widely-used video cards on the market. And the only way to use that video card effectively under Linux is to use their binary-only drivers. Get a clue. Linux doesn't belong to commercial entities any more than it belongs to Linus. What you do with your kernel tree is your own business.
Re:Arrogance (Score:3, Insightful)
The problem is nvidia (and I use nvidia simply as an example, this applies to many others) WON'T, since unlike Red Hat, having a Linux kernel branch is very tangential to their real business. There are a number of companies that offer Linux support simply as a goodwill gesture, or at most for an extra bit of PR, despite the fact that the limited Linux support they do offer isn't really a good return on investment (just like id games for Linux aren't a good ROI but id releases them anyway for their own reasons). Anything the kernel developers do to make it harder for these folks to support Linux will mean less Linux support from hardware makers, which will make the much-vaunted Linux desktop push stillborn. If that's what the kernel developers want to do, that's fine. As you said, it is their code... But then they can't go crying later when everyone drops their Linux support.
Re:Arrogance (Score:2)
They don't have to be happy about it, but given how things work in the Real World, they damn well ought to learn to deal with it.
Re:Arrogance (Score:2)
Re:Arrogance (Score:3, Insightful)
Corporations that write binary modules are only allowed to write them by Linus' good graces - normally, the GPL doesn't allow for non-source availible binaries to be linked into GPL code in the manner that kernel modules are added.
Corporations should be happy they are allowed the level of integration that linux gives them, as they get an exemption (no-GPL) from the rules. They are also free to switch to the BSD's any time they want, which lacks many of the GPL's problems.
BBK
Re:Arrogance (Score:2)
Re: (Score:2)
Multibillion dollar business (Score:2)
I don't think kernel developers are _that_ expensive
Re:Arrogance (Score:3, Insightful)
The GPL does not stop you from linking binary only code to GPLed code. Nor does it stop you from distributing your own binary-only code that can be linked to GPLed code. It only stops you from redistributing someone else's GPLed code which is linked to your binary-only code.
This is because the GPL puts no restrictions on the use of GPLed code, only on the redistribution of it. If you don't distribute the GPLed code, you can't violate the GPL. As long as a company that writes binary modules doesn't distribute the Linux kernel, there is no way that they can be in violation of the GPL.
The end user can link the binary module to the Linux kernel and use it. The end user can't redistribute this combo, however.
Re:Arrogance (Score:2)
It is a very grey area. The GPL does not forbid linking GPL code with closed source code for your own personal use. But you are not allowed to distribute such code.
Now since the modules as they are distributed is not yet linked they might be legal. The linking is done at load time, at which time it might be considered personal use.
Re:Arrogance (Score:5, Insightful)
Arrogance indeed. Users are so used to being customers that they don't know when they are receiving a gift.
It's weird how, after over ten years, many people still don't get Linux. Every single Linux developer does what he does does because he gets something out of it. Not because he want's you to get something out of it. That's the beauty of the GPL. It guarantees that everyone can do what they want with the code, as long as they give others the same courtesy.
If you want something, just do it. If you can't, find a way to motivate someone to do it for you. You have the same rights as everyone else, no more, no less.
Re:Arrogance (Score:2)
I see your point, but I respectfully disagree. Linux will ultimately be accepted or rejected by businesses based on the cost of running it versus the cost of running a competing OS. I do not believe that forcing commercial developers to evolve their products to match changes in Linux will increase the relative cost of running Linux, because commercial developers typically have to do this for other OS's anyway. Regularly paying for upgrades of your commercial software is standard practice.
By indefinitely supporting obsolete (and potentially bad) features, however, the kernel developers could actually drive up the relative cost of running Linux. Why? Because there's less motivation for commercial developers to modify their products to utilize the new-and-improved features and, ultimately, make the system as a whole more robust and less costly to operate.
Open source software already has the disadvantage of not necessarily being driven by short-term economic gain. I say disadvantage, because short- term economic gain is an easy thing to sell to people. Given this disadvantage, a little arrogance and strong-arming is not only justified, it's essential.
Re:Arrogance (Score:2)
It's the arrogant attitude that I have a problem with. Working on open source means working with a community. Sometimes that community includes commercial operations. Messing with them just because "you can" just doesn't seem like good diplomacy.
Re:Arrogance (Score:3, Insightful)
Is that what you think? That's hardly how things are, it's not like Linus sits in his dark tower, steeples his fingers and says "Today, I think I shall once again break binary compatability to screw over nVidia.. bwhahahahaha".
When they break kernel interfaces, it's to make a better kernel. If they didn't, those parts of the kernel would effectively be frozen in time, and the kernel woudln't move forward, it'd get more crufty and less reliable. We'd all suffer, just so binary driver producers don't have to recompile their drivers. Doesn't sound like a good tradeoff to me.
Re:Arrogance (Score:2)
The commercial operations are a part of the community as well, hence they must be contributing to the atmosphere of arrogance. Seriously, if they had a good standing in the community they would be less likely to be walked over. The Linux community tends to have little patience for would be members who want things but are reluctant to contribute. This, I think, is completely understandable.
Let's see. How could my company, as a hardware manufacturer, get on the good side of the Linux community? How about we GPL our device drivers? What a great idea! It would work too.
Re:Arrogance (Score:2, Insightful)
Accountant: but Mr CEO person, our research shows that only 200,000 people use Open Source software that would have a use for our super-deluxe hardware. at the same time, 4.5 million Windows users have a potential need for our super-deluxe hardware. in addition to that, the cost of creating and maintaining and Open Source driver would cost us an extra 15% on the development of super-deluxe hardware. If we dont have OpenSource compatible drivers, we can lower the cost of super-deluxe hardware by 15% and still make profit on it.
Mr CEO: Ok, that sounds even better.
Re:Arrogance (Score:2)
There are major differences between kernel modules and applications. I don't use any closed source kernel modules, and I certainly hope I never have to. But I happily use a few closed source userspace programs.
If you take a closer look on the kernel/module ABI and the kernel/user mode ABI, you will see that the first one is changing basically on every build of the kernel while the second is almost unchanged all the way from 2.0 to 2.6.
Closed source modules never was a good idea and always causes trouble, while userspace applications can be closed source and work on a wide range of kernels because the system call ABI is very stable.
Just great... (Score:5, Informative)
For anyone out there who is just waiting and drooling on themselves over 2.6, unless you NEED one of the few features present in a new kernel, you have no need to upgrade. The latest isn't always the greatest, and even "stable" releases need to go through testing before you put them in production.
Re:Just great... (Score:2)
Good riddance (Score:5, Interesting)
Particularly when there's no demonstrably good reason for running a kernel-mode webserver; lots of recent development has shown that a well-written user mode webserver can easily match the speed of a kernel mode webserver on modern hardware (i.e., context switches are relatively inexpensive).
As for further restrictions on binary-only modules... I forsee more arguments about which license is freer, the GPL or the BSD/MIT license.
Re:Good riddance (Score:2, Informative)
"lots of recent development has shown that a well-written user mode webserver can easily match the speed of a kernel mode webserver on modern hardware"
Could you provide proof here? The research I have done shows kernel-mode servers beating the pants of user-mode servers, especially for static content.
Who do they think they're kidding? (Score:4, Insightful)
Does anyone think for a minute that ATI and nVidia are going to release all their trade secrets under the GPL just so they can make Linux users happy? No way. More likely, they'll just port their stuff to FreeBSD and abandon Linux, driving all the serious graphics people (movie production companies, engineering firms, etc.) away from Linux. Great work guys. Guess that's what happens when you let RMS run the show...
Re:Who do they think they're kidding? (Score:3, Insightful)
These make the issue worth considering.
Re: (Score:3, Insightful)
Re:Who do they think they're kidding? (Score:5, Insightful)
You haven't done any driver development in the past 3 years have you? In many cases companies CAN'T release full open source drivers even if they wanted to because they are licensing technology from third parties for their hardware and/or driver software. The problem is a lot more complicated than 'boom, Open Source the drivers'.
Re:Who do they think they're kidding? (Score:2)
Actually, they'll probably just ditch Open Source altogether, since it is a liability for them. Why should they support FreeBSD, if the FreeBSD developers could pull the same stunt at any moment?
No, the most likely scenario is that nVidia (and other companies like them) will start to see Open Source as an arrogant, elitist movement, and simply stop being nice to us. Which I would completely understand.
Yay! Fewer features! (Score:5, Interesting)
Thankfully, open source makes this a feasible thing to do: if your legacy apps won't run without the old features in the kernel, then change your legacy apps (or, hell, if you're brave, change the kernel).
It's open source, damnit! (Score:5, Insightful)
Or, better still, why not delivering the whole product with an installer doing all this for them? It's not going to break GPL, as long as they publish the source code for the patch itself, which should be trivial.
I'm all for GPL, but this is not going to make that big an impact.
Are they nuts? (Score:5, Interesting)
See also: quickest way to discourage commercial development on your platform.
Gee, do you think all these corporations who have been embracing Linux in these past few years will still be using it when they can no longer use their expensive software investments with it? I doubt there are reasonable open source alternatives for most of these applications, like video card drivers or movie production applications, for example. Good luck on getting more people to adopt your platform after that.
I forsee a massive move to FreeBSD if this bullshit continues.
Best solution (Score:3, Interesting)
For some technical correctness is a primary goal, in Linux this means that sometimes features and interfaces change.
This may tend to piss of some, but you end up with a technically superior product.
For others consistency of interfaces may be most important and technical correctness is secondary.
This tends to generate lots of legacy crap, we see this in MS Windows. Now they're cleaning up, and we have the compatibility problems.
There is always a tradeoff. But I think a well documented technically good solution is best.
Re: (Score:3, Informative)
Re:Are they nuts? (Score:2)
I wonder if the parent is a professional Linux-hater spreading FUD or just plain ignorant.
Reiser4? (Score:4, Interesting)
Re:Reiser4? (Score:3, Informative)
What have you been smoking? Reiser4 has *not* been integrated into 2.5. Judging from discussion on their mailing list and the available documents on their site it is currently in a very early alpha state (i.e. data loss is to be expected). Since adding a new filesystem is not a very intrusive change it might still get added now after the features freeze maybe even in the (early) 2.6 series but not before it becomes quite a bit more mature.
Adding alpha-quality filesystem to a mainline kernel does not really help anyone.
-- kryps
Weird interview (Score:2)
A simple example might be where Robert Love mentions the need for a standard disk layer. What does that mean, to somebody who doesn't understand the way that the kernel in many areas creates a standard set of instructions (e.g. for disks, like "write", "access x data") and that he thinks this should be extended to disks, to take some of the bloated code that repeats all this stuff out of the SCSI codebase?
I think hackers in general really need to work on getting their ideas across to the more average person, otherwise most people have no reason to get excited by new releases unless they enjoy growing numbers!
Re:Weird interview (Score:2)
If everyone were to do that, nothing would ever get done because we'd all be writing tutorials (no offense). In any field--hell, in life--you learn to denote complex semantics with symbols so you can then refer to even more complex semantics. Those symbols might be words like "disk layer" or "dog" or "average person" or whatever. To have to constantly explain the never ending chain of meaning of the composite parts to the would be fruitless.
Re:Weird interview (Score:2)
Perhaps alongside the normal changelogs with major revisions, a layman-friendly changelog could be written, just describing the changes in easier terms (not laymans, you can always simply link to a useful tutorial (ahem, *grin*) which will explain the complete basics).
Just imagine you're a manager, and your IT staff have converted your servers over to GNU/Linux. You read somewhere that kernel 2.6 is out, and you wonder "what does that mean?", and yet you can't find out, and perhaps even your IT staff can't find out (as kernel internals arent' exactly a prerequisite for every sysadmin) - will that impress you? I doubt it.
Derivative works. (Score:4, Insightful)
As other posters have already specified, you can distribute your own kernel or patch that doesn't enforce the GPL license, but in doing so you may indeed be violating the GPL yourself. Remember, the GPL is like any other license, you must abide by it or lose the privelidge of using the software.
Also, this does not break userspace (i.e. proprietary and binary-only applications), unless such software is dependent on a binary-only module.
I, for one, am curious to see how those people who really want to distribute binary modules will react. I think many have a market in Linux systems and will continue to provide their code. However, they may be well-served to develop a GPL module that provides very consistent interfaces for binary-only modules. The kernel developers don't want to do this, but if developers of binary-only modules develop it and apply it, well that's their business.
Re:Derivative works. (Score:2)
Actually, no. GPL doesn't deal with use at all, only with distribution.
Drivers please (Score:5, Insightful)
I love linux but I want so bad to be able to buy the latest neates thing and have it just work right away in linux and not a year later. Right now I have a radeon 9000 pro and a wintv pvr 250 I'm struggling with.
Drivers are the ONLY issue I have with linux and because of that I'm trying to learn C but I have so far to go and in the meantime I have to just be patient and wait for the vendor to produce a driver or for some linux developer go buy the same card I have and make it work. That's all fine and dandy except for this one thing: Some of these kernel developers are PAID to develop the linux kernel. That's right, it's their JOB. Not to show any disrespect to those kind hearted souls who sacrifice their spare time to do a community service, but as an enduser who has paid far far more for linux distro's than I ever would have paid if I was using Windows I have a right to insist on support for ME the end user. I have purchased Redhat 7.1, Mandrake 8.2,9.0 and every Suse since 6.2. It's my opinion that the kernel developer employed by the distro's have an obligation to develop the linux kernel with me in mind. And I want drivers. I don't care if they're GPL or not. I want hardware vendors to write the driver for the hardware they sell and distribute that driver WITH the hardware. And I want that driver to just work. That means the linux kernel must allow it to work. Politics and personal philosophy regarding open source have nothing to do with the discussion. I'm a paying customer and I should be treated that way.
Re:Drivers please (Score:4, Interesting)
Back in the day there was this company called WordPerfect. Their schtick was that there were thousands of printers, but no universal way to get shit printed. So they wrote printer drivers, for all of them, and they were fantastic. WordPerfect quickly took over the market because they wrote printer drivers. They knew how the printers would be used and figured the best way to access them, and were motivated to maintain the whole base of drivers.
Open source drivers are much the same way. Owners of hardware have a pretty serious motivation to make the drivers work. You also get higher quality drivers because of the many-eyeball effect. The best situation for customers and companies alike is for the companies to release a "beta" driver, detailed specs, and hire one guy to coordinate work on the driver. Then let the thing evolve. It's the beauty of the source.
"Source code is like manure, if you spread it around things grow. If you hoarde it, it just smells bad."
-- Bob
Re:Drivers please (Score:3, Interesting)
Wow (Score:3, Interesting)
Can you imagine the magnitude of the sh*tstorm they would create if Microsoft tried to pull something like this?? That's a pretty ballsy move for people who rely on the good will of the companies developing software for their platform.
Binary modules can still be used. (Score:4, Informative)
What is true is that they are doing things like not exporting the system call table so that any module can change it at their will. That is, a binary module can't replace the write call or fork call. There are other mechanisms like syscall registering for modules that need some new system call. (I haven't looked into that aspect yet).
What they are doing is not encouraging binary only modules. (and by binary I mean non GPL). The example they use is the modification of work queues. Things like tainting the kernel (so the kernel knows when it's been tampered with by proprietary code (read loaded a non GPL module)) have been around for a while now. Kernel people will not give support to problems with tainted kernels.
I use and nvidia driver in one of my computers, and that taints my kernel. I understand the implications. I also see no reason why nvidia has to modify my syscall table.
In short, I don't think normal "drivers" need to modify the syscall table. You can add a new filesystem, network protocol, etc without the need to modify the syscall table. So stop complaining about no more binary only drivers.
I agree with the developers in the choice. I also wish nVidia, along with the other companies, GPLed their drivers. After all, they are _drivers_ for the hardware I bought. And if they don't want to, they could at least release the complete specifications for the hardware so we can build our own 3D accelerated drivers.
cl
Open discussion. (Score:3, Insightful)
As for arrogance, they're enforcing the license on their product. Microsoft would do the same for their products if your code massages their code without abiding by their license.
BTW, this sounds like an idea for Ask Slashdot. Get someone developing the Linux/BSD drivers from nVidia to answer questions about this and find out if it really is a problem, or if
Binary-only restrictions (Score:3, Insightful)
Nobody is preventing NVidia from writing binary-only drivers, they just need to hook into the kernel at lower levels. Some kernel developers want the NVidia people to mooch less.
They're tightening restrictions, not banning binary-only modules. Relax. They're just saying if NVidia wants to use binary-only modules, that's thier perogative, but it's a huge pain for the developers that become de facto support for those NVidia drivers. Basically "You want to be a pain in my ass, go ahead, but you're now getting less help from me to do it."
The *BSD kernels are simpler and may not have equivalents to the special higher-level functions that are being hidden from non-Free modules. I don't know. In any case, it's unlikely NVidia is going to jump ship for one of the *BSDs. I'm not even surewhat companies hope to achieve by providing binary-only drivers. Thier competitors certainly have decompilers. If they really need to protect patented algorithms, that can be done in firmware/hardware and/or usermode drivers. Usermode drivers also prevent binary-only kernel instabilities and reduce kernel dependancies.
Not good from a strict GPL standpoint (Score:3, Informative)
Re:Not good from a strict GPL standpoint (Score:3, Insightful)
Exactly. This is especially true with video cards.
What the hell are they thinking??? (Score:3, Insightful)
And besides, imagine the hypocrisy of the Linux kernel devs taking away choices from the people that use their kernel. I mean, I thought Linux was supposed to be for people who actually wanted control over what goes into their kernel.
Question for Scheduling Knowledgeables (Score:3, Interesting)
Is this a hack? It sounds like a workaround, but maybe it's just creative use of existing tools.
Can anyone tell me if this is how other systems do preemptive multitasking? I really don't know. Is this similar or analogous to Intel's new chip that acts like a multiprocessor?
Stable API (Score:3, Interesting)
Look at Solaris. It's quite possible to take even certain kernel modules that were built for Solaris 2.6 and use them on Solaris 8 without recompiling. I am not even mentioning that kernel modules don't break at all between minor kernel releases (or patch levels) on Solaris.
Re:I'm not sure I like the changes re: binary only (Score:3, Interesting)
You sound like the prosecution in the Johanssen trial.
Re:I'm not sure I like the changes re: binary only (Score:2)
Where I live it is not theft. In fact we even have a law explicityl giving us the right to reverse engineer as long as the purpose is to achieve compatibility which will always be the case with drivers.
the Johanssen trial.
IIRC Johanssen lives in Norway which have a law similar to the one we have in Denmark.
Re:I'm not sure I like the changes re: binary only (Score:3, Interesting)
Besides, it's quite possible to write userland drivers, though this happens at the expense of performance so it probably won't work with something like video cards.
Re:I'm not sure I like the changes re: binary only (Score:3)
Interesting attitude - what about Wine? They've had to reverse engineer some stuff, but I find it hard to think of it as theft considering all Microsoft stand to lose is their illegal grip on the markets.
Reverse engineering for interop is OK by me, reverse engineering to steal ideas is not. Do you make the distinction?
Reverse engineering isn't always a bad thing (Score:3, Interesting)
I use Samba nearly every day. I've used WINE extensively. I've paid for transgaming's version of it even. I've used AbiWord and Kvivio as well. I remember using third-party, open Adaptec drivers long before that company "got" open source. I've used a home-built version of Road Runner's login client, which was the only way I could log in for a long time. I've watched DVDs using software based on ideas found through reverse engineeering. I've used software that accessed a webcam, a didgital camera, a SmartMedia reader and a whole bunch of other stuff; all of it involved reverse engineering in one way or another. Hell, I've even played games [chaos2.org] that were (in some small way) reverse engineered.
Taking apart someone's software and then releasing similar code as your own stinks, especially if done for profit. But to blackbox something for interoperability issues, especially when the vendor is uncooperative, is totally acceptable. Or should be. It's certainly not in any way theft (unless -- maybe -- you count things like me not having to shell out for a Windows license to run my fileserver on because Samba lets me run Linux). I don't know about you, but it's in my nature to take things apart and see how they work and I don't think there's anything wrong with that.
-B
Re:the mighty slashdot effect killed TinyMinds (Score:5, Funny)
See how nice this looks?
Even if you make good points, nobody is going to read a long post with no whitespace.
Re:Perhaps now (Score:2, Insightful)