Stable kernel 2.6.25 released

Wow, I look forward to having that on my machine. 

Finally... I can't tell you how much that annoyed me (and similar hangs) in the last 10
years...

For what it's worth, the sysadmins at work literally jumped for joy when 
they heard of this. (This is using the word 'literally' correctly, too, 
rather than the too-common usage meaning 'not literally': they jumped up 
and down.)

That is an amazingly useful feature. Kudos.

> Now, just press ^C, ls will die and you get
> your prompt back.

Willy, you say ^C (i.e., SIGINT), but looking at fatal_signal_pending() the only signal that
seems to be matched is SIGKILL, so I'd have thought ^C wouldn't be sufficient.  What am I
missing?

to answer your final question (why are drivers in X instead of the kernel)

it basicly boils down to historic reasons, it's always been done that way.

X works on many different systems with different kernels and it used the same drivers on all
of them.

there's work being done currently to define an interface between kernel drivers and X that
will shift this boundry significantly, but they will need to keep much of the old code around
to support other (and older) systems

> [W]hy are graphics drivers being included in
> X.org instead of directly in the kernel?

The following is based on what I've read as I've followed X events myself, 
not on any particular first-hand knowledge I have, as I most certainly 
don't, at least in this area!  If aspects or even the entire picture are 
wrong, please, someone correct me!

This is to a large degree historical legacy.  X11 thru xfree86 and 
therefore its in-practice successor xorg were/are designed to be a 
specific platform agnostic *ix graphics interface.  As such, formerly, the 
push was to keep for-the-most-part unified drivers in X, only putting in 
the various kernels enough functionality to expose the hardware interface, 
interrupts and etc, to the user-space X.  Back when X was more a 
networkable protocol with remote (from the user perspective) client and 
local server aspects and less a direct driver of the 3D hardware common 
today (to the point where 2D is legacy and now not necessarily included at 
all, the 3D hardware handles it), that made a lot of sense.

Today, as direct (and therefore local) 3D hardware interaction becomes 
more important, with extension support now and planned traditional X 
emulation on 3D OpenGL direct implementations a generation or two in the 
future, the latency and other issues related to all those kernel/userspace 
transitions now necessary to directly access that hardware are taking 
their toll, and the push is in the opposite direction.  Development into 
the future is pushing toward each platform implementing its own native 
drivers and code, with higher level common "stub" drivers in X.  As 
mentioned, this is likely to take the form of kernel drivers implementing 
OpenGL directly on the hardware, while exposing a common interface to 
software, both 2D/3D direct, likely mostly in the kernel, and a 
traditional 2D X, likely implemented mostly in X as a mini-driver 
interfacing with the kernel drivers.

Note that a specific goal of this transition is to maintain and actually 
improve X's traditional network transparency.  By design, it's not going 
away anytime soon.  One improvement will be that due to the layering, it 
should actually be possible (over a suitable link and with a certain loss 
in speed, but acceptable in certain applications none-the-less) to do 3D 
over the network as well, while that aspect is currently extremely 
limited.  The effect is likely to be somewhat like trying to run software 
3D today, limited and slower than direct hardware access 3D, but it'll be 
possible, where it basically isn't today.

However, that's a way off still, with a number of intermediate steps in 
the middle.  Linux and the BSDs (among others, Solaris, OSX...) will need 
to gradually increase their driver functionality in step with xorg's 
development (and xfree86 still exists too, AFAIK, with at least some of 
the BSDs having moved rather more slowly to xorg and only now defaulting 
to it, with both still options) and exposure of mini-drivers and a new 
common direct hardware access OpenGL API that the kernel drivers can all 
be written to implement on their side of the interface.  We're talking 
several years of effort, on a journey that's likely to have various 
unexpected twists and turns of its own, such that the eventual 
implementation may not look much like it has been described here at all, 
altho chances are it'll be fairly close and only in the journey will we 
find the necessary different paths that end up being taken.

Confusing to the newbie it certainly can be, but that's what I've gathered 
from the various articles I've read.  Hope it clarifies things a bit for 
you as it has for me.

Duncan

What does this mean, exactly, for someone who set up a Fedora 8 server with software raid1
using the standard tools in anaconda?  Have I not been getting read balancing, but will get it
when F8 moves to 2.6.25?