Slashdot Mirror

It should be possible to get the source code to ionice and look at that. The other big thing I would like to see in the task manager is the ability to identify which window belongs to which task.
Look at the source code to ionice at ftp://ftp.kernel.org/pub/linux/utils/util-linux/te sting/util-linux-2.13-pre7.tar.bz2
It contains code to set and get the IO nice properties.

Linux users do not have to pay for software

There, I fixed your purposeful omission it for you.

take responsibility for your own needs and write the software you want.

Isn't free software up to the challenge?

Where have you been for the past twenty years?

Linux kernel developers use this:

http://www.kernel.org/pub/software/devel/sparse/

That condition is not a whim, is the only mechanism known to work to protect Free as in Speech in software. Free code as in the BSD and MIT licenses is how software was created at the beginning, and it quickly derived into an incompatible set of compiting closed, proprietary systems.

Yeah, it was awful. All the BSDs went away, and nobody used their code anymore.

Seriously, though, the BSD license has worked out well for many projects. I don't know who said this, but "the goal of the GPL is to make all software free; the goal of the BSD license is to make all software better."

Components of one of my GNU/Linux installations, their functions, and their sources:

• Linux; kernel; Linus Torvalds, et al.
• GRUB; bootloader; GNU Project
• coreutils; core operating system components (e.g.: unix commands) contained in fileutils (chgrp, chmod, chown, cpdd, df, dir, dircolors, du, install, ln, ls, mkdir, mkfifo, mknod, mv, rm, rmdir, sync, touch, vdir), shellutils (basename, chroot, date, dirname, echo, env, expr, factor, false, groups, hostname, id, logname, nice, nohup, pathchk, printenv, printf, pwd, seq, sleep, stty, su, tee, test, true, tty, uname, users, who, whoami, yes), and textutils (cat, cksum, comm, csplit, cut, expand, fmt, fold, head, join, md5sum, nl, od, paste, pr, ptx, shalsum, sort, split, sum, tac, tail, tr, tsort, unexpand, uniq, wc); GNU Project
• grep; regular expression parser; GNU Project
• bash; command shell (enables utiliziation of coreutils); GNU Project
• nano; text editor (yes, operating systems contain text editors); GNU Project
• Emacs; text editor, etc.; GNU Project
• gcc; compiler collection; GNU Project
• make; compilation assisting tool; GNU Project
• patch; patching tool; GNU Project
• gdb; debugger; GNU Project
• gawk; string manupulation language; GNU Project
• sed; text stream editor; GNU Project
• finger; user info; GNU Project
• cron; scheduling; GNU Project
• parted; partition editor; GNU Project
• tar; archiving; GNU Project
• gzip; file compression; GNU Project
• GnuPG; asymmetric key cryptography; GNU Project
• less; paginator; GNU Project
• ncurses; text display tool; GNU Project
• screen; multi-terminal utility; GNU Project
• time; time-reporting tool; GNU Project
• wget; file downloader; GNU Project
• which; executable path tool; GNU Project

That's not counting all of the libraries, GNOME, or GUI tools (Nautilus, et al.). If you count--at minimum--GNOME and X, then you may add GNOME (GNU Project) and X.org (X.Org Foundatio

and surprising to me at the same time - HP always seemed to be "one of the good guys", fostering and supporting GNU/Linux and free software on many occassions (for instance, HP provides the quite powerful infrastructure for kernel.org).

I was going to go buy a HP notebook some time later this year, but as things turn out this way, I'll stick to Lenovo/IBM once more again...

yes, right here

I also have a feeling he's wrong about the pseudonyms part as well. I'd bet the majority of kernel contributions come from people who are identifiable.

And you'd win that bet. Just check out the CREDITS file in the root of the Linux kernel source tree find most people's full names, addresses, phone numbers, etc. The kernel contributors are far from anonymous.

Before I start this, I need to confess that I am a bad, bad person for posting this. This is because Enderle is a troll looking for attention and by acknowledging him at all, I'm giving him that which he craves. On the other hand, whoever posted this to Slashdot is a much worse person than I and needs to be spanked much more harshly (and not in a good way) so it's not like I'm doing any more harm. Besides, this is my opportunity to explain why he's not to be taken seriously.

So I shall now critique the linked article.

First points:

1. None of the thing he lists are in any way new or controversial.

2. The article is horribly written. Normally, when you write an essay advocating a point, you state a thesis and then present various points that support it. This one doesn't. Enderle writes an inflamatory topic heading, then a a bunch of not-really-related statements--packaging material, presumably--around his actual point.

   If I were paranoid and cynical, I'd say that the posting was actually written in the hope that the reader would just read the headings and assume they were valid arguments from the presence of the remaining text.

Now, on to the Five Forbidden Subjects of Linux. (Insert orchestral sting here.)

One: Is Linux A Myth?

The name "Linux" can mean either:

1. An operating system kernel available for download at http://www.kernel.org and many other places.
2. A family of (mostly) Unix-like operating systems which use the Linux kernel. Examples include Redhat, Debian, Ubunto, Mandriva and many others.

Both of these pretty clearly exist, at least as much as software can exist. (If Enderle had gone into that philosophical debate, this article would have been a whole lot more interesting.)

Mostly, he argues that Linux is often being talked about as something it's not. Yup, I knew that.

From there, he goes on to whinge about unfair comparisons between other products and some corporate corruption without actually saying that either of those are in any way responsible for Linux's success. So why does he bring it up? Beats me.

Two: Is Linux Secure?

Here, he brings up the tired old argument about how if (gasp) just anyone can modify Linux, how do you know that the bad guys haven't H4XX0R3D it? Or that incompetent basement hackers haven't screwed it up somehow?

(Simple: the people who decide what actually goes into the versions you buy are competent, honest and you know their real names. Also, the good guys vastly outnumber the bad guys in this game so bugs and any hypothetical deliberate sabotage are going to be found, and found quickly.)

Packaging material in this section includes a slam at Groklaw and some rambling about the importance of physical security. The latter makes sense to me, sure, but it's completely irrelevant to the point.

Three: Do Communes Work?

Now this is an interesting rhetorical trick. See, he's not asking, "Is the open source movement a commune?" because the answer to that is pretty clearly "no". (Or, given how often this particular comparison has raised its ugly head and been beaten down again, "No, you idiot!".)

Instead, he discusses the merits of communes, in the process taking it for granted that open source is a commune and so sidestepping any criticism of that idiotic assumption.

So in fact, this topic is almost never discussed in the open source community because it's irrelevant to it. I'll ignore the actual text here except to snarkily point out that his main complaint--that the whole process is so political--applies just as easily to democracy.

Four: Is Linux Pro-Developer, or Pro-You?

I'm not actually sure what he's talking about here. I think he's bringing back the old complaint that Linux drives down t

fedex ftw

This sort of thing is why security people sometimes act so devoid of hope.

Yes. The ability to directly access memory space by address from a FireWire connection is a totally inappropriate "feature" on a machine with an operating system. It's intended for embedded system debugging and remote device control. The FireWire interface hardware has it off by default. Windows has to explicitly turn it on. Despite the fact that, as far as I know, that feature is never used for anything legitimate.

And yes, it's broken in Linux. I just looked at the hardware spec (see figure 5-28) and the source code for "fw-ohci.c", and there it is:

reg_write(ohci, OHCI1394_PhyUpperBound, 0x00010000);

That line says "external FireWire packets can access any physical address below (0x10000 << 16)", or, in other words, the first 4GB of memory. Apparently this security hole hasn't been upgraded for 64 bits yet, although the hardware supports a 48-bit memory address. Note the lack of any comments in that area. That one bit opens up a huge security hole, one known for three years, and nobody has fixed it.

I'd suggest changing that value to 0, which turns this "feature" off.

At this point, Linus is the head maintainer of Linux 2.6, so the majority of the work he does is accepting patches, arguing in the mailing lists, and talking with the other main programmers and "sub-maintainers" (I don't know if they get a special name or anything).

He doesn't need to write code for the kernel to be important at this point. Besides, he contributes code to other things like git (an SCM) and GNOME.

At this point, Linus is the head maintainer of Linux 2.6, so the majority of the work he does is accepting patches, arguing in the mailing lists, and talking with the other main programmers and "sub-maintainers" (I don't know if they get a special name or anything).

He doesn't need to write code for the kernel to be important at this point. Besides, he contributes code to other things like git (an SCM) and GNOME.

Just a note: the trance vibrator driver is indeed in the mainline kernel; it's not in the "input" directory, but rather "misc", now, in case you were looking for it. Here it is. Amazing what they do with computers nowadays.

Consider that you don't need a special driver for a particular brand of ATAPI CD-ROM drive, or for a particular USB Mass Storage Device. Heck, Windows has USB class drivers for Bluetooth devices, smart-card devices, hubs, HIDs (keyboards, mice, CueCats and such), mass storage devices, printers, PTP-protocol scanners and cameras, audio devices, modems and video devices. Linux has a variety of supported class drivers as well. There are, of course, more classes, and that's all just for USB devices.

Sure, there are a lot of corner cases and pathological hardware--I think video cards are the best example--but it's entirely possible and indeed desirable to support all kinds of devices in the kernel. Even if sometimes we have to say goodbye to one of them, it was worth it to have them around.

No it isn't. It's about choices. The only people who whine about luck are people who make bad choices.

> stability, speed, price.

Those aren't graphical. How strange that what you call the important parts of the GUI, as opposed to the system, are actually parts of the system. Could it be that the Linux GUI has no redeeming value whatsoever, being nothing more than a half-assed copy of Mac and Windows concepts?

> If it's closed source, I could only take it's functionality.

Straw man. We're talking about whether one program can come from another even if it doesn't use any of the same source.

> That is "like", not "from".

Fallacy of the undistributed middle: the concepts are not mutually exclusive.

> Linux now does run on old hardware while
> Microsoft's OS doesn't.

Well, yeah, it does. Because it doesn't do anything new. Everything it does today is pretty much the same stuff it was doing in 1994. There are subtleties and new applications, but fundamentally, it's pretty much the same O/S.

> Linux is getting better, Microsoft OS is
> getting worse.

I think volume shadow copy rocks. Every time I show it to someone, they get excited about it. They're like kids. They say "Oh my GOD, that is SO COOL! Hey, Bob, come see this!" and Bob comes over and says "Holy shit, I wish I had that last month! Sharon, come see this!" and before you know it there are a dozen people crowded around the machine who are all but dancing in the aisles over this fantastic new feature.

I've never seen that with Linux. Have you?

http://en.wikipedia.org/wiki/Virtual_machine_monit or

http://www.kernel.org/pub/linux/kernel/v2.6/Change Log-2.6.20

Hi Makyrae,

Just trying to be helpful... ignore me if you don't need this.
2.6.20-rc7 is in the testing directory. I've been running it since it was released last Wednesday, no problems. YMMV.

I'm glad that 2.6.20 has been released. I had serious problems with 2.6.19 and 2.6.19.1 (but now 2.6.19.2 is quite good). I expect the initial 2.6.20 will be much better. I'm going to reboot soon and try it out. :-)

Best of luck!

"hugetbl" should be "hugetlb"
see here for more info

This comment hurts my brain. You bitch about TLAs but they're not even acronyms. Do you even know what TLA stands for?!

Lockless means it's doing something without locking everyone else from the data. Sometimes this means optimistic resolution (everyone try, and if it looks like it screwed up, try again!), sometimes it means keeping local read copies, sometimes it means something new and/or crazy. Lockless approaches are used when you have data that lots of threads must share but efficiency concerns or non-blocking requirements force you away from simply using a lock and blocking when someone else is playing with the data.

A radix-tree, as opposed to "radix-free", is a data structure used in certain applications, with operations dependent on the length of the key rather than the amount of data stored. In 2.6.20 (and others), it's used to organize some information about the page cache.

This code is associated with the RCU, which you may recall is part of an SCO lawsuit. If you're interested in any other feature or changes, the kernel newbies site is instrumental!

it works. ...
kinda.

for 10.3 everything 'works like a charm' (like someone has written here before)

for 10.4: read only access is reliable.
stay absent from the prefernce pane and use the terminal to mount the disk. to make the partition visible in the finder, etc. use cmd-shift-g and enter the mount point.

for write access use the latest public development version by installing d3 and upgrading to d4 which can be found in the sourceforge forums. be warned about the write access, though: it's known to cause kernel panics. you need to e2fsck/fsck_ext2 after any such crash which takes a long long long time of the moment but rarely finds defects related to the crash. to avoid the panics unmount/remount often and make sure you don't re-access a file that has been tampered with before (since you last remounted that partition).

there is a fuse implementation of ext2 aswell, you can find it here: http://www.kernel.org/git/?p=fs/fuse/fuse-ext2.git
it's been developed as part of unionfs. unionfs again is reported to work with macfuse (at least that's what is written in the macfuse wiki). however, i found no reports of somone using or trying to use ext2 via macfuse, yet. it might be worth a look - i'm afraid i lack the skills for pioneering work.

-losof

When i go to http://bugzilla.kernel.org/query.cgi, and enter some keywords like "LONGHAUL", "IDE TAPE", "IDE SCSI" and "VIA", i cannot find any bugs or critical failures you have mentioned. Where did you get this information?

Umm, what? According to http://www.kernel.org/ 2.6.19.1 is the latest stable version. Stable versions are denoted by having an even number for the major revision, odd numbers are for development versions.

This patch should fix your problems: http://www.kernel.org/

You're still confusing Linux (which is a kernel) with what you're talking about. Linux is a mere few dozens of megabytes.

Trying to get an exhaustive list of all WLAN adapters supported under Linux is the wrong way to approach the pb because there are literally hundreds of them on the market. However they are all based on only a dozen or so of common WLAN chipsets: Zydas ZD12xx, Atheros, Intel PRO/Wireless 2xxx, etc. It's easier to assemble a list of supported chipsets rather than a list of supported adapters.

Firstly, you can have a look at the drivers/net/wireless directory of the kernel source code. From there look at the Kconfig file (compilation options) where every WLAN chipset natively supported by the kernel is succinctly described, and pointers to additional details about the drivers are often provided: READMEs, URLs...

Secondly, some WLAN chipsets are not natively supported by the kernel, but instead by third party drivers from independent open-source projects (most of them will be integrated into the kernel in the near future). So check out this webpage for example (the interesting section is "The devices, the drivers - 802.11+, 802.11a, 802.11g"), it has been written by Jean Tourrilhes who got involved as a developer with early work on the Wireless framework in Linux. He wrote this page specifically to gather info about all the existing WLAN drivers in a central place. It contains info about third party drivers as well as drivers natively supported by the kernel. The page is slightly outdated though, so check out this wikipedia article about open source wireless drivers for a complement.

Thirdly, other WLAN chipsets are supported by proprietary drivers only, I recommend you stay away from them.

At this point, personally, I like to take decisions about hardware purchases "from the bottom up". In other words, I decide which one of the WLAN chipsets I would like my adapter to be based on (since it determines the major features of the device), and then I search for adapters using it. Usually the website of the driver maintainer, or the mailing list of the driver project, or the driver documentation are good places to look for list of adapters based on particular chipsets.

I agree.

But since they asked, you might as well think big.

If you are playing with someone else's money - even as a learning exercise - you have an obligation to act in their best interests. Otherwise, you're just doing a Halliburton on a smaller scale. Save your good intentions for your own money.

You are spot-on, but this doesn't answer the question he asked. Assuming (hypothetically) you were ordered to invest in Open Source, what company would you invest in? Novell?!?! (SARCASM THERE!)

It's not hard to understand a mutual fund's interest in Open Source. The PHB's hear that buzzword as often as they hear web2.0, right? Okay, so people want Open Source to work for them, make them money, you know, just like everything else.

This is where I get off the train, so the rest of this post is a tangent. But the question is valid, and I'm choosing not to answer it either. Someone else feel free to jump in with options like Google, Red Hat, even Oracle... Now let me explain why Open Source is not a part of my investment strategy

(Standard disclaimer that the following is not to be construed as investment advice and I am not liable for your financial losses -- or gains.)

I think that looking at the whole point of the FSF's Free Software (intentionally narrowing the definition, since the BSD license makes things more complicated for this discussion) -- Free Software is not only liberated from closed-source restrictions such as copyright and IP laws so that it can be shared openly, but this also means the act of copying it can be performed at zero cost. Zero-cost copies are an inherent element of the internet and commodity computing. Therefore, although Free Software makes great sense in business plans, it is the antithesis of business!

Free Software provides the same thing that other communities provide: donated goods and services that have market value but have been "given back" to the community. Thus, Novell faces serious repercussions if they are booted from the community -- and that could hurt their balance sheet. However, even though the community involves sales, transactions, etc., where a customer pays money (e.g. Red Hat support contracts), the donated goods and services produce a segment of the market that has zero market value. Whether we are talking about Free Software, with the technology to give the donation to everyone in the world, or other communities where hospitals are sometimes willing to write off medical expenses when the patient is completely overwhelmed by medical bills -- the effect is to make the goods and services (software or medical bills) of zero value. Why would a hospital do this? Why would a "hobbyist" (Bill Gates' term) or programmer give away software? Some would argue this threatens the very livelihood of the one giving away stuff.

But the hospital or programmer receives intangible goods and services in return. Put simply, it's a return to a basic barter system. I, the hospital director, authorize certain "free care." In return, I receive the goodwill of members of my community. If I am overwhelmed with immigrants from far-away communities who demand my free care, and then depart, the economics of medical care might overwhelm me. (But many hospitals are so well-funded that this really isn't a problem.) Any marketing student will tell you that the goodwill of your community can have a concrete impact on your balance sheet. As a contributor to Free Software, I receive the goodwill of members of the community. In this technology realm, though, there can be as many leechers as kernel.org and sourceforge.org can handle before hypothetically the community would start to suffer.

Thus companies like Google have exactly the right business plan. By investing in open source software, they invest in the community goodwill where the community is the entire planet. Then they capitalize on this by asking the community to view their advertisements, use their online office tools, se

or HTTP server http://www.kw.kernel.org/pub/mirrors/gentoo/distfi les/gaia-0.1.0.tar.bz2

All those pirated copies of SuSE Linux and RHEL are putting Novell and Red Hat out of business! I hear this http://www.kernel.org/ site lets you DOWNLOAD LINUX FOR FREE! This must be stopped; think of all the people that won't have income or even jobs if this continues! IP FOR EVAR MAN!

</sarcasm> <!-- sad that I have to have this here -->

This tree has the information about the patches that are about to get into the 2.6.20 kernel for supporting the PS3. A few device drivers are still missing because they need some more cleanups before getting merged, but they are all publically available.

linux-1.0.tar.gz 13-Mar-1994 00:00 1.2M

I'm going to Gentoo - unless someone can tell a relative noob how to easily update the kernel to 2.6.18!! (yes I realize 'easily update the kernel' is an oxymoron)

There's going to be a kybosh on naughty developers mucking about with the 64-bit kernel; patching will be banned.

But does it run... yes.

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.

Here's the OpenBSD link Search for pf_test_state_tcp - it's abotu 2/3 the was down the page

After 30 minutes of searching I couldn't find the Linux equivalent. It's either in one of the files here or maybe here. Maybe. OK I'm showing my ignorance somewhat here but I don't understand why there's a whole heap of stuff all over the place. Anyhow, netfilter's state matching basically about 4 lines which just checks a packet against a list of ip,srcport,dstport. Sorry I'd have been able to find it if I had a linux box to hand to grep on, but I don't at the moment

One thing should be stated in comparason - Linux is a *LOT* faster at throwing packets through its firewall, mind you it's a direct result of it not really checking them much...

Here's the OpenBSD link Search for pf_test_state_tcp - it's abotu 2/3 the was down the page

After 30 minutes of searching I couldn't find the Linux equivalent. It's either in one of the files here or maybe here. Maybe. OK I'm showing my ignorance somewhat here but I don't understand why there's a whole heap of stuff all over the place. Anyhow, netfilter's state matching basically about 4 lines which just checks a packet against a list of ip,srcport,dstport. Sorry I'd have been able to find it if I had a linux box to hand to grep on, but I don't at the moment

One thing should be stated in comparason - Linux is a *LOT* faster at throwing packets through its firewall, mind you it's a direct result of it not really checking them much...

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.

Weird how Hans gets arrested the day Ext4 filesystem is released eh?

http://www.kr.kernel.org/pub/linux/kernel/people/a kpm/patches/2.6/2.6.19-rc1/2.6.19-rc1-mm1/announce .txt

Oddly enough, Andrew Morton included Reiser4 in his -mm kernel series today.

http://kernel.org/pub/linux/kernel/people/akpm/pat ches/2.6/2.6.19-rc1/2.6.19-rc1-mm1/announce.txt

Why don't you look for yourself?

The latest 2.4 version of the Linux kernel is: 2.4.33.3 2006-08-31 20:20 UTC
The latest prepatch for the 2.4 Linux kernel tree is: 2.4.34-pre4 2006-10-02 20:45 UTC

Seems pretty recent to me.

http://www.kernel.org/

--
BMO

People might finally get the pronounciation right.

"Hello, my name is Liinus Toorvalds, and I pronounce Liinux as Liinux."

You are wrong; you're thinking of the BSD-style licenses. Anything under the GPL (or software that extensively uses GPL-software's interfaces) must have source released if it's released.

Actually, you are wrong. The GPL is only required (i.e., only applicable) when copyright is involved; i.e., making a derivative work. For there to be a derivative work, there has to be a copying within the ambit of the copyright act. If you look to the Altai test (adopted by pretty much every court), you'll see that code dictated by external requirements (i.e., pretty much every piece of software running on a UNIX/Linux system has to use malloc, etc., and thus must either call the system calls directly or via the C Library) is specifically filtered out of the copyright comparison. So any interface calls, even symbols brought in from include files, are [strongly] arguably not even copyrightable (a 'method of operation'; see, e.g., 17 U.S.C. 102, and Lotus v. Borland, 49 F.3d 807 (1st Cir. 1995)) and even if they are, would be stripped out of any comparison of code done in an infringement action. Absent an infringement, there's no need for GPL applicability...

Further, the COPYING file for the Linux kernel (http://www.kernel.org/pub/linux/kernel/COPYING) specifically carves out "user programs that use kernel services by normal system call." So, with appropriate facts, one could easily argue copyright estoppel in the (unlikely) event that Linus (as the copyright holder for much, if not most, of the kernel, AFAIK -- the FSF, etc. would not have standing to sue, it would have to be Linus or some other kernel contributor whose work was in the Wii) brought suit.

The point is, once you have root, there are any number of ways to compromise the system and hide your exploits.

That's not necessarily true on recent Linux versions, or at least it isn't for the reasons that you listed. Aside from the fact that /dev/kmem and loadable modules can be disabled, even if those features are active, not all processes with UID 0 necessarily have access to them.
For quite some time now, Linux has included support for POSIX Capabilities. The API is ugly as heck, and unfortunately there isn't any FS support (analogous to set{u,g}id flags) yet, but the basic functionality (dropping selected capabilities, changing UID without dropping capabilities) does work.
Module (un)loading is CAP_SYS_MODULE. Ignoring file permissions is CAP_DAC_OVERRIDE. There's some other pretty critical stuff like CAP_MKNOD, but in principle it should be possible for a uid 0 process to have no special privileges whatsoever.
Access to binfmt should not change this fact.

Of course, in practice there probably aren't very many vanilla linux systems that rely on this at the moment. If one does want to retain only some privileges, the sound practice is to not only drop the others but also change UID; for one thing, a lot of critical files (like /etc/shadow) are still owned by uid 0 by default.

Want to write a new driver for Linux? Download everything you need, free, from http://www.kernel.org./ The "driver development kit", or "kernel" as it is more usually known, includes working source code for thousands of other drivers, which you can modify to make your new driver.

I read the point made on osnews forum about the change. The claim is that since the Firefox logo is trademarked, it is not-free.

If this is really the case, then Debian needs to stop distributing *any* other trademarked bit of software.

Let me give you a really simple example which , if it were really about trademarks not being free, they would have to stop distributing.

The Linux kernel. See the bottom of www.kernel.org . Or the url http://www.kernel.org/legal.html

You see, if it was because trademarks aren't free, then they would have to stop distributing anything with a trademark, including the kernel. Since it is not about trademarks, but about a group that is looking for a way to get around a reasonable branding request, they are doing and saying dumb things.

Good job Debian. Good job. This really moves forward the concept of companies/organizations putting their stuff out as open source, only to be strong armed by the likes of Debian.

This is sad. For Debian, and anyone who follows in their mistaken footsteps.