Slashdot Mirror

> It's not retarded. Anybody who has ported applications to various UNIX platforms knows that it can be non-trivial.

Quite right. In recent years much of the traffic on the Debian Hurd ML has been about package porting issues see for example Heimdal issues.

A new OS is a new partition, a new disk, totally new way of doing things

Actually, if you can spare a gig or so, you can make a file and make it a filesystem and install GNU/Hurd in that file (I believe that this is the way WINE works with DOS partitions?) (that is the plan anyway). So repartitioning will not be necessary to try out GNU/Hurd and everyone had a spare gig or two these days, right? :).

It is not really a new way of doing things, I found. Debian GNU/Hurd is as different to Debian GNU/Linux as Debian GNU/Linux is to RedHat Linux (roughly).

select() has indeed been a problem - e.g see this

So, although not every package is ported without effort, many packages can be got working with a little effort. Many (most?) of the porting problems are because the packages are Linuxified and not strictly POSIX.

Thanks for you interest in the Hurd.

> It's not retarded. Anybody who has ported applications to various UNIX platforms knows that it can be non-trivial.

Quite right. In recent years much of the traffic on the Debian Hurd ML has been about package porting issues see for example Heimdal issues.

A new OS is a new partition, a new disk, totally new way of doing things

Actually, if you can spare a gig or so, you can make a file and make it a filesystem and install GNU/Hurd in that file (I believe that this is the way WINE works with DOS partitions?) (that is the plan anyway). So repartitioning will not be necessary to try out GNU/Hurd and everyone had a spare gig or two these days, right? :).

It is not really a new way of doing things, I found. Debian GNU/Hurd is as different to Debian GNU/Linux as Debian GNU/Linux is to RedHat Linux (roughly).

select() has indeed been a problem - e.g see this

So, although not every package is ported without effort, many packages can be got working with a little effort. Many (most?) of the porting problems are because the packages are Linuxified and not strictly POSIX.

Thanks for you interest in the Hurd.

I've got 5 devices running off of IRQ 9 and the thing is rock solid, never had a crash since early 2.4.0pre days and it probably wasn't because of an IRQ problem.

The Linux kernel has ACPI support in its future and it all started back in 1999

Anyway check this out...

[root@haemal]:/proc# cat interrupts
CPU0

0: 29750549 XT-PIC timer
1: 87289 XT-PIC keyboard
2: 0 XT-PIC cascade
3: 2 XT-PIC serial
5: 183414591 XT-PIC EMU10K1
8: 3 XT-PIC rtc
9: 1551326 XT-PIC acpi, usb-uhci, usb-uhci, eth0, eth1
10: 1318690 XT-PIC ide0
12: 2323801 XT-PIC PS/2 Mouse
14: 89064 XT-PIC ide2
15: 62 XT-PIC ide3
NMI: 0
LOC: 29751193
ERR: 46561
MIS: 0

A good pace to find this information is Kernel Traffic. It's like a summary of the mailing list.

There is an interesting run down of the work on 2.5 at Kernel Traffic. JFS is apparently going to be included, but I haven't seen much about XFS. I was looking forward to huge file capability (>2G). Anyone know?

Yes, even the read-only module. It might be worth spending some time catching up on this matter by browsingthe archives of Kernel Traffic.

In answer to your question about compile-time options for the vm's...
http://kt.zork.net/kernel-traffic/kt20011029_139.h tml#3

http://kt.zork.net/kernel-traffic/kt20011105_140.h tml#3

-- ecc

In answer to your question about compile-time options for the vm's...
http://kt.zork.net/kernel-traffic/kt20011029_139.h tml#3

http://kt.zork.net/kernel-traffic/kt20011105_140.h tml#3

-- ecc

See this link and scroll down a bit for this quote from linus:

"Which, btw, explains why I don't consider you a kernel maintainer, Rik, and I don't tend to apply any patches at all from you. It's just not worth my time to worry about people who aren't willing to sustain their patches."

--xPhase

While I am not certain, I see the entries for Davide Libenzi, Ingo Molnar on scheduler improvements. Ingo published a huge scheduler update that looks promising, might be worth checking it out if you have a system under high load that tends to be come poky/etc.

I believe there was some discussion of integrating Ingo's patch with the preemptive patch, should be good for everyone.

A link to his discussion http://kt.zork.net/kernel-traffic/latest.html#4 on Kernel Traffic.

It seems as though many businesses would be interested in protecting their internal information in this manner, which might turn out to be a selling point of this "Trusted OS".

This guy is right - the workaround for the problem has been about for a while. For more information on the problem take a look at the Via Hardware FAQ. The whole via problem has been known about for sometime (a search on Kernel Traffic for KT133 turned up a few references. The most recent reference was 2.4 Kernel freezes on VIA KT133.

As mentioned in other comments, motherboard makers were encouraged to workaround this at bios level.

This guy is right - the workaround for the problem has been about for a while. For more information on the problem take a look at the Via Hardware FAQ. The whole via problem has been known about for sometime (a search on Kernel Traffic for KT133 turned up a few references. The most recent reference was 2.4 Kernel freezes on VIA KT133.

As mentioned in other comments, motherboard makers were encouraged to workaround this at bios level.

The KDE folks have at least considered using Orbit. Check it out. In fact the only reason that KDE isn't using Corba right now is that when they started KDE2 development there weren't any useable (read fast) Free Software ORBs available. Which highlights what is perhaps the biggest difference between the KDE and Gnome camps. There wasn't a useable ORB when Gnome started either, so they wrote one themselves (just like they essentially wrote their own widget set).

The KDE folks tend to look for shortcuts. They used a (then) non-free widget set because it was easier. When they couldn't find a useful ORB they simply wrote something else. Gnome's support of Corba turned out to be a big deal. It's the primary reason why Sun, HP, and some of the other UNIX big names are pouring money into Gnome and not KDE.

I can't find any example links right now, and I might be mis-remembering it, so somebody more knowledgeable should add their thoughts.

--Robert

*LOL* Damn, that's brilliant. (TTMTB: Please mod up.)

Unfortunately, I suspect the average poser that lurks on /. are probably unaware of the memory management fiasco that has been going on between RVR and AA. (And if that is the case, hit Kernel Traffic and catch up on the past 6 months of weekly lkml summaries.)

The expert opinion: http://kt.zork.net/kernel-traffic/kt20000814_80.ht ml#1

I've been excited about the TUX2 filesystem ever since I heard of this. I hope this is the default for 2.5 - 2.6 barring some unforeseen problem.

-l

"Best" is an awfully loaded term.

For most people, all that this will do is cause them a flood of email about minutiae for which they have no context.

I would rate Kernel Traffic much higher on the "best way to keep up with what's happening in the kernel" scale for anybody who's not actually contributing code to the kernel. Even experienced C coders, if they aren't ass-deep in the kernel for other reasons.

So journalling's been available to the masses for a while now. Or maybe Michael meant ease of converting for the installed base?

Now if only the damn preemptible kernel patch would make it in. Unfortunately, it looks like that's going to wait until 2.4.5. *sigh*...

The latest Kernel Traffic suggests that Alan is considering using the AA VM anyway. Looks like Rik's stuff is getting dumped entirely. That is unless they can figure out how to parameterize VM's and make it a compile time option as they've been talking about.

It looks like there were many fixes to the VM, which is good news. Hopefully this is the one we can all be happy with (well that will never happen, but at least be content for a bit) and let the Linux team move on to 2.5. The VM talk has seemed to calm down a bit on the LKML.

(Yes, I spend an hour a day reading the kernel mailing list.)

I'm too lazy to read LKML, but I am interested in the happenings of the Linux kernel development. I highly recommend Linux Weekly News' kernel news (updated every Thursday) and Kernel Traffic , an in depth summary of the week's LKML happenings (usually updated every Sunday or Monday).

"Too ugly for words." -Alan Cox

so why does linux have 1 VM? it seems that 2 of them exist, and the BSD's have more... guys, "gimme a hunk" and "page fault" aren't exactly rocket science anymore, particularly with hardware support... the fact that there is room to make a big deal out of this is the problem, not the VMs.

If Linux was a microkernel I'm pretty sure this would be possible but from what I've seen of the Linux kernel code and from some discussions on the linux kernel mailing list, the virtual memory code is too entrenched in various parts of the code to be #ifdefed around with any sort of ease.

(speaking of KDE) My bet is that their decision to use Gnome has more to do with the geographical location of its core developers than the code itself.

I read this some tim ago on KDE KT Cousin, basically they say that KDE isn't that portable, and port to Sun asch is going to take a while. GNOME is plain C and has ran on Sun for a long time, so there's not so much trouble to go through.
Consider also that KDE uses C++, and Sun's own compilers isn't maybe so good at C++ and g++ sucks on Sun too...
And.. If Sun used KDE on their arch, they'd had to pay Qt $$. That's pretty hard to explain to shareholders when there's equivalent totally FREE option available.
I'm not talking about government however ;P

This is a link to the kernel-traffic discussion with details and basic benchmarks: here!.

Linux Kernel Pillow Talk

(Linux Kernel Pillow Talk: Page1of1)
By Moshe Bar

October 29, 2001

And you thought the netherworlds of dry kernel engineering were free of politics, egos, and prima-donnas? Guess again. The events of the last four to six weeks and the e-mails flying to and from the Linux kernel mailing list show how Byzantine and complex the dynamics of decision finding, features design, and implementations can be. Go to http://www.tux.org/lkml/ to subscribe to the kernel mailing list, but be careful: This is a very high-traffic list. Subscribe only if you really want to follow every single detail of the Linux kernel, or instead read the weekly digest at Linux Kernel Cousin at http://kt.zork.net/kernel-tra ffic.

Sure, the lively debates have always existed. In the past there have been disputes about the Linux firewalling code, networking code, scheduler, installer, driver model, and many more. One recurrent theme has always been the Virtual Memory (VM) manager. Nothing determines the peculiar behavior, the feel -- even the ultimate success or failure of an operating system -- like its virtual memory design. Sometime during the development cycle leading up to the Linux 2.4.0 kernel, in other words in 2.3.xx times, Rik Van Riel (http://www.surriel.com), a Dutch kernel hacker working for Brazil-based Conectiva (one of the smaller Linux distributions), introduced a radically new VM code. It was based on what seemed to be new and advanced algorithms for efficient finding, allocation, and disposal of virtual memory pages requested by programs. Rik later introduced an interesting new kernel feature called the "OOM killer." OOM stands for Out Of Memory. The OOM killer attempts to locate a killable process when memory runs out in the system. Without such a feature the whole machine can go nuts or enter a vicious cycle of swapping out a few pages, realizing immediately after that those pages are needed, and searching again for swappable page candidates, keeping the kernel busy doing only this instead of letting user processes run.

Rik is a gifted hacker, and among other things he has been trying to improve the efficiency and speed of maintenance of those lists in the kernel responsible for managing all the virtual memory pages in the system. One of the main questions to address in every operating system VM code is: "How do you choose which page to steal next when there is a RAM shortage?"

In the 2.4.0 release, the Linux kernel scans the process page and decides which page to remove. The problem with this approach is that sometimes a lot of process tables have to be scanned to free just one page, or very few pages. Also, this approach does not guarantee that the pages stolen are only those that will not be needed again very soon. Some UNIXes introduced the notion of the working set; that is, the minimum amount required by a process to function efficiently. This solution is, however, limited to per-process pages only and does not consider other kinds of pages, such as filesystem caching. Stealing from these pages might in some cases even prove counter-productive. Very often in VM theory, a solution to one problem can worsen another; that's why kernel programming is difficult.

Rik van Riel and I have variously discussed another approach, called "reverse mapping," which implements a reverse-lookup between the page and process table. Once you have reverse-mapped pages, the VM can simply scan the pages for the ones to be freed. Naturally, some extra fields need to be added to the appropriate control tables to allow this reverse mapping. My own implementation has an overhead of 14 bytes and is therefore certainly a lesser solution than Rik's -- his overhead is just 8 bytes.

Other extremely talented kernel hackers such as Marcelo Tosati and Ben LaHaise have made other important contributions to the Linux VM.

However, even though all these intelligent people tried hard to make the Linux VM fast, efficient, and powerful, user reports since the 2.4.0 release indicated poor Linux kernel performance and erratic and unstable behaviors. Up to kernel 2.4.7, for instance, on machines with small memory footprints (less than 40-MB RAM), sudden swap storms could erupt which would virtually freeze the system while it inexplicably started swapping pages in out and like crazy. In some cases, the aforementioned OOM Killer would choose the wrong process to kill; I have seen the all-important init process killed erroneously. Many fringe kernel projects, like my own Mosix project or others such as Win4Lin, suffered because users accused these projects of unstable operations, assuming that a released kernel like 2.4.0 must be free of such nasty bugs. Even though the kernel had gradually evolved from 2.4.0 to 2.4.9, it was evident that the VM design was more of a liability than an advantage.

Linus himself said in a recent kernel list mailing that he wasn't happy yet with the VM. These problems were enough for many Linux shops to resist the migration to the 2.4 kernels and instead continue using the 2.2.19 kind of kernels. Obviously, compared to 2.4., the 2.2. series has many shortcomings -- like no zero-copy networking, the division of page cache and buffer-cache in filesystem operations, big spinlocks (serializations of kernel execution paths for computers with more than one CPU) for many parts of the kernel, and so on.

A simple C program like the one below shows how kernels up to 2.4.9 had problems dealing with stress workloads on the VM system. If, after running this program, you turned the swap partition off with swapoff, your server or workstation would become totally unresponsive for up to 15 minutes.

/* based on a code originally proposed by Andrew Tanenbaum, later by Derek Glidden and many others since */ #include void main(void) { /* in the next line we allocate 200MB, but since the virtual memory page is not actually allocated by the kernel until we use it, we also have to create an access to. The amount of allocated pages should reflect the total RAM on your computer. This test runs well with machines of, say, 256MB */ void *p = (void *)calloc(50000000, sizeof(int)) ; /* In the next line we let the system calm down a bit after allocating pages*/ sleep(12); /* and now re release it all again */ free(p); }

Back in February 2001, I ran an informal and unscientific benchmark comparing FreeBSD 4.1.1 to kernel 2.4.0 (visit http://ww w.byte.com/documents/s=558/byt20010130s0010/) on exactly the same hardware and with exactly the same subsystems versions (MySQL, Sendmail, Apache, and others). The results clearly showed that, indeed, there were major problems with the efficiency and speed of the early 2.4 kernels. A New VM

Then, on September 24, with the kernel standing at version 2.4.9, everything suddenly changed. Andrea Arcangeli, an Italian kernel hacker (read my interview with him two years ago at http://ww w.byte.com/documents/s=287/byt20000229s0008/) and a very prolific contributor, decided that enough was enough. He sat down and in one of those marathon hacking bouts completely rebuilt the VM from scratch. In short succession he sent to Linus Torvalds over 150 patches to the 2.4.9 kernel, to implement a new VM engine. This is an extremely remarkable feat. A VM is a major piece of software and by nature very complex. One needs to satisfy many opposed objectives: Simultaneously efficient handling for server-type loads and interactive-type loads; ease of implementation and at the same time, optimized use of every last and small feature of the CPU. The VM must also be able to run well on Intel CPUs spanning 4 or 5 generations, as well as on AMD chips, Alphas, MIPSes, Sparcs, ARMs, and what have you. Andrea, by the way, does all his development on a Compaq AlphaServer with 2 500-MHz CPUs and 3-GB RAM.

Out of the blue, Linus accepted the new VM and incorporated it into the official Linux kernel tree.

Recently, I spent two days with Andrea giving speeches. During the two days, over many bottles of beer, we had plenty of time to discuss his new VM. I was mainly interested in how the new VM affects Mosix. Because Mosix must migrate virtual memory pages belonging to the program's address spaces between cluster nodes, it is important to correctly understand the VM and interface efficiently to it.

Specifically, Andrea took exception to the following problems in the 2.4 VM:

• kswapd looping forever on DMA or NORMAL class-zones.
• swap+ram will be almost all available address space (modulo when the swap cache serves to avoid swapin of shared anonymous memory after a fork).
• swapout storms.
• benchmarks, when run repeatedly, gradually slow down.

The new VM is much simpler and faster. Let me explain how it works.

The old 2.4 VM had a major design problem that manifested itself mainly when freeing physically dirty pages (remember dirty pages are the frames of 4-KB memory in the RAM whose contents have been modified by one of the virtual memory pages residing in it). The last owner of the page (usually the VM, except in swapoff) has to clear the dirty flag before freeing the page. When being swapped off in swapoff it may be a little more complicated -- we may need to grab the pagecache_lock to ensure nobody starts using the page while we clear it.

So, Andrea went and did the following: All physical pages are now divided into active and inactive pages. These two are further divided into dirty and clean for both active and inactive. When the active dirty pages become about 66 percent of the total number of pages, the VM starts to scan them for the oldest ones to be put into inactive dirty and then, later still, from there to the swap when memory becomes tight. This part is very central to the new VM and its simplicity is...well, simply stunning.

This elegant mechanism totally changes the behavior of the 2.4.10 kernel under heavy load and also makes for much better predictability of the system. Another very important change is that the swap is now additional to the RAM, just like in 2.2 times. All earlier 2.4 kernels (since 2.3.12) needed at least the same amount of RAM in swap and then more to give you additional virtual memory. This meant that on an 8-GB server, you needed to put aside almost a full 9-GB disk just to be able to swap, similar to some versions of Solaris or other UNIXes.

Finally, the page scanner doesn't page scan if there are theoretically no freeable pages, whereas before it did. Oh, and the OOM killer never really worked, so Andrea disabled it, as I did for all my kernels. In 2.4.12 it is enabled again; this time, however, it works much better. Try it with the above program to see it in action.

Arcangeli's VM is stable, acts predictably -- something that the old VM never really achieved -- and it makes the swap space look like it did in 2.2 days. Additionally, the design is much simpler and easier to understand. People will catch up fast with it.

However, many kernel hackers disagree. Upon the release of kernel 2.4.10, a virulent and sometimes aggressive debate flamed up, with many people trying to show why one of the two was a good VM and the other not. Some comments got a bit out of control, and only in the last two weeks or so has some calm been restored.

However, one nasty side effect stays. Alan Cox, the number two man after Linus Torvalds, does not yet like the new VM and in his own kernel tree (called the "ac tree") he still continues to use and patch the old VM. As a consequence, users and system administrators now find themselves facing two very different kernel trees to choose from: the official Linux tree and the Alan Cox tree. Quite often, latest patches to drivers and new features are only in Alan Cox's tree. Those who want to go with the official Linux source code may find themselves unable to apply the patches due to the different VM code all over. It is acceptable for the two trees to be different for a few days on such important subsystems like VM, but it is not acceptable to have them different for months and across many kernel versions.

Nobody has yet dared to speak of a Linux source fork, but this is dangerously close to one.

It became obvious that the VM up to 2.4.10 was a design liability. You can try to fix something that was designed badly, but it will never become a beauty. I think Linus' decision to scrap the old VM and go with the Arcangeli VM was courageous and right. Having a functioning and stable Linux box should not be deferred to 2.5 when we can do it already with 2.4. Kernel Preemption

But apart from the VM issues, there are other lively debates in the kernel community. There was an interesting interview at h ttp://kerneltrap.com/article.php?sid=328&mode=thre ad&order=0 with Robert Love, who is leading one of two projects trying to make the Linux kernel fully preemptible. Making the kernel preemptible means making it possible to interrupt whatever the kernel is doing (say, executing a system call) to process some other outstanding task and then return to its original task. Linux, as a multiprocessing OS, obviously always did that for user-land processes. However, many, just like Robert Love, feel that the fact that Linux up to now would not let itself be interrupted contributed to poor latency. Latency describes how quickly you can expect a response from your kernel when you actually need something from it. Note that Linux is not designed as a real-time OS (though there is at least one Linux real-time implementation somewhere), and therefore does not explicitly guarantee latency. User-land programs must be aware of this as, especially with kernel preemption, latencies can be very unpredictable.

Theoretically, an OS will answer faster if it can be interrupted. What does suffer from kernel preemption is the global throughput. If you have a task that gets n seconds within the kernel to complete (let's say executing a given system call takes 0.005 seconds), then all the interruptions add some overhead to switch from one kernel task to another. So, finishing the execution of that system call (in our example) will finally require n+op where p is the frequency of switching and o the static overhead for one switching operation. Notice that kernel context switching does not invalidate the CPU cache, and is therefore not as expensive as process switching. However, kernel preemption will surely lead to a higher rate of switching from kernel space to user space, because upon preemption the scheduler might decide to give higher priority to a user process.

In other words, kernel preemption does decrease latency but slows down overall throughput. It's the math: nothing to be done against it.

Furthermore, in his interview, Robert Love heavily criticized Linus Torvalds for adopting Andrea Arcangeli's new VM in 2.4.10 and dropping the old van Riel VM.

Well, I did try the patch with kernel 2.4.12 and with pre13. While accurate measurement (which Robert Love provides with the preemption kernel patches) does indeed report an improvement in latency, for the life of me I have not noticed it on an empirical basis.

I really do appreciate Love's work, but I do not fully agree with some of his comments in the interview. First, as Linus himself said, if latency sucks in the kernel then we should check why it sucks, with or without preemptive scheduling. If the latency is bad in the stock kernel, then it should be fixed anyway.

The preemptive kernel 2.4.12 worked fine on my laptops and on my SGI 550 workstation where I do interactive work. The MP3 player very rarely skipped beats when doing heavy background work such as kernel compiling or opening large files in the editor. But for my servers and clusters, the decrease in performance and the unpredictability of latency is a problem. Also, some important patches will not apply to a Love-patched kernel. Mosix, the clustering kernel extension, does not patch correctly, and neither do some versions of the LIDS intrusion detection system.

It is up to each individual user to decide whether or not to use the patch, but is important to understand the implications of using it. Linux and FreeBSD Revisited

Upon returning home the other week after meeting with Andrea, I went to my lab and searched for the disk images of the server comparison I ran back in January of this year (of FreeBSD 4.1.1 versus Linux 2.4.0). I took the Compaq ML500 server I have been reviewing (2x 1-GHz CPUs, 2-GB RAM) and upgraded both the FreeBSD disk image to 4.4-Stable and the Linux version to 2.4.12. Then, I changed the memory down to 192-MB RAM so as to stress the VM system more. I also upgraded to the latest stable versions of Sendmail (8.12.1) and MySQL (version 3.23.42). Finally, I compiled everything with the latest version of gcc, 3.0.2, and tuned the two instances to the best of my knowledge (softupdates and increased maxusers for FreeBSD, and untouched default values for Linux).

The results were very interesting indeed. Since this benchmark is too much to be handled in this article, Byte.com will post it here soon for you to read.

The story of this article is that the 2.4 kernel has finally grown up with the 2.4.10 release. Not many users outside the relatively small kernel community realize that. Now you know about it, too. Spread the good news and immediately install 2.4.12 on your busy server. The server will thank you for it.

Moshe Bar is a systems administrator and OS researcher who started learning UNIX on a PDP-11 with AT&T UNIX Release 6, back in 1981. Moshe has a M.Sc and a Ph.D. in computer science and writes UNIX-related books.

For more of Moshe's columns, visit the Serving With LinuxIndex Page . Page1of1

Michael T. Babcock asked how ugly it would be to make Rik van Riel's and Andrea Arcangeli's Virtual Memory subsystem code into a compile-time option, so folks could try each one out as they pleased. Alan Cox replied simply, "Too ugly for words." Mike Fedyk suggested that it might be feasible in 2.5, and asked if there were a way to make it non-ugly. Marcelo Tosatti replied, "Even if its non-ugly, its non-easy. Way too much overhead. For 2.5 we'll probably be able to get people working together."

final:
. . .
- me: handle VM write load more gracefully. Merge parts of -aa VM

The good news is that Linus seems ready to hand 2.4.x over to Alan. From the latest Kernel Traffic Linus was quoted as saying:

. . .
He replied to himself shortly thereafter after noticing more breakage, adding, "On the other hand, the good news is that I'll open 2.5.x RSN, just because Alan is so much better at maintaining things ;)"

I'd just like to say that I think the KCDH is good stuff. Interesting, critical and sometimes funny, it's a worthwhile read. A bit too Debian-influenced for my liking to be ideal, but the articles about the kernel proper are certainly worthy of attention (as is Kernel Threads, of course).

I'm using gcc 2.95.4 (just checked). I haven't had the cojones to upgrade to 3.0 yet, although it's available in Debian unstable. ;)

As for not using 2.96, I've seen several warnings to that effect on Kernel Traffic (highly recommended). If I'm not mistaken, Red Hat provides 2.95.something as a "kgcc" package, intended for kernel recompilation ("kernel gcc").

I agree. Without the GPL, Linux would not be where it is today. Imagine Linux under a BSD license. Why not just run BSD?

Alan Cox is far more positive in his defence of the GPL. I read the linux-kernel mailing lists (mostly courtesy of the nice abridgement with commentary to be found at Kernal Cousins) and Linus rarely talks about licenses. Perhaps he does see the value of his early choice, but he doesn't shout about it.

Linus is not in any kind of competition with Microsoft, because Linus is in it for fun, and because Microsoft cannot do a single thing to weaken or destroy Linus' ability to have fun hacking the kernel. Linux companies have to worry about Microsoft. Linus doesn't.

Anyone who thinks Linus should be concerned about Microsoft's moves does not understand Linus. He is not a businessman, or a general, or a leader, or an ideologue, or a diplomat. He is a hacker. Try reading Kernel Traffic sometime, you'll see what I mean.

Just like the majority of you readers, I am not a kernel developer. But I like to know what I'm running. My conclusion is that if you want a stable kernel, ignore Linus' tree and use the Alan Cox tree. To say it blunt, 2.4.10+ really is 2.5, and you should only run it if you are prepared for some weird behaviour.
Now am I a troll? Hope not. I did get my info out of Kernel Traffic, which I've been reading for months. It is a very good, understandable and clear compression of all important things that happen on the linux kernel mailinglist. If you use Slashdot as your only information portal about the kernel, you are *braindead*.
Ok, now my point - it is the VM subsystem. By now you should know that 2.4.x, until recently 2.4.10, used the VM code by Rik van Riel. That code has taken some time to develop, but you definitely can't blame Rik as the cause for all 2.4 stability problems, as well as the eternal delay of 2.5. But according to the l-k list, Linus himself made several errors in including Rik's patches, which indeed caused 2.4.7 and up to be unstable! Ok, now stop and think about this. Linus has an enormous responsibility. He didn't realize where the fault was, but he did perceive that the stable kernels were NOT stable. He knew that Andrea Arcangeli was still working on his own VM (that work improved Rik's VM too in 2.3. Not having a monopoly really does improve invention!) Then Linus made the big step: even in a *stable* series, he took over Andrea's VM and threw out Rik's one. This is really an important decision, and I applaud it!
The only thing Linus should not have done, is labeling this thing 2.4.10. It really is 2.5. For the big public, that kernel was definitely everything but a stable kernel. Luckily a lot of problems have been solved since (2.4.11 is a hell of a lot better than 2.4.10), and I consider Andrea Arcangeli really a good coder, but actually I trust Alan Cox most. He commented that Linus' recent kernels trashed several boxes of his overnight. Alan really sees the -ac tree as the stable one currently. I run 2.4.9-ac18 too, with the kernel preemption patch as mentioned earlier, on a p2-233 with quite some load, and it doesn't show any strange behaviour. (The kernel preemption patch doesn't do really much here: I still get skips when I record an mp3 from my soundcard and switch desktops in the meantime. But I should not expect wonders :))
One last thing: Rik van Riel's VM has improved *too*. Alan Cox catches up with his patches very speedily. No more big bugs; Rik even added some optimizations in 2.4.9-ac16. I can't see that of course, but overall the system is a lot more responsive than 2.4.3-pre6, my last kernel before this one.
So my advice: use the ac-series of the kernel. Linus has made some wise decisions. I think he should start 2.5 and leave 2.4 to Alan, before people go sulking about 2.4.10 versus the always-stable reputation of the Linux kernel.

In the past few Kernel Traffics, there has been a lot of discussion about Andrea Arcangeli's VM patches. Alan Cox, for one, was reluctant to introduce such drastically new VM code mid-2.4.

In the Changelog they are listed as "tweaks".

What changes made it into 2.4.11? How reliable are they?

2.4.2 was the latest kernel available at the time of release, and since there have been no gaping security holes and that kernel has proven fairly stable, there's no reason to mess with a good thing.

I beg to differ. There are lots of reported data corruption bugs in all 2.4 kernels prior to 2.4.6:

• 2.4.5 Data Corruption
• Potential Filesystem Corruption With IBM Travelstar 20G Drive
• Massive Filesystem Corruption in 2.4.3
• New Filesystem Corruption in 2.4.2-pre2
• Filesystem Corruption in 2.4.1
• VIA Disk Corruption Continued
• Still Hunting Filesystem Corruption in 2.4
• Temporary Filesystem Corruption Workarounds in 2.4
• Filesystem Corruption Possibly Traced to RAID5 In 2.4
• Unexplained 2.4.0 Filesystem Corruption
• Possible Filesystem Corruption In 2.4.0-prerelease

Linux 2.4.3 ate my hard drive. I booted up, got weird problems...ran an fsck, it failed, saying the superblock was invalid. I specified one of the alternate superblocks...it kept giving me errors. I piped yes into it and let it run. When it was done, my entire filesystem was in little pieces in /lost+found.

That's the most important problem, but there are also a couple reported crashes I believe and, of course, the VM problems (which are still an issue. 2.4.10 has a huge patch to the VM system.)

I've been pretty disappointed by Linux 2.4 so far and at this point I'd say I still would not run it on a server. (I use FreeBSD, but Linux 2.2, though old, is good as well.)

I'm used to running bleeding edge stuff on my desktop, though. I'm not too upset about the losing my Linux partition thing, since I had most stuff backed up elsewhere.

(In fairness to Linux, I have a VIA686b South Bridge Controller. I think that's the chipset they had the most trouble with by far, though from the descriptions, not all of these bugs are related to it.)

2.4.2 was the latest kernel available at the time of release, and since there have been no gaping security holes and that kernel has proven fairly stable, there's no reason to mess with a good thing.

I beg to differ. There are lots of reported data corruption bugs in all 2.4 kernels prior to 2.4.6:

• 2.4.5 Data Corruption
• Potential Filesystem Corruption With IBM Travelstar 20G Drive
• Massive Filesystem Corruption in 2.4.3
• New Filesystem Corruption in 2.4.2-pre2
• Filesystem Corruption in 2.4.1
• VIA Disk Corruption Continued
• Still Hunting Filesystem Corruption in 2.4
• Temporary Filesystem Corruption Workarounds in 2.4
• Filesystem Corruption Possibly Traced to RAID5 In 2.4
• Unexplained 2.4.0 Filesystem Corruption
• Possible Filesystem Corruption In 2.4.0-prerelease

Linux 2.4.3 ate my hard drive. I booted up, got weird problems...ran an fsck, it failed, saying the superblock was invalid. I specified one of the alternate superblocks...it kept giving me errors. I piped yes into it and let it run. When it was done, my entire filesystem was in little pieces in /lost+found.

That's the most important problem, but there are also a couple reported crashes I believe and, of course, the VM problems (which are still an issue. 2.4.10 has a huge patch to the VM system.)

I've been pretty disappointed by Linux 2.4 so far and at this point I'd say I still would not run it on a server. (I use FreeBSD, but Linux 2.2, though old, is good as well.)

I'm used to running bleeding edge stuff on my desktop, though. I'm not too upset about the losing my Linux partition thing, since I had most stuff backed up elsewhere.

(In fairness to Linux, I have a VIA686b South Bridge Controller. I think that's the chipset they had the most trouble with by far, though from the descriptions, not all of these bugs are related to it.)

2.4.2 was the latest kernel available at the time of release, and since there have been no gaping security holes and that kernel has proven fairly stable, there's no reason to mess with a good thing.

I beg to differ. There are lots of reported data corruption bugs in all 2.4 kernels prior to 2.4.6:

• 2.4.5 Data Corruption
• Potential Filesystem Corruption With IBM Travelstar 20G Drive
• Massive Filesystem Corruption in 2.4.3
• New Filesystem Corruption in 2.4.2-pre2
• Filesystem Corruption in 2.4.1
• VIA Disk Corruption Continued
• Still Hunting Filesystem Corruption in 2.4
• Temporary Filesystem Corruption Workarounds in 2.4
• Filesystem Corruption Possibly Traced to RAID5 In 2.4
• Unexplained 2.4.0 Filesystem Corruption
• Possible Filesystem Corruption In 2.4.0-prerelease

Linux 2.4.3 ate my hard drive. I booted up, got weird problems...ran an fsck, it failed, saying the superblock was invalid. I specified one of the alternate superblocks...it kept giving me errors. I piped yes into it and let it run. When it was done, my entire filesystem was in little pieces in /lost+found.

That's the most important problem, but there are also a couple reported crashes I believe and, of course, the VM problems (which are still an issue. 2.4.10 has a huge patch to the VM system.)

I've been pretty disappointed by Linux 2.4 so far and at this point I'd say I still would not run it on a server. (I use FreeBSD, but Linux 2.2, though old, is good as well.)

I'm used to running bleeding edge stuff on my desktop, though. I'm not too upset about the losing my Linux partition thing, since I had most stuff backed up elsewhere.

(In fairness to Linux, I have a VIA686b South Bridge Controller. I think that's the chipset they had the most trouble with by far, though from the descriptions, not all of these bugs are related to it.)

2.4.2 was the latest kernel available at the time of release, and since there have been no gaping security holes and that kernel has proven fairly stable, there's no reason to mess with a good thing.

I beg to differ. There are lots of reported data corruption bugs in all 2.4 kernels prior to 2.4.6:

• 2.4.5 Data Corruption
• Potential Filesystem Corruption With IBM Travelstar 20G Drive
• Massive Filesystem Corruption in 2.4.3
• New Filesystem Corruption in 2.4.2-pre2
• Filesystem Corruption in 2.4.1
• VIA Disk Corruption Continued
• Still Hunting Filesystem Corruption in 2.4
• Temporary Filesystem Corruption Workarounds in 2.4
• Filesystem Corruption Possibly Traced to RAID5 In 2.4
• Unexplained 2.4.0 Filesystem Corruption
• Possible Filesystem Corruption In 2.4.0-prerelease

Linux 2.4.3 ate my hard drive. I booted up, got weird problems...ran an fsck, it failed, saying the superblock was invalid. I specified one of the alternate superblocks...it kept giving me errors. I piped yes into it and let it run. When it was done, my entire filesystem was in little pieces in /lost+found.

That's the most important problem, but there are also a couple reported crashes I believe and, of course, the VM problems (which are still an issue. 2.4.10 has a huge patch to the VM system.)

I've been pretty disappointed by Linux 2.4 so far and at this point I'd say I still would not run it on a server. (I use FreeBSD, but Linux 2.2, though old, is good as well.)

I'm used to running bleeding edge stuff on my desktop, though. I'm not too upset about the losing my Linux partition thing, since I had most stuff backed up elsewhere.

(In fairness to Linux, I have a VIA686b South Bridge Controller. I think that's the chipset they had the most trouble with by far, though from the descriptions, not all of these bugs are related to it.)

2.4.2 was the latest kernel available at the time of release, and since there have been no gaping security holes and that kernel has proven fairly stable, there's no reason to mess with a good thing.

I beg to differ. There are lots of reported data corruption bugs in all 2.4 kernels prior to 2.4.6:

• 2.4.5 Data Corruption
• Potential Filesystem Corruption With IBM Travelstar 20G Drive
• Massive Filesystem Corruption in 2.4.3
• New Filesystem Corruption in 2.4.2-pre2
• Filesystem Corruption in 2.4.1
• VIA Disk Corruption Continued
• Still Hunting Filesystem Corruption in 2.4
• Temporary Filesystem Corruption Workarounds in 2.4
• Filesystem Corruption Possibly Traced to RAID5 In 2.4
• Unexplained 2.4.0 Filesystem Corruption
• Possible Filesystem Corruption In 2.4.0-prerelease

Linux 2.4.3 ate my hard drive. I booted up, got weird problems...ran an fsck, it failed, saying the superblock was invalid. I specified one of the alternate superblocks...it kept giving me errors. I piped yes into it and let it run. When it was done, my entire filesystem was in little pieces in /lost+found.

That's the most important problem, but there are also a couple reported crashes I believe and, of course, the VM problems (which are still an issue. 2.4.10 has a huge patch to the VM system.)

I've been pretty disappointed by Linux 2.4 so far and at this point I'd say I still would not run it on a server. (I use FreeBSD, but Linux 2.2, though old, is good as well.)

I'm used to running bleeding edge stuff on my desktop, though. I'm not too upset about the losing my Linux partition thing, since I had most stuff backed up elsewhere.

(In fairness to Linux, I have a VIA686b South Bridge Controller. I think that's the chipset they had the most trouble with by far, though from the descriptions, not all of these bugs are related to it.)

2.4.2 was the latest kernel available at the time of release, and since there have been no gaping security holes and that kernel has proven fairly stable, there's no reason to mess with a good thing.

I beg to differ. There are lots of reported data corruption bugs in all 2.4 kernels prior to 2.4.6:

• 2.4.5 Data Corruption
• Potential Filesystem Corruption With IBM Travelstar 20G Drive
• Massive Filesystem Corruption in 2.4.3
• New Filesystem Corruption in 2.4.2-pre2
• Filesystem Corruption in 2.4.1
• VIA Disk Corruption Continued
• Still Hunting Filesystem Corruption in 2.4
• Temporary Filesystem Corruption Workarounds in 2.4
• Filesystem Corruption Possibly Traced to RAID5 In 2.4
• Unexplained 2.4.0 Filesystem Corruption
• Possible Filesystem Corruption In 2.4.0-prerelease

Linux 2.4.3 ate my hard drive. I booted up, got weird problems...ran an fsck, it failed, saying the superblock was invalid. I specified one of the alternate superblocks...it kept giving me errors. I piped yes into it and let it run. When it was done, my entire filesystem was in little pieces in /lost+found.

That's the most important problem, but there are also a couple reported crashes I believe and, of course, the VM problems (which are still an issue. 2.4.10 has a huge patch to the VM system.)

I've been pretty disappointed by Linux 2.4 so far and at this point I'd say I still would not run it on a server. (I use FreeBSD, but Linux 2.2, though old, is good as well.)

I'm used to running bleeding edge stuff on my desktop, though. I'm not too upset about the losing my Linux partition thing, since I had most stuff backed up elsewhere.

(In fairness to Linux, I have a VIA686b South Bridge Controller. I think that's the chipset they had the most trouble with by far, though from the descriptions, not all of these bugs are related to it.)

2.4.2 was the latest kernel available at the time of release, and since there have been no gaping security holes and that kernel has proven fairly stable, there's no reason to mess with a good thing.

I beg to differ. There are lots of reported data corruption bugs in all 2.4 kernels prior to 2.4.6:

• 2.4.5 Data Corruption
• Potential Filesystem Corruption With IBM Travelstar 20G Drive
• Massive Filesystem Corruption in 2.4.3
• New Filesystem Corruption in 2.4.2-pre2
• Filesystem Corruption in 2.4.1
• VIA Disk Corruption Continued
• Still Hunting Filesystem Corruption in 2.4
• Temporary Filesystem Corruption Workarounds in 2.4
• Filesystem Corruption Possibly Traced to RAID5 In 2.4
• Unexplained 2.4.0 Filesystem Corruption
• Possible Filesystem Corruption In 2.4.0-prerelease

Linux 2.4.3 ate my hard drive. I booted up, got weird problems...ran an fsck, it failed, saying the superblock was invalid. I specified one of the alternate superblocks...it kept giving me errors. I piped yes into it and let it run. When it was done, my entire filesystem was in little pieces in /lost+found.

That's the most important problem, but there are also a couple reported crashes I believe and, of course, the VM problems (which are still an issue. 2.4.10 has a huge patch to the VM system.)

I've been pretty disappointed by Linux 2.4 so far and at this point I'd say I still would not run it on a server. (I use FreeBSD, but Linux 2.2, though old, is good as well.)

I'm used to running bleeding edge stuff on my desktop, though. I'm not too upset about the losing my Linux partition thing, since I had most stuff backed up elsewhere.

(In fairness to Linux, I have a VIA686b South Bridge Controller. I think that's the chipset they had the most trouble with by far, though from the descriptions, not all of these bugs are related to it.)

2.4.2 was the latest kernel available at the time of release, and since there have been no gaping security holes and that kernel has proven fairly stable, there's no reason to mess with a good thing.

I beg to differ. There are lots of reported data corruption bugs in all 2.4 kernels prior to 2.4.6:

• 2.4.5 Data Corruption
• Potential Filesystem Corruption With IBM Travelstar 20G Drive
• Massive Filesystem Corruption in 2.4.3
• New Filesystem Corruption in 2.4.2-pre2
• Filesystem Corruption in 2.4.1
• VIA Disk Corruption Continued
• Still Hunting Filesystem Corruption in 2.4
• Temporary Filesystem Corruption Workarounds in 2.4
• Filesystem Corruption Possibly Traced to RAID5 In 2.4
• Unexplained 2.4.0 Filesystem Corruption
• Possible Filesystem Corruption In 2.4.0-prerelease

Linux 2.4.3 ate my hard drive. I booted up, got weird problems...ran an fsck, it failed, saying the superblock was invalid. I specified one of the alternate superblocks...it kept giving me errors. I piped yes into it and let it run. When it was done, my entire filesystem was in little pieces in /lost+found.

That's the most important problem, but there are also a couple reported crashes I believe and, of course, the VM problems (which are still an issue. 2.4.10 has a huge patch to the VM system.)

I've been pretty disappointed by Linux 2.4 so far and at this point I'd say I still would not run it on a server. (I use FreeBSD, but Linux 2.2, though old, is good as well.)

I'm used to running bleeding edge stuff on my desktop, though. I'm not too upset about the losing my Linux partition thing, since I had most stuff backed up elsewhere.

(In fairness to Linux, I have a VIA686b South Bridge Controller. I think that's the chipset they had the most trouble with by far, though from the descriptions, not all of these bugs are related to it.)

2.4.2 was the latest kernel available at the time of release, and since there have been no gaping security holes and that kernel has proven fairly stable, there's no reason to mess with a good thing.

I beg to differ. There are lots of reported data corruption bugs in all 2.4 kernels prior to 2.4.6:

• 2.4.5 Data Corruption
• Potential Filesystem Corruption With IBM Travelstar 20G Drive
• Massive Filesystem Corruption in 2.4.3
• New Filesystem Corruption in 2.4.2-pre2
• Filesystem Corruption in 2.4.1
• VIA Disk Corruption Continued
• Still Hunting Filesystem Corruption in 2.4
• Temporary Filesystem Corruption Workarounds in 2.4
• Filesystem Corruption Possibly Traced to RAID5 In 2.4
• Unexplained 2.4.0 Filesystem Corruption
• Possible Filesystem Corruption In 2.4.0-prerelease

Linux 2.4.3 ate my hard drive. I booted up, got weird problems...ran an fsck, it failed, saying the superblock was invalid. I specified one of the alternate superblocks...it kept giving me errors. I piped yes into it and let it run. When it was done, my entire filesystem was in little pieces in /lost+found.

That's the most important problem, but there are also a couple reported crashes I believe and, of course, the VM problems (which are still an issue. 2.4.10 has a huge patch to the VM system.)

I've been pretty disappointed by Linux 2.4 so far and at this point I'd say I still would not run it on a server. (I use FreeBSD, but Linux 2.2, though old, is good as well.)

I'm used to running bleeding edge stuff on my desktop, though. I'm not too upset about the losing my Linux partition thing, since I had most stuff backed up elsewhere.

(In fairness to Linux, I have a VIA686b South Bridge Controller. I think that's the chipset they had the most trouble with by far, though from the descriptions, not all of these bugs are related to it.)

2.4.2 was the latest kernel available at the time of release, and since there have been no gaping security holes and that kernel has proven fairly stable, there's no reason to mess with a good thing.

I beg to differ. There are lots of reported data corruption bugs in all 2.4 kernels prior to 2.4.6:

• 2.4.5 Data Corruption
• Potential Filesystem Corruption With IBM Travelstar 20G Drive
• Massive Filesystem Corruption in 2.4.3
• New Filesystem Corruption in 2.4.2-pre2
• Filesystem Corruption in 2.4.1
• VIA Disk Corruption Continued
• Still Hunting Filesystem Corruption in 2.4
• Temporary Filesystem Corruption Workarounds in 2.4
• Filesystem Corruption Possibly Traced to RAID5 In 2.4
• Unexplained 2.4.0 Filesystem Corruption
• Possible Filesystem Corruption In 2.4.0-prerelease

Linux 2.4.3 ate my hard drive. I booted up, got weird problems...ran an fsck, it failed, saying the superblock was invalid. I specified one of the alternate superblocks...it kept giving me errors. I piped yes into it and let it run. When it was done, my entire filesystem was in little pieces in /lost+found.

That's the most important problem, but there are also a couple reported crashes I believe and, of course, the VM problems (which are still an issue. 2.4.10 has a huge patch to the VM system.)

I've been pretty disappointed by Linux 2.4 so far and at this point I'd say I still would not run it on a server. (I use FreeBSD, but Linux 2.2, though old, is good as well.)

I'm used to running bleeding edge stuff on my desktop, though. I'm not too upset about the losing my Linux partition thing, since I had most stuff backed up elsewhere.

(In fairness to Linux, I have a VIA686b South Bridge Controller. I think that's the chipset they had the most trouble with by far, though from the descriptions, not all of these bugs are related to it.)

2.4.2 was the latest kernel available at the time of release, and since there have been no gaping security holes and that kernel has proven fairly stable, there's no reason to mess with a good thing.

I beg to differ. There are lots of reported data corruption bugs in all 2.4 kernels prior to 2.4.6:

• 2.4.5 Data Corruption
• Potential Filesystem Corruption With IBM Travelstar 20G Drive
• Massive Filesystem Corruption in 2.4.3
• New Filesystem Corruption in 2.4.2-pre2
• Filesystem Corruption in 2.4.1
• VIA Disk Corruption Continued
• Still Hunting Filesystem Corruption in 2.4
• Temporary Filesystem Corruption Workarounds in 2.4
• Filesystem Corruption Possibly Traced to RAID5 In 2.4
• Unexplained 2.4.0 Filesystem Corruption
• Possible Filesystem Corruption In 2.4.0-prerelease

Linux 2.4.3 ate my hard drive. I booted up, got weird problems...ran an fsck, it failed, saying the superblock was invalid. I specified one of the alternate superblocks...it kept giving me errors. I piped yes into it and let it run. When it was done, my entire filesystem was in little pieces in /lost+found.

That's the most important problem, but there are also a couple reported crashes I believe and, of course, the VM problems (which are still an issue. 2.4.10 has a huge patch to the VM system.)

I've been pretty disappointed by Linux 2.4 so far and at this point I'd say I still would not run it on a server. (I use FreeBSD, but Linux 2.2, though old, is good as well.)

I'm used to running bleeding edge stuff on my desktop, though. I'm not too upset about the losing my Linux partition thing, since I had most stuff backed up elsewhere.

(In fairness to Linux, I have a VIA686b South Bridge Controller. I think that's the chipset they had the most trouble with by far, though from the descriptions, not all of these bugs are related to it.)

The KDE team does what they can to run on Linux and other unices, read this for example of how KDE 3.0 is planning to support large file systems both in Linux and in 64 bit file systems.../OS's

There are people in the kde-development lists that have other unices that they can use or use mainly - and if something breaks - this tester/developers tell and almost all the times he's getting answer what went wrong and they're fixing it on the CVS - thats happends with Solaris, SGI, Tru64, FreeBSD... Of course - if an OpenBSD hacker would come along just to report problems (or even gives a hand to fix those problems) - this would benefit the OpenBSD community...

They added a few conspiracy charges against him. It's up to 25 years now.

That should change after KDE 3 is released, since the API will remain stable (binary-compatible even!) for some time, allowing an application base to build up. I think it was the big change from KDE 1 to KDE 2 that made KDE fall behind in the apps department, and GNOME will likely experience a similar phenomenon with its next major release, probably occurring within KDE 3's lifetime.



Unfortunately, KDE 3 will break binary compatibility with KDE 2, which will definitely hurt KDE's application base; KDE 3 will have both API changes and use the new TrollTech Qt 3.0.

From the Linux Kernel Cousin archives "The Road Ahead: KDE after 2.2":

there was concern over third party developers as Waldo Bastian noted saying, "Although I understand the advantages, in general I think that major version updates are very bad for KDE because it fragmentates the efforts of third party developers. There are plenty of applications out there that have never been ported to KDE 2, hell, even in our own CVS we have tons of applications that still have to be properly adapted. (grep for QDialog to see what I mean) In think that KDE's current strength is its framework and that actual applications are its weak points. Moving to Qt 3 is a huge improvement for the framework, but it puts a strain on application developers. Development can go too fast as well, you know. Having a great KDE 3 desktop is nice, but not if we lose all application developers in the process."

"As a senior computer scientist at Adobe, you will help define and implement PKI-based security features for Acrobat in the areas of digital signatures and encryption."

Looks like they got rid of the last idiot who implemented the stupid XOR algorithm. Personally, I think anyone other than Dmitry who fills this job has got the rest of the high-tech community laughing behind his or her back. :)

Credit for finding this amusing listing goes to Rick Moen on the free-sklyarov mailing list archive.