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.
The Slashdot front page had about 20 giant adverts and all the links were fished!
By forcing open source drivers, crap like paddlium will find they are not welcome. Therefore computing will become freer by keeping the source clean and open.
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.
-- Will program for bandwidth
Why does Linux Suck on the desktop
.blah,blah,blah. . .come on - focus your efforts. I don't need 1,500 programs which do the same thing poorly. I just want one focused program that will work and doesn't take a rocket scientist and cryptologist to figure out. Linux is over diversified with too many things doing the same thing. So before you put your efforts in creating a new and improved FTP program - I say, survey the landscape and see what's out there.
by Joe Linux User
SOFTWARE INSTALLATION
Oh wait - I got to learn C to use this thing? What the hell is a makefile? Why do I have to go into the console, rip out my hair, and bleed from the eyeballs to play Khangman. Why is an installer program such mysterious nebulous thing in the linux world? Why not copy installers from Mozilla or OpenOffice instead of making the user base loses its hair trying to use the program. I'd rather be wrestling with my procrastination than wrestling with just getting the damn thing to run.
RPM
RPM's are great except when you need other RPMs which require other RPMS and even more RPMS. RPM is a govermental beaucracy digitized and put in the computer. When it works - it works great. When it doesn't - man, does it suck.
DESKTOPS
Let's face it. The current desktops for Linux are the ugly stepchildren you keep locked in the closet. Sure, they might do great tricks to impress the neighbors but no one wants to look at them. Lets face it - eye candy counts. And Linux doesn't cut it. It looks just what you'd expect a free product to look like. Ugly.
MORE LANGUAGES THAN PROGRAMS
All right - so I'm fudging this one. There are some great programs in Linux. But you get my point. The Linux community has perfected the art of tool making - now make something substantial with them instead of creating half billion half finished applets in the end which probably do the same thing. Yes - a "completed" abandoned program is much better than a "uncompleted" one.
KDE DEVELOPERS
Okay - the letter K is being used beyond overkill. It's very irrirtating to open up a menu and see "k" everything. YOu know - it kinda of loses its meaning. I challenge you half-application finishers to start your program with the letter other than k.
DOCUMENTATION
I bet a gazillion of you are going to yell at me to write documentation for the project. Fuck that. I can barely write this rant. And besides, not all your users want anything to do with Linux besides use it. You know - the joe user. Me. So go fuck yourselves and write a semi-coherent doc on how to use your program. Hell, I even challenge you to write your documentation before you write your application. and before you start the meat of your doc, make sure to add the paragraph stating your intended audience.
IF SOMEONE ELSE IS DOING IT. . .
Everyone talks about diversity in Linux . . blah,blah,blah . . competition fosters growth. .
CONSOLE SUCKS THE BIG ONE
Okay - unix is console culture. I get it now. Linux and unix guys are the people who still use typewriters when computers are readily available. But when I use a computer, I never want to touch the fucking thing. It's hideous and ugly and brings me back to the eighties. I hate that I have to use the thing. It drives me nuts. When most users realize they have to use the damn thing, trust me, back to Bill and the Monkey Boy. They'd rather pay for someone else to take care of that crap, rather than deal with it themselves.
There's more, but I go to go back to work. I only write this 'cause I want linux to succeed. flame away.