2.6 Linux Kernel in Need of an Overhaul?

toadlife writes "ZDNet UK reports that Andrew Morton, the head maintainer of the Linux production kernel, is concerned about the amount of bugs in the 2.6 kernel. He is considering the possibility of dedicating an entire release cycle to fixing long standing bugs." From the article: "One problem is that few developers are motivated to work on bugs, according to Morton. This is particularly a problem for bugs that affect old computers or peripherals, as kernel developers working for corporations don't tend to care about out-of-date hardware, he said. Nowadays, many kernel developers are employed by IT companies, such as hardware manufacturers, which can cause problems as they can mainly be motivated by self-interest."

Comments

Re:Important for the Old Debate

[TheRaven64]

Linux got me using *NIX. BSD showed me how *NIX is meant to work. I currently use OpenBSD and FreeBSD, and this is exactly the kind of reason why I switched.

In FreeBSD, there are three branches, -STABLE, -CURRENT, and -RELEASE. Any new features are put into -CURRENT. Here, they undergo testing. The only people who should be running -CURRENT are those who are developing or actively bug-hunting. Once a feature is stabilised, it migrates into -STABLE. Here, it receives more general testing. A lot of people use -STABLE, and file bug reports. Finally, a -RELEASE branch is created from -STABLE. This undergoes even more testing and is then shipped (usually after several betas and RCs). The -RELEASE branch is maintained in the tree, but only bug fixes are allowed to go in it. If you want a stable system, you stick with a -RELEASE branch. For a slightly less-critical system, you might want -STABLE for the features (my ThinkPad runs -STABLE, and I have never yet had it crash).

The direction of the OS development is driven by the core team. These are elected annually by the developers.

In the OpenBSD world, there is a code review process. Every piece of code in the base system is audited on a regular basis. When a new category of bug is discovered (e.g. the multiply overflow that caused a security hole in OpenSSH), the entire source tree is searched for occurrences of that bug. These are then fixed.

Both of these development processes give high-quality, stable systems.

Re:Important for the Old Debate

[ozmanjusri]

Failing that, you could just install the Debian distro of it from here: http://www.debian.org/ports/hurd/hurd-cd

Re:Important for the Old Debate

[Tim C]

In Windows there are NO logs, no clues, NOTHING to indicate what the problem might be.

When Windows crashes, it writes an error log and a memory dump to the disk. Under XP, check the Startup and Recovery settings (My Computer -> Properties -> Advanced -> Startup and Recovery settings)

Also, Windows logs a lot of information to the event logs. The event log viewer is in the Administrative Tools. By default, when Windows crashes, it logs information about the crash there (in the System log).

No offence, but given that you appear not to know about the crash dump or event logs suggests that either you don't know enough to correctly diagnose the problem, or you're running one of the 9x series of Windows, in which case frankly your only sensbile option is to throw it away and install something based on NT; 9x is a joke.

Re:Important for the Old Debate

[*SECADM]

Some completely offtopicness:

XP by default will reboot when it encounters a bugcheck (or BSOD as people call it). However typically a mini dump or a full memory dump is created in your %windows% directory. This is pretty much like a core file on unix, with the stack information necessary for debugging.

So, if you ever feel brave enough to do some windoze hacking, you can grab this file by booting into a safeOS on the system or a linux live CD, and then head to http://www.microsoft.com/whdc/devtools/debugging/i nstallx86.mspx to grab the MS debugger. Once inside the debugger, usually only 1 or 2 steps are needed to figure out who the culprit is that caused the bugcheck. (by seeing what's on the stack at the crash for example). The other thing you can do, if you can boot into safemode, is to open up the event log viewer and typically there are messages that explain who caused the last bugcheck.