hi
Are there any plans to move Tux into the official kernel?
roy
--
Roy Sigurd Karlsbakk, MCSE, MCNE, CLS, LCA
Computers are like air conditioners.
They stop working when you open Windows.
If that's not part of the roadmap I'd be surprised,
since tux is so much more capable than the
khttpd which is currently part of the tree.
Tux has clearly demonstrated it's performance
and low resource consumption.
I also think including tux in the mainline kernel
would further stimulate development, as folks
begin to realize what they can do with tux....
At least Red Hat seems committed to it.
IMHO of course...
Joe
Roy Sigurd Karlsbakk wrote:
>hi
>
>Are there any plans to move Tux into the official kernel?
>
>roy
>
>--
>Roy Sigurd Karlsbakk, MCSE, MCNE, CLS, LCA
>
>Computers are like air conditioners.
>They stop working when you open Windows.
>
>
>
>
>
>_______________________________________________
>tux-list mailing list
>[email protected]
>https://listman.redhat.com/mailman/listinfo/tux-list
>
On Mon, Feb 11, 2002 at 08:36:55AM -0800, J Sloan wrote:
> If that's not part of the roadmap I'd be surprised,
> since tux is so much more capable than the
> khttpd which is currently part of the tree.
>
> Tux has clearly demonstrated it's performance
> and low resource consumption.
it has also been demonstrated that equal performance can be had in
userland (search archives for "X15"). most of tux' improvements have
been generalised and absorbed into the mainline kernel anyway.
j.
--
R N G G "Well, there it goes again... And we just sit
I G G G here without opposable thumbs." -- gary larson
john slee wrote:
>On Mon, Feb 11, 2002 at 08:36:55AM -0800, J Sloan wrote:
>
>>If that's not part of the roadmap I'd be surprised,
>>since tux is so much more capable than the
>>khttpd which is currently part of the tree.
>>
>>Tux has clearly demonstrated it's performance
>>and low resource consumption.
>>
>
>it has also been demonstrated that equal performance can be had in
>userland (search archives for "X15")
>
Well, I don't know about "equal" but many
webservers have benefitted from the tux
related kernel enhancements - yes I know
about X15, I tested it out too...
It's fast, but tux is faster.
>. most of tux' improvements have
>been generalised and absorbed into the mainline kernel anyway.
>
Granted -
So, just out of curioisity, why is khttpd in
the kernel? If there were any web server
in the mainline kernel I'd think it'd be tux -
Best Regards,
Joe
On Thu, 2002-02-14 at 18:33, J Sloan wrote:
> So, just out of curioisity, why is khttpd in
> the kernel? If there were any web server
> in the mainline kernel I'd think it'd be tux -
Personally khttpd should be ripped from the kernel. It is a nice, uh,
example. Or something.
TUX touches enough code that it isn't a clear decision to merge,
although it is certainly worth it. I, however, think we are rapidly
approaching the point, if not there already, that with a zero-copy
network driver userspace can perform as good as TUX with none of the
downsides. That was part of Ingo's goal and a lot of the benefits -
sendfile etc - are a result of TUX.
Anyhow, if I recall correctly, X15 performed better than TUX.
Robert Love
The problem with X15 is that it's unavailable. I've tried for months
and months to get someone at that company to respond or get a copy to
try. Also, is it GPL? Free?
For me, X15 are three alphanumeric characters.
I'd love to try it, though.
As for TUX, I would certainly prefer user-space if it was indeed as fast
in all cases. But I don't think X15 is really a factor in TUX's
inclusion. I'd say replacing khttpd with TUX2 is a no-brainer unless
X15's performance has been proven and it's GPL. And while khttpd is an
interesting example, it really rocks at small image serving. I've had
it in production since 2.4.0-test1.
--
Ken.
[email protected]
On Thu, Feb 14, 2002 at 06:54:41PM -0500, Robert Love wrote:
| On Thu, 2002-02-14 at 18:33, J Sloan wrote:
|
| > So, just out of curioisity, why is khttpd in
| > the kernel? If there were any web server
| > in the mainline kernel I'd think it'd be tux -
|
| Personally khttpd should be ripped from the kernel. It is a nice, uh,
| example. Or something.
|
| TUX touches enough code that it isn't a clear decision to merge,
| although it is certainly worth it. I, however, think we are rapidly
| approaching the point, if not there already, that with a zero-copy
| network driver userspace can perform as good as TUX with none of the
| downsides. That was part of Ingo's goal and a lot of the benefits -
| sendfile etc - are a result of TUX.
|
| Anyhow, if I recall correctly, X15 performed better than TUX.
|
| Robert Love
|
| -
| To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
| the body of a message to [email protected]
| More majordomo info at http://vger.kernel.org/majordomo-info.html
| Please read the FAQ at http://www.tux.org/lkml/
On Thu, Feb 14, 2002 at 07:00:03PM -0600, Ken Brownfield wrote:
> The problem with X15 is that it's unavailable. I've tried for months
> and months to get someone at that company to respond or get a copy to
> try. Also, is it GPL? Free?
i believe it was free for noncommercial use, a restriction imposed by
the author's company. i didn't bother to read back on the archives
though so don't accept this as verified fact :-)
> As for TUX, I would certainly prefer user-space if it was indeed as fast
also thttpd is very very fast on linux. really to need this sort of
performance on modern hardware is quite unusual at least in the public
internet.
> in all cases. But I don't think X15 is really a factor in TUX's
maybe not x15 on its own. but the existence of multiple userspace
servers that can provide similar performance may be a good reason to not
include it, as well as ...
> inclusion. I'd say replacing khttpd with TUX2 is a no-brainer unless
> X15's performance has been proven and it's GPL. And while khttpd is an
there's no reason why it can't stay as an external patch. redhat provide
tux rpms for example. i think khttpd should be removed altogether from
the standard kernel and not replaced with tux.
j.
--
R N G G "Well, there it goes again... And we just sit
I G G G here without opposable thumbs." -- gary larson
Ken Brownfield wrote:
> The problem with X15 is that it's unavailable. I've tried for months
> and months to get someone at that company to respond or get a copy to
> try. Also, is it GPL? Free?
I have a copy -- they sent one to me readily back when it was new --
but it's not open source, so I can't share it.
It's not a huge program; the whole thing is 5000 lines of C.
It uses the rtsignal method of readiness notification.
IMHO anyone writing a similar user-space server these days should start
with a clean encapsulation of the readiness notification code, e.g. http://www.kegel.com/dkftpbench/doc/Poller.html .
The performance would be similar, the code would be
a lot cleaner, and it'd be a heck of a lot more portable.
> As for TUX, I would certainly prefer user-space if it was indeed as fast
> in all cases. But I don't think X15 is really a factor in TUX's
> inclusion. I'd say replacing khttpd with TUX2 is a no-brainer unless
> X15's performance has been proven and it's GPL. And while khttpd is an
> interesting example, it really rocks at small image serving. I've had
> it in production since 2.4.0-test1.
Point taken. One of my friends uses khttpd in production, too.
Somebody needs to come up with a nice GPL'd userspace replacement
for khttpd. (Or does one already exist? I haven't been following things
too closely...)
- Dan
On 14 Feb 2002, Robert Love wrote:
> On Thu, 2002-02-14 at 18:33, J Sloan wrote:
>
> > So, just out of curioisity, why is khttpd in
> > the kernel? If there were any web server
> > in the mainline kernel I'd think it'd be tux -
>
> Personally khttpd should be ripped from the kernel. It is a nice, uh,
> example. Or something.
Linus put khttpd in the kernel just after sendfile support was added, IIRC
he said something about khttpd being a very small number of lines to add
once sendfile support was there.
if it's really that small (IIRC <<100 lines of code) it's still in there
becouse it's not worth ripping out.
David Lang
>
>
>Linus put khttpd in the kernel just after sendfile support was added, IIRC
>he said something about khttpd being a very small number of lines to add
>once sendfile support was there.
>
does anyone use the khttpd service for real today ?, is there
possibility making some useful stuff of it ? , interface it with apache
getting better performance or whatever ...
/Benny
I am using it, for example, on some web site, and it works well, abnd rock
solid. But on the internet, as it is today, it has no meaning
to talk about speed performances. But the server are less stressed than
with just apache.
On Fri, 15 Feb 2002, Benny Sjostrand wrote:
> >
> >
> >Linus put khttpd in the kernel just after sendfile support was added, IIRC
> >he said something about khttpd being a very small number of lines to add
> >once sendfile support was there.
> >
> does anyone use the khttpd service for real today ?, is there
> possibility making some useful stuff of it ? , interface it with apache
> getting better performance or whatever ...
>
> /Benny
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Wed, 2002-02-13 at 08:58, john slee wrote:
> On Mon, Feb 11, 2002 at 08:36:55AM -0800, J Sloan wrote:
> > If that's not part of the roadmap I'd be surprised,
> > since tux is so much more capable than the
> > khttpd which is currently part of the tree.
> >
> > Tux has clearly demonstrated it's performance
> > and low resource consumption.
>
> it has also been demonstrated that equal performance can be had in
> userland (search archives for "X15"). most of tux' improvements have
> been generalised and absorbed into the mainline kernel anyway.
>
> j.
>
If I"m not mistaken, Tux needs SSL and V-domains support. then I can use
it instead of Apache with mod_proxy (static) --> Apache mod_perl
(dynamic content) dual apache setup. Once this happens. My little
PII-350 should surly keep up with, if not be faster then that Dual 733
NT box for static content :)
--
Jason Czerak.
On 16 Feb 2002, Jason Czerak wrote:
> If I"m not mistaken, Tux needs SSL and V-domains support.
You are partly mistaken - tux does virtual domains like a champ.
Mass virtual hosting is easy and effective. Tux does need to pass
SSL requests off to a helper server though.
> then I can use
> it instead of Apache with mod_proxy (static) --> Apache mod_perl
> (dynamic content) dual apache setup.
I'd love to see mod_perl for tux - did I miss something?
I'd be just as happy about php, and there is what looks like the beginning
of tux support in php. If tux could load and run php modules, it would
open a lot of doors very quickly. (i.e. there are a lot more php
programmers out there than are in the tiny, rather elite group of those
who understand and can use the tux dynamic content api.)
> Once this happens. My little
> PII-350 should surly keep up with, if not be faster then that Dual 733
> NT box for static content :)
Indeed.
Joe