Behind the Scenes in Kernel Development

An anonymous reader writes "Some interesting changes took place in the way the Linux kernel is developed and tested. In many ways, the methods used to develop the Linux kernel are much the same today as they were 3 years ago. However, several key changes have improved overall stability as well as quality. This article takes a look behind the scenes at the tools, tests, and techniques -- from revision control and regression testing to bugtracking and list keeping -- that helped make 2.6 a better kernel than any that have come before it." We might as well mention here (again) that a couple of new kernels are out: leif.singer writes "2.6.3 and 2.4.25 are out, fixing another vulnerability in do_mremap()."

Comments

GOOD WORK KERNEL MAKING PERSONS

[Jerk City Troll]

G00D KERNEL MAKING PERS0NS SH0ULD HAVE A NICE TIE

Upgrade ain't gonna happen.

[Anonymous Coward]

Uptime uber alles!

coward@server:/usr/warez/torrent$ uname -a ; uptime
Linux server 2.4.21 #8 Wed Jul 9 20:33:22 CEST 2003 i586 GNU/Linux
15:51:40 up 196 days, 1:50, 1 user, load average: 0.01, 0.05, 0.07

Re:Upgrade ain't gonna happen.

[Anonymous Coward]

i586 GNU/Linux

AHHAHAHAHA! Which distro is that? I need to know, so that I can recommend to my colleagues to stay away from that GNU/Hippy propaganda!

Re:Upgrade ain't gonna happen.

[Anonymous Coward]

It'll be Debian so you needed worry, your colleagues wern't going to be using it anyway.

Re:Upgrade ain't gonna happen.

[Anonymous Coward]

1 user, load average: 0.01, 0.05, 0.07

And that would be, because your GNU/Linux box doesn't seem to be doing anything...

Kernel development interests me terribly

[ObviousGuy]

I wish I could wrap my head around even the smallest part of the kernel. There is so much code in there and aside from main(), it is hard to find a good place to start studying.

Would these tests be a good starting place?

Re:Kernel development interests me terribly

[deadlinegrunt]

Find a particular functionality of the kernel that really interest you; read any documentation you can find about it; then grep the src till you see the relevant sections of code and start perusing with your $(EDITOR)

Much time is spent teaching people how to write code but never really reading it. This is a perfect example of how to do it and why you would.

Re:Kernel development interests me terribly

[millahtime]

"Much time is spent teaching people how to write code but never really reading it. This is a perfect example of how to do it and why you would."

Reading code can be a huge help in becomeing a better coder. You see how other coders do things. Learning from their bad on what not to do and seeing new good methods you may not have come up with on your own.

Re:Kernel development interests me terribly

[Rosco P. Coltrane]

I wish I could wrap my head around even the smallest part of the kernel. There is so much code in there and aside from main(), it is hard to find a good place to start studying.

You could contribute some work to SCO: I hear they're very interested in having someone sprinkle several "printk("(c) SCO\n");" lines here and there in init/main.c, since they can't do it themselves, having no technical department, being a law firm and all...

Re:Kernel development interests me terribly

[tcopeland]

Code Reading by Diomidis Spinellis contains a bunch of ideas on ways to comprehend large codebases more easily.

He talks about browsing code, package structures, adding features or fixing bugs in a large codebase, and so on. It's a good read - well worth the money.

Re:Kernel development interests me terribly

[Anonymous Coward]

Your best bet to learn kernel hacking would not be to start working on a vast mass of code like Linux. Try hacking something smaller and easier to understand, like Minix or Syllable.

Re:Kernel development interests me terribly

[JuliusRV]

"Linux Kernel Development" is a nice introduction book by kernel hacker Robert Love, and it already covers the 2.6 Kernel.

It doesn't go into too much detail, but it gives a very good overview and basic understanding of the issues you have to deal with in the kernel! I'm currently reading it and getting enlightened :-)

Re:Kernel development interests me terribly

[po8]

Does the fact that Diomidis Spinellis has repeated won the International Obfuscated C Code Contest (IOCCC) make him more or less qualified to write such a book :-)? Check out his "best abuse of the rules" entry from 1988 that is my all-time favorite. BTW, the contest is currently open.

Re:Kernel development interests me terribly

[tcopeland]

> Does the fact that Diomidis Spinellis has
> repeated won the International Obfuscated
> C Code Contest (IOCCC)

Heh :-) Yup, he talks about that a bit in the book, and makes the point the to IOCCC winners usually employ the preprocessor in their entries.

Then he goes on to suggest that preprocessor usage be minimized in 'normal' programming activities :-)

Re:Kernel development interests me terribly

[realdpk]

This isn't Linux, but it is definitely an interesting read if you want to learn how a kernel works. The Design and Implementation of the 4.4 BSD Operating System.

It's a bit expensive, since it's also apparently a textbook, but I think it is worth it. Reads easy, too.

Re:Kernel development interests me terribly

[phnork]

I found a hacker who has contributed some code to the kernel development. When I asked him to explain his contribution, he smiled and started talking. The words went in one ear and off a duck's back, but I was impressed that a mere mortal could be in front of me and talking about this esoteric topic. It's definitely worth persuing. Good luck. phnork

Re:Kernel development interests me terribly

[pavon]

This is exactly why Universities should have the senior or junior CS design-project be to add some significant functionality to an existing large project. There simply isn't enough time to build something that large from scratch in that short amount of time, and the things you learn from working with a large codebase are invaluable. Furthermore, in the real world you will spend much more time improving other people's code then you will writing from scratch anyway.

Re:Kernel development interests me terribly

[slamb]

I wish I could wrap my head around even the smallest part of the kernel. There is so much code in there and aside from main(), it is hard to find a good place to start studying.

Very recently, I've been writing some low-level code. There was a long while I'd thought this was out of my league. Then I realized several things:

• I was not happy with several characteristics of the low-level code other people had written and I was depending on.
• I had done some more low-level stuff long ago - like a couple simple but legitimately useful assembly programs in DOS, and even a patch that added a sort of capability system to the OpenBSD kernel. (I never polished up the patch enough to send it in to them or anything, but the point is that it essentially worked, and I wasn't afraid to take it on.)
• When I'd done those things back in the day, I wasn't anywhere near as good a coder as I am now.
• The only reason I'd been unable to do these things more recently is an attitude that I'm not good enough, not a reality. (It's an attitude a lot of people in low-level code promote, I think. They so much don't want to waste their time with people who really are bad that they probably don't mind scaring off a few people who are in fact good but don't realize it. Also, I think there's ego involved - it's an exclusive club, why not let it stay that way.)

So I think the moral of the story is to just be fearless/persistent. If you're not confident, there are plenty of ways you can improve without even involving anyone else:

• Read the code. It sounds obvious, but there's a lot of code I'd stayed away from even looking at because of intimidation.
• Try experiments. Make a change, set a hypothesis about what it will do, and run it. Then see why you were wrong, if you were. Then try it again. Even just getting in the habit of running the build system will help, and setting up experiments like this will help your debugging.
• Find something lacking and try to fix it.

And then, if you're still not comfortable talking on the linux-kernel list, I think you have at least another couple choices:

• If you're lucky, you're friendly with someone more skilled and can use him/her to screen questions.
• There's a couple lists like kernel-janitors and kernel-newbies to dip your feet in the water.
• Sometimes in the process of writing an eloquent question through email you'll figure out the answer yourself. (Did you see the teddy bear anecdote in the debugging link above?)

As for myself, I'm taking my own advice to make sigsafe - an alternate set of system call wrappers (libc level) that eliminate a couple race conditions involving signals, without a performance penalty. It's going well - the code works, and I have a race condition checker and microbenchmark to prove it. I just released my first version. Now I'm working on the documentation; it still needs a lot of work. (I could use plenty of help with this project! If you want to try low-level programming, it's a great way. It requires writing assembly for each combination of operating system and architecture. I've only written it for two systems. There are plenty left, and public systems to do it on if you don't have access to exotic machines of your own. Plus, you can hopefully gain some low-level understanding by proof-reading and helping me write the documentation.)

Once I have that polished, I've got a couple projects I might try in the Linux kernel (and/or other kernels):

• implementing a couple of system calls - the nonblocking_read(2) and nonblocking_write(2) that djb mentions.
• implementing SO_RCVTIMEO and SO_SNDTIMEO under Linux. Assuming no one has yet; I haven't checked, so the manpage could just be out of date. Which brings m

Re:Kernel development interests me terribly

[WindBourne]

I will assume that you are serious.

While testing is one way, you might try doing janitorial work or some of the simple stuff.

If you have good coding skills, try newbies, otherwise, you may find testing is up your ally.

Re:Kernel development interests me terribly

[Anonymous Coward]

I'm posting anonymously for obvious reasons.

I'm a graduate assistant at Harvard who grades students' code to support my graduate studies. I would not recommend you learn any part of the kernel because of the controversy with the SCO case.

I've graded a lot of code as part of my job, and am pretty good at finding students who have copied code and cheated. Looking at the code snippets that SCO has released and comparing them with the relevant portions of the Linux kernel, I've never seen a more obvious form of cheating.

I'd recommend you study the recently released win2k source or the FreeBSD source, whose legality is more established.

Re:Kernel development interests me terribly

[Sweetshark]

For german geeks I can only recommend "Linux Kernelarchitektur" by Wolfgang Mauerer - it is a good introduction and well written. The only thing annoying is that it has a few typos and sometimes skips some details (like Reiserfs) - although this is obviously unavoidable - the book still has 770 pages.

Re:Kernel development interests me terribly

[Anonymous Coward]

#include "/dev/tty"

Huh? Is that so fun?

Re:Kernel development interests me terribly

[slamb]

Try experiments. Make a change, set a hypothesis about what it will do, and run it. Then see why you were wrong, if you were. Then try it again. Even just getting in the habit of running the build system will help, and setting up experiments like this will help your debugging.

An addendum: your experiments don't have to be anything spectacular. Here are a few:

• Try adding a few printk statements throughout the code, decide when you expect they will print and what they will say, and confirm it.
• Try tuning a sysctl or hardcoded value. See how it affects performance. Do microbenchmarks or benchmark real systems. Make pretty graphs. (Graphs are fun!)
• Add a likely() or unlikely() option to help the compiler's branch prediction. Again, test the performance. Or take one away - it's possible someone was wrong about the performance

And in user-level code, there are even more things you can do:

• compile with -ftest-coverage to see what code is run and design unit tests to that uses every line. This will help your understand, could find existing bugs or dead code, and will help you be confident in your changes if you later make any.
• compile with -ftest-coverage -fprofile-arcs to see what code branches are very likely or unlikely to be taken, then use likely() and unlikely() to change the branch prediction. Benchmark the results.

Another project I've considered is adding likely() and unlikely() equivalents to boost. A lot of people use this code, so increasing its performance a little would be pretty beneficial.

Re:Kernel development interests me terribly

[bucky0]

Cool suggestions, I had 2 questions though:

Is there any nifty way to speed up the compile->execute cycle? The way I see me coding is:
a)code
b)compile
c)reboot test machine and wait 1-3 minutes for it to come up
d)see if it worked
e)goto (a)

step C could be frustrating, is there a quicker way to go about it?

Also, what is the likely() and unlikely() functions you speak of. Google shows a lot of unrelated info.

Thanks

Re:Kernel development interests me terribly

[slamb]

Is there any nifty way to speed up the compile->execute cycle? The way I see me coding is:
[...]
c)reboot test machine and wait 1-3 minutes for it to come up
[...]

step C could be frustrating, is there a quicker way to go about it?

You could making your changes to a User-mode Linux kernel to avoid the reboot. Or running it inside a virtual machine. That way you only have the kernel's boot time, not the main system BIOS, ATA-100 BIOS, SCSI BIOS, etc.

Also, what is the likely() and unlikely() functions you speak of. Google shows a lot of unrelated info.

They're macros that tell the compiler if the expression contained within is likely to be true or false. There's an article about them here. If you've ever seen any code that mentions __builtin_expect, it's the same thing with better names:

#if COMPILER_SUPPORTS_BUILTIN_EXPECT
#define likely(condition) __builtin_expect(!!(condition), 1)
#define unlikely(condition) __builtin_expect(!!(condition), 0)
#else
#define likely(condition) (condition)
#define unlikely(condition) (condition)

Re:Kernel development interests me terribly

[Anonymous Coward]

ccache - http://ccache.samba.org/
Safe compiler cache if you do "make clean" a lot.

distcc - http://distcc.samba.org/
Simple, fast compilation cluster software.

Both are great.

Re:Kernel development interests me terribly

[Anonymous Coward]

That's a rather pathetic troll; keep practicing.

Re:Kernel development interests me terribly

[Anonymous Coward]

:) :) :)

Re:Kernel development interests me terribly

[Dalcius]

I agree.

I'm a firm believer that all CS curriculum should have two classes for the sophomore year entitled "Real World Programming Part 1 & 2". Part 1 consists of an entire semester writing a user application to meet a loose set of design specifications.

In part 2, the students drop their own code and inherit another student's codebase from part 1. Part 2 will consist of dropping 30% of the functionality, altering another 40% of it and then adding in another set of features about half the size of the original design specification.

And in both parts the students will be under the gun to meet due dates.

Why? Because this is how it happens in the real world. Working on other programmer's bad code, bad specifications, impossible due dates, management which doesn't understand application development, etc.

The problem with all these damn college graduates is that they have no clue what it is like to maintain software. Hence, they get out of school and take about 3-5 years to pick up any kind of clue about good code. Their code is thrown together, barely tested, wasn't developed with a user in mind and doesn't catch more than 20% of possible errors.

What does all of this add up to? A bunch of n00b programmers writing crufty, unmaintainable code, ignoring existing libraries and refusing to write new ones. After years you end up with a product which has outgrown its original design and doubled in size and complexity and is impossible to maintain without hacks or rewrites.

How would I know? I got to spend almost two years taking problem reports and debugging my company's software.

Colleges who teach how to maintain but don't teach why turn out, all in all, nearly worthless programmers who make the long-haul very difficult.

Sorry for the rant.

Cheers

Re:Kernel development interests me terribly

[avandhar]

I could not agree more (or less). Though, I would have to point out that, while schools could do more about this subject, in the end it comes down to the person behind the keyboard.

I manage a department, which includes about 20 programmers and some do it right from the start (and right out of a school), and some don't.

What is interesting, while not maybe surprising, is that women tend to document their code better and also write more maintainable code. This observation is prone to errors (most of the programmers are guys in my dep.), but still.

There seems to be also a correlation with the talent. The better programmers usually grasp the idea of writing generic and maintainable code faster. Perhaps that is because they have to fix other peoples code.

My two and half cents.

Oh no, another one.. poor *BSD

[Anonymous Coward]

It was announced some time ago, YET ANOTHER key person left the *BSD core!!!Diletant dabblers are the only ones tinkering *BSD kernels now.

Automatic Testing

[4of12]

I can't say how much I appreciate the automatic tests. This is applying computers to a thankless task that they're suited for.

Now if they only had a web dashboard portal showing the latest results in an easily-assimilated color coded HTML table....

Re:Automatic Testing

[tcopeland]

> a web dashboard portal showing the latest
> results in an easily-assimilated color
> coded HTML table

So true. I've set up one of these for a project I work on, and it's really helpful to be able to see at a glance the status of a bunch of projects.

Seems like some lintish tools could be incorporated into a kernel daily build, and maybe something like CPD as well...

Re:Automatic Testing

[platypus]

Alas, while I'm in doubt about the "easily assimilated" part, they have a lot of reports there at
http://www.osdl.org/lab_activities/kernel_test ing/

Just look around there.

Whatever it is, it's working...

[bc90021]

I don't know what they've done in terms of changing things, and I didn't RTFA. What I do know is that I've been using the 2.6 kernel on my new ThinkPad T40, and the machine is FAST, and stable. Hats off to all reponsible.

Kernel quality

[Rosco P. Coltrane]

However, several key changes have improved overall stability as well as quality.

I have a suggestion : how about not calling development kernels with an even version number?

- 2.6.0-beta-something kernels were bad (okay fair enough, it was beta, and Linus admitted having called a 2.5.x kernel 2.6 in order to lure early adopters and get them to test it).

- 2.6.0, 2.6.1 and 2.6.2 were unstable for me, with doozies such as oopses while rmmoding and random crashes using ide-scsi (yes I know it's deprecated, but some of us need it).

I now run 2.6.3-rc3 and it's the first time it seems stable enough to be called a 2.6 kernel. There are some problems left, but overall it's getting decent. But then why are the others "2.6" kernel called 2.6 at all? they were really 2.5 kernels imho.

This has happened before, with the beginning of the 2.4 serie. I only felt it was getting good enough at version 2.4.6 and above (I'm not counting the failed 2.4.11 release). When 2.4.0 went out, I thought it meant it was ready for prime time, like 2.2.0 was, or at least was more, but no it was crap. I was slightly annoyed with Linus then, but I thought he had been pressured by commercial Linux shops and that he wouldn't do it again. But no, he did it again with 2.6.

It's really quite annoying, because those who follow Linux know the first "stable" kernels aren't stable at all, therefore avoid it, therefore defeat the point of testing it for Linus, but beginners think "cool, a new stable kernel", try it and are disappointed, giving a bad name to an otherwise great kernel. Too bad ...

Re:Kernel quality

[Psiren]

This is a chicken and egg situation. Unless there is widespread testing of a kernel, some bugs won't be found. But not everyone wants to risk running a development kernel, so the only way to get them to test is to bend the truth slightly, and call a beta version the new stable kernel. At the end of the day, the number just reflects the developers opinion on the stability of the thing as a whole. They could make no changes to 2.6.3 and release it as 2.7.0, but that wouldn't make it any less unstable.

Re:Kernel quality

[Rosco P. Coltrane]

the only way to get them to test is to bend the truth slightly, and call a beta version the new stable kernel

I realize that, but what I'm saying is that those in the know get burnt a couple of times, then see through the bullcrap and silently renumber the kernel versions. In the end, early adopters are pissed off because they've been lied to a little, and swear never to try newer stable versions again, newcomers get disgusted by the quality of early stable releases, and Linus doesn't get the testing he wanted that made him bend the truth in the first place, therefore everybody loses.

I'd much rather see Linus say : "here, there's this 2.5, we call it 2.5.xx-RC-something. It's close to 2.6, but not quite. *PLEASE* test it for us *PLEASE*!, that'll allow 2.6.0 to be good". He could even have a "best testers" or "more devoted QA volunteers" list prominently displayed on the main page at kernel.org, to appeal to people's sense of ego.

At least that would be a more honest approach to testing new kernels than lying to people.

Re:Kernel quality

[GrenDel Fuego]

- 2.6.0, 2.6.1 and 2.6.2 were unstable for me, with doozies such as oopses while rmmoding and random crashes using ide-scsi (yes I know it's deprecated, but some of us need it).

Out if curiosity, why do you need ide-scsi? Most people in the past used it for CD burning under linux, but ide-scsi is no longer a requirement for using ATAPI cd burners.

There are other uses as well (tape drives for example), but they're generally a lot less common.

Re:Kernel quality

[redKrane]

Man, come on dog, it is after all a free Operating System kernel. I bet you bitch about rain being wet...

Re:Kernel quality

[Anonymous Coward]

and random crashes using ide-scsi (yes I know it's deprecated, but some of us need it).

disable ide-scsi and use latest cdrecord with

dev=ATAPI:x,x,x

instead of

dev=x,x,x

and everything is cool. Don't forget to check lilo.conf. Stop using cdrdao. Ignore xcdroast's "This would be faster is you had ide-scsi enabled" dialogs.

This should apply to almost every kind of ide-scsi use.

Re:Kernel quality

[Rosco P. Coltrane]

Out if curiosity, why do you need ide-scsi? Most people in the past used it for CD burning under linux, but ide-scsi is no longer a requirement for using ATAPI cd burners.

I need(ed) it because I could not, for the hell of me, get a POS Mitsumi CD burner to work any other way. The other reason I want(ed) it was because I tend to dislike breaking things that work, such as init scripts, fstab, symlinks and various script thingy I made that expect the burner to be a scsi device, and other scsi devices to appear in a certain order when detected at boot time.

This said, I said "needed" and "worked" because I went buy a new burner yesterday and changed things to work with 2.6 (since I was messing with that box anyway). The Mitsumi was a 4x burner and it was high time :-)

Re:Kernel quality

[A.T. Hun]

Actually, there's a new version of cdrdao out that supports ATAPI burners without the need of ide-scsi.

Also, I'm not sure what hardware the original poster has, but I had no problem with 2.6.1 or 2.6.2. As always, YMMV.

Re:Kernel quality

[Anonymous Coward]

JFC!!!
It's only common sense a dot 0 release, or even dot 1 dot 2 release is going to have bugs!
It's the nature of software and humans mixing.
I bet you'll complain 2.8.0 is full of problems...
guess what, I'll help you out.... 2.8.0 is going to be problematic. No need to try it until it stabilizes.

Re:Kernel quality

[Rosco P. Coltrane]

Man, come on dog, it is after all a free Operating System kernel. I bet you bitch about rain being wet... that's my word, holla...

My friend, not everybody uses Linux just for shits and giggle, and for the heck of saying "Windoze sux0rs" to buddies. I actually need to get work done with my Linux boxes, and so when a stable kernel isn't stable, it pisses me off.

Also, FYI, I reckon I have a certain right to be annoyed because I contribute code back to the free software community, in the form of userland software projects and specialized Linux drivers. It's not much perhaps, but I'm not just a freeloader who should be happy with what he gets for free.

Re:Kernel quality

[Trashman]

In a previous story re: 2.6.x someone mentioned that PS/2 (the interface, not the Game system) Mouse support is broken w/ 2.6 if you're using a KVM switch. I have experienced this problem w/ 2 different KVM setups (one at work and one at home) and wondering if this has be resolved.

In a nutshell; The problem occurs when I switch back and forth between machines my mouse stops working or goes erratic. (the work-around is to restart gpm and then X) I dropped back to 2.4.24 because it doesn't have this problem.

Re:Kernel quality

[Anonymous Coward]

Linus never claimed everything was working 100%. In fact, if you followed the list, quite the opposite. That is not what 2.6.0 meant at all. He's not lying, your just reading into what 2.6.0 way way too much. And he did do the '2.6 but not quite' thing a good bit with the 2.6rc's.

Name me one piece of software that worked as expected with a .0 relase.

Re:Kernel quality

[adrianbaugh]

That's exactly what Linus does: there is such a series of release candidates (first introduced prior to 2.4). You can argue that it isn't long enough, but there's an obvious counterargument that if you wait forever nothing will ever get released.
I can't think of a x.y.0 release of any software project that's been properly stable. It's not just linux, it's the way the world is. You could argue that software never ever becomes perfectly stable: marking a series as "stable" is really just shorthand for good enough that further development is largely maintenance, therefore we expect the structure and codebase to remain stable", not some guarantee that they'll never go wrong. It's more a development term than a performance or reliability term, though the stability of development generally arises from the performance and reliability being sufficient to obviate the need for large changes to the code.

Even quite late in stable kernel release cycles there's occasionally a shocker - anyone remember 2.0.33?

If you don't like those kernels, just stick with 2.4 until a distribution ships with 2.6.8 or so. For what it's worth 2.6.(1+) has been fine for me.

Nobody's lying to you - there has to be some cut-off where a kernel series is declared stable, and by and large I think Linus judges it pretty well.

Re:Kernel quality

[Anonymous Coward]

I think you're misunderstanding the kernel versioning scheme. Even-numbered kernels are stable as in "not changing". New features aren't added. They are not necessarily stable as in "robust". Wait a few point versions and things will get better.

Re:Kernel quality

[Anonymous Coward]

I invite you to look up the term "banana software", and you'll see that before Microsoft made it a common practice in the software industry, it was not acceptable to ship immature products with a "stable release" sort of version number. Maybe you're too young to remember that...

There's no problem with immature software, but they should be labelled as such. No need to try to fool people with stable release numbers, since everybody knows it's bollocks.

Re:Kernel quality

[MikeCapone]

I don't think that production people use the early stable kernels anyway (especially since most distros aren't even using it yet).

That leaves people like me who use it on the desktop (and I haven't had a single problem from 2.6.0 onward) and geeks who test it on non-vital server boxen.

I don't think it's much of a problem, frankly.

Re:Kernel quality

[b17bmbr]

because waiting for a final release to be stable, secure, and thoroughly tested has worked for microsoft, and we wouldn't want to do things their way.

Re:Kernel quality

[swillden]

It's really quite annoying, because those who follow Linux know the first "stable" kernels aren't stable at all, therefore avoid it, therefore defeat the point of testing it for Linus, but beginners think "cool, a new stable kernel", try it and are disappointed, giving a bad name to an otherwise great kernel.

The problem here is not with the kernel numbering, it's with your understanding of the kernel numbering. An even-numbered kernel is "stable" in the sense that the developers promise they will not muck with the kernel in deep ways, such as changing APIs or replacing VMs (er... well, usually). It is *not* necessarily stable in the sense that it works without problems.

This is why you never see Linux distros jumping on early stable versions as their default kernel, they know that you have to wait a while and let the early bugs be shaken out.

As to whether or not the use of the word "stable" is intended to fool newbs who don't understand this into doing testing -- I don't think that's the case.

But, hey, if it works... ;-)

Re:Kernel quality

[Anonymous Coward]

bwhahahahahahahahah

someone HAS to +5 Funny this. o man.

Re:Kernel quality

[Anonymous Coward]

He's been saying just that for the last twenty revisions of 2.5.x and nobody but the usual core testers cared. That's why.

Re:Kernel quality

[Gollum]

You mean something like the 2.6.0-test series? Which started with the following post, 5 months before the final 2.6.0 was released:
Linus Torvalds: Linux 2.6.0-test1
Jul 14 2003, 09:16 (UTC+0)
Ok, the naming should be familiar - it's the same deal as with 2.4.0.

One difference is that while 2.4.0 took about 7 months from the pre1 to the final release, I hope (and believe) that we have fewer issues facing us in the current 2.6.0. But very obviously there are going to be a few test-releases before the real thing.

The point of the test versions is to make more people realize that they need testing and get some straggling developers realizing that it's too late to worry about the next big feature. I'm hoping that Linux vendors will start offering the test kernels as installation alternatives, and do things like make upgrade internal machines, so that when the real 2.6.0 does happen, we're all set.

Linus

Re:Kernel quality

[ncr53c8xx]

oopses while rmmoding

I thought rmmmod support was removed or at least deprecated in the latest kernel? Any kernel hackers care to clear this up?

but beginners think "cool, a new stable kernel", try it and are disappointed, giving a bad name to an otherwise great kernel.

Why would beginners be installing a new kernel? The distros would have the latest features patched into their supported kernels. In any case, if you are installing kernels, you should at least read kernel traffic.

Re:Kernel quality

[pohl]

For what it's worth, 2.6.0 and the subsequent minor revisions have worked flawlessly for me and many associates. You seem quick to assume that they named it a "stable release" prematurely. Have you considered the altertnate hypothesis that you are in the minority of users who have encountered problems? If so, that's not a dishonorable place to be...somebody has to be the poor soul who encounters a bugs. (Thank you, by the way, I appreciate your hardship.)

Re:Kernel quality

[thue]

dev=ATAPI:x,x,x

dev=/dev/hdc works for me. Seems simpler.

Re:Kernel quality

[jguthrie]

All this does is point out the folly of attempting to label some versions of software as "stable". How do you, or anyone, KNOW that it's going to be stable? Well, the only reliable way to do that is to run said software for a while under production conditions. Even that is uncertain. So, either you adopt a kernel early on and expect problems, or you wait for others to try the kernel first and hope that they discover all the problems for you. I do the former, others do the latter.

From my perspective, the difference between the "experimental" kernels and the "stable" kernels lies in a difference in direction and emphasis. With the "stable" kernels, changes are usually more about fixing defects than about changing or adding features. With "experimental" kernels, the emphasis is more on changing or adding features with less concern for the people who might try to use the kernel to do real work. However, that doesn't mean that a "stable" kernel will work, for fixes may beget other problems and it doesn't mean that an "unstable" kernel might not be solid as a rock, for the intent is to make the new features work well.

Early "stable" releases are probably best approached with caution, and not just because the kernel itself may be unstable. In my case, the problems I ran into with 2.6.0-testN kernels had to do with the fact that there's some pretty big changes in the way things are supposed to be done so a lot of the supporting software had to be fixed. (See, for example, some of the defect logs for Debian's initrd-tools package, where my email address appears a few times as I reported problems so that Mr. Xu could fix them.) Once I got the kernels installed and bootable, I didn't have issues with stability. Not at the house.

On the other hand, the SCSI driver from 2.6.1 refused to function at all on my work machine, but it did work on similar hardware at home. I never nailed that problem down because 2.6.2 appears to work on both machines.

Re:Kernel quality

[WNight]

Part of the confusion is that 'stable' refers to the interfaces, as well as to the code maturity and crash-proofness.

There's no guarantee a module from 2.5.x will work on 2.5.x+1, where a module (ignoring bugs) from 2.6.0 will work in 2.6.60.

If you want crash-proof, wait for RedHat or Suse or someone to package the kernel for you. If you want stable interfaces so you can begin to develop your kernel module, or whatever, then grab 2.6.0 straight off the presses, but maybe don't put your valuable data on it right away.

Re:Kernel quality

[Anonymous Coward]

I can't think of a x.y.0 release of any software project that's been properly stable. It's not just linux, it's the way the world is.

Well, MS made sure that Windows NT had so much testing, they didn't even release a version 1.0. Heck, they even kept 2.0 and 3.0 in house for testing. It took all the way up to version 3.51 before it was stable enough for public release. That's true dedication to producing a stable product!

Re:Kernel quality

[Short Circuit]

Are you sure the problem's not with gpm? Whenever my mouse accidentally came unplugged, I restarted gpm and everything worked fine.

Of course, I use a USB mouse now, so I don't know.

Versions of Windows up through ME had the same problem. I'm not sure, but I'd guess that PS/2 mice need to be bootstrapped.

Re:Kernel quality

[Trashman]

pretty sure. like I said I dropped back to 2.4 and this behavior is non-existant. oh, and forgot a step: I have to rmmod ps2mouse and then modprobe ps2mouse then restart gpm then everything works again. The part about restarting X only fixes a problem with my pointer turning into a big square when I switch to a VC (but I know that's X's fault.)

Re:Kernel quality

[Crazy Eight]

My experience has been the opposite. I've found the 2.6.x releases to be very stable on x86 and ppc. I think I hit one oops in the -beta-foo days but haven't seen another one since. This is of course a YMMV type of situation. I just want to add a counter anecdote to the discussion because my impression has been that pains were taken to give 2.6 a better birthing than 2.4 had and (to me at least) it shows.

Post: -1, Redundant

[HoldmyCauls]

"2.6.3 and 2.4.25 are out, fixing another vulnerability in do_munmap()."

The announcement for 2.6.3 and 2.4.25 was yesterday, and the vulnerability to which the link in the text above refers was with mremap, not munmap; there's also another vulnerability with mremap mentioned yesterday as an *update* to the kernel announcement.

Re:Post: -1, Redundant

[szo]

This means 2.4.25 is still vulnarable by the do_mremap bug?

Szo

MOD PARENT UP

[Anonymous Coward]

We really have to admit that FreeBSD is in decline. In all likelihood, there may be only one more (or possibly two) release before FreeBSD goes away forever.

I know it is now almost a mantra set in stone that "FreeBSD is dying". Unfortunately, the abuse of that fact by trolls has obscured the truth, that truth being that FreeBSD really is dying.

My main reason for moving away from FreeBSD has been twofold. First, to avoid the constant political infighting and bickering. And secondly, to investigate more promising and viable entries into the operating systems sweepstakes. FreeBSD is no longer a legitimate player, I'm sorry to say.

SCO

[rauhest]

Without RTFA (of course), I tried to find any reference to "sco".

The only match was "a misconfigured system". :)

ACPI cure for 2.4.25 HOW-TO

[Quietti]

Was here in yesterday's thread about 2.4.25 and 2.6.3 releases.

The Tao of Linux

[Anonymous Coward]

Something forms itself from the silent void of the empty mailing lists and the noisy chaos of the crowded mailing lists. It shapes and protects us, it entertains and challenges us, it aids us in our journey through the ether world of software. It is mysterious; it is at once source code and yet object code. I do not know the name, thus I will call it the Tao of Linux.

If the Tao is great, then the box is stable. If the box is stable, then the server is secure. If the server is secure, then the data is safe. If the data is safe, then the users are happy.

In the beginning there was chaos in *ix.
Tanenbaum gave birth to MINIX. MINIX did not have the Tao.
MINIX gave birth to Linux 0.1 and it had promise.
Linux gave birth to v1.3 and it was good.
v1.3 gave birth to v2.0 and it was better.
Linux has evolved greatly from its distant cousins of the old. Linux is embodied by the Tao.

The wise user is told about the Tao and contributes to it. The average user is told about the Tao and compiles it. The foolish user is told about the Tao and laughs and asks who needs it.

If it were not for laughter, there would be no Tao.

Wisdom leads to good code, but experience leads to good use of that code.

The master Cox once dreamed that he was a Kernel. When he awoke he exclaimed: "I don't know whether I am Cox dreaming that I am a Kernel, or a Kernel dreaming that I am Cox!"
The master Linus then said: "The Tao envelopes you. You shall create great code for Linux."
"On the contrary," said Cox, "The Tao has already created the code, I will only have to find it and write it down."

A master was explaining the nature of the Tao to one of his students:
"Is the Tao in the VM subsystem?" he asked. "Yes," replied the master.
"Is the Tao in the scheduler?" he queried again. "The Tao is in the scheduler."
"Is the Tao even in the modules?" "It is even in the modules," said the master.
"Is the Tao in the Low-Latency Patch?"
The master frowned and was silent for much time.
"You fail to understand the Tao. Go away."

The Tao is the yin and the yang. It is the good and the evil, it is everything and yet it is nothing, it is the beginning and the end.

The Tao was there at the kernel compile, and it will be there when the kernel panics.

A novice user once asked a master: "Why compile in C when C++ is more popular?"
"Why a monolithic kernel when Mach is more popular?"
"And why use ReiserFS when ext2 is more popular?"
The master sighed and replied: "Why run Unix when NT is more popular?"
The user was enlightened.

A frustrated user once asked a master: "My kernel has panicked, should I post to lkml?"
"No," replied the master, "You will only bother the Tao."
"Should I rm -rf?"
"No, you will have wasted the Tao's time."
"Well should I search the web?"
"You will search for all eternity," said the master.
"Perhaps I should try FreeBSD?"
"Then you will have disgraced the Tao."
"I suppose I could try gdb," said the user.
The master smiled and replied: "Then you will have made the Tao stronger."

A stubborn user once told a master: "I run version 2.2. I always have, and I always will."
The master replied: "You are foolish and do not understand the Tao. The Tao is dynamic and ever changing. Linux strives for the perfection that is the Tao. It flows from version to version with peace."
"So my Linux does not have the Tao, so what?" said the foolish user.
"Oh your Linux is of the Tao," said the master. "However, the Tao of Linux follows the Tao of the C library. One day the C library will change, and your Linux will be left behind."
The user was silent.

An angry user once yelled at a master:
"My Linux has panicked! What lousy software it is, I hate it so!"
"You are insulting the Tao," said the master. "The Tao is everywhere bringing order to hundreds of networks, aiding thousands of users, and fighting that of which we call the 'lame.' Do not disrespect the Tao; however, the Ta

Re:The Tao of Linux

[duffbeer703]

Is this some sort of ESR quasi-religious babbling?

Re:The Tao of Linux

[Anonymous Coward]

Oddly enough most of that explains a lot about Linux. Not in a good way mind you.

Re:The Tao of Linux

[Trigun]

Then you do not understand the Tao. Go meditate until you are enlightened.

Re:The Tao of Linux

[Anonymous Coward]

Oh but I do. The "TAO" involves hacking code as quickly as possible, but does not involve any of the following:

• Design
• Documentation
• Ease of use
• Friendlyness

In other words, all the stuff users actually care about. The "TAO" of Linux also means being exclusive and derisive of new ideas. It means being a bit of an asshole and blanking anybody who doesn't agree with your opinion because you "understand" the TAO.

Last but not least it apparently involves making "cute" Confuscious style stories about the "TAO" in an attempt to explain away these difficiencies instead of actually doing something about them.

Re:The Tao of Linux

[Anonymous Coward]

You need to get a life and learn of Geoffrey James.

Re:The Tao of Linux

[Anonymous Coward]

The wise programmer is told about Tao and follows it. The average programmer is told about Tao and searches for it. The foolish programmer is told about Tao and laughs at it.

If it were not for laughter, there would be no Tao.

The highest sounds are hardest to hear.
Going forward is a way to retreat.
Great talent shows itself late in life.
Even a perfect program still has bugs.

Re:The Tao of Linux

[Anonymous Coward]

Except the Geoffrey James stuff is The TAO of programming which is actually pretty insightful and clever. Not the TAO of Linux, which is actually pretty insightful for the wrong reasons and not very clever as it's just ripping off Geoffrey James.

Re:The Tao of Linux

[Anonymous Coward]

The Slashbot hears of the TAO of Linux and goes fwapfwapfwapfwap!!!

TAO of Programming != TAO of Linux
TAO of Programming > Turd on your shoe > TAO of Linux

Re:The Tao of Linux

[Anonymous Coward]

The correct way to spell
"friendlyness" is "friendliness."

If only...

[Gothmolly]

Now if they only had a web dashboard portal showing the latest results in an easily-assimilated color coded HTML table....

Then you'd become a PHB.

*BSD : Computing :: Howard Dean : 2004 Election

[Anonymous Coward]

*BSD is done. Turn the lights out, folks. As a one-time administrator of a hey-uge BSDi server farm, it was a great party but I think we all agree that it's over.

gg, *BSD.

503 Service Unavailable ??

[Anonymous Coward]

Please try again later.

Taco... I told you guys to fire michael. Now you've lost readers, lost ad revenue, lost the few subscriptions you garnered... it's over. Please sell out to Go and let this puppy thrive under new leadership/editors. I think you've burned out, that you no longer really care, that you're punching the clock.

Best,

A longtime reader

XBox rules!!

[Anonymous Coward]

first post!!! you lame assholes... I can post first because my XBox is a american product and my pride in my great country and my great XBox accelerate everything...

If only they would make games for that bitch... IAve played Metroid Prime and it ruled... I hope M$ will buy those japanese bastards and port Metroid to my great american console system!!!

do_mremap

[suckamc_0x90]

fixing another vulnerability in do_mremap() ah, good old Mr. Emap.

Re:do_mremap

[Anonymous Coward]

Yeah, let's "do" him!

2.2.0?

[autechre]

2.2.0 had a bug where the system would instantly reboot when any user ran "ldd". I wouldn't call that "ready for prime time" :)

(I remember this because we were waiting for 2.2.x to come out, having just gotten a dual P-II 350 server [2.0.x didn't have SMP support]. Fortunately, we managed to hold off for the first few revisions.)

It's not as if this problem is unique to the Linux kernel. "Never use a Red Hat .0 release" is pretty sage advice, and of course we know Microsoft's track record. You're not going to be able to catch all of the bugs before something gets truly widespread testing, no matter what you call it or how long you work on it.

Framebuffer?

[bruthasj]

I think they forgot to test the framebuffer in 2.6.x kernels. If I can't see Tux, then I ain't booting it! (radeon)

Re:Framebuffer?

[Anonymous Coward]

I think they forgot to test the framebuffer in 2.6.x kernels. If I can't see Tux, then I ain't booting it! (radeon)

Couldn't you just use vesafb for the console, and X for the fancier stuff on your video card?

Bitkeeper

[jurgen]

I sent this to the author of the article...

[the author] wrote:

The lack of formal revision control and source code management led many to suggest the use of a product called BitKeeper.

I grant that sometimes you have to simplify history to avoid digressing in an article, but this is a bit too inaccurate to let stand.

Bitkeeper wasn't suggested by anyone; it didn't have to be. It was developed from the ground up to Linus' requirements. Larry McVoy had a discussion about source control with Linus years ago, in which Linus said "none of the products are good enough" and Larry said, "ok, I'm going to write one that is". Apparently he had this on his mind anyway, and so he started Bitmover Co. As bitkeeper became a usable product Larry continued to take Linus feedback and improve it until it was good enough for Linus to use... at which point Linus started using it.

This is still a simplification of course, but it's closer... and as you can see, there were no third party suggestions involved.

Re:Bitkeeper

[pangloss]

Some more on that history: Larry McVoy on Bitkeeper, kernel development, Linux Torvalds & Bruce Perens

friZsT stop

[Anonymous Coward]

Of BSD/OS. A pERFORM KEEPING

Interesting read

[Derkec]

It's still amazing to me that a project as large as Linux was able to be so successfull BEFORE the changes that were made to the development process. It lacked a centralized CVS, coherent bug tracking, automated testing... These are all things I use in the smallest of professional projets. Many eyes goes a long way towards compensating for having many hands in a big project, but some structure seems like it's helped.

Re:Interesting read

[FePe]

It's still amazing to me that a project as large as Linux was able to be so successfull BEFORE the changes that were made to the development process. It lacked a centralized CVS, coherent bug tracking, automated testing...

Without beeing too sure, I believe that Linux developer's in the beginning focused more on fixing bugs than keeping things clean and structured. That's mainly because the base of the system needed to be developed, and little attention was drawn to factors like speed and optimization. "First make it work, then make it fast."

And most bugs were indeed caught. Linus's law, states that "given enough eyeballs, all bugs are shallow". More formally: "Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone." (From Wikipedia)

Re:Interesting read

[swillden]

It's still amazing to me that a project as large as Linux was able to be so successfull BEFORE the changes that were made to the development process. It lacked a centralized CVS, coherent bug tracking, automated testing... These are all things I use in the smallest of professional projets.

CVS is an interesting one. I don't really understand his rationale, but Linus says that for Linux development, CVS is not only inadequate, it is bad. Linus has said that if he ever has to quit using Bitkeeper, he'll go back to tarballs, patches and manual version control, because every other available system is worse.

I can certainly see weaknesses in CVS, and for Linux development I can see how the lack of changesets would be problematic, but the notion that manual version control could be better is... startling.

Re:Interesting read

[raxx7]

I'm just speculating here, but I think the issue would be speed. CVS isn't very efficient in terms of speed or disk space. Handling something as large as the kernel might be a problem and duplicating trees with cp -rl an interesting alternative.
SVN is much more efficient though. I'm not sure that comment aplied only to CVS or to avaliable versioning systems in general.

Re:Interesting read

[joib]

It lacked a centralized CVS


It still lacks a centralized revision control system, since one of the prime virtues of BitKeeper is that it is decentralized. ;-)

Re:Interesting read

[Derkec]

My mistake :). I wrote CVS when I should have said VCS - meaning some sort of version control system.

Re:Interesting read

[Derkec]

Yet another mistake. Both times I should have said SCM (Source Control Management) if I wanted to be proper.

Re:Interesting read

[swillden]

Whatever abstract name you want to use, or whatever specific system you want to point at, what's interesting to me is that Linus says that manual management is better that everything except Bitkeeper. CVS may have deficiencies, but I can't imagine that a directory full of tarballs is better...

Re:Interesting read

[Derkec]

I can't imagine it either. My favorite source control approach that I've seen is having each developers machine backed up to tape nightly. You want your source as it was last week? Let's go get that tape.

changes, huh

[b17bmbr]

i thought it was just:

cp -R /usr/src/sco /usr/src/linux

ducks

But why is it in so few distros?

[Bob Bitchen]

That's what bothers me. How long will the distros wait until they use the 2.6 kernel? I hear the scheduler is improved amongst many other things. So what's the hold up? Is it just that there's no one willing to be the guinea pig?

Re:But why is it in so few distros?

[lavalyn]

For Debian, 2008.

Re:But why is it in so few distros?

[inerte]

Mandrake 10.0 (which has a RC already) will feature the 2.6 Kernel.

Re:But why is it in so few distros?

[Sweetshark]

You can use it with gentoo right now(tm).
However I get the feeling that the new scheduler still needs some finetuning for desktop apps.
It seems to be great already for servers.
But glxgears dropped by almost 50% for me - and tvtime drops frames all the time.
Surprisingly the kernel is even SLOWER, when I disable powermanagement and framebuffer support.

I also looked forward for the Sis 746 AGP support - but it is still very unstable.
Unfortunatly, Dave Jones, the main agpgart developer does not seem to be too interested in improving the support soon - and I am just beginning to understand how the kernel works internally and am not able to fix things myself right now.

Re:But why is it in so few distros?

[crush]

Fedora Core Test 2 is already using 2.6

Re:But why is it in so few distros?

[drinkypoo]

You just have to pick a distribution that supports your desires. I'm emerging gentoo-dev-sources/gentoo-dev-sources-2.6.3_rc4.eb uild, which is gentoo's patched kernel - mostly x86-64, some drivers, their boot splasher. I just emerge it and it plops the source down and patches it. Then I patch the kernel for MPPE/MPPC support for ppp (for my pptp vpn) and bingo. 2.6.0 didn't work very well for me, 2.6.1 seemed to be okay, I'm running 2.6.2 but I only rebooted today. I'll be running 2.6.3 by this evening, I hope. Thw mppc/mppe patch for 2.6.2 applied ok to 2.6.3, I hope it works.

Re:But why is it in so few distros?

[TKinias]

scripsit lavalyn:

For Debian, 2008.

Yuck, yuck, yuck. Seriously, though, 2.6.2 is in Sid right now, and 2.6.0 is already in Sarge. Sure, it's not the default kernel, but it's sure as hell available -- four years early ;)

Has any JVM been used in this production?

[totierne]

Just wondering if java has got its ugly head in somewhere in the kernel development release, maybe someone uses jedit perhaps, or even a JSP or servlet web site.

Maybe real kernel hackers do not use something that is half the speed of C but maybe the odd exception likes java.lang.Exceptions.

Offtopic but I just like to know where a 5 year java programmer might fit in besides maybe jakarta from apache.

Linux in C++

[onash]

I would like to see Linux written in C++. I've had to dig into the code a couple of times, and it's really not easy to understand what's happening under the hood,for example all those function pointers to that could be replaced by virtual functions. C++ being slower than C is a myth, it may have been true few years ago.. but not anymore.

The benefit of writing something like Linux in C++ is that the more complex things can be abstracted so they can be understood by more programmers and computer science students (or according to Open Source philosophy; more eyes, fewer bugs). Object orientation, instead of modular C programming, would also mean that it would be easier to refactor parts of the systems, which could ease things up for students that want to test their theories in action, and then donate them to Linux if they are better

C can be thought of as a subset of C++, so there is no reason to stop using neat C tricks (not everything should be an Object - C++ is not Java!). This isn't about stop low level programming. It should be about making the code more understandable. C and C++ can live happily together, but some Linux coders are just stubborn and won't stop using new as variable names and etc.

Re:Linux in C++

[Anonymous Coward]

computer science students who can't understand it should get the hell off their course, or spend more time studying, and less time on /.

Re:Linux in C++

[one_eyed_king]

C++ is NOT a good choice for kernel development, this has been covered many times before in the kernel mailing lists. Anyway the kernel already uses sound OO design principles, the whole of the VFS (Virtual File System) implementation is a good example as is some of the memory allocation stuff (slabs etc).

Re:Linux in C++

[onash]

Well, I've reads these 'covers' in the kernel mailing lists, and they have just ended in brainless flamewars. Mostly because C developers don't like C++ and assume things.. and perhaps C++ developers have a hard time understanding that OO design with C isn't that hard.

the bottom line is; the code is complicated and it takes a lot of time to get into it! Even though you get nice coupling between systems with modular C programming, it does not mean that it couldn't be done better. If the slab memory allocation where easier to understand, then maybe it had more SMP support, with magazines for each CPU and stuff. That would be a great research project for graduate computer scientists...

OMG WTF LOL

[Anonymous Coward]

ROFFLES OMG WTF LOL

Re:OMG WTF LOL

[Anonymous Coward]

Say that again, I couldn't understand you with that cock in your mouth.

Beautiful

[maximilln]

I don't like to start new threads but I didn't see this: A general "Thank you for your time, effort, and a job well done" to all of the kernel hackers out there. They're fixing kernel level bugs that are almost at the hardware level while M$ is still patching their web browser. I don't think there's any doubt which system is ultimately more secure.

Can anyone take a guess how many low-level memory exploits are in Windows XP, 2k, or others? Perhaps it's irrelevant. Who needs to crack the low mem when there are so many ways into the system at the document level?

Re:Beautiful

[MyFourthAccount]

I don't like to start new threads

Because Karma to effort ratio is too low (especially if you post more than 5 minutes after the story got posted)?

BitKeeper?

[Anonymous Coward]

Is that true that Linux is developed using the proprietary BitKeeper? Why not Subversion or CVS or RCS? I just tried to download BitKeeper and there's a strange question in the download form: "Do you anticipate implementing a source management system in the next: [Please Select]" What's the deal? Don't just tell me that if I want to contribute to Linux, than I cannot contribute to Subversion... If that is indeed the case, then what are they nuts? No wonder that Subversion is maturing so slowly, when all of the Linux contributors are legally obligated to not help it. But is that really fair? I'm sure Linus Torvalds would never choose software with such an EULA, so who has made that decision? Was BitKeeper always proprietary and anticompetitive?

Re:BitKeeper?

[typobox43]

I read the word "implementing" here as asking you when you plan on utilizing a source management system, not when you plan on coding one.

Re:BitKeeper?

[raxx7]

First, you can contribute to Linux and Subversion. You just have to:
a) not use BitKeeper
b) buy a BitKeeper licence

Second, RCS doesn't support concurrent development. That's why we have CVS.

Third, why BitKeeper?
Though CVS has lots of shortcommings (and thats why Subversion exists) and Subversion (SVN) is still labeled "alpha" by it's developers (though in practice it's stable enough to be self hosted and widely used), the real reason has to do with the basic model of CVS and SVN. Two main issues, in my opinion:
a) In CVS/SVN you need write access to the central repository or you can't make proper use of versioning control. Giving write access is a problem for Linux's contribute based development model. BitKeeper doesn't need it.
b) CVS/SVN know about branches but they don't know about merges from one branch into the other. Their view of the repository is a pure spanning tree. Subversion has a "merge" command, but a merge is commited as any other change into the repositoty. BitKeeper knows about previous merges and where they were merged from and uses that information to be smarter at resolving conflicts when you do a merge.
In contribute based development every change to the project has to go through one of few maintainers who can write into the main repository (in Linux's case, there's only one), so proper merging support becomes very important. At some point before BitKeeper, Linus was having trouble keeping up with all the patches people were sending him and people were getting angry with that.

If you don't believe me, you can check the GNU Arch website: http://wiki.gnuarch.org/
They're developing a Free versioning control system very similar to BitKeeper.

Re:BitKeeper?

[Anonymous Coward]

Bitkeeper is proprietary. You can contribute (all you like) by posting patches to the linux kernel mailing list (LKML). Linus didn't like CVS or RCS. There was a lot of (angry) debate on LKML about using bitkeeper. I know (at least one) kernel developer using subversion. You can call bitkeeper proprietary all you like (and be correct, since it is). Anticompetitive? Maybe. It's what Linus wants to use because it works (there is only one Linus, and he would pull his hair out applying patches all day without it). It provides excellent, decentralized source control (better than CVS or RCS or SCCS or any of the others). Smaller projects can use these (and they work great). The kernel is too large to use them.

Re:BitKeeper?

[chromatic]

Just a nit on Subversion's status: it's in beta now, with a release candidate scheduled for tomorrow and the official 1.0 release set for Monday.

Recommended book on the Linux kernel

[supersat]

I highly suggest picking up a copy of the Linux Core Kernel Commentary. The first part of the book contains the code of the majority of the "core" kernel components, and the second part explains the code. It's slightly out of date, but still a good read.

Re:Automatic Testing-

[SkjeggApe]

JUnit does a nice job of presenting "visually" pleasing results if you want it to. I usually use it in combo with Ant (if the JUnit test fails, don't deploy/check in/etc)

Haven't looked at the c++ port CppUnit, but I'm sure it's results can be presented just as pretty. :-)

Microsoft could learn from this

[xjqkojqxj]

From the 2.6.3 Changelog: [NETFILTER]: Fix signedness overflow in ip{,6}_tables.c Bug discovered by Olaf Kirch. M$ Wouldn't have had the recent embarrassment about a certain BMP import filter if its code was opened earlier. (It was the same type of bug that was exploited...)

the old days

[Anonymous Coward]

Linus would put out a new release every day or so,
sometimes even twice in one day. We all ran the
latest code on our desktops and even servers, so
it got plenty of testing. When the kernel wasn't
solid, e2fsck got tested too!

Important bugs get reported again and again.
Spurious bug reports don't get re-reported, so
they get forgotten. This eliminates the problem
of year-old unreproducable "bugs" sitting in a
bug-tracker.

CVS sucks. You can't even rename a file. You have
to run a server, instead of having peer-to-peer
operations between equals. Linus himself, using
just microemacs and the patch command, makes for
better revision control.

In defense of Mr. Emap

[MicroBerto]

Hey, if a million linux users [read: geeks] were trying to do ME, I would be feeling vulnerable and exploited too! No wonder he's rebelling.

2.4.x and 2.6.1 and external USB devices

[Spoing]

This isn't the right story to mention this on, though it's somewhat related.

I've encountered many problems with external hard drives using USB 1 and 2 interfaces. Locking up the entire system on large file copies was the main issue. (Copying small numbers of files was never an issue. Lockups occured on different drives, different external chipsets, different 2.4.x kernels though supposedly fixed in the latest 2.4.x releases.)

I've finally gotten the nerve to run a few days of tests on 2.6.1 to see if this has been really resolved, and I'm happy to report that this now works like a charm.

If you've encountered similar problems with 2.4.x, give 2.6.x a try.

Re:Kernel quality: OpenBSD

[debrain]

I can't think of a x.y.0 release of any software project that's been properly stable.

OpenBSD comes to mind. I faithfully rely on their .0 releases, and have never been burned. YMMV, of course, and they are an exception, not the rule, I suspect.

biznatc4

[Anonymous Coward]

Dim. If *bSD is Let's keep to

Troll Alert!

[Anonymous Coward]

Listen, it's very simple: Subversion wasn't (and still isn't) up scratch. CVS or RCS are so fundamentally broken as to be irrelevant to this discussion.

Wrt. the "must-not-develop-a-competitor" angle: This does not prevent people contributing to Linux. It simply means that they cannot use BK to do it! (If they plan on being able to work on any RCS). You may argue the fairness of such a stipulation in the BK license, but the fact remains: Linus chose BK.

mod Down

[Anonymous Coward]

bloc in ordAer to Counterpart,

two things

[John Harrison]

1. Don't upgrade a critical system to a new kernel unless you need to. Nobody is forcing you to upgrade to 2.6, and if you don't have a need to then don't do it.

2. I don't think that "stable" in this context means what you think it means.

Java kernels

[mparaz]

How about JBoss, or Apache Geronimo? User Mode Linux is also important for Linux, like in Java hosting companies.

Interesting read-Adult development.

[Anonymous Coward]

What I'm wondering is other OSS going through a similiar "growing up" process, and what does that mean for OSS development in general?

Linux? Yeah. But GCC is also interesting.

[sploxx]

Because there are several posts that ask how to get into Linux kernel development, I would also ask here (a bit OT): How to get into GCC development, especially backends?
GCC is also an amazing feat of software and creating custom backends would make many experiments possible (porting to old architectures, porting to virtual machines, c++ on virtual machines) etc.

Re:Linux? Yeah. But GCC is also interesting.

[Anonymous Coward]

If you are interested in porting GCC to a new target, then read the porting GCC for dummies document. There are several other accounts floating around that document this process. If you want to get involved with development of GCC internals then read through the GCC internals document. Then download the source code and start looking through it. Start on some small project just to get familiar with how GCC is layed out, how it's built, etc. http://gcc.gnu.org/projects/ has several projects that are relevant; maybe the beginner projects or documentation would be a good place to start. Subscribe to the mailing lists, and ask questions if you don't understand something.

Already got that, w/o C++

[Anonymous Coward]

There are per-CPU caches for memory allocation.