Slashdot Mirror
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."
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.
I am TheRaven on Soylent News
A few things to consider:
* Remember what happened when Netscape 4.7 decided to do a complete rewrite instead of incremental improvements over a longer period of time? Netscape went from 90% market share to 1%. A complete rewrite would be just as damaging to Linux.
* Bugs are bugs, no matter where they are. Most of Linux's "million lines of code" are drivers. If no-one is doing bug fixes in the kernel drivers, moving them out of the kernel wouldn't help.
* Linux *has* moved most things to modules and the core is pretty well understood and not a likely source of bugs because it has the most eyeballs on it. So the added modularity of Microkernels wouldn't buy you anything.
* Linux scales from super computers to the Linux watch using the same code base. Supercomputers might not care about the added microkernel layer but low resource environments definitely *would*.
* Buffer overflows are generally not the reason most well designed kernels go down, it's hidden race conditions, starvation, and other NP complete problems that go hidden for years. Moving these problems to user space wouldn't solve them. In fact, it may aggravate them unless intimate knowledge of global state is available to user space (which is in itself a security risk and thus a source of bugs)
Failing that, you could just install the Debian distro of it from here: http://www.debian.org/ports/hurd/hurd-cd
"I've got more toys than Teruhisa Kitahara."
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.
It's official. Most of you are morons.
Some completely offtopicness:
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.
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/
sure I'll have a sig.
Why you don't want to run older kernel even on old hardware:
- You want to run apps with new features or with most recent bug fixes;
- Newer versions of applications don't run on older kernel versions;
- There are no distributions with recent apps and old kernel.
You say: "My general rule is to use a kernel that is approximately 6 months to a year newer than the hardware it's running on." Suppose I buy a new laptop. Now I have to wait "6 months to a year" before starting to use it?
Gustavo J.A.M. Carneiro