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.
Pros:
Cons:
Have the kernel devs decided whether they are good or not?
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.
Last time I checked, you're a troll.
Note: this really only applies to drivers, not applications.
Finkployd
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.
Reiser4 is currently in 2.5, which should drift over to 2.6 assuming it doesn't screw up big time mid-transition..
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."
1.)In house user mode code is not affected by kernel changes.
2.)The API is stable during a release, i.e. 2.2.x API is the same throughout, while 2.4.x has a different API from 2.2, but it is consistant throughout that series.
3.)This would only be necessary if they keep upgrading to the latest and greatest kernel, which shouldn't happen frequently. They can stay on one kernel series and not have the API change on them, and yes, security patches DO come out for the older kernels, 2.2 is still maintained, and I'm not sure but I think 2.0 is too.
C Pungent
Reiser4 is currently in 2.5, which should drift over to 2.6 assuming it doesn't screw up big time mid-transition.
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