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.
You left off one major con:
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.
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.
You left off one major con:
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?
Do you care about the security of your wireless mouse?
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.
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.
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.
0 1 - just my two bits
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 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...
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
1^2=1; (-1)^2=1; 1^2=(-1)^2; 1=-1; 1=0.
- Smart guy, he is. Nice guy apparently too.
- After 2.6, aside from tuning, I think desktop-wise for one and two-way machines the kernel is done as far as features go. Now we need the applications, as Robert said.
- We need better applications. Open Office is pretty rad but its needs to look better and have missing features like grammar. Hell it needs to be Word!
- Odd how he finds time to be one of the biggest kernel hackers and still maintain a core utility package like procps.
- I would be curious to hear more about his day job with MontaVista. I always wondered what kernel hackers get paid to do. How free is he? Gets paid to hack for fun a bit but still has assignments? Or an extreme? All assignments or all what he picks? I wonder if Red Hat would pick him up if he so choose..
All-in-all, a good interview. I think I better liked his two runs with Kerneltrap. They really went into detail and seemed to connect with him.John
>> 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."
This sure is not the way to ensure broad hardware support and acceptance. Believe it or not, hardware companies do not feel the same need to support linux as they do windows, and making the platform hostle isn't going to win anyone over. Sure, a few ideological purists will feel better, but those of us who just want to use the darn thing will be the ones who loose out.
"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?
I never fully understood the bias against binary drivers until I read this article, if its the same one I read earlier. In it they mentioned that binary kernel modules have access to override system calls as well as make use of GPL system calls, etc. The recent changes will prevent this from happening in the future by limitting the access non-GPL drivers have, limitting which system calls they care override, etc. Security, especially against close-source commercial software that may not have my best interests at heart, makes me happy. I love linux. :)
"Tainted" kernels, eh? Creating new type of firewall to address the security problems introduced by kernel modules (proprietary or no) MIGHT be a worthwhile project. But trying to stop people from doing endruns around the GNU "ideal" seems about as futile or draconian as "palladium". If you have to go to bizarre lengths to keep software free, then perhaps your concept of what is freedom is the real problem.
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.
The kernal part of the nvidia drivers are provided in source code form and wont be affected. The proprietary part is the X11 drivers.
Sorry if this is redunent as far as I read nobody brought this up.
Mess Stuff Up