Slashdot Mirror
Vanishing Features Of The 2.6 Kernel
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.
hopefully there wont be anything in the kernel related to the advertising. M$ .net sdeems to be paying for this article....
bite me
rainman
Nothing's vanished... just not included... now you too can learn to kernel hack!
www.superdorf.com
Pros:
Cons:
Have the kernel devs decided whether they are good or not?
-- Will program for bandwidth
I am an op in a Linux support channel on IRC, and I always dread new rleases of both kernels and redhat. It never fails.. some noobie comes in *demanding* we help him fix the production mail server he just trashed by installing RH8 or the newest kernel (dev or otherwise).
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.
Everyone is entitled to their own opinion. It's just that yours is stupid.
If non-GPL companies feel they can require users to install binary-only modules, why not simply requiring them to apply a kernel patch to remove this new limitation first?
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.
Score:-1, Wrong
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.
--sdem
Anyone know if Reiserfs4 got into the 2.6 release? I think I read Reiser had been pushing Linus to include Reiser4, and from what I've read in LinuxJournal, Reiser4 supposed to be 2-3 times faster than Reiser3.
Je ne parle pas francais.
The best solution depends on your point of view.
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.
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.
I always get the shakes before a drop.
Jesus, give me some whitespace! At least a
here and there.
See how nice this looks?
Even if you make good points, nobody is going to read a long post with no whitespace.
Why, o why must the sky fall when I've learned to fly?
When a new product comes out on the market, the box almost always includes a cd with a windows driver on it. That driver is written and supported by the manufacturer of the product.
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.
Samsung took back my unlocked bootloader because Google wants me to rent movies. They're both evil.
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.
Most observers foresee a tightening of the limits on binary modules. This may very well break some rather expensive commercial Linux products, but that doesn't seem to bother most kernel developers.
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.
I've seen quite a few posts that seem to imply that binary modules cannot be used with the new kernel. That is not true.
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
Reply . . . let's get it over with.
Its also important to realize that the methods being used to enforce the GPL in the kernel have been developed completely in the open. If binary-only module developers are having problems with this, have they spoken out, have they said anything, does this really affect them much? I've not seen much of a discussion of this on Kernel Traffic, except that the Linux kernel developers don't feel its their business to make concessions for binary-only modules.
/. readers are just gettting huffy for no real reason.
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
I always get the shakes before a drop.
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...
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.
Copyright Violation:"theft, piracy"::Anti-Trust Violation:"thermonuclear price terrorism"<-Overly dramatic language.
A lot of people are complaining that the new binary module licensing changes are too restrictive, and reduce people's freedom when writing drivers (and I won't argue with that). Something else to think about, though, is whether the new changes are really the best thing to do from a purely GPL standpoint, where the end goal is to have as much software as possibly be free. As the GNU project points out in their discussions on licenses, it is sometimes a better idea to allow binary software. There are other operating systems than Linux (I hear there's a company in Redmond that makes one that's quite popular). If Linux discourages or forbids binary only drivers, the driver manufacturers won't make drivers for Linux (since, in many cases, they are bound by licenses that won't allow them to release open source drivers). If Linux doesn't have hardware support, then fewer people will be willing to use it, and thus fewer software companies will release Linux versions of their software. So far, Linux hardware support has been very good, but slow. New devices are often poorly supported. However, commercial drivers (binary and open source) have been starting to gain momentum, new hardware is more likely to have support, often from the manufacturers of the hardware themselves. I hope that the new 2.6 kernel won't stall that advancement, and seriously slow widespread adoption of Linux as a viable OS.
"If English was good enough for Jesus, it's good enough for everyone else."
No binary modules? What self-rightous idiot thought of that? That would alienate all major support for video cards. For all you purists, get it through your thick skulls: Patents exist on OpenGL and many other technologies (Such as S3TC) that are required for many applications (Such as Unreal Tournament 2003). Check other threads with nVidia-related information and you'll find more detailed information on nVidia / SGI / Microsoft / etc. patents on widely used industry standard OpenGL technologies.
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.
"Fundamentally this is a simple change but it requires a large-scale reimplementation of code to protect concurrency. Thankfully, the kernel's SMP spin locks already provide the large majority of this protection. So these spin locks are used as markers of where to temporarily disable preemption, to avoid mangling shared data. It works and everyone is happy."
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?
Why can't Liunx kernel developers come up with an API for binary kernel modules and keep it stable at least between minor kernel releases so that users could use third party kernel modules withfout having to recompile them for each kernel upgrade?
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.
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, 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?...)
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README