"The Linux 2.6.31 kernel is still under active development until it is released later this quarter, but the merge window is closed and most of the work going on is to address bugs and other regressions within this massive code-base. Some of the key additions to the Linux 2.6.31 kernel include many graphics-related advancements (merging of the TTM memory manager, Radeon kernel mode-setting, Intel DisplayPort, etc), an ALSA driver for the Creative X-Fi, initial USB 3.0 support, file-system improvements, and much more. To see how the general system performance has been impacted by the new Linux kernel that is in development, we have a few benchmarks today."
Post a Comment
Member since:
2006-08-15
Member since:2007-03-20
Member since:2005-07-06
If you take a brief look at the graphs you'll see that the throughput has increased but the latency has increased as well - it depends on what you wish to achieve when it comes to performance; do you want lower latency with lower throughput or higher throughput and higher latency?
Unfortunately those who criticise the Linux kernel have had very little exposure to other operating systems let alone computers outside that of the x86 world. I tend to be more of a *BSD/Mac OS X fanboy though.
Member since:2005-07-06
Whereas this is not a stretch, they aren’t many (or any) other kernels that work on as many platforms, on large (88% of supercomputers) and small scale (RJ45 SoCs, ARM wall-plugs) devices, phones, routers, TVs, all with the same codebase. The argument only rests on what you define best to be.
Member since:2005-11-15
Member since:2006-02-15
Linux is the best kernel/OS ever.
The kernel itself is pretty good, no major issues, stable, works on almost anything ranging from your electronic toothbrush to large-scale supercomputers. But I still don't like how it lacks some stable driver API/ABI. That's one thing that stops certain manufacturers from supporting Linux. And I still find Linux power-management to be flaky.
On the desktop side of things there's also quite a bunch of things that need some attention, but I'll leave the rant to some more proper topic 
Member since:
2005-09-08
Member since:2006-11-30
Generally, Phoronix has about as much credibility as The National Inquirer. They are more interested in hits on their website than whether Linux gets faster or slower.
Real regression tests get posted to the LKML and indicate some level of competence (i.e. a syscall trace or postulate rather than some buffoon running stock benchmarking tools). Luckily, some folks at Intel run good tests from time to time.
Member since:2005-07-06
That is rather harsh, I always got the impression that those from Phoronix were just enthusiasts running a website - although one has to be sceptical of any sort of benchmark because one finds that it is never mirrored in reality (in terms of performance outcomes).
Reminds me of the TPC benchmark and what a Sun engineer said about them, "they might be a great benchmark if all you intend to use your hardware for is TPC benchmarks all day".
True, then there is also the question where things might have changed in the kernel but because the benchmark is badly written, it comes up as a loss of performance.
Member since:2007-12-26
Member since:2006-01-02
Member since:2007-11-23
Have you ever came across kernel compilation? it just needs a fix. Tons of different stuff mixed altogether, unmet dependencies, weird connections between several components. What I am thinking of is the logical structure: "Hard disk" with all needed subclasses, like HD controllers, then "Multimedia" divided to "sound devices", "video devices", etc. It's pretty messed up now and I'd like to see it finally working like it should work. I won't even mention the lack of profesionalism and lack of code quality that is typical to linux kernel: it just HAVE to work, no matter HOW, while I - personaly - think, that this "how it works" is the most important thing when it comes to the OS-land. I have really no interrest in throwing a bad word on linux, I just want it to be better - I think we all benefit from it - regardless the camp we're actually in, whether it's GNU, BSD or another one.
Member since:2006-01-02
The kernel menu config system is a bit messy, but that's just one *interface* to configuring the kernel and they have been doing a lot of cleanups over time and it's a lot better than it used to be. Still, there are a lot of options and suboptions and things that affect multiple subsystems, so there's not much you can do to organize that any better. Still, I would call that the least serious problem with the Linux kernel.
As far as your accusations regarding lack of professionalism or code quality, I guess you really have never followed kernel development or read the rules the have regarding new code and subsystems, etc. They have some very strict policies about that kind of stuff. And it'll do you well to remember big deals such as reiser4, suspend2 and others that never got merged because of quality and design incompatibility issues. Doesn't sound like lack of code quality to me.
Member since:2007-07-27
"Doesn't sound like lack of code quality to me."
Even Linux kernel developer Andrew Morton complains about the declining quality of the Linux kernel. His words:
http://lwn.net/Articles/285088/
Q: Is it your opinion that the quality of the kernel is in decline? Most developers seem to be pretty sanguine about the overall quality problem. Assuming there's a difference of opinion here, where do you think it comes from? How can we resolve it?
A: I used to think it was in decline, and I think that I might think that it still is. I see so many regressions which we never fix.
Member since:2006-01-02
Read the rest of your link: the main problem is really testers not doing their job. They can't fix regressions that they don't have enough information about to fix.
He also speaks highly of the code review process:
"Q: How would you describe the real role of code review in the kernel development process?
A: Well, it finds bugs. It improves the quality of the code. Sometimes it prevents really really bad things from getting into the product. Such as rootholes in the core kernel. I've spotted a decent number of these at review time.
It also increases the number of people who have an understanding of the new code - both the reviewer(s) and those who closely followed the review are now better able to support that code.
Also, I expect that the prospect of receiving a close review will keep the originators on their toes - make them take more care over their work."
Member since:2007-07-27
"Read the rest of your link: the main problem is really testers not doing their job. They can't fix regressions that they don't have enough information about to fix."
So what? It doesnt matter why, only the result matters: Linux kernel code is of varying quality as Andrew Morton says.
Member since:2006-01-02
Nowhere in there does he say it's a mess or needs to be thrown away. That's the point of the OP. Yes, maybe some parts need some TLC. Perhaps taking some time to take a look at the dev process to make it a bit tighter would be good too. And maybe it's having a year or two where things aren't quite as good as they were before. I won't deny these facts. I will deny, however, that they mean everything is crap and Linux is terrible and needs to be rebuilt. Can you accept that argument as well?
Member since:2007-11-23
I guess that no one here was really talking about the linux kernel being complete and utter crap.
It is quite useful, although it certainly LACKS some features, overall code quality and the general ORDER.
I'd suggest some LINUX KERNEL WORKING GROUP that would be reponsible for maintaining the base of the kernel code. Jesus, they already have an easy task - some *BSD, MacOSX, Windows guys out there are managing THE WHOLE SYSTEM SOURCE, where *system* means "kernel+userland", not only the kernel ...
Increase code quality. That is my postulate.
Member since:
2009-06-30
Member since:2005-11-15