Linus Confirms 2.4 In December
Lothsahn was the first to write to us about the latest statement from Linus regarding the Linux 2.4 Kernel release date. His statement says that he knows of no major showstoppers, and that he's asking the major devel houses to deploy the test kernels internally and start bug testing. Early December, hopefully, for a release.
Aha! So it's true! All major Linux houses are in fact hackers trying to exploit the linux kernel!
I knew it!
<grub> Reading
do they ever listen...
IIS is NOT in the kernel, even a little bit, really. It is a userspace series of applications that are executed in the context of one or more service accounts. (no, the account(s) does not have to be give admin priv)
IIS is faster in some cases for 2 reasons
1. IIS is highly multithreaded, Apache is not
2. IIS caches damn near every thing, Apache doesn't.
please let the kernel myth die allready
Yes, the article is done up in vapid, breathless 'IT Rag' speak designed to make a manager think their job is exciting and that they learned something important by reading the article.
The article could be summed up in a paragraph or three as:
The stable version of the Linux 2.4 kernel, which was expected to be released 4th quarter of last year, will instead likely be released this December of this year. While the 2.2 kernel is quite functional and adequate for many people's needs, the 2.4 kernel has some nice, long awaited features such as support for USB and better tuned SMP performance, along with a re-written networking stack.
Many of the SMP and networking improvements were made because NT 4 beat the Linux 2.2 kernel in some benchmarks in the beginning of 1999, and it's hoped that the improvements will avoid a repeat of that embarassment.
Several Linux distributions are prepared to release a new version as soon as the 2.4 kernel becomes available, having already prepared for its release in the current versions of their products.
Need a Python, C++, Unix, Linux develop
Why no CVS for linux ?
or evil monkeys.
Does my bum look big in this?
The Linux 2.4 todo list can be found here, and an article detailing the new features of 2.4 is here.
Forwarding to Apache (or whatever) is most useful for complex modules that would be difficult to port to TUXapi. TUXapi is event-driven instead of connection-oriented, in order to provide maximum speed. This makes TUX modules harder to write than Apache modules. Forwarding to Apache lets you take advantage of the ease of writing Apache modules when speed for that particular module is not critical, while still allowing TUXapi modules to directly handle speed-critical tasks.
Lots more detail is available in the /. interview with Ingo Molnar.
(I'm not dissing khttpd; Arjan (author of khttpd) likes TUX. :-)
-- "Ever wonder why the SAME PEOPLE make up ALL the conspiracy theories?"
What happened to the driving force behind the quality of open source: "thousands of eyes go over the code to find bugs". ?
Thousands of eyes is great. I'm sure thousands of eyes found lots of bugs. But nothing compares to live load. This is something I learned when working on larger systems, like the ones at AOL. You can comb the code as much as you want, and test it for weeks. There will still be bugs that only a live system will show. What I would guess is that these large Linux shops "test cycles" include things like running live load on the systems, and pushing them harder than they can be pushed on someone's desktop.
Also, you're way off with comparing this to MS. It's not as if you can't pull a copy of the latest test kernel and run it on your boxen and find bugs and report them. Linus is not saying that these large Linux houses get to test the kernel exclusively. All he's saying is that that's where he's expecting to find most of the last minute bugs.
The Linux community should consider itself lucky to have large shops that will test new releases internally. I have seen so much code that has been "released" by companies that are not known for bad software, that has completely fallen apart under live load. It tends to be true that the more load we put on a system, the more obscure the bugs we found. But as obscure as the bugs were, they were showstoppers to a large system. And these were things that the software companies couldn't find themselves in their QA labs because they just didn't have access to the load that we were placing on the systems.
-Todd
---
"The details of my life are quite inconsequential..."
The kernel cannot, inherently, be "late to market," not only because it isn't a 'market' that it's being released to, but by * definition* it is "due" when it is done.
They don't get this. There is, and never has been, a projected 'release' date in the industry sense. There is Linus saying, " I think I can get it done by. . . "
If he does he does, if he dosn't he dosn't.
By the same token everbody who says something along the lines of "Linux needs (Office, IEX, Magically delicious Lucky Charms, etc.) to succeed," ALSO dosn't get it.
What does Linux need to succeed? Glad you asked because I'm going to TELL you what Linux needs to succeed.
It needs *ONE* geek sitting up in his room at three in the morning going "Oh wow."
And anyone who gets THAT gets *it.*
KFG