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
Okay. This makes sense now. Not to be confused with the Solaris 2.6 kernel. ;)
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.
just in case the server is down - there's the interview I did. But please do stop by www.tinyminds.org once the server is back up, it's a great little newbies site. Robert M. Love Interview by Lovechild Want to know what's in store for you, the Linux desktop user, with the upcoming kernel 2.6, well have no fear, TinyMinds brings you an early christmas present: an interview with Robert M. Love, kernel hacker extraordinare, student and all round nice guy. TM: First of all, I'd like to thank you for taking the time to answer a few questions for our members. RML: You are welcome. TM: Most of us only know you as the guy that brought us the preemptive kernel patch and all it's niceness, please enlighten us a bit on the real Robert Love? RML: The real Robert Love enjoys the finer things in life, such as Cheetos. I am a Mathematics and CS student at the University of Florida. Born in Southern Florida and now in Central Florida. Not a big fan of Florida at all, though. I work for MontaVista Software, the embedded Linux company, as a kernel engineer. I primarily work on scheduling, performance, and real-time kernel projects. I enjoy photography, good music, and good food. TM: How did you get involved with Kernel hacking? RML: I always found operating systems interesting and Linux provided a rare but welcome opportunity to get involved. I started following the lists, reading books, and perusing the source. I aspired. I started with bug fixes and driver updates. Then I jumped in head first. TM: But why the Linux kernel, there are many kernel projects out there, fx. HURD and the BSDs - What attracted you to this kernel. RML: I had been using Linux for awhile, so it was a natural progression for me. TM: On to the actual questions, as Tinyminds.org is primarily a desktop user Linux site we were wondering if you would tell us a bit about the changes the desktop user can expect in the upcoming kernel 2.6? RML: Desktop users can expect a bit in 2.6, which is somewhat surprising as the goals of 2.5 were primarily to improve scalability and reduce bottlenecks in large machines. First off, of course, there is the preemptive kernel. The preemptive kernel makes the kernel schedule preemptively like user-space, as opposed to schedule cooperatively. This improves process response by allowing a freshly woken up process to immediately preempt the running task, even if the task is inside the kernel. Next, the new scheduler is important. Although the primary features of the O(1) scheduler are not important to desktop users - since desktop users typically have only a handful of runnable processes and only one or two processors - the interactivity estimator in the O(1) scheduler can greatly improve system feel. For example, during a large multi-job compile in X it is very possible for the system to lose responsiveness as the compilers hog the processor. With the O(1) scheduler, the interactivity estimator can ensure that your "interactive" tasks receive the processor's time. The new I/O scheduler has a couple improvements that benefit interactivity. The I/O scheduler is the part of the kernel which decides which blocks to write out or read in from disk. The kernel orders such block requests to try to keep drive access linear - so the drive head is not hoping around like mad. In 2.5 we have the new "deadline I/O scheduler" which replaces the old "elevator". The first benefit from the new I/O scheduler is it enforces deadlines. This insures that no request is starved. The second benefit is a preferential treatment given to reads over writes. This solves the issue of writes starving reads. In applications, pending reads generally stall the program until they are serviced and contribute to process latency. Pending writes, on the other hand, do not matter one bit to the program. Both of these features improve desktop performance. Finally, we have the new VM and block I/O layer. They have both been redesigned and greatly simplified. They work together a lot better now, and it is much easier to saturate the disk. These changes have two large ramifications for desktop users: better fairness and improved performance in corner cases. This is a big change over 2.4, which was not all that fair. In 2.5, a lot of work has gone into insuring that multiple tasks all make equal progress when the machine is under load. Swap out performance is improved. Tasks are not blocked for ludicrous amounts of time. In short, 2.6 should be "nicer" on the desktop but for normal machines with normal workloads the improvement will not be huge since 2.4 was not that bad to begin with. But 2.6 will certainly be excellent. TM: Now your preemptive kernel patch has become very popular with desktop users, would you mind giving us a quick walk through on how it works? RML: Sure. Previously, the kernel was not preemptive. It was scheduled cooperatively. This meant that process code in the kernel (executing a system call, servicing a page fault, etc.) and kernel threads ran until they explicitly give up the processor and caused a reschedule. This can cause latency and poor response if a reschedule is pending and cannot occur until the current process exits from the kernel. Let us look at an example. Pretend there are two processes on the system. The first is a background job, like a compile. The second is the great text editor, vim. The compiler is running while vim is blocked waiting for keyboard input (as usual). Assume the compiler is in the kernel executing a system call. Next, the user types into vim. This causes an interrupt from the keyboard controller, which copies the new data into a buffer for vim. Then vim is woken up and hopefully rescheduled. Unfortunately, vim cannot run until the compiler exits from the kernel. This delay contributes to scheduling latency (the difference in time between wanting to run and actually running). If it is noticeable, users get cranky. The problem is bigger for real-time applications, because they need minimal latency. It is not good if a lower priority process can prevent a higher priority process from running. So now, with a preemptive kernel, when the keyboard interrupt wakes up vim, vim can run immediately. Soon as the interrupt returns, the kernel notices a process was woken up and can invoke the scheduler. 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. TM: Besides the preemptive kernel patches, what else have you been working on? RML: A bit of scheduler work. I work on bugs and issues as they arise and helped with some of the initial work. I wrote the processor affinity system calls, which are now in 2.5. I did a hint-based scheduling call and most recently wrote a small patch for allowing run-time tuning of the scheduler via procfs or sysctl. I like to pretend I am a VM hacker. I ported the VM strict overcommit infrastructure from 2.4-ac to 2.5, and that is now merged. I try to send useful cleanups or improvements to Andrew Morton. For example, I did a low latency zap_page_range() implementation. I also wrote and maintain schedutils , the Linux scheduler utility package. And I maintain procps - the package that contains ps, top, vmstat, free, etc. - with Rik van Riel. TM: Recently it has become tradition for ConTest result to be posted on lkml. I understand you have played a role in this (along with Andrew Morton and Con Kolivas). Why is has this testsuit been so well received when kernel hackers normally flame benchmarking suites in general, and what impact will ConTest have on further fine tuning of the kernel? RML: Contest is a very unique benchmark in that it measures system responsiveness. More importantly, it is a great tool for measuring fairness. Contest has been a big help in enabling us (and by 'us' I mean very much Andrew) in improving the performance of doing multiple things at the same time. I guess its beauty lies in its simplicity. Contest simply times a kernel compile - first, by itself, then under various loads. This helps us understand fairness issues and insure the machine stays usable under load. Contest is a significant reason for the fairness and responsiveness seen in 2.5. But I do not think kernel developers normally have an issue with benchmarks. They are very useful for tuning and regression testing. They just are not all that matters. TM: Care to guess at what marvels we will see in the next development cycle (kernel 2.7)? RML: Whatever the developers find interesting. Probably some improved NUMA support. Perhaps a couple VM features to solves issues discovered during 2.6. Easier is to say what we need: tty layer rewrite and SCSI layer rewrite. A unified disk layer would be very nice. TM: What would a tty layer rewrite and SCSI layer rewrite grants us, meaning is the current one just really suboptimal ? RML: The current layers work, but are just suboptimal. More specifically, they are not clean. Perhaps even gross. The tty layer is old, poorly understood code. It may contain races or hard to find bugs. It is strongly wed to the BKL. The SCSI layer is not terrible, but it needs some work. SCSI drivers have to implement far too much code on their own. The SCSI layer needs to be cleaned up, generalized, and receive a face lift. Boring work, unfortunately. TM: I was thinking more in the lines of when(if ever) will we see stuff like Supermount in the mainline kernel, it's provides a much needed feature for desktop use. Personally I think we need features like that to make Linux more useable for migrating users from say Windows or Mac. RML: I do not know the future of supermount. I agree its a useful feature for users migrating from stateless mount systems like Windows. I think it has its place in vendor kernels, at least. TM: What's your take on Linux' future on the desktop market? RML: I wish I could say "well our technology is superior so of course Linux can capture the market". But it does not work like that, because we are facing a monopoly. We are attacking a market that historically no one has made significant progress in. I think we are better than Windows. I do not believe anyone can look at the state of the current GNOME or KDE desktop and tell me that the Windows desktop is superior. The UI decisions made in the current GNOME releases are excellent. It is a beautiful and well-thought out implementation. For example, Red Hat 8.0 is quite impressive. We are missing applications, though. Windows has a very wide array of programs, including important titles like Microsoft Office. While I think some Linux desktop applications are superior (Mozilla) or at least equal (Evolution), we need more. I started using Open Office recently and I was very surprised how complete it was. Application availability is our weak spot, but we can do it. Oh, and of course our kernel is far superior ;)
TM:
Again thank you for all your hard work on the Linux kernel and thank you for taking time away from hacking the kernel to talk to us. From all of Tinyminds.org, a merry Christmas to you and your loved ones.
RML:
Thanks and the same to you and yours.
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!
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:
- Stick with an older Linux distro which uses a 2.4.x kernel.
- Wipe Linux and use Windows. [1]
- Spend over $100 for an external modem (I'm a college student, so no).
- Drop out of school for the next semester, and abandon my current open-source project so I have the time to develop an open-source driver for win modems. I want to graduate ASAP, so alas no.
- SamThen 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.
The secret to enjoying Slashdot is to realize that it should not be taken too seriously.
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.
You can use the old kernel, you can use the new kernel, you can use your own kernel.
Everyone can make whatever they want.
They don't owe you anything.
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.
And that multibillion dollar business can't find a handful of guys to make their own kernel.
I don't think kernel developers are _that_ expensive
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.
Oh yeah, perhaps it's time. I feel vindication coming.
Perhaps this post will be modded down as flamebait or troll, and that's OK. But perhaps all the people who read at -1 will see it, and understand why Linux is no better than Microsoft (or the other way around), and why spreading FUD is something done with gusto by everyone, everywhere. Perhaps wrapping oneself in the flaming gown of "open source" and "free software" is not so effective anymore.
I don't know exactly what a Winmodem is. But from what I have heard it is a lousy poorly designed hardware component that is best used for slowing down the system. The purpose of the design was to cut a few cents off the price for the component while at the same time making the hardware a lot worse. Work that was best done in hardware now has to be done in software because the component doing it was removed. But many people don't know about all this, they think all modems are equal. They think the clockfrequency of the CPU is the most important factor on system speed, and they surely don't know how many clockcycles will be wasted due to the Winmodem. A Winmodem is a piece of hardware so badly designed that you cannot write a good driver for it.
Do you care about the security of your wireless mouse?
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.
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.
Mod me down, ya bastards. But if you don't address these issues, how do you ever think you'll become an option for joe user? You'll always be on the fringe.
If (and when) Microsoft do this it's significantly worse because they have total control of their operating system.
If the changes the Linux folk are making are indeed heinous then any one of us is permitted to fork if we so desire. With MS it would be all or nothing. With Linux if you don't like what you're being offered you can change it if you want to.
Boffoonery - downloadable Comedy Benefit for Bletchley Park
This is just another facet of the kernel developers' jihad against binary modules. Presumption of guilt does not imply bad code, it implies prejudice(*).
Recent drivers are better than they used to be, but the nvidia kernel module really, genuinely has had a LOT of problems. I have a machine with a Geforce2 that will stay up for months when using the open-source nv XFree86 driver (which uses no in-kernel code at all), but using the nvidia binary drivers oopsed at least once a day with random memory management errors and would freeze hard about once every 3-4 days. It finally seems to be fixed in the most recent release of the binary drivers. And let's not even go anywhere near AGP support - even with the most recent drivers, if I leave the AGP support on I am guaranteed a wedged machine within 5 minutes of starting X, whether I tell the driver to use the kernel or its own agpgart support. I'm not using weird hardware either - this is a PIII Abit motherboard with Intel BX chipset - about as standard as you can get. The card is flawless in Win2k with AGP on, again using the nvidia reference drivers. If I swap the Geforce2 out for the old Rage128 I have lying about, that works flawlessly in Linux too, 3D, AGP and all, but it's a lot slower than the Geforce. Oh, and I'm using stock Linux kernels, no distro-specific stuff or strange patches. The only option that I could see in the kernel that might make a difference is using the local APIC on the PIII as opposed to using the XT-PIC, as this can mess with the interrupt delivery timings and delivering an interrupt which the driver isn't expecting might wedge it, but I tried it both ways with the same results. It ought to just work though, right?
Therfore, the only conclusion that I can draw is that the nvidia Linux binary driver is buggy, particularly with regard to its handling of AGP. I don't think I'm alone in reaching this conclusion either - I have heard plenty of fairly similar bug reports. I can't begin to debug it myself because I don't have the source to the nvidia driver. I've reported it to nvidia. I haven't bothered pestering the kernel developers with it because it's plainly not their fault and there is nothing they can do to rectify the situation.
I admit I've not tried it in another motherboard, but why then does it work in Win2k flawlessly? Ok, Win2k is also using binary drivers - but then, when was the last time you mailed an NT kernel developer with a driver bug report? You don't, you mail the driver developer if they give you an address or simply sit tight if you don't have one. That's all the Linux developers are asking too.
Put simply, the reason the Linux kernel developers tell you to piss off if you're using the nvidia binary driver is because 99% of the time that is the problem, and if you're too stupid to be able to realise that and attempt to reproduce it without the nvidia driver loaded, then you're too stupid to provide a decent bug report and your mail might as well go straight to /dev/null. Most kernel developers are drowning alive in email as it is, and that's email that's got useful stuff in it. They have better things to do, like fixing bugs in code that they have the possibility to fix.
(*) Please don't flame me for calling Linus a racist.
I'm not. I'm flaming you for being stupid and not understanding the issues involved.
Omigod, they've reinvented Mac OS 9!
You bastards!
---
Information wants...you to shut your pie hole.
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
LOL.... voted (Score:0, Offtopic) Yet it is the topic.... this is so much fun.. yes yes, I know, now I'll become (-1, Flamebait)
I would say ` I cant beleive anyone with half a brain would mod this down' , but then this is slashdot.
anyways, the post itself is totally true and real issues in Linux that MUST get address if anyone is to beleive that they could tople the Microsoft User market
now will come all the usual "we dont need stupid M$ drones" and "linux doesnt need to conquor the world" posts.
I follow the SDK and GDN principles.. Spelling Dont Kount, Grammer Dont Neither
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.
I agree with many of your points... however many are impossible to change due to the nature of the beast. Many suckware programs arise out of a geeky need to see if they can do it rather than a need for the end product. That's why there are so many "kinda work" programs out there... at that point, it's not fun anymore.
However, your console point is misplaced. Obviously there needs to be a GUI for the masses, but the shell should always be there and prominent. The reason is that a console is an order of magnitude more efficent than a GUI for doing the majority of computing tasks. It's just quicker to type a quick command than open up 3 windows, click around, and drag-and-drop. It also uses less system resources and allows for efficient remote management. The console, even as prominent as it is in Linux, is still underrated. Give it a try.
if I leave the AGP support on I am guaranteed a wedged machine within 5 minutes of starting X
That's odd. It works fine for me.
- 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
I realize Ati and Nvidia can't open source their drivers in linux because they use technology that is patented from other organizations like OpenGL. Wouldn't it be possible for them to release just enough hardware specifications so a no frills 2d only driver could be produced with GPL license? That way, when a new kernel is out you don't have to wait for Ati/Nvidia to release an updated driver (a week in nvidia's case, a year in ati's).
just kidding
Gee, did it ever occur to you that Linux wasn't written so that Big Corporations could make money selling bloated software to other Big Corporations?
If the big companies want to use Linux, let them, its not like they have to pay for it or anything. But come on, they can't sit around demanding a cash-engine so they can get totally rich while kernel hackers end up with a part-time job for said Corporations.
Gee, do you think that maybe, just maybe, those big companies should hire thier own developers and have them roll the code that fits thier needs, rather than ride around in limos wishing the unpaid kernel hackers would quit being so snotty with thier own creations and make something that will get the Corporations even richer? Corporate America loves to take, but gives back so little (inlcuding crappy binary drivers).
And what makes you believe that the FreeBSD developers would be willing to sweat for these same corporations?
As was said earlier, after all this time, you people STILL dont GET Linux (which is not a platform by the way, its a KERNEL).
Is that if MS make such a policy change they are dictating to everyone as no-one else has the rights required to forge another route, it's their way or the highway
No one is in such a forced dependancy relationship with the Kernel developers. We may depend upon them by choice, but if what they do really is seen as unacceptable then the rights given to us all by the kernel licence protect us from being completely at their whim.
Boffoonery - downloadable Comedy Benefit for Bletchley Park
The good folks at the OpenAFS project had to deal with some of these changes as RedHat started introducing them into their builds of the 2.4 kernel. Their experience may be somewhat instructive -- they found a way around several attempts to prevent them from adding syscalls.
"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?
As the man said
"Finally, I the most important thing to say is that the community does not need to standardise. Over what is almost twelve years we have pulled ourselves up by the bootstraps. We have done this using a development model that allows us to produce software that proprietary vendors cannot compete with. Over time, as the software gets better, desktop distros get even more user friendy, and more people become aware of the existence of Linux (this is already happening on a large scale with the trickle down effect from use of Linux in governments and business), more and more users will experience, and then switch over to it.
To put it simply, the Linux community does not need to set up businesses with the specific intention of trying to "win" users from Microsoft; all w have to do is continue to develop software in the same way, and the users will make the switch all by themselves."
He was speaking about standarizing, but his argument applies equally well to this thread.
Linux can't conquer the world. If Linux sucessfully conquered the world, Linux would cease to be a good thing. Simple as that. Mock on.
A bigger risk is that it could provoke a fork in Linux -- with commericial/end user oriented developers taking a separate 'practical' branch of Linux away from the 'beautiful' version of the purist developers. That would be a disaster.
Will that actually happen? Probably not in the short term as even the most 'practical' of the talented developers has too much respect for Linus. But it is a danger if the cost of meeting end user demands within a 'beautiful' Linux becomes too high.
"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.
Ah "let's pretend" argument.
How about:
Computer market which is dominated by windows is nearly saturated with computers with video cards[2]. Were do we sell our product next? How about those 200,000[1] Open Source computer users? And as a bonus there are few companies with our features and price competing in that market? Plus to boot our development team can actually look at the APIs and implimentation, instead of assuming like on that other platform, thereby wasting time and money.
Also your cost argument is bogus.
Remember companies have been maintaining differences across different OS varients (unified drivers minimize but don't entirely eliminate), and even different platforms (Mac,Windows) for years. Didn't bust them back then. What's different now?
[1] The number I bet is much bigger, and could be even bigger for companies that look at all the platforms that use Linux, and BSD.
[2] There's a reason Nvidia's branching into chipsets, and other things.
"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!"
Why should the average person be excited about new kernel releases? That sounds like Marketing Department talk to me.
Marketing people love trying to get the average people excited by inventing new symbols/acronyms for them - e.g. Quantispeed, PMPO.
As far as I can see, those who need to be excited have no difficulty understanding what the new features mean to them - better threads, better scheduler.
As a tech person I prefer a situation where if I don't understand something, it is actually something new to learn, NOT some stupid bullshit or LIE Marketing thought of.
Yes I know there may be cases where even the average tech person doesn't know what the developers are doing. But often that's a transitional case - maybe the developers aren't sure either - changing/testing stuff. And in other cases the average tech person doesn't need to know either. For example: if the developers do most of their stuff correctly, we won't need to know what a particular lock is for. Coz the reason why we would ask, probably means they screwed up somewhere: deadlock.
I'd love to see a kernel release with *complete* help and descriptions in the "make Menuconfig" system.
It's trivial to power users, but you've got to remember that a "serious" Linux newbie will get a lot of knowledge by playing with, and compiling, new kernels.
To truly understand what each feature does, the first place they usually look is in the "Help" button in Menuconfig. Not in the Readme's, and certainly not in the code.
If we actually make these help screens useful, and a little less condescending ("If you don't know what this does, say N here") we'd make the learning curve less steep.
It would also be nice to see a little more grouping by functionality. USB is a good example... it's a logical grouping by type of device. Perhaps though, USB, PCMCIA, etc. could be under "Removable hardware" (again, for the newbie and for ease of use) while network shaping could be under just that, and shaping/drivers/network file systems, etc. could all be under "network".
Trivial to you and I, but really important to the one group of people who count most: Future power users.
mindslip.
Yes Nvidia is selling software with their hardware.
But that software is a means to an end. Sell you hardware. That's all!! Nothing more.
And as both history and others have pointed out to you. Those secrets aren't really a secret to someone determined enough. The only thing that keeps the sides honest is the fact that the other side can do the same to you. Now were did I hide that patent?
" You can say that this sucks and I'll sort of agree -- I'd really like to see some good specs from all of the graphics card companies to make free-as-in-speech drivers possible. But as long as they're giving away good drivers, even closed-source, my complaining will be no more than a whisper."
And when things do change and your voice switches from wisper to shout. The question will be. Were was your voice before? You don't wait till disaster strikes before you buy insurance. Why are you waiting now?
"Well, one exception: they need to work (if you use NVidia drivers, upgrade to the latest 4xxx release -- there is a serious bug [minion.de] in previous versions that will crash your kernel!) The kernel developers have had some issues with having to tell whether bugs are in the kernel or in proprietary drivers -- but this particular, very nasty bug was in the open source glue section of the nvidia driver, since it was making heavy use of kernel APIs!"
I have the latest and it STILL doesn't work.
Ah my Windoze memories. Glad I didn't learn anything.
I thought the same thing.
:-P
I agree with other arguments that this will just push them towards OS X.
We have a commercial product on Linux which ships as source. We support Red Hat 7.2 only (currently), and with GCC 2.95.3. Because that's not the default compiler, you can guess it's not a big seller.
Unless we ship as source, we can only get a small fraction of the Linux distros. It's just a lot easier to ship/work with Solaris or Windows (and now OS X) when they do a much better job of providing a platform for shipping as binaries (and until we choose to ship source this will remain an issue). We don't have the resources to support 15 different Linux distros/versions, so they get the short shrift because they really each count as a "platform" that we need to be able to test on.
Then again, Linux users are also often averse to our prices
Evidently, the gent's a craftsman using all his tools. Very impressive. I respect his work. The product, sundry Lusrs and *nix SOTA all benefit from his no-nonsence effort. Makes ME feel well justified to have PAYED ( p-a-y-e-d ) for my current *nix release, unlike the /. standard downloading dweezle.
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
So, you're just lucky.
I'm all about free (as in liberty) software -- and drivers are already free-as-in-beer. But aren't we missing something here? Why does it matter if you can't get a GPL driver for a closed proprietary piece of hardware?
I think if you're going to be an ass about the GPL-only software, you should be an ass about the hardware too. Hell, the BIOS on your motherboard probably isn't GPL, but you use it. The driver for your GeForce isn't too different, except it runs in the OS instead of below it.
Get off your high horse and put your money where your mouth is. Buy hardware that has GPL drivers, or live with what you have. So many other posters had it right - it's NOT wise for ATI and NVidia to put out GPL versions of their drivers, they obviously have a lot of trade secrets in there - have you seen the performance and features that they get between driver versions?
The best solution I've seen to this is to put a shim over the binary module. You recompile an interface layer to suit YOUR kernel. The interfaces aren't changing too often, and nobody that can put on the new kernel right away is looking for high-performance graphics and/or rock-solid stability.
So that's why I get an unwanted editorial when I load my Nvidia kernel module. I always wondered who coded a piece of Stallman into modprobe.
So what does this mean? I guess I can kiss Nvidia support goodbye. Thanks a lot guys.
And don't anyone say "use the DRI module". The DRI modules SUCK. They leak memory worse than windows and have been the cause of more complete system hangups than anything I can think of. DRI has been around for years and the best they seem to be able to offer is a "stable" driver for the Mach-freaking-64. DRI is a complete and utter failure. I can't even use the 3dfx-DRI modules to reliably run something like BZFLAG for any extended time--it hangs the system up reliably, CONSTANTLY.
The NVIDIA drivers work and work very well. If I end up losing that because of stupid license whining then sorry folks, bye bye Linux. I hope NVIDIA supports FreeBSD...better yet, I'll just get a Mac.
On one hand, we all want Linux to be embraced commercially right? And then stuff like this happens, slapping the hands of anyone good enough to support Linux commercially.
I've already been on the verge of deciding not to buy NVidia again. It'll be a while before I replace my box and there's still a bunch of time to decide. For now, it works for me. Also, quite a few other graphics vendors have not really been forthcoming with specs either.
To be clear: I'd really like totally open source drivers, everything at kernel level open source, but it's more to ask than it's worth. I eventually demand open specs for the building of open drivers -- even if the "official" drivers are closed -- but I'm willing to overlook this in the short term only because I have better things to worry about, like getting a life.
...I'm waiting with some amusement for calls to nationalize the Linux source code and imprison the current kernel developers.
"It doesn't matter if it's someone's homebrew project: simply by virtue of distributing it and acting like they had over the prior 10 years, they lulled us into a false sense of security. Then, WHAM! Bait and switch."
"We the users should have full rights over the development of this kernel. After all, this is a public works project."
"Linus, Alan, and everyone else use the roads to get to work, right? Or, if not, they buy food that is transported by the roads. Or, if not, they enjoy the smell of the asphalt. In any event, they are enjoying a public resource, which means we all have a right to the fruits of their labor."
I laugh whenever I hear these arguments applied to anything. I truly hope you're laughing to hear these arguments applied to Linux.
[ home ]
It has probably always been true that the only way to protect investment in Linux deployment of drivers and other kernel facilities (not applications) is to go open source, even if that is difficult for commercial enterprises to absorb.
Commercial enterprises are the only places that linux is succeeding - talk about shooting in the foot..hell, they're putting it right to the temple. And they continue to dream of the average person using this OS...ho ho....
Companies sometimes write binary modules that work only with one exact version of the kernel for one architecture, thus preventing their customers from upgrading both their OS and hardware.
How is this any better? Why pick on the kernel developers but not on the binary modules creators?
Installed the Bubblemon yet?
Last time I checked there were a lot of wrappers for kernel compiling that made it somewhat simple, except for checking for things like your boot-loader would fine the new kernel, etc - which some people overlook. Is it simple a disable option... allow_binary_kernel_linkage etc?
Some people whine that they would like the source so they could mod their video card properties, but it's still a hell of a lot better than having no driver at all, for which many more people will whine unless they cannot get their video card to work without going through a huge hassle.
Then we have people whining about how the binaries can violate GPL. But maybe we need a clause for video drivers.
If the drivers are released as free to the public - not with source, but without cost, then that would make 90% of the users happy.
You also have to consider that things like video cards don't work exactly like software from a marketing perspective. Software like mySQL etc can market their troubleshooting and/or programming, as well as enhanced-feature licenses while still making their base-produce free and open source.
How many people would pay for a troubleshooting contract for a video card brand? The profit is in the sales, and the sales are based on that it works. I know very few people who would begrudge NVidea for releasing compatible drivers, even if they are only binaries. Making the hardware work is one more step towards making linux a more accepted o/s, and that's a good thing!
Your response was hilarious!
As if being a op on IRC HAS ANY CREDIBILITY!!
Creative use of existing tools.
It sounds like you're a little confused about what preempt mode is and isn't. So here goes - HTH. It isn't the ability to preempt a running job in favor of scheduling a new job. That's called "preemptive multitasking", and Linux has had it since Day 1. It also isn't multiprocessing - running multiple jobs simultaneously via multiple CPUs. Linux has had that since, oh, 1995, I think (kernel 2.0).
Preemption, in this context, means interrupting one job to schedule another while the first job is busy running something within the kernel itself. You see, most processes ("jobs") run part of the time in user space where they are executing their own instruction streams, and part of the time in kernel space where the kernel is working on their behalf - reading disk files, sending messages to other processes, etc. Now, while the process is in user space, it can be preempted at any time, whenever the scheduler decides it has used its fair share of CPU and it's someone else's turn. (This is preemptive multitasking. MS-DOS and MacOS 9 didn't have it - on those systems, a single process can run as long as it wants, and is only stopped when it voluntarily gives up the CPU.)
Kernel space is another matter. If you ask the kernel to, say, read a disk file, it will usually put your process to sleep until the file comes back from the disk, and will schedule other processes in the meantime - but for various other work the kernel does on your behalf, it does not normally interrupt itself periodically to make sure you still have time left on the clock, as it were. Thus, if a process makes heavy use of kernel facilities, there may be (relatively) long periods of time where the process should "in fairness" relinquish the CPU but it won't because it's "in kernel mode".
The reason for this rule - the reason the kernel scheduler never jumps in and preempts other kernel code - is that by doing so it would be quite easy to corrupt the state of kernel variables. This one is hard to explain if you haven't learned about locking primitives in programming courses, and unnecessary to explain if you have. Suffice it to say that arbitrarily grabbing the CPU and switching to another task is prone to basically the same failure modes as having multiple CPUs running different tasks simulatneously - i.e. SMP mode.
So, what's the problem with not preempting kernel code? Say you have another process doing highly interactive things, like a game, or an MP3 player, or even the X server tracking your mouse movements. Ideally you want it to react to new events (keyboard and mouse input, for example) as quickly as possible, so your system feels "snappy". Which is a problem if another process happens to be taking its own sweet time in kernel mode while you impatiently wiggle your mouse for half a second, wondering if the system is frozen.
Note that if you have multiple CPUs and use an SMP kernel, this "latency problem" is not nearly so bad. Since any one of your multiple CPUs may be available to service your all-important "main snappy application", the chance of seeing unacceptible delays is greatly reduced.
With me so far?
So here's what the preempt patch does. It changes the above-mentioned rule so that the scheduler is allowed to interrupt other kernel code without explicit permission, just as it does with user-mode code. If the kernel happens to be in a critical section (another technical term hard to explain to those who don't already know it), it should already have taken a lock in the SMP-mode case, so preempt-mode just redefines the lock/unlock operation as "disable preempt mode" / "reenable preempt mode". Thus, the kernel can sit and do all the work it wants to, and as long as it isn't holding any locks, the scheduler can pause it and run something more important (like letting your MP3 player trickle a bit more music into your sound card so the sound card won't run out, at which time you'd hear a skip).
I guess the terminology is really up to the reader, but in my opinion, while this is a "hack" in the sense of "clever program snippet", I think "creative use of existing facilities" is a good description. The key here is the realisation that the problem of how to preempt the kernel in arbitrary places is very similar to the problem of letting multiple copies of the kernel run at once on different CPUs, and since the latter is basically a solved problem (it was, in fact, probably the biggest difference between the 2.0 and 2.2 kernels), Robert Love was able to reuse this infrastructure to solve the vast majority of the problems with the former, in one fell swoop. Of course, preempt mode had other problems which had to be solved other ways, but SMP support was the major thing that paved the way.
(By the way, this wasn't Robert Love's idea originally. Linus Torvalds expressed it some time around the 2.4.0 era, but didn't feel like doing the work himself. I don't know if it was his original thought or if all this has been done before. I suspect Solaris, at least, uses a similar trick.)
Completely different. Intel's HyperThreading mode uses cooperative (not preemptive) multitasking implemented within the chip itself. At least that's my guess. Each virtual CPU runs until it hits whatever Intel deems a good stopping point, then changes hats and lets the other virtual CPU have a go. It works because a lot of facilities in the CPU can go underutilised because of bottlenecks elsewhere (fetching memory into L1 cache, for example), so by simulating two CPUs you can often keep these resources busier.
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
The best vanishing trick is to banish this NIH inferior unstable OS from the world and go to the original superior stable BSD OS. There is just no reason in this day and age to keep reinventing what's already available in BSD.