From: Chase Venters <chase.venters@clientec.com>
To: Luke Kenneth Casson Leighton <lkcl@lkcl.net>
Subject: Re: what's next for the linux kernel?
Date: Sun, 2 Oct 2005 20:27:45 -0500
User-Agent: KMail/1.8.1
Cc: "Martin J. Bligh" <mbligh@mbligh.org>, Rik van Riel <riel@redhat.com>,
       linux-kernel@vger.kernel.org
References: <20051002204703.GG6290@lkcl.net> <54300000.1128297891@[10.10.2.4]> <20051003011041.GN6290@lkcl.net>
In-Reply-To: <20051003011041.GN6290@lkcl.net>
Organization: Clientec, Inc.
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200510022028.07930.chase.venters@clientec.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2024
Lines: 43

I'd venture to say that Linux scalability is fantastic. This also sounds like 
a repeat of a debate that happened ten years ago.

I too was intrigued by Andrew's comment about 'finishing the kernel', though 
I'm guessing (albeit without ever having spoken to Andrew personally) that it 
was partially in jest. What it does suggest, though, is a point that KDE 
desktop developer Aaron Seigo has made recently about the focus moving up the 
stack.

If we are admirably tackling the problems of hardware compatibility, 
stability, scalability and we've implemented most of the important features 
that belong in the kernel, then a lot of the development fire for a so-called 
complete Linux system is going to have to move up the stack - into the 
userland.

Indeed, adding 100 cores to my Pentium 4 isn't going to do me a damned bit of 
good when Akregator goes to query some 40 RSS feeds and Kontact blocks, 
refusing to process GUI events. It's also not going to make compiling a 
single .c file any faster. 

I have no doubt that the bright minds here on LKML will continue to find 
places to improve Linux's scalability, but that certainly doesn't require 
rebuilding the kernel - we're already doing remarkably well in the 
scalability department.

The bottom line is that the application developers need to start being clever 
with threads. I think I remember some interesting rumors about Perl 6, for 
example, including 'autothreading' support - the idea that your optimizer 
could be smart enough to identify certain work that can go parallel.

As dual cores and HT become more popular, the onus is going to be on the 
applications, not the OS, to speed up. 

Regards,
Chase Venters

On Sunday 02 October 2005 08:10 pm, Luke Kenneth Casson Leighton wrote:
> ... words ...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/