Linus Announces the 2.6.25 Linux Kernel

LinuxWatch writes "'It's been long promised, but there it is now,' began Linux creator Linus Torvalds, announcing the 2.6.25 Linux kernel. He continued, 'special thanks to Ingo who found and fixed a nasty-looking regression that turned out to not be a regression at all, but an old bug that just had not been triggering as reliably before. That said, that was just the last particular regression fix I was holding things up for, and it's not like there weren't a lot of other fixes too, they just didn't end up being the final things that triggered my particular worries.' There were numerous changes in this revision of the OS. The origins of some of those fixes is detailed in Heise's brief history of this kernel update."

Comments

Wonderful. More Stable. ... So?

[PC and Sony Fanboy]

Great. Now that the engine is all fixed, can we get a decent looking chassis with working accessories?

Re:Wonderful. More Stable. ... So?

[Spleen]

Sorry we only make engines and provide them to all the major manufacturers. Please speak with them about the accessory packages.

Re:Wonderful. More Stable. ... So?

[megabyte405]

That's not really a Linux thing - look at Debian, you've got two kernels there and effectively the same userspace. Now, if you say you want everyone to stop using X, you'd probably need to implement some sort of direct rendering on the next level up, which is going to be your toolkit stuff (GDK/Cairo/GTK+ or the QT equiv, for most apps) You have now just bisected your GUI application compatibility.

I'm not sure that X11 is so lacking anymore - the recent versions have been making some nice improvements, and it's still the only thing with that high of compatibility.

Re:Wonderful. More Stable. ... So?

[Simon Brooke]

My history with Linux has the problem not being with the Linux Kernel but with the X Windows System (Xwindows is big and clunky to support features that we don't fully utilize and are fully utilizeing them less and less). I think Linux needs to seporate from its Unix haritage and start moving away from X11 and to something a bit more direct with the frame buffer and video card (Much like how OS X has). Granted X11 has improved in the areas of 3d acceleration and such. But compared to OS X it is lacking

And that has precisely what to do with the kernel? X is in user space. If you want to replace X with any other windowing system you like, just port it or write it. And when you've written something as powerful and stable as the X Window System, come back and tell us about it.

Re:Wonderful. More Stable. ... So?

[bytesex]

I'm no proponent of the GP, but there *is* a 'third way', if you will - expand the X-library so that a) local connections don't necessarily use a protocol over a pipe, but make function-calls instead, and b) implement widgets in the X-client library much more detailed than the current window- and image-primitives; say a basic set of menu-bar, scrollbar, list, tabs etc. All pluggable in the X-server, of course, so that everybody can still 'skin' their desktop according to their taste. c) Do away - finally - with the silly ways that cut-n-paste and drag-n-drop, in short, IPC and buffers, have been implemented in X. Invent a serious way to communicate between X clients, not a tag-along.

Re:Wonderful. More Stable. ... So?

[Kjella]

And that has precisely what to do with the kernel? X is in user space. If you want to replace X with any other windowing system you like, just port it or write it. And when you've written something as powerful and stable as the X Window System, come back and tell us about it. Userspace and kernelspace are developer-speak, not something the average user really has to know. Users divide the world in to the operating system and applications, and since X isn't an application it's part of "the system" and goes into one big pile. Paricularly since the line has become very blurred, not only is X in userspace, but drivers are in userspace (all high-level USB drivers, for example) or filesystems (FUSE) and so on. It's fairly valid to point out that often problems with "Linux the system" isn't a problem with "Linux the kernel" but rather everything around. For example, USB support in the kernel is done but there's plenty work left on USB device support...

Re:Wonderful. More Stable. ... So?

[beav007]

If my laptop isn't supported by linux (any distro), then linux sucks!

Wrong. If your hardware manufacturer doesn't release decent drivers for Linux, the manufacturer sucks*.

Linux devs are working their asses off in their parents basements, hacking and testing drivers for hardware that they don't have access to the interface specifications for. If things still look a little shakey, just remember to be glad that they work at all, given the hours of work for $0 return.

When you are done giving thanks, complain to your hardware manufacturer, who does make money from the deal, and does have the full specifications - AND for reasons unknown, have turned down the offer of OSS developers writing the drivers for them, for free .




*See also: Canon

Re:Wonderful. More Stable. ... So?

[db32]

Right, and when you convince professional racers to give up their finely tuned gear shifters in favor of a stick shift with a chrome skull and glowing eyes you let us all know.

I truely don't understand this mentality of making everything stupid user friendly. Once upon a time you actually had to know a little bit about the tools you were using to make them work. Now instead of creating powerful tools that require some understanding we want to replace them all with stupid proof crippleware? And people wonder why well over 90% of all email on the internet is spam. People wonder why Windows infection rates are so high (aside from the security holes allowing the stupid user tricks, the stupid user still clicks on everything presented).

In this I propose that we place large concrete barriers along every major highway and paint tunnels on them with overhead messages like "Do you want a bigger penis? Drive here!" or "Get rich in this tunnel!" and maybe even "Protect your car from theives, enter here!"

Re:Wonderful. More Stable. ... So?

[at_slashdot]

When you've written something as powerful and stable as Windows Vista, come back and tell us about it :)

Re:Wonderful. More Stable. ... So?

[drinkypoo]

expand the X-library so that a) local connections don't necessarily use a protocol over a pipe, but make function-calls instead

What you are asking for would add substantial complexity to the codebase. Right now things are simple because X messages are just that, messages; it doesn't matter if they're carried over TCP/IP or a Unix Domain Socket. That's a feature. As computers get more powerful, message passing becomes more commonplace for convenience's sake. There ARE other GUIs available for Unix, especially on Linux where there's a kernel gui package. Perhaps one of those solutions would better be suited to your needs?

implement widgets in the X-client library much more detailed than the current window- and image-primitives; say a basic set of menu-bar, scrollbar, list, tabs etc. All pluggable in the X-server, of course

We have that already. It's called GTK+ or Qt or WxWidgets. Why should they be directly in X?

Do away - finally - with the silly ways that cut-n-paste and drag-n-drop, in short, IPC and buffers, have been implemented in X. Invent a serious way to communicate between X clients, not a tag-along.

My understanding is that this existed in both GNOME and KDE.

It seems to me like you're repeating a frequent and misguided call for overcomplication of X11, which is already quite complicated enough, thank you.

Re:Wonderful. More Stable. ... So?

[Junta]

I will say I agree with you on the message passing situation, it doesn't seem to be a significant penalty (I can still get Windows or better frames per second in 3d games, for example).

We have that already. It's called GTK+ or Qt or WxWidgets. Why should they be directly in X? While I in part agree with your sentiment, I will say that richer X primitives would mean better default remote performance. Instead of 'here are *all* of the x primitives required to draw a GTK button with the word Cancel on it', which is a not insignificant number, it could say 'draw Cancel button' and cut down on network performance requirements for good remote X. Keeping to a cross-platform API, but with the X implementations of the backend implemented as X extensions may have some value in remote usage scenarios.

I also agree with you on the sentiment of xdnd and cut and paste. As a user, I'm not seeing the problem. The only user issue I see is that the middle click paste sometimes confuses people, but I'd hate to see that go away. Nothing about that could be called an issue with the architecture regardless of the opinion.

X gets a lot of power from having abstractions that can be remote agnostic. I think the implementations have done a sufficient job of providing short-path optimizations for the local case without sacrificing the fundamental remote functionality. I think X's task of taking the network architecture and doing it locally fast has produced a smoother experience than the platforms that have had to do the opposite, and try to make their GUI cleanly remotely usable.

Re:Wonderful. More Stable. ... So?

[Burz]

You have just articulated the major perceptual obstacle to Linux developers' ability to grasp the desktop. They refuse to draw a neat line between "system" and "applications" and then promote and support that set of interfaces, so there is no consistent platform that facilitates independent distribution of applications to end-users.

Re:Wonderful. More Stable. ... So?

[Abcd1234]

Well, you go run some benchmarks and prove that there's a big win to be had by moving to a non-IPC based model of communication. A significant rewrite like that requires some serious numbers to back it up, and so far, all you've provided is anecdotes and gutfeel, and my friend, that ain't enough.

Re:Wonderful. More Stable. ... So?

[PitaBred]

Yes. The problem is, your vaunted "MS or Mac" still have a closed development cycle. Those talks still happen, you just don't hear about them, and fewer people get a say. That may mean quicker decisions are made, but that doesn't mean they're the right decisions.

Besides, most of us don't work on Linux to make money with it directly. We work on Linux because it's fun and it enables us to do what we want with a machine, rather than being told where to go today.

Re:Wonderful. More Stable. ... So?

[Simon Brooke]

Benchmarks may not help as well. Gut feel is sometimes the best we get. I have found linux to be sparatic. with Xwindows. Tiny Delay Blast Tiny Delay Blast. On Average it may be on par but there is something off on its performance that doesn't vibe with me, that other systems such as OS X and Windows doesn't give me.

Oh, for pity's sake. Throw all your engineering discipline out of the window (ha!) and fall back on gut feel. and superstition. The fact is that Linux (with X Windows) performs much better on the same hardware than either Windows or MacOS. Why is this? Until you've shown that X Windows is a significant cost, then you really don't have any argument beyond hand-waving.

I have this to add: I personally have been using the X Window system for eighteen years. I've used it on hardware which had an 8MHz - MHz, not GHz - processor. I've used it on hardware that had 8Mb - Mb, not Gb - of RAM. The X Window system performs perfectly well on that hardware spec. It's always outperformed every other windowing system on the same hardware, and it still does now.

Basic engineering tenet, known to all old engineers (but obviously not taught to young ones): if it ain't broke, don't fix it.

Re:Wonderful. More Stable. ... So?

[Simon Brooke]

Lots of alternatives to choose from: http://en.wikipedia.org/wiki/Windowing_system And thank you for posting your snarky comment before doing 30 seconds worth of research. Pretty much all the alternatives listed are dead or dying, so pot kettle black on the amount of research done.

That's precisely the point. In a competitive environment, X Windows has won out. Why? Because it's extremely hard to write anything as good, and even harder to write anything sufficiently better to persuade any significant number of users to switch.

Re:Wonderful. More Stable. ... So?

[PeterBrett]

Most people who use XWindows don't use it over TCP/IP anymore. (Yes I will probable get comments from a bunch of Slashdot users say Yea I Do it is great...) But for normal use it is between the Computer and the Monitor.

I certainly use it all the time. I'm at university, and the ability to pull up Emacs running on my box in my room from any of the Linux workstations around the university (or in my friends' rooms) is really useful.

Here's an example of how it saved my arse once. I'd been writing a report using LyX, and was at my department to hand it in. Just as I was about to, I noticed that the caption of one of the figures was totally wrong. I logged onto one of the department's workstations, fired up SSH, launched LyX, made the change, generated a PDF, SCP'd it to the local machine and printed it. Without remote X, that would have been an enormous hassle -- I'd have had to set up a VNC server or something (which might have involved installing packages). With remote X, it's a simple matter of ssh -X.

tl;dr version: you can tear remote X from my bleeding broken dead hands.

Re:Wonderful. More Stable. ... So?

[Simon Brooke]

so if I had windows, I'd complain about not having the support of microsoft. but since I'm trying linux, I get told to buy new hardware. That sounds like a nice double standard from the linux crowd.

You paid for Windows. You have a contractual relationship with the people who wrote it.

Re:Wonderful. More Stable. ... So?

[Abcd1234]

Benchmarks may not help as well. Gut feel is sometimes the best we get.

That has to be the most absurd thing I've read in a long time. Either you're not a software developer, or you're an incredibly bad one. Either way, it's clear your opinions regarding X can probably be safely ignored.

Re:Wonderful. More Stable. ... So?

[Simon Brooke]

Why is it that Macs came from the ashes and haves close to 10% marketshare, while Linux install base (is between 0.5% - 3%) and you need to pay for Macs, and for OS upgrades, get stuck on priority OS and Hardware. The Linux comunity really step on its foot durring the Late 90's and early 2000's It really could have been a huge player on the desktop area, but the comunity is so Anti-Corproate and so resistant to change that it left them off as a distant 3rd place.

Why should we care whether you use Linux or not? Hint: Steve Jobs makes a lot of money if MacOS becomes popular. He's in it for the money and he's making lots of it. Good for him! Linus Torvalds makes a reasonable salary if Linux becomes popular, but he's a talented guy and he'd make a reasonable salary anyway. He's not in it for the money, he's in it for the fun.

When you buy a Mac, Steve Jobs gets more money. When you use Linux, Linus doesn't have more fun (if anything, with all your moaning and whinging, he'll have less).

Understand now? There ain't no such thing as a free lunch, and Linus isn't obligated to make you one.

Re:Wonderful. More Stable. ... So?

[spitzak]

The problem is NOT with the IPC. So "gut instinct" might make you know there is a problem, but also leads to wrong conclusions.

There are imho two problems with how X works:

First there is the ICCCM window manager design. This makes it absolutely impossible to have clean updates and resizes of windows because two asyncrhonous processes are updating different parts of the window. Programs that bypass the window manager, such as media players that do it to make windows without borders, work obviously faster and more smoothly, despite the fact that X is otherwise not changed. The real solution to this is to have the toolkits/libraries draw the window borders. Of course then you will run into the luddites who will scream that the user will be "confused" because all their window borders are not exactly the same color. But that is the correct solution, and users don't seem "confused" that buttons are being drawn by local libraies. If this is politically unacceptable, then solutions involving synchronization between the processess, primarily by letting the application call some code to redraw the borders and also having messages to indicate the desired size/position so the app can resize the window and immediately draw, may work. But that is much messier.

The second problem is synchronous calls to the xlib where the program has to wait for an answer (which the program often then throws away, but xlib had no idea it did not need to wait). The result is that latency gets turned into bandwidth. In fact we are fairly lucky that ipc was used because it's latency discouraged this design far more than the Win32 kernel api does, but not enough... I think a lot of this is being addressed with xcb replacing xlib.

Re:Wonderful. More Stable. ... So?

[spitzak]

I said: expand the current functionality with something that simply *must* have better performance. Think laying out functioncalls in shared memory and calling interrupts for local clients. Think transporting events back to the client in the same way. Think painting directly in the frame buffer using shared memory. Actually ipc is the fastest way if designed right. You are ignoring the fact that it can easily send MORE than one message in a single context switch, by buffering them. Windows only got modern speeds by changing as many of the calls as possible to ones that write messages in a buffer, only sending that buffer when a return value or sync is needed. So in some ways the design of X is already the correct one for maximum performance. Pipelines are how graphics hardware runs so fast, you know.

Also, I realize that there are a load of APIs on top of the X client library that paint beautiful (and sometimes less beautiful) widgets, but a) they can't be fast because they wrap both the way in (XCreateWindow) and the way out (XGetEvent), and b) it would be a lot nicer if the X server actually understood what you *meant* when you said: 'make a scrollbar'. It can implement a faultless scrollbar namely. And generate scrollbar specific events. Here you are making a serious mistake. If X had done this from the start, it would be using something that looked like Athena widgets, and it would never be able to change. The reason X can run UI designs that were made 30 years after it was created is precisely because it was designed this way. If you believe that "theming" will magically make an obsolete widget library competitive there are some bridges in Brooklyn I would like to sell to you, too.

Also if you have done any work with talking to window managers or toolkits, you will probably notice that such api's have the annoying tendency to balloon into requiring far more code to talk to the interface than you would require to implement the widgets yourself. You don't want this mess locked into the basic design of your system, you want to be able to replace it when it gets too baroque to use.

With respect to cut-n-paste; they exist in Gnome and KDE. Separately. And also, separately inside WindowMaker and XFCE. It is a royal *bitch* to program against in X client lib, it depends entirely on the cooperation of the various program- and windowmanager-makers and a few conventions, and it is *very* incomplete. Here I agree. Somebody should write a wrapper for that xlib mess which acknoledges the fact that programs just want to treat the cut & paste as a single block of memory, no matter how large it is, and that should be the official xlib cut/paste api. Right now you cannot get it without using a toolkit and sometimes you don't want to use a toolkit, for instance if you want to write your own toolkit.

Graphics are also a huge mess, but Cairo seems to be addressing this.

I like that one

[jackharrer]

Running a pre-release of Fedora 9 on his wife's computer, Linus Torvalds was not able to view YouTube videos with Swfdec, leading him to send a comical error report in which he makes an ardent appeal for help to Fedora developers, "This is 'high' priority because the wife will kill me if she doesn't have her videos."

LOLZ ;)

Re:I like that one

[Arancaytar]

Dear Linus,
From all of us here at the Fedora Project we just wanted you to know we're very
pleased you're testing Fedora 9 and filing bugs. We also wanted to let you know
that we're never gonna give up fixing these bugs.We know when we do our best
we're never gonna let our users down. Sometimes it may feel like it but we're
never gonna give you the run around on these bugs, either. We don't want to
desert you nor you to desert us.

As frustrating as they are we hope we're never gonna make you cry.

Sincerely,
Seth Vidal
Fedora Project Board Member.

Re:I like that one

[superash]

I like the reply to the above comment :

The Board wishes it to be known that:
1. Mr. Vidal has, in the parlance of second-rate spy movies, "gone rogue," and has posted on behalf of the Board without the required routing through several committees, endless cross-posted discussion, and explicit approval, and therefore his pay will be docked accordingly.
2. He is clearly an enormous Rick Astley fan, although he attempts to disguisse this fact through paraphrase.
3. We love you, Linus! *scream*
4. We wish for Mrs. Torvalds not to visit pain upon us, and thus thank our community for stepping in and helping Linus get this bug handled.
5. Because it's Friday, things may get a little silly around here. Oh, and mind the gap.
Paul W. Frields Fedora Project Leader

Re:I like that one

[hey!]

Dear Mr. Torvalds

We appreciate your submission of a bug report for swfdec, and we have submitted it to the maintainers. However we are unable at this point to assign it "high" priority because it appears to be an interaction of a buggy ACPI BIOS with the Intel HDA audio codecs. We refer you to Toshiba for support details.

In the meantime, you may not be aware that the traditional SYSV "inittab" mechanism has been replaced in recent editions of Fedora with the newer "upstart" mechanism. Simply edit the "/etc/event.d/linus" file, specifying that under the appropriate runlevels you should be automatically respawned. This should effectively prevent you from being killed. At least permanently so.

-The Fedora Support Team

A better link to the post is...

[Anonymous Coward]

http://kerneltrap.org/

Re:A better link to the post is...

[Daimanta]

Modding post -1, itsatrap

Re:Black monolith

[Doc Nielsen]

no no they invented this new thing called modules, which you can load and unload. It's really neat! ;D

Almost slashdotted: copy of important stuff below

[Anonymous Coward]

Direct link to Linus' 2.6.25 announcement message

Also kernelnewbies.org seems to be very slow at the moment. Here is a copy of the important changes section from their 2.6.25 changelog page:

1.1. Memory Resource Controller

Recommended LWN article (somewhat outdated, but still interesting): "Controlling memory use in containers"

The memory resource controller is a cgroups-based feature. Cgroups, aka "Control Groups", is a feature that was merged in 2.6.24, and its purpose is to be a generic framework where several "resource controllers" can plug in and manage different resources of the system such as process scheduling or memory allocation. It also offers a unified user interface, based on a virtual filesystem where administrators can assign arbitrary resource constraints to a group of chosen tasks. For example, in 2.6.24 they merged two resource controllers: Cpusets and Group Scheduling. The first allows to bind CPU and Memory nodes to the arbitrarily chosen group of tasks, aka cgroup, and the second allows to bind a CPU bandwidth policy to the cgroup.

The memory resource controller isolates the memory behavior of a group of tasks -cgroup- from the rest of the system. It can be used to:

* Isolate an application or a group of applications. Memory hungry applications can be isolated and limited to a smaller amount of memory.
* Create a cgroup with limited amount of memory, this can be used as a good alternative to booting with mem=XXXX.
* Virtualization solutions can control the amount of memory they want to assign to a virtual machine instance.
* A CD/DVD burner could control the amount of memory used by the rest of the system to ensure that burning does not fail due to lack of available memory.

The configuration interface, like all the cgroups, is done by mounting the cgroup filesystem with the "-o memory" option, creating a randomly-named directory (the cgroup), adding tasks to the cgroup by catting its PID to the 'task' file inside the cgroup directory, and writing values to the following files: 'memory.limit_in_bytes', 'memory.usage_in_bytes' (memory statistic for the cgroup), 'memory.stats' (more statistics: RSS, caches, inactive/active pages), 'memory.failcnt' (number of times that the cgroup exceeded the limit), and 'mem_control_type'. OOM conditions are also handled in a per-cgroup manner: when the tasks in the cgroup surpass the limits, OOM will be called to kill a task between all the tasks involved in that specific cgroup.

Code: (commit 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12)

1.2. Real Time Group scheduling

Group scheduling is a feature introduced in 2.6.24. It allows to assign different process scheduling priorities other than nice levels. For example, given two users on a system, you may want to to assign 50% of CPU time to each one, regardless of how many processes is running each one (traditionally, if one user is running f.e. 10 cpu-bound processes and the other user only 1, this last user would get starved its CPU time), this is the "group tasks by user id" configuration option of Group Scheduling does. You may also want to create arbitrary groups of tasks and give them CPU time privileges, this is what the "group tasks by Control Groups" option does, basing its configuration interface in cgroups (feature introduced in 2.6.24 and described in the "Memory resource controller" section).

Those are the two working modes of Control Groups. Aditionally there're several types of tasks. What 2.6.25 adds to Group Scheduling is the ability to also handle real time (aka SCHED_RT) processes. This makes much easier to handle RT tasks and give them scheduling guarantees.

Documentation: sched-rt-group.txt

Code: (commit 1, 2, 3, 4)

There's serious interest in running RT tasks on enterprise-class hardware, so a large number of enhancements t

Behold! Thus sayeth Linus!

[Anonymous Coward]

And a collective orgasm was released from the entire Lunix community.

It's a kernel, not an OS

[H4x0r Jim Duggan]

"numerous changes in this revision of the OS"

Asking people to call it GNU/Linux is one thing, but it's not much to ask Slashdot not to call a kernel changelog an OS changelog.

CIFS

[Chemisor]

Has anyone noticed the forced CIFS migration warning yet? Do you have some links on how to do that? I mean just the obvious two things of being able to mount a remote windows share (preferably without being root), and setting up CUPS for printing to a windows-shared printer. All I see on Google are technical articles about the protocol.

Re:CIFS

[neersign]

i'm not 100% sure on what you're asking, but I'm guessing you are trying to change from smbfs to cifs, which isn't a big deal. Go in to the kernel config and select "CIFS", deselect "SMBFS" (you can have both selected, but there is no need), recompile, reboot. more details: http://www.gentoo-wiki.com/HOWTO_Setup_Samba

Re:Black monolith

[X.25]

Ok, so is it still a big monolithic kernel that we need to recompile every time we need to load a driver into kernel-space?

You're the proof that time travel is possible.

Re:Behold! Thus sayeth Linus!

[LingNoi]

I'm confused. I thought Linus worked on Linux, not Lunix

exec mode

[Sobrique]

I'm really looking forward to 'exec mode'. It's an awesome kernel feature that pipelines applications for faster execution. It's still experimental though, so you've got to enable it.

It's an option in your system profile (usually /etc/profile).

Just add 'exec true' in there, and it'll start using the prefetch code. OK, so it's not a huge performance boost, but I'll take a free 5-7% any day of the week.

I think you can do it as a non-privileged user by adding it to your 'personal' profile (.profile or .bashrc typically) but obviously it's not then affecting the core system processes.

Re:exec mode

[Anonymous Coward]

Funny. How about -1, wrong audience?

For the uninitiated: placing 'exec true' in your profile renders you unable to open a terminal (on 99% of linux desktops that use bash as shell)

(heh. Captcha: lecture)

CAN support! Yay!

[fgaliegue]

Linux can now be used to debug your car's network - provided a hardware interface exists.

If it doesn't, I bet it will not be long before someone implements one. And since CAN is used in pretty much every automation in modern cars, who knows. "An open firmware for your Passat", anyone?

calling a kernel a kernel

[H4x0r Jim Duggan]

No one runs "just a kernel" on their phone. Look at OpenMoko, they use GNU libc just like Debian and Fedora do.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Apple? OSX? 3d acceleration???

[myowntrueself]

Granted X11 has improved in the areas of 3d acceleration and such. But compared to OS X it is lacking

If Apple cared about 3d acceleration in OS X, they'd put decent graphics cards into their computers.

They don't.

In fact they sell you graphics cards which are crap for 3d applications, compared to what is available.