Slashdot Mirror

What if (for example) the kernel interfaces change, and your statically linked library is now interacting wrongly with the kernel? Certainly not everyone thinks static linking is a good idea, just for reasons such as this.

yes; have a look at http://www.redhat.com/ - you'll find some nooks and crannies left from a previous table-based design, but the majority of the site is pure css with not a table to be seen.

The Novell-MS "protection" is simply worthless compared to what RH has to offer. On top of that, FSF is going to release glibc/gcc/etc. under GPL v3 - which will explicitly prohibit MS-Novell deals. Which means, that in probably less than a year, Novell will be in a legal poopoo, or will remain stuck with the latest glibc that was released under GPL v2 - in other words, it will be at a technological disadvantage compared to other distroes. Actually, it is Novell whose days are numbered, not RH (especially with SUN's GPLing java, and RH owning Jboss!)

If your business' products are entirely reproducible and then sold for cheap, you cannot sustain a living in such a place.

If it bothers you so much, why not try an alternative?

Fedora Core
Ubuntu
Debian
SUSE
Mandriva
Slackware
Gentoo

or any of these?

Or Mac, or BSD, or even Solaris? There's no shortage of options

Uh, get the software images from http://olpc.download.redhat.com/olpc/streams/devel opment/. They are developed on modern hardware. You can run the images from a livecd, a usb memory card or qemu on a host system but the best test would be on the hardware itself. There is need to optimize and make sure the correct drivers get loaded and that the drivers work. You don't just put software on any old hardware platform and it just works. A lot of engineering goes into it.

Did you really just compare Gandhi's fight for freedom from British rule in India to the OS "wars"?

What... you've never seen "Truth Happens"?

http://www.redhat.com/truthhappens/videos/ourfilms .html

Q: Did Red Hat consider a similar patent deal with Microsoft?
A: An innovation tax is unthinkable. Free and open source software provide the necessary environment for true innovation. Innovation without fear or threat. Activities that isolate communities or limit upstream adoption will inevitably stifle innovation.

Q: What's Red Hat's position on interoperability?
A: Our business has always been based on open standards and interoperability.
Open standards create interoperability everyone can implement. That's the real solution. It doesn't require a deal between two companies.

And this is why programmers should not try to be lawyers.

FYI, that act would be illegal. See Red Hat's trademark policy for details.

As long as I work on the Fedora Project, Fedora will never compromise on the essential liberties of FOSS nor will it betray the community. But the price of liberty is not free, nor is it comfortable. And unfortunately, some "leaders" of our community are willing to compromise liberty for short-term convenience. I am disgusted by people like this, and by Novell's betrayal of the community today.

Novell has effectively traded Long-Term Liberty for Short-Term Safety.

Red Hat supports causes that matter like providing the original seed money for Creative Commons. Or being a key partner in the anti-software patent movement during the miraculous last-minute turnaround at the European Parliament last year. I am proud to be part of an organization that demonstrates such moral and ethical commitment.

But ultimately, Red Hat cannot change the world alone. That is why the Fedora Project exists. We want to enable the community to work together to improve FOSS at a rapid pace, in partnership with the large and consistent contributions from our engineers. We strongly believe that this is the most effective way for the entire FOSS movement to advance. Yes, we made some big mistakes in our community relationship earlier, but we are learning, and continue to improve at an ever accelerating pace.

For these reasons that I urge the FOSS community to support the Fedora Project through volunteer contributions of time and effort. Or if you lack time to contribute, please consider monetary donations toward any of the shared causes that we are fighting for.

http://wtogami.livejournal.com/11305.html
Please read more in the original version in this blog entry.

Warren Togami
Founder, Fedora Project
Software Engineer, Red Hat, Inc.

Who do you think is "the kernel developers" ?
It's mostly RedHat, Novell, and many other companies ...
And there's many other important free software that every distro include which are mainly developed by RedHat employes.
Have a look at http://www.redhat.com/truthhappens/leadership/osde velopment/

I think the bigger news from this article is the fact that RedHat is now offering indemnification for its customers. They slipped this into their FAQ now as well ( http://www.redhat.com/promo/believe/). While I think their hand was forced a bit on this one in order to remain competitive with where the market seems to be going, its still welcome news. This has been a significant hurdle for many companies even considering whether to adopt open source. As it becomes more widespread and "the norm" that you do not need to worry about legal hassles for running Linux, more companies will consider the switch.

I do have a retail CD of Windows XP (pre-SP1) that I bought early 2002, and forked real money for. If I put it in my drive and it doesn't let me install "because I need SP2", pray tell me where I can download the ISO for the CD I need without having to pay more money.

Try a FC4 CD with a brand new raid card and see if it recognises it. What do you do when it doesn't?

I'll go to the Fedora website and get the latest installer for free.

http://www.groklaw.net/article.php?story=200611021 75508403
"Novell has effectively traded Long-Term Liberty for Short-Term Safety."
- me 2006/11/02

The Primary Goal of the Fedora Project:
Rapid Progress of Free & Open Source Software.

Red Hat engineering invests millions every year in FOSS development. These developers contribute in a great many ways to stimulate growth in the FOSS ecosystem and the community itself. Red Hat makes this investment for three key reasons:

• It makes business sense: A healthy relationship with community builds quality products faster, and with lower expense. It is indeed possible to make money and not compromise on values.
• Perhaps the technology leaders who made many of these key FOSS improvements are best able to support business customers.
• Many of the people at Red Hat believe in the ethical values of FOSS and the benefit that it brings to society.

As long as I work on the Fedora Project, Fedora will never compromise on the essential liberties of FOSS nor will it betray the community. But the price of liberty is not free, nor is it comfortable. And unfortunately, some "leaders" of our community are willing to compromise liberty for short-term convenience. I am disgusted by people like this, and by Novell's betrayal of the community today.

Red Hat supports causes that matter like providing the original seed money for Creative Commons. Or being a key partner in the anti-software patent movement during the miraculous last-minute turnaround at the European Parliament last year. I am proud to be part of an organization that demonstrates such moral and ethical commitment.

But ultimately, Red Hat cannot change the world alone. That is why the Fedora Project exists. We want to enable the community to work together to improve FOSS at a rapid pace, in partnership with the large and consistent contributions from our engineers. We strongly believe that this is the most effective way for the entire FOSS movement to advance. Yes, we made some big mistakes in our community relationship earlier, but we are learning, and continue to improve at an ever accelerating pace.

For these reasons that I urge the FOSS community to support the Fedora Project through volunteer contributions of time and effort. Or if you lack time to contribute, please consider monetary donations toward any of the shared causes that we are fighting for.

Contribute to Fedora
The Fedora Project needs your contributions in many ways. If you know how to make RPM packages, you can become a maintainer in Fedora Extras where you can contribute your favorite FOSS software into the central repository for all to benefit. We have many opportunities for even non-developers to get involved. We need help with things like Documentation, Artwork, or promoting Fedora in the Ambassadors team. Even simply using Fedora, responsibly reporting bugs in Bugzilla, and helping each other helps the entire community.

Donations
The Fedora Project does not need your money[1], but I hope that you would consider donating to one of the major charities that fight for your liber

I don't think Red Hat's financial model relies much on people who used to buy a set of CDs for their home computer, and Oracle is even less interested in that market.

It's my understanding that the boxed sets were a consisent money loser for Red Hat.

Given the amount that they invest that benefits ALL distributions I'd rather see Red Hat continue to survive as a profit-making good-player in the community.

They've done a lot of good by: hiring people that hack the kernel, help to write the Free Java stuff (classpath and gcj), pretty much pay for the development of gcc (through what used to be Cygnus), have purchased and Free'ed what was Netscape Directory Server (now http://www.redhat.com/solutions/directoryserver/ Red Hat Directory Server and Fedora Directory Server http://directory.fedora.redhat.com/ ) and consistently refuse to include patent-encumbered crap in their distribution.

They also provide a very visible rebuttal to anyone that says you can't make money with a Free operating-system. They show that Free Software makes good business sense and that a business can be built on providing excellent service and nurturing the rest of the community.

I think it's in everyone's interest that Red Hat stays out of the clutches of the asshats in Oracle.

I don't think Red Hat's financial model relies much on people who used to buy a set of CDs for their home computer, and Oracle is even less interested in that market.

It's my understanding that the boxed sets were a consisent money loser for Red Hat.

Given the amount that they invest that benefits ALL distributions I'd rather see Red Hat continue to survive as a profit-making good-player in the community.

They've done a lot of good by: hiring people that hack the kernel, help to write the Free Java stuff (classpath and gcj), pretty much pay for the development of gcc (through what used to be Cygnus), have purchased and Free'ed what was Netscape Directory Server (now http://www.redhat.com/solutions/directoryserver/ Red Hat Directory Server and Fedora Directory Server http://directory.fedora.redhat.com/ ) and consistently refuse to include patent-encumbered crap in their distribution.

They also provide a very visible rebuttal to anyone that says you can't make money with a Free operating-system. They show that Free Software makes good business sense and that a business can be built on providing excellent service and nurturing the rest of the community.

I think it's in everyone's interest that Red Hat stays out of the clutches of the asshats in Oracle.

See Red Hat's patent policy. Consider their "promise": Red Hat agrees to refrain from enforcing the infringed patent. It's not a license, it's not irrevocable, it's not even a hard promise: it's just an indication that the present owners of Red Hat probably won't sue you for infringing their patents today.

So, does anyone think that Oracle will feel bound by this "promise" if they buy Red Hat?

So, the way to achieve this is by changing contents in the pagefile by writing disk sectors directly.
 
This problem on Vista isn't newly discovered. It was discussed here earlier this month, in fact.

Great. A link to a site that takes forever to load, just for very minimal (maybe 1K of essentially nothing) content, and a link to RH's Unfakeable page, which is http://www.redhat.com/promo/unfakeable/, and loads fast. Other RH content worth looking at is http://www.redhat.com/truthhappens/. Links off that last page include a breakdown of cost 'savings' by Dave Dargo, who developed Oracles licensing strategy, etc.

Poster must be pimping for osdir or something.

Great. A link to a site that takes forever to load, just for very minimal (maybe 1K of essentially nothing) content, and a link to RH's Unfakeable page, which is http://www.redhat.com/promo/unfakeable/, and loads fast. Other RH content worth looking at is http://www.redhat.com/truthhappens/. Links off that last page include a breakdown of cost 'savings' by Dave Dargo, who developed Oracles licensing strategy, etc.

Poster must be pimping for osdir or something.

I'm going to loose my mod point for this, but I think I found another copy at redhat.

ols2006.108.redhat.com reprints jones-reprint.pdf

Better download just the paper itself instead of the full proceedings.

BTW, newsforge has a report about the presentation as well.

--
Ademar http://www.ademar.org/

http://www.redhat.com/promo/unfakeable/

"The Red Hat database is not a defunct product. It has been deemphasized..." OK, deemphasized. Fairly well, too, as I see no mention of it at http://www.redhat.com/solutions/. The "Storage Solutions" link, chased out of curiosity (only thing I could find by direct nav), led only to RH GFS. Appropriate from the link text, and a sweet FS. But it wasn't the RH DB, and that's as close as I came to a link.

"RH is profitable, and its revenues are increasing." What's more, it's market cap is still very high. If Oracle wants to pay that sort of money for a Linux distribution then that's good news for folks in the Linux business." Something like a $0.5-1.0^9 got pealed off the market cap to day. Didn't check the closing price. But what's at stake here is the entire premise of those 'increasing revenues', given that RH sells support, and the second largest software company in the world has declared support war on them. I think there's cause for concern about that.

I definitely don't buy into the RH PR line about how this is good for RH (or did they just say Linux?), as stated at http://www.redhat.com/promo/unfakeable/
but that same link goes into some detail from RH that's pretty informative, and indicates that not all is doom and gloom for RH. To me, Ellison seemed at least to be just deploying his vaunted mad media skilz.

I guess we'll see. Overall, I'd far rather see RH get through this.

"The Red Hat database is not a defunct product. It has been deemphasized..." OK, deemphasized. Fairly well, too, as I see no mention of it at http://www.redhat.com/solutions/. The "Storage Solutions" link, chased out of curiosity (only thing I could find by direct nav), led only to RH GFS. Appropriate from the link text, and a sweet FS. But it wasn't the RH DB, and that's as close as I came to a link.

"RH is profitable, and its revenues are increasing." What's more, it's market cap is still very high. If Oracle wants to pay that sort of money for a Linux distribution then that's good news for folks in the Linux business." Something like a $0.5-1.0^9 got pealed off the market cap to day. Didn't check the closing price. But what's at stake here is the entire premise of those 'increasing revenues', given that RH sells support, and the second largest software company in the world has declared support war on them. I think there's cause for concern about that.

I definitely don't buy into the RH PR line about how this is good for RH (or did they just say Linux?), as stated at http://www.redhat.com/promo/unfakeable/
but that same link goes into some detail from RH that's pretty informative, and indicates that not all is doom and gloom for RH. To me, Ellison seemed at least to be just deploying his vaunted mad media skilz.

I guess we'll see. Overall, I'd far rather see RH get through this.

Red Hat Enterprise Linux is really just a rebraded version of Fedora Core.

http://www.redhat.com/fedora
"The Fedora Project is a Red Hat sponsored and community supported open source project."

This move by Oracle may make The Fedora Project something Red Hat can't financially maintain, or at least not alone. If you watched Ellison's speech, the first half of it was to attack the mainframe hardware market and replace it with PC Linux grids which is a direct threat to IBM who has been aggressively trying to revive the mainframe hardware market.

So what if Red Hat didn't sponsor The Fedora Project anymore? Their business model is based on supporting Linux, not developing it which is The Fedora Project. Maybe a company like IBM will start to support The Fedora Project and we'll start to see grid computing mainframes.

"The vendors aren't offering indemnification, Ellison said, and because of SCO, there's all this uncertainty and doubt about intellectual property. He says he will offer indemnification. In the Q&A at the end, he was asked if Oracle was planning to buy SCO to bring that uncertainty to an end. No, was the answer.

"Red Hat has a separate indemnification policy. In Red Hat's case, this policy is called the Open Source Assurance program."

Presumably if Larry really believed the SCO case had any validity he wouldn't even consider using RHEL. And in relation to RHEL and the GPL what's stopping anyone buying a single copy of Oracle Linux and repackage it and selling it with support contracts. Presumably if Larry doesn't allow this then Oracle is in breach of the license.

"We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software"

Hi
Red Hat seems to have replied:

http://www.redhat.com/ with Linux Unfakeable, with info located at: http://www.redhat.com/promo/unfakeable/

Nice arguments there ;)

Hi
Red Hat seems to have replied:

http://www.redhat.com/ with Linux Unfakeable, with info located at: http://www.redhat.com/promo/unfakeable/

Nice arguments there ;)

Unfakeable Linux

Check your facts

I have not checked the prices of comparable RedHat and Microsoft server offerings. It turns out that RedHat is still cheaper, but by a trivial amount. Compare the RedHat Store (see: Server Operating System Products) and Windows Server 2003 R2 Pricing. (Wouldn't it be nice if Slashdot support post annotation or editing?)

At any rate, Windows might still be a superior server platform thanks to the effectiveness of ActiveDirectory, fine-grained ACL, and so on. I am no Windows apologist (on the contrary, quite the advocate of open source solutions), but I fear Microsoft may be leaping far ahead of their competition in this space.

Just like http://fedora.redhat.com/

is it just me or does it seem odd to have a "pretty thorough review" considering it's only been released for an hour?

I'm sure you created bug reports for all the issues you encountered, correct ? They all have bug numbers at bugzilla , right ?

Funny, but you can do this:
http://fedoraproject.org/wiki/YumUpgradeFaq

Simply use this rpm instead of the one on that site.
http://download.fedora.redhat.com/pub/fedora/linux /core/6/i386/os/Fedora/RPMS/fedora-release-6-4.noa rch.rpm

Dont forget to do yum update before and after.

From the Firefox maintainer for Fedora-

The message was from f-d-l on 14 Oct 2006 12:33:35.

It's traditional for us to have some sort of "whimsical" or "funny" release announcement that accompanies all of the serious stuff. The full link to it is here:

https://www.redhat.com/archives/fedora-announce-li st/2006-October/msg00008.html

Stallman's arguement that, "one is allowed to charge for GPL'd software" is laughable at best and hippocritical at worse, since what individual would pay for something he can get for free?

Ask a company like Red Hat how they make money by selling free software. No, it's not just by selling services...

Encrypting your whole disk on Linux is somewhere between a minor pain and a complete nightmare. Support for it doesn't even exist on certain high-profile commercial distros (Red Hat) which you would THINK would have had it long ago because it's something their customers would want.

I had to put together my own unofficial packages to get an encrypted root filesystem on Fedora Core 5. (And then it broke on FC6, so no upgrading yet...) In theory, the support will officially be in Fedora Core 7, but there's still a bunch of code to be written between now and then.

On Linux, address space randomisation is done by various kernel patches which aren't selinux related. Red Hat uses execshield (which went mainline around 2.6.11) but there have been patches from PaX which also implemented it. See RH Mag on Execshield and Wikipedia's address space layout randomisation article.

Online hard disk resizing. This has only recently (last two years) been possible on Linux and is filesystem dependent (on ext3 you need to have made your partitions within LVM, I think reiser3 can online grow even with regular partitions) I've not been aware of an NTFS online resizer until now though. I will also point out that your school (and probably you) are at some point paying for all that "free" MS software though.

As for ACPI under Linux - there can be a whole stack of issues, some which are related to various BIOSes only looking for XP (and now Vista) and enabling/disabling various features depending on what they find. It is true that putting devices into low power mode doesn't tend to happen by default on Linux though. Power consumption will also be helped when the tickless/dyntick kernel patches arrive.

Duuuuuude, just ask John Titor. Time Machines are SO real. The aliens are waiting for us in the 5th dimension. Let's go! Come on, LET'S GOOOOOOOOooooooooooooooo!!!!!11111111111111111111. .............

err... Whoa, I did NOT see that one coming. Damn acid flashbacks. Where was I? Ah yes, back to running kubuntu with 2.6.18-rt5 :P

(This has to be one of the weirder posts I have written on Slashdot.)

I have a question about the new mutex features: what glibc version is required to use this stuff? do I need other user space libraries?

The latest upstream glibc version (2.5) has it:

* Support for priority inheritance mutexes added by Jakub Jelinek and Ulrich Drepper.
* Support for priority protected mutexes added by Jakub Jelinek.

(See: http://sources.redhat.com/ml/libc-alpha/2006-09/ms g00065.html )

No other userspace library is needed.

I hate saying things like that. I'm a geek and I'm proud of it, and therefore want Linux to have the maximum flexibility possible. However, poorly maintained code is worse than no code at all, and there just isn't the userbase to keep hard real-time in the kernel at an acceptable standard.

We have good news for the geek in you: the upstream Linux kernel is already more than 50% on the way to become hard-realtime :-)

The 2.6.19-rc2 kernel already includes the following features/subsystems, which are the precondition of hard-realtime (PREEMPT_RT):

- the generic interrupt code (genirq)
- the generic time of day subsystem (GTOD)
- the hrtimers subsystem
- the lock validator (lockdep)
- the generic spinlock code
- priority inheritance enabled mutexes
- robust and PI-futexes
- SRCU
- the mutex subsystem
- irq handler prototype simplification (removal of pt_regs)
- (and more stuff that escapes my mind right now)

Most of these features were written for and prototyped in the -rt tree and were split out and merged individually. (they all have other uses besides serving a hard-real-time kernel, so their merging was largely uncontroversial)

Granted, there's still 1.4+ MB of patches pending in our 2.6.18 based -rt tree (such as the core bits of PREEMPT_RT, irq threading, high-res timers, dynticks and more), but roughly the same amount of code has been merged upstream already, and we can now see the end of the tunnel.

In fact, i'd say that the most controversial ones are already merged and the flamewars are largely over: such as the generic mutex code (which replaced semaphores half a year ago in 2.6.16/17) or the priority inheritance and rt-mutex code (which is now in 2.6.18).

ADEOS - the microkernel used in RTAI - is "hard real-time", as is VxWorks. TimeSys' Linux patches are soft real-time.

Small correction: if by "TimeSys' Linux patches" you mean the -rt patchset that i'm maintaining (and to which Thomas is a major contributor), and in particular if you mean the CONFIG_PREEMPT_RT kernel feature, then the answer is a clear "no": it's not "soft real-time", it's intended to be "hard real-time" in the same sense as ADEOS/RTAI is.

The -rt patch-set implements a fully preemptible Linux kernel, which allows a higher-prio event to preempt any lower-prio processing: it can preempt device driver interrupt processing or other "irqs off" critical sections or other normally non-preemptible (for example spin-locked) code within the kernel, immediately. (it does all the necessary hard-real-time things one would expect: it pushes interrupt processing into special kernel threads, it implements priority inheritance for all Linux locking primitives to guarantee processing and to get out of priority inversion scenarios, etc.)

See more about the technology behind the -rt patchset in Paul McKenney's article on LWN.net, and on Kernel.org's RT Wiki. You can also try out an -rt kernel based Linux distribution yourself, grab a Knoppix-based PREEMPT_RT-kernel live-CD from: here.

RT has a pretty big speed penalty.

I can definitely say that unlike some other approaches, the -rt Linux kernel does not introduce a "big speed penalty".

Under normal desktop loads the overhead is very low. You can try it out yourself, grab a Knoppix-based PREEMPT_RT-kernel live-CD from here: http://debian.tu-bs.de/project/tb10alj/osadl-knopp ix.iso.

From early on, one of our major goals with the -rt patchset (which includes the CONFIG_PREEMPT_RT kernel feature that makes the Linux kernel "completely preemptible") was to make the cost to non-RT tasks as small as possible.

One year ago, a competing real-time kernel project (RTAI/ipipe - which adds a real-time microkernel to 'above' Linux) has done a number of performance tests to compare PREEMPT_RT (which has a different, "integrated" real-time design that makes the Linux kernel itself hard-real-time capable) to the RTAI kernel and to the vanilla kernel - to figure out the kind of overhead various real-time kernel design approaches introduce.

(Please keep in mind that these tests were done by a "competing" project, with the goal to uncover the worst-case overhead of real-time kernels like PREEMPT_RT. So it included highly kernel-intensive workloads that run lmbench while the box is also flood-pinged, has heavy block-IO interrupt traffic, etc. It did not include "easy" workloads like mostly userspace processing, which would have shown no runtime overhead at all. Other than the choice of the "battle terrain" the tests were conducted in a completely fair manner, and the tests were conducted with review and feedback from me and other -rt developers.)

The results were:

LMbench running times:

| Kernel............ | plain | IRQ.. | ping-f| IRQ+p | IRQ+hd|

| Vanilla-2.6.12-rc6 | 175 s | 176 s | 185 s | 187 s | 246 s |
| with RT-V0.7.48-25 | 182 s | 184 s | 201 s | 202 s | 278 s |

(Smaller is better. The full test results can be found in this lkml posting.)

I.e. the overhead of PREEMPT_RT, for highly kernel-intensive lmbench workloads, was 4.0%. [this has been a year ago, we further reduced this overhead since then.] In fact, for some lmbench sub-benchmarks such as mmap() and fork(), PREEMPT_RT was faster.

(Note that the comparison of PREEMPT_RT vs. I-pipe/RTAI is apples to oranges in terms of design approach and feature-set: PREEMPT_RT is Linux extended with hard-realtime capabilities (i.e. normal Linux tasks get real-time capabilities and guarantees, so it's an "integrated" approach), while ipipe is a 'layered' design with a completely separate real-time-OS domain "ontop" of Linux - which special, isolated domain has to be programmed via special non-Linux APIs. The "integrated" real-time design approach that we took with -rt is alot more complex and it is alot harder to achieve.)

See more about the technology behind the -rt patchset in Paul McKenney's article on LWN.net, and on Kernel.org's RT Wiki.

Linux has made major progress in the real-time area. But it still doesn't have everything needed.

Many drivers are still doing too much work at interrupt level. There are drivers that have been made safe for real time at the millisecond level, but that's not universal. Load a driver with long interrupt lockouts and your system isn't "real time" any more. This is the biggest problem in practice. There are too many drivers still around with long interrupt lockouts.

That's where my -rt patchset (discussed by Thomas in the article), and in particular the CONFIG_PREEMPT_RT kernel feature helps: it makes all such "interrupt lockout" driver code fully preemptible. Fully, totally, completely, 100% preemptible by a higher-priority task. No compromises.

For example: the IDE driver becomes preemptible in its totality. The -rt kernel can (and does) preempt an interrupt handler that is right in the middle of issuing a complex series of IO commands to the IDE chipset, and which under the vanilla kernel would result in an "interrupt lockout" for several hundreds of microseconds (or even for milliseconds).

Another example: the -rt kernel will preempt the keyboard driver right in the middle of sending a set of IO commands to the keyboard controller - at an arbitrary instruction boundary - instead of waiting for the critical section to finish. The kernel will also preempt any network driver (and the TCP/IP stack itself, including softirqs and system-calls), any SCSI or USB driver - no matter how long of an "interrupt lockout" section the vanilla kernel uses.

Is this hard technologically? Yes, it was very hard to pull this off on a general purpose OS like Linux (the -rt kernel still boots a large distro like Fedora without the user noticing anything) - it's the most complex kernel feature i ever worked on. I think the diffstat of patch-2.6.18-rt5 speaks for itself:

613 files changed, 22401 insertions(+), 7903 deletions(-)

How did we achieve it?

The short answer: it's done via dozens of new kernel features which are integrated into the ~1.4MB -rt patchset :-)

A longer technical answer can be found in Paul McKenney's excellent article on LWN.net.

An even longer answer can be found on Kernel.org's RT Wiki, which is a Wiki created around the -rt patchset.

It was all just a big misunderstanding - she was talking about the global file system...

For those that have a problem with this, is it the cost or the principle of the matter? If it cost $50 instead of $500, would that change your mind?

Soytainly. A price of $50 per year for small businesses, including sole proprietorships, would be much more palatable. That's less than the price of a Windows OS license for two developer workstations over the three- to five-year life span of a Windows major release. It would be much easier for low-volume hardware makers to recover such a reduced fee from their customers.

If you care deeply about principles, you know where to find them.

• Fix No 1
• Fix No 2

Get with the program? Are you serious? Should we not patch Linux either? How 'bout X?

You should read Matthew Garrett's recent blog entry about why it's a good thing (for the Mozilla Corp, Debian, and the user community at large) for Debian (or anybody else) to be allowed to distribute patches. http://mjg59.livejournal.com/68112.html

Also, you should probably read this post to the Fedora devel list that shows that Mozilla's trademark policies are a real problem not just for Debian but for other distributors as well.

noah