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
The last time I saw windows repeatedly bluescreen due to a software error was Word XP on Windows 2000:
Insert floppy #1 with foo.doc
Open my computer
Double click foo.doc to open it in word.
Remove floppy #1, insert floppy #2.
Press save.
What happens next:
1) Nearly every single time, the original foo.doc file on floppy #1 will be rendered unreadable. (This actually happened the moment they pulled floppy #1 out)
2) The vast majority of the time the computer will BSOD
3) Occasionally, the computer will corrupt floppy #2. I've seen the floppy be reported as unformatted a number of times, and once I've even seen floppy #2 end up with a copy of the directory structure of floppy #1, but not the actual files.
I no longer work in the university labs where the wails of students who have lost all their work echo from the walls on a daily basis, but I suspect that Word 2003 on windows XP will still kill your word document, though it may not BSOD or scramble floppy disks. I base this on the fact that Word STILL creates the temporary file on the same directory as the original file (despite C:\windows\temp, or the personal Application Data folder in 2k and up.) and will shit all over your word doc should you open it from a network share that becomes temporarially unavailable.
Incidentally, I have personally reported this as a bug in every version of word from 4 to 2000. After that, they made the bug-reporting system too difficult to use (read: I wasn't bored enough to bother searching their site for and filling out all their forms)
I had an XP SP2 bluescreen a few times in the past few months. I wasn't quite sure what caused it any time.
I use Windows once in a blue moon. The last time was last week. New landlady's Win 2K, she turned it on, we waited for it to finish booting, she closed her MS chat client, I clicked on control panel, and it froze. I waited several minutes, gave it the three finger salute, got a blue screen and it was totally hung. Had to hard reset.
Not XP I admit, but it's a pretty sad state of affairs when control panel hangs a freshly booted system.
i'm sorry if i'm being blunt, but get the fuck outta here. the latest 2.6 kernel (as of this writing) is ~39MB. that means you can get it in ~7h at 14k and ~2h at 56k. you can surely leave a wget running while you sleep or you're away from home.
when i was on dialup my monthly traffic was in the multiple gigs, so you'll really have to come up with a better excuse.
Stop Computers/Cars Analogies on S
It wasn't on server 2003 - it was on the recent home computer OS that Microsoft released afer win2k, but it was definitely a blue screen.
As for the linux side - sometimes gnome revisites the windows lockups, paticularly running remote applications on X can hang up the entire session if something goes wrong. A single user non-network aware environment doesn't belong on *nix but unfortuately gnome started that way and hasn't entirely outgrown it.
Let me see... The last time I remember was October last year, when I got my Philips 200W6 monitor and tried to install it in XP. I went through ten or so blue screens, after following the instructions in the included CD. Having no success, I did a few driver downloads, the closest I could get was a 1600x1024 resolution. I gave up and never tried to boot in XP anymore.
In the Linux side, it took me about two minutes to add "1680x1050" in
Of course, you have first to learn what is all this, but every minute you spend studying Linux you recover later from a smoother operation. All the time you spend downloading drivers and rebooting Windows is wasted by the time the next bug arrives.
I hate Windows as much as the next guy, but really, when was the last time you saw Windows bluescreen?
I got called LAST NIGHT to help with a BSOD in Windows XP for a family member that would happen 20-30% of the within a few minutes of booting. I just had them copy their "My Documents" folder to a DVD and then reinstall. Problem seems to have been solved...
STOP . AMERICA . NOW
That article has GOT to be a joke, I mean he mentions that his software came with comet cursor, which I think is just spyware that adds fancy cursors to your mouse cursor. It just has to be a joke...
It is - click on the "Meaning and Purpose" link at the bottom of the page
Add to that the fact that you only need to do this once. After that, you can download small 2-5MB patches to incrementally apply to the tree you already downloaded to go from any version to any other version, as they are released.
You can also use git and get compressed binary packs of around 1MB to switch your tree from any release to any other release in seconds.
LL
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."
Want to know what's wrong with it? Turn on Operating System Error Reporting in System properties Advanced tab > Error Reporting.
Next time the crash occurs, visit http://oca.microsoft.com/
They'll tell you exactly what program is causing it, and exactly which procedure it's occuring in.
But I imagine you'll just reinstall Windows and end up reinstalling whatever driver is causing this behavior, or using whatever faulty hardware is installed, and you'll continue blaming it on the OS.
hello dear sirs my name is jamesh i are india (bihar) can u guide me install red had linux 9?
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.
Also, you might want to look at recent advances in atomic theory. This young fellow, Dalton I think is his name, has a most interesting hypothesis about matter being made of indivisible (and countable) units. Marvelous!
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