Every year the lkml sees a handful of April 1'st gags, and this year was no exception. One of the more elaborate jokes was Dave Jones [interview]' announcement of a new Linux-like operating system for the x86-64 architecture called "Davix". He begins his announcement, "do you pine for the nice days of Linux-1.1, when men were men and wrote their own device drivers? Are you without a nice project and just dying to cut your teeth on a OS you can try to modify for your needs? Are you finding it frustrating when everything works on Linux? No more all-nighters to get a nifty program working? Then this post might be just for you :-)" Those who go so far as to download the 12MB tarball will find a 2.6.11 kernel stripped down to only support the x86-64 architecture. A README within the tarball explains, "Davix is the result of Linux 2.6.11, lots of rm -rf, and removal of legacy obsolete features such as devfs, i386 architecture support, niche architectures such as ia64, and removal of a whole bunch of other junk, whilst still remaining 'usable'."
Co-postmaster of the lkml David Miller, forwarded a joke email that he had received about the release of the 2.7 Linux kernel, listing the changed files as, "pretty much everything, as usual...". Evgeniy Polyakov offered a patch to remove i386 support from the kernel, calling the architecture "absolutely unused in [the] real world, unsupported by vendors and definitely hard to build from commodity hardware. Due to it's famous bugability there are tons of quirks all over the place in the Kernel tree, so it is only begining. Let's create our OS the best all over the world - let's remove i386." And Jeroen Vreeken offered a benchmark to "measure the performance of the kernel for its most important user group, the kernel hacker." His "results" indicated little change since the 1.2 kernel which he attributed to "either the kernel hasn't regressed for years in this respect (which would mean somebody is doing a fine job indeed) or [...] the average kernel hacker simply doesn't do much usufull anyway..."
From: Dave Jones To: linux-kernel Subject: Free Linux-like kernel sources for x86-64 Date: Fri, 04/01/2005 - 13:45
Do you pine for the nice days of Linux-1.1, when men were men and wrote their own device drivers? Are you without a nice project and just dying to cut your teeth on a OS you can try to modify for your needs? Are you finding it frustrating when everything works on Linux? No more all- nighters to get a nifty program working? Then this post might be just for you :-) I'm working on a free version of a Linux-lookalike for x86-64 computers. It has finally reached the stage where it's even usable (though may not be depending on what you want), and I am willing to put out the sources for wider distribution. It is just version 0.02 (+1 (very small) patch already), but I've successfully run bash/gcc/gnu-make/gnu-sed/compress etc under it. Sources for this pet project of mine can be found at http://www.kernelslacker.org/davix The directory also contains some README-file and a couple of binaries to work under Davix[*] (bash, update and gcc, what more can you ask for :-). Full kernel source is provided. The system is able to compile "as-is" and has been known to work. Heh. Sources to the binaries (bash and gcc) can be found at the same place in /pub/software/. ALERT! WARNING! NOTE! These sources still need Linux to be compiled (and gcc-4.0, possibly 3.x, haven't tested), and you need Linux to set it up if you want to run it, so it is not yet a standalone system for those of you without Linux. I'm working on it. You also need to be something of a hacker to set it up (?), so for those hoping for an alternative to Linux-x86-64, please ignore me. It is currently meant for hackers interested in operating systems and x86-64's with access to Linux. The system needs an AT-compatible harddisk (IDE is fine) and EGA/VGA. If you are still interested, please ftp the README/RELNOTES, and/or mail me for additional info. I can (well, almost) hear you asking yourselves "why?". Hurd will be out in a year (or two, or next month, who knows), and I've already got Linux. This is a program for hackers by a hacker. I've enjouyed doing it, and somebody might enjoy looking at it and even modifying it for their own needs. It is still small enough to understand, use and modify, and I'm looking forward to any comments you might have. I'm also interested in hearing from anybody who has written any of the utilities/library functions for Linux. If your efforts are freely distributable (under copyright or even public domain), I'd like to hear from you, so I can add them to the system. I'm using Ulrich Dreppers glibc right now (thanks for a nice and working system Uli), and similar works will be very wellcome. Your (C)'s will of course be left intact. Drop me a line if you are willing to let me use your code. Davej [*] Yes, the name sucks, but its all some other guys fault. http://www.uwsg.iu.edu/hypermail/linux/kernel/9902.2/0288.html
Mail by Dave Miller :
From: David S. Miller To: linux-kernel Subject: double April fools (Fw: Linux kernel 2.7.0 released) Date: Fri, 04/01/2005 - 06:22
As vger co-postmaster I see some interesting stuff sometimes. Sadly, this guy not only choose a lame april fools posting, he couldn't even post it to the correct email address. (he sent it to *-owner@ which goes effectively to me) So here it is in it's full glory :-) Begin forwarded message: Date: Fri, 01 Apr 2005 01:03:50 +0200 From: Hal9000 To: linux-kernel-announce-owner Subject: Linux kernel 2.7.0 released Linux kernel version 2.7.0 has been released. It is available from: Patch: ftp://ftp.kernel.org/pub/linux/kernel/v2.7/patch-2.7.0.bz2 Full source: ftp://ftp.kernel.org/pub/linux/kernel/v2.7/linux-2.7.0.tar.bz2 Sizes in bytes Compressed Uncompressed ------------------------------------------------------------ Patch 895 3666 Full source 50508495 608465132 ----------------------------------------------------------------------------- This is an automatically generated message. To unsubscribe from this list, please send a message to majordomo@vger.kernel.org containing the line: unsubscribe linux-kernel-announce <your_email_address> ... where is the email address you are receiving this message at. ----------------------------------------------------------------------------- The following files were changed in this release: * (pretty much everything, as usual...) ----------------------------------------------------------------------------- Finally the kernel tree has been forked. The 2.6 tree will now concentrate on stabilization and security issues only, while all the crazy und uncontrolled development experimental shit will continue on the 2.7.x.y(.z?) kernel tree. It was about time! oh yeah... too bad this is just an april fool :(
Mail by Evgeniy Polyakov:
From: Evgeniy Polyakov To: linux-kernel AT vger.kernel.org Subject: [RFC] : remove unreliable, unused and unmainained arch from kernel. Date: Fri, 04/01/2005 - 08:11 Hello, developers. In order to compete with the new upcoming releases of the various OSes, and to join all developers efforts into the one really promising and powerfull direction, I present you following patch, which removes absolutely unused in a real world, unsupported by vendors and definitely hard to build from commodity hardware arch. Due to it's famous bugability there are tons of quirks all over the place in the Kernel tree, so it is only begining. Let's create our OS the best all over the world - let's remove i386. Signed-off-by: Evgeniy Polyakov
Patch by Jeroen Vreeken:
From: Jeroen Vreeken [email blocked] To: linux-kernel AT vger.kernel.org Subject: YABM (Yet another benchmark) Date: Fri, 04/01/2005 - 04:00 Hi, This benchmark was made in response to a recent post here on lkm were Linus indicated he would welcom pretty much any benchmark. Since there are already several database benchmarks, 3d benchmarks I opted for a more down to earth approach. As such I am pleased to announce the 'linux kernel hacker benchmark', a benchmark designed to simulate the activities of the average linux kernel hacker. With this benchmark it should be possible to measure the performance off the kernel for its most important user group, the kernel hacker. This workload turns out to be relativly simple to simulate as can be seen in the attached benchmark program 'lkh-bm.c'. It is compiled with 'gcc -Wall lkh-bm.c -o lkh-bm'. This test has been run on all 2.6 releases and several older kernels dating some years back. Unfortunatly 1.1 and lower kernels aren't able to complete the test. The compiler used was gcc 3.2.3, the cpu a Celeron @ 2.4GHz. I plan to run this test daily on all releases, bk, mm and ac snapshots and maybe more trees on kernel.org asuming nobody objects to me doing a recursive web-suck with wget. At the end of this post you will find the already done benchmarks. As Linus seems to dig pretty pictures a graph has been attached (lkh-bm.gif) with the same results. Surprisingly the number seems to be constant during the last years. This could either indicate that the kernel hasn't regressed for years in this respect (which would mean somebody is doing a fine job indeed) or it could mean that the average kernel hacker simply doesn't do much usufull anyway.... Regards, Jeroen Benchmark results: 1.1.0 0 1.1.20 0 1.1.40 0 1.1.60 0 1.2.0 603 2.0.0 604 2.0.10 605 2.0.20 600 2.0.30 601 2.2.0 602 2.2.10 603 2.2.20 604 2.4.0 605 2.4.10 600 2.4.20 601 2.6.0 602 2.6.1 603 2.6.2 604 2.6.3 605 2.6.4 600 2.6.5 601 2.6.6 602 2.6.7 603 2.6.8 604 2.6.9 605 2.6.10 600 2.6.11 601
kernel 2.7
Wow, that really was lame.. ouch.
The sad thing is that stabili
The sad thing is that stabilization of 2.6 would be more than welcome and using it as a april fools' joke is even sadder.
are you actually having problems or
are you just making noise?
It seems to me that most people who shout about 2.6 being unstable usually don't have any issues with it but are just "being part of the crowd". 2.6 in my experience (yes, on many systems, not just one home box) is that 2.6.11.6 (which is part of the -stable branch which everyone has been shouting for (so stop shouting) btw) is just as (or more) stable than 2.4 ever was - and more featurefull to boot.
Well, it depends on what you
Well, it depends on what you mean with "stable".
You can think as "stable" as something that works great, or you can think as "stable" as something that doesn't change every day.
Both meanings are corrects and useful to judge a kernel.
If need something that works, than kernel 2.6 is good. If you need something that doesn't change too much, maybe you can have something to say about 2.6
stability
I'm beginning to think that the word "stability" has too many meanings to be worthwhile. For example perhaps the poster means code stability. The 2.4 kernel code doesn't change much compared to 2.6. Or perhaps he means API stability in which case the 2.6 kernel is not stable either.
Or other people mean that 2.6 is stable for one application on one architecture. This is almost certainly true but not very difficult.
Or other people use stability to mean that it can't be crashed no matter what you do on whatever hardware. There are certainly hardware configs that are less stable than others. Just Thursday I was using some USB drivers that locked the computer. But really there are no specific numbers to measure this kind of stability.
So basically talking about stability is worthless unless you have a specific example in mind.
You could say: "The tty layer is a peice of crap with race conditions and is unstable". "devfs has design flaws, it isn't tested and it's crap."
No, I'm not just making noise
No, I'm not just making noise here.
Try running a real server with real users with 2.6. The 2.6-series seems superior when it comes to performance, but every single point-release fixes some horrible root-exploit which doesn't exactly help me sleep my nights peacefully.
Trying to reboot a busy production server is something very different from home boxes, and the ones I run with 2.6 have given me enough trouble. Fortunately all the new ones run BSD.
Have you compared the exploits to your risk analysis?
Have you gone looking at the root exploits that are fixed in each kernel version, and compared them to your risk analysis? Every box has some way of getting root access given enough work, it's just that we discount some methods as unlikely (e.g. beat up the sysadmin till he tells you how to log in as him).
Just looking at the root exploits in 2.6.11.6 (for example), the isofs ones shouldn't affect a busy production server (users shouldn't be able to mount arbitrary filesystems), the bluetooth socket fix is only an issue if the server has bluetooth, and the information leak in ext2 is only an issue if you both run ext2 filesystems for general access, and users have read access to the block devices (which provides them with the ability to read other stuff they shouldn't, like /etc/shadow).
Similar results apply if you look at 2.6.10 (one exploit is s390 specific, another requires a hga framebuffer). In short, just because the changelog says "root exploit" doesn't mean you're vulnerable; check the vulnerability against what you run.
Risk Analysis
The risks you mention have already been announced - they're known issues with previous versions of 2.6. I'd fear the upcoming announcements more than the previous ones. I have no way of measuring that risk.
I run 2.6 on my laptop, which has a single user; the rc scripts and firewall helps to make sure it stays that way. Incoming 22/tcp, 80/tcp are allowed (unless I connect it to an untrusted network, in which case those services are stopped).
The way I see it, I'd risk dismissal if I installed 2.6 on a company server. Linux 2.4 - fine, it's a stable system; some bugs will be found and reported and fixed. Linux 2.6 - it's a system still under development. However you define stable, it's not a good way of finding a secure system, even if it turns out to be so well-coded that it never crashes.
I ran pre-release versions of Solaris 10 before it was released - but only on my personal laptop, with no services enabled. I wouldn't consider that a stable release. Installing a pre-release OS on a live server is reckless, at best. When there is no dev tree for hackers to try things in, there can only be two possible outcomes:
I'm not sure I'm too keen on either of these options.
Linux 2.7.X
OMG!! And we all know that fun is fun. Good thing I did not try to use it, lol, if it were even real. Found out my problems with 2.6.11.6, I need a new NIC, bad NIC bad NIC, going for a 3 Com card to make the new 2.6.11.6 work correctly.
The link to Evgeniy Polyakov'
The link to Evgeniy Polyakov's patch, which removes i386, is wrong (it links to the kernel hacker benchmark) :-)
Linux forks
Linux is Open Source and should not be restricted to only one kind of division. Although too late for this April, I shall be working on Linux Knives and Spoons for next year...
Later, we can merge those sep
Later, we can merge those separate divisions together into Linux Spork.
Later, fork again!
Then later fork Linux Spork.