Slashdot Mirror
The Speed Demon That Is Tux 2.0
gergi writes: "Running at the kernel level, Redhat's Tux 2.0 blew away Apache and IIS in webserving content according to this benchmark! Given the never-ending security flaws found in other webservers, has a major turning point in web server design come about?"
Where is everybody getting that Tux 2.0 is a static webserver?
They're confusing Tux HTTP Server with khttpd.
pin eightThey do mention X-15 in the article, about 2/3rds of the way down this page http://www.zdnet.com/eweek/stories/general/0,11011 ,2776396,00.html
That is one way of doing dynamic content in TUX. You can also write TUX modules, which can run either in kernelspace (insane) or userspace.
> and Cheetha (from MIT) is 2-3 ORDERS OF MAGNITUDE faster than either.
From the cheetah page:
> Last updated by Marc 5, 1998.
The Zero Copy networking code that made it into the kernel thanks to TUX is also accessible via sendfile from userspace. X15 uses that and the RT Signals IO notification mechanism (like NT's completion ports, but lighterweight) to get TUX level performance entirely from userspace.
That said, Tux runs its modules in userspace, so by far the most likely place to have security problems is already pushed out into userspace. When was the last time you heard of an exploit for the core apache HTTP handler? Ever?
While you're waiting, check out this benchmark. Linux keeps getting better and better. There is no doubt about it; when speed counts, Linux is at the top of the list.
a) MacOS versions b) MacOS 10 is unix-based (more or less), and thus now comes with a command line.
So, I fail to see how MacOS is vastly superior to unix-based systems (or ever was).
Goddam, ppl keep saying its running in kernel space, thinking like all the time. Please ppl, note that only fairly _generic_ code is running in kernel - it spends like 2% of its time in kernel. Whats more this code is making its way into the offical kernel, for use for anything, so hopefully it won't need to patch the kernel once these changes are in.
The actual server so to speak is in usermode.
The us Army switched to MacOS servers from WinNT after being haked so many times (there are quarterly discovered expolits in MS Win NT web servers and as we all know Linux and even Apache on BSD have had many hacks and exploits regularly.
.exe extension can be executed!
Why is the mac the most secure? Runing MacOS 9.1 and earlier OS's it has no published vulnerabilities ever running WebStar (the most popular of the mac webservers).
Webstar is not magical, its just that that MacOS is more secure than unix for many reasons.
1> There is no command line shell to allow redirection. No shell, no shell exploits or redirection of scripting.
2> Everyhing is 'root' at all times so programmers do not get lazy and fantacize about the existance of a more secure root to help protect them. The Webstar server, as most mac programs, is written knowing that security is is important and that the code is running at root. Truthfully, PowerPC apps run at user-level, and Gary Davidian's birthdate needs to be passed in a register to gain true supervisor level, but no normal benefit is gained on a mac from running in the microkernel space or debugger-nub space.
3> Macintoshes do not suffer from stack exploits based on buffer overruns of C style strings. The mac uses Pascal style strings, instead of slow null-terminated strings in most all aspects of the entire operating system and in most users code. ANSI-C libraries are traditionally shunned. Pascal style strings are not only faster, they prevent the vast majority of buffer overrun problems.
4> Macintoshes do not EVER exucute code from file that are simple data files, no matter how the file is named or no matter how the file suffix is generated or set. Macintoshes use dual fork files, and text files and data files traditionally cannot easily become executables, and firthemore would typically need to have their 4-byte FILE-TYPE set to a value to even begin to allow a hackers file to be blessed for execution. Webstar and other tools do not typically allow any hacker or rougue tool to set file types by accident or on purpose. On a wintel system a text file saved with a
5> Source to mac os (pre os X) is not typically available outside apple corp. This is not a valid argument for security, (obscurity) but the appologists for the copious amount of linux redhat exploits use this as one reason for the many bugtraq exploits coverred.
6> The Mac OS weservers running Webstar do not automatically allow errantly saved files from executing out of the CGI bin merely because they are stored there.
7> The Mac OS has other good multi-homing multi-domain tools that run on it for robust free email (SIMS), DNS (QuickDNS Pro), FTP (Rumpus) and all have nice user interfaces to configure them and though these commercial tools may not be technically as secure as Webstar itself is, or the MacOS, I prefer them over running any open source tools on FreeBSD,NetBSD,OpenBSD,Linux, etc. Free is only free if you value your tech support at 0 dollars an hour sometimes. Plus, these other non Webstar related tools seem to have mostlty unblemished histories, unlike BIND.
8> People on the mac tend to use scripting languages based on Applescript rather than perl for os level dynamic work and protecting against some minor perl problems, or unix scripting (no command line on a mac, thankfully). I cannot attest to java as being swell, but the fact is many mac people tend to do dynamic content in straight C. Happlily Webstar includes a rich variety of trusted dynamic content assist tools.
There are many reasons that the WWW consortium members published that MacOS webservers are the most secure web servers.
Even source forge was hacked into last month, where apache source is held?
So all this laughable talk about shoving crap into kernel space is amusing to me (Tux).
The Mac OS running Open Transport, based on open protocols, and bilevel protocol stack declaration order is amazing. It avoids lots of famous TCPIP hacks and it also allows end-to-end file transfer from ram to ram without copying a single data byte! (only pointers to buffers are passed end-to-end in the most ideal situations) This is similar to some of the work Tux is trying to achieve. There are also papers that discuss proper tuning of open-transactions vs queued transactions and how to get the most astounding hits per second from dynamic webstar content. But if you want speed, run Apache on a mac, because apple demonstrated 18 months ago that the mac ran apache in a benchmark far faster than any other computer similar in cost.
- I'm not so sure putting the web server (ie, more code) in the kernel is a good route to better security
Then why say anything?Anyone that was sure about this would know that there are plenty of things that can be done to secure the system fully.
What I really want to know is how well it compares to X-15 (free reg. required), which trounced the original TUX, *despite* running in user mode. X-15 is also open source, and from the guys who make the ChromeLinux web server that was mentioned in the Apache section a while back.
Tux beats apache. Big deal. Apache is slow. Everyone knows that. I want to see Tux take on the current Linux web-server champ.
Yes, that would be rather insane.
Tux passes on requests to Apache so PHP content will still work, but it won't be as fast as serving static files.
---
> Frankly, from a security perspective, having a public-facing daemon running in kernel space is utterly frightening.
Maybe, but that's exactly what NFS does...
---
Gee, that's all well and good for serving static content, but what about dynamic content? And what about Apache with mod_mmap or those SGI performance patches?
They weren't trying to put together a comprehensive view of the market, only show that Tux 2.0 is dramatically faster than the competition.
This also means that if you DO have a bug that allows someone to exploit your web server they only get access to the web user, not the kernel privilegde level..
Anyone want to guess how long it's going to take before an exploit is found in Tux?
Tux is not just for kernel space. It has a very clever loadable module API for writing dynamic weblications (it is being actively researched by ad agencies judging by the Tux mailing list BTW). The modules can either run in kernel mode or user mode but obviously are much safer in userland. There is a clever mechanism for handing off control to the userland code whilst minimising context switches (as far as I understand). This allows for blazingly fast CGI like behaviour.
It also has a clever mechanism for running CGI apps more quickly than something like Apache.
If Tux didn't have support for dynamic content then it wouldn't pass the SPECWeb benchmark which has a large dynamic content from what I've seen.
In all other respects though you are right. It isn't as fully featured as a web server like Apache. I *am* hoping however that it will mature into a rock solid platform for dynamic weblication developemnt which really needs the drop in latency (rather than raw throughput) that you get from Tux's clever CGI architecture. Much smarter than Apache modules or ISAPI.
Dave
That's a little simplistic. Even some web content is protected, perhaps it's a pay site or members only site. As for database, you're obviously talking best case scenario here. Yes, you have access to the same data as the web server, but it's not true that this is the same amount of data you'd have access to as a web browser. Consider a simple members database, username, password (hopefully crypted), email address, contact info. Any particular user can see their own record (obviously), but they certainly can't see all the data the web server can (which is to say, all records). Being able to run 'select field1 from table1 where loginid='bob'' and 'select * from table1' are two totally different things. Normally, database driven, 'extranet'-type pages have access to a little bit more valuable data than this, having someone running the same queries a web server can against your db is a very serious security breach.
--
"Hot lesbian witches! It's fucking genius!"
LOL!
/. post I've read in ages :-)
Best
-----
In consequence, all that this benchmark proves is that proprietary software is pathetic, that over-burdened designs are poor, and that small, specialised tools are by far the most powerful.
Congratulations! Most of the UNIX world came to the same conclusion, over 20 years ago. Hence all the small (but powerful) utilities, rather than one single humungous blob.
What's needed is less arrogance, and more understanding that Small Is Beautiful (And Bloody Fast). A specialised server-side script server, that can do nothing else but handle server-side scripts, would be a good place to start. Essentially, it would be a "shell" for web clients, which could access a handler for PHP, a handler for Zope, another for CGI, etc.
Nothing would be "built-in", and nothing would be loaded unless it was being used. Small apps are fast apps. Less to load, less to page, less to copy in the event of a fork().
The problem with Apache is that there's too much of it. It's a brilliant piece of engineering, but that is precicely the problem. A multi-threaded, multi-purpose, multi-colour device is a marvellous device. It's the Swiss Army Knife of web servers. But, like a Swiss Army Knife, you generally don't use it for cutting steak, eating a hamburger, or mowing the lawn. You use specialist tools for specialist tasks.
This is something that is too easily forgotten. The Osprey is a classic example of why such approaches are doomed. Whatever turf it's on, it's always going to be the turf of the other guy. And that means it's always going to be inferior. Yes, overall, it can beat the pants off anything. Aircraft (with the sole exception of the Hawker Sidley Harrier) cannot fly vertically. Thus, in situations where vertical flight is necessary, the Osprey cannot be matched by (almost) any conventional aircraft.
Likewise, the Apache web server can compete in more arenas than ANY other web server in existance. But the price for this flexibility is that it will NEVER seriously compete with any specialised web server, of any kind. It can't.
Now, the question is: Is this a price you are willing to pay?
If the answer is yes, then Tux 2.0's performance can go rot in /dev/hell. If the flexibility is of overriding priority, then the speed penalty is of no consequence.
If the answer is no, then you need to get a specialist web server for each type of transaction you wish to perform, PLUS a transaction server which can fire up the necessary tool and hand over the transaction to process.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
TUX does a good job of identifying inefficiencies in the network code, and of identifying at least one critical path that can be optimized. It doesn't actually do all that much which is particular to web serving; it's mainly a routine for efficiently getting a file from disk (or, most likely, cache) onto the network, with a bit of stuff that does HTTP. Doing the whole thing is the kernel is slightly useful for performance, but I think the main effect is that the whole thing gets written and optimized at once.
Normal web servers are two problems working together: the kernel and the web server. Having a single program doing it means that it's easier to track what's going on through the whole execution path, so end-to-end debugging is easier.
In any case, HTTP is significantly simpler than TCP and IP, which the kernel handle anyway. So most of your web server is really already in the kernel; it's just that, instead of responding to just pings and TCP control packets for you, it also responds to certain requests for you.
But this is the point of the CSS 11801 Slashdot bought. You can load balance based on URL, extension, port, whatever. So images should get served from the image farm which should have enough RAM to server images from cache and run the OS, but not much more. Db servers would need more disk and RAM depending what you're doing. And so on. Purpose built hardware/software can do wonders for scaliblity. Tux is a good example of that thinking. Let all static info get served off it and the dynamic happen at other points.
kashani
- Why is the ninja... so deadly?
Well, if you want to get technical, it is probably:
Hypocracy - Less than normal rule, under rule (hypotonic, democracy)
Hypocrisy: Duplicitous behaviour.
But that's less funny.
-- perl -e'print pack"H*","6e656d6f406d38792e6f7267"'
You don't have you facts straight about TUX. TUX 1.0 run in kernel space because the developer thought a couple of things should be done differently. SInce then, a lot of his code has been incorporated into the 2.4-kernel. Because of this, userspace implementations run just as fast. (Look for X15 in the kernel archives if you want to know more). /jarek
TUX has four ways of handling dynamic content, and only one, kernel-space TUX modules, runs in kernel space--and we recommend that people not implement kernel-space TUX modules unless they have an overriding reason to do so. Normal TUX modules are run entirely in user space and have all the same security checks as any other user-space program.
-- "Ever wonder why the SAME PEOPLE make up ALL the conspiracy theories?"
TUX can serve dynamic content VERY fast, even running CGIs. Because of the overhead of dynamic linking, we recommend that CGIs running under TUX be linked statically for maximum performance. (This is, of course, not an issue for TUX modules, since they are loaded at server start time, not at each invocation.)
While TUX does have a fast path that can serve up static content without ever reaching user space, there is an option to send all requests through user space that only costs a few percent of performance even in the worst case. This can allow all sorts of interesting fine-grained control.
-- "Ever wonder why the SAME PEOPLE make up ALL the conspiracy theories?"
Not only that, but IIS (with SWC) also beat Tux 2.0 on nearly identical hardware. The question is whether or not the difference in hard drives was enough to account for the difference in performance. My hunch is that it is, but that's just a hunch. Either way, it's obvious that MS have been shocked into action by the performance of Tux, and have come up with something comparable. I'd like to see a real comparisson of Tux, IIS/SWC and X15 on identical hardware.
"The invisible and the non-existent look very much alike." -- Delos B. McKown
Yeah, I really dug that thread. As Ingo points out, X15 really shows how fast the 2.4 kernel can be in user or kernel space.
:-)
Now if they can just fix the freakin' VM...
-l
Help cure AIDS, cancer, and more. Donate your unused computer time to worldcommunitygrid.org. Join Team Slashdot!
Actually, IIS has most of the same API hooks as Apache via ISAPI Filters, which would allow you to write something very similar.
A quick google search turned up this from the Zeus manual of all places, which is an example of how that would work.
I've written my own URL-rewriting functionality for IIS before now with no problem, but at the moment, AFAIK, you do need to use some C to do it.
--
the telephone rings / problem between screen and chair / thoughts of homocide
"don't fall into the fallacy of believing that Perl can solve social problems. Maybe Perl 6 can, but that's a ways off"
until Bar came along which puts the entire internet in RAM. hope you have lots of it installed!
---
You don't need to hack the server in order to hack the access controls on the data available to the server. Is it immensely easier? Usually. But not necessary.
If I have the admin password for whatever app you're running, then I can see all the data, and never have hacked the webserver system.
This space for rent. Call 1-800-STEAK4U
This space for rent. Call 1-800-STEAK4U
Is running in the kernel necessarily safe? No, probably not. However, the Linux kernel is intrinsically safer than the NT kernel. Add the patched CAP functions to the kernel, and limit what the web server has access to. Besides which, if your data is that important to your company, you shouldn't be hosting anything on your web server BUT your web server pages. There shouldn't be any other logins or user accounts, the server should be in a extranet, and the only access allowed from it to other boxes should be from it to your backend database servers or such. Those connnections should be limited to some dumbed-down user equivalent in the DB. So if the machien gets hacked, the hacker can see all the web pages that he would have been able to see through the web server anyway, and can connect to your database to see data that he would have been able to see anyway.
Even in NT, this should be the case. Your web server being hacked, while problematic, should not be cause to call in the National Guard while S'Kiddies make havoc on your network. There's nothing wrong with Kernel-space applications when the box is set up correctly to account for the possibility of it being hacked.
In addition, Apache itself is marginally attackable by hackers anymore. Most hack attempts come through poorly configures applications on the backside that yield access to the server.
This space for rent. Call 1-800-STEAK4U
This space for rent. Call 1-800-STEAK4U
The main kernel improvements from Tux have been merged into the mainline kernel, so there really isn't anything interesting that Tux can do which can't be done in user space. I agree that running a web server in the kernel is a risk. Moving that to user space and running as a regular user should be the next step. There has been much yakking on linux-kernel about a user space web server that outperforms Tux.
AOL.
Except that it's going to be harder to write kernel code to give you a root shell (I hope) which is what all the script kiddies really want to run their IRC bots.
> Fear: When you see B8 00 4C CD 21 and know what it means
More fear: seeing that and in the process of working out what it does learning what the MOV AX, stuff opcode is.
--
Pretend that something especially witty is here. Thanks.
Maybe you should read the article:
Tux is also very easy to deploy incrementally across an enterprise because it can transparently forward Web requests it cannot handle to another Web server, such as Apache.
-Vic
X15, an experimental user-space server written to "compete" with Tux is faster:
h tml#3
http://kt.zork.net/kernel-traffic/kt20010507_117.
Frankly, from a security perspective, having a public-facing daemon running in kernel space is utterly frightening.
Apache is meant to have configurability over performance, and does dynamic content. However, I'm sure we'll see better performance from *nix based Web servers over time. Paul
http://www.pauldrobertson.com
the benchmark compared it to Apache, and not, say, IIS, iPlanet, or other servers.
ZOMG I WOULD LOVE TO KNOW ABOUT YOUR FEELINGS ON MACINTOSH VERSUS WINDOWS, VI VERSUS EMACS, AND HOW YOU'RE NOT A DORK
Um... the whole reason X15 is so fast is that many of the improvements made for Tux were actually put into the standard kernel, allowing X15 to take advantage of them from userspace (e.g. zero-copy sendfile).
Soon, we'll have:
X in the kernel
GNOME in the kernel
xterm in the kernel
a MUA in the kernel
and we wonder why Linux crashes 2 times a day....
But, it is always nice to see progress, and I'm glad that part of the credit is given to the kernel developers and their speed improvements in the 2.4 kernel over the 2.2 kernel.
Yeah... I defitely can't wait until Redhat decides to integrate and X server, Gnome, Mozilla, and an mp3 player into the kernel as well.
BTW, anyone know where the actual results are posted?
well, most images are static, so tux could handle the sending of images and javascripts, for instance, and leave the pages themselves to apache...
I don't quite see the point, though... Most sites are fine. Any processor with an ethernet connection available these days can saturate a T1, for instance... And with hardware performance increasing as it does, it would seem that effort would be better spent developing easy to use frameworks for deploying web based apps, as opposed to making a really fast applet.
Funny, how the /. editors didn't do anything but post what the NON-SLASHDOT EMPLOYEE submitted into the queue. So please point your biased finger at gergi. And they covered the benchmarks showing IIS faster quite well (search for "mindcraft" if you don't believe me). I don't recall *anyone* around here saying that apache is faster than IIS. Or Zeus. Or aolserver. It's just more supported via documentation on the 'net and well-rounded via modules that you can plug in. The larger user base almost guarantees that if you have a problem, someone else has had it before, and posted it somewhere along with the solution.
*plonk*
I read on the LKML about another web server which was almost as fast as Tux (sorry, no direct link because I can't remember the name). It was user-space rather than kernel space, but almost as fast as Tux and still faster than Apache because it was able to make use of some of the kernel improvements spawned by Tux.
Apache was never the real target, anyway - they've never claimed to be particularly speedy, just robust, flexible, and correct.
Caution: contents may be quarrelsome and meticulous!
Your right to not believe: Americans United for Separation of Church and
Amusingly enough, in a community of zealots, all members get painted with the same brush. Not all Palestinians are running around with "bombs for Allah", but they're all envisioned that way because enough do, and they're the loudest and most obvious.
You are very much judged by the company you keep, and I am utterly tired of this same whiny rant when linux zealotry is pointed out. If it doesn't apply to you, SHUT THE HELL UP. If it does, do something about it.
It is too, if those opinions are hypocritical. I don't think hypocrisy means what you think it means.
-Jer
X15. There is a blurb about it on the last page of the article. In fact most of the last page is touting that the speed improvements are not really because Tux is kernel space, but rather because the kernel as a whole has improved tremendously.
Q.
For those who aren't aware what Tux is, it's a cute penguin--the linux mascot. The real news is that it can now swim faster than a military aircraft can fly.
Celebrate the finer things in life
The fast webserver is called X-15. Here is a release announcement from the author, Fabio Riccardi.
For a discussion of this webserver on LK, see Kernel Traffic #119
/Styx
Tux handles dynamic content simply passing it to an user-level server such as Apache, Roxen, Zeus or whatever else you wish to use.
This means that were this a purely static-content benchmark, the results would have been much,much more in favour of Tux.
Funnily enough, having a kernel-space HTTP server might actually improve security.
Follow me: a buffer overflow's exploit works by uploading some malicious assembly code to the target system, and overwriting some memory location to cause the execution flow to execute the uploaded code.
Doing so might trash the stack, but it's not a problem since the malicious code might just not care. Suppose for instance we're cracking Apache: if the 'sploit mangles the stack, the process serving the request will die for segfault or similar. The super-process will just fire up a new one, thinking that the infected process just exited because it wanted to.
Now let's suppose that the same happens to a live kernel. If the kernel crashes, there's no recovery. If the attacker wanted to change something on disk, the changes wouldn't even reach it! Flaws in such a server would be much harder to exploit, because the attacker would have to ensure system integrity while doing her own deeds.
Sure, such a thing could cause availability problems (can you say "ping of death"?) to no end, but it wouldn't be a security problem. I don't know you, but I'd take an availability problem over a security flaw any time of the day.
Oh, we realize that. Happily, the moderation system picks out the interesting and funny stuff, and ignores all but the most entertaining or subtle trolls.
I notice your post is sitting at 0 points - I rest my case...
So is Tux 2.0 really any more secure than other web servers, or is it just that since it doesn't amount to a noticable percentage of servers, crackers haven't been trying to break it?
Is there anything fundamental about the design of Tux that should make us feel secure?
Hi Spoing, the story doesn't position Tux as a competitor to Apache. In fact, we went out of our way to test the combination of Apache and Tux working together, as well as Tux and Apache (and IIS) on their own. We point out how well Tux and Apache work together and recommend that combination.
You may have come to your conclusion only on the basis of the title of the Web article, which is different than the print version. I think the print title is better, which is Tux: Built for Speed.
Also, I think that painting all stories from all Ziff-Davis publications with the same brush is too broad a generalization. The company produces content aimed at everything from home users and gamers to IT managers at companies that spend millions of dollars a year on technology (the later is eWEEK's market). You're more likely to find stories you like by following the work of particular authors or publications than the activities of an entire publisher.
Regards,
Tim Dyck
West Coast Technical Director
eWEEK Labs
I bumped around redhat.com and found:
s /tux/
http://www.redhat.com/products/software/webserver
In case anybody had no clue, like me.
-S
Scott Ruttencutter
We Apprentice Developers and Designers
Why moves this into the kernel?
// EvilJohn
// Java Geek
Context switches between kernel mode and user mode take time. Indeed these context switches tend to be the single greatest overhead in I/O bound, multithreaded apps. If memory serves, the p3 700 mhz xeon requires around 3ms to do a context switch. These little buggers add up in a real hurray. For fun, turn on the "View Kernel Times" on your Windows Task manager and see how much time certain apps spend in kernel mode. Or for real fun, head into perfmon and turn context switches. Those take time.
Moving things into the kernel isn't always a bad thing to do. When Microsoft moved the graphics engine into the kernel, it allowed Win2k to use DirectX for real, not a bad thing, and it really hasn't affected stability of the OS. I think its safe to say win2k is most stable windows operating system yet.
Network drivers, USB Drivers, indeed IDE RAID drivers all reside at the kernel level, you just have to be careful that you've built a stable base.
I think the real advantadge here would be defining what you want in the kernel and what you don't. Hell, I suspect Apache in the kernel would push pages nearly as fast as Tux, and I could say the same thing about IIS.
John "EvilJohn" Carney
Windows Team Lead - TowerJ
http://www.towerj.com/
Less Talk, More Beer.
>They moved the GDI in the kernel at NT4, not 2K
. ht ml#1
// EvilJohn
// Java Geek
Yes the GDI was moved with NT4. But thats not the whole ball of wax, either.
>Your suspicion is wrong. Context switch is not the only things that tux optimizes. There is now an user-mode web server that seems to be at least on par with tux.
I assume you mean this:
http://kt.zork.net/kerneltraffic/kt20010521_119
It really just goes to prove the point about optimization. Algorithmic optimizations are better then system level ones, something I would categorize the movement into kernel space to be. The question on kernel space is does TUX gain from movement into kernel space?
I think it's pretty silly to assert that moving into kernel space doesn't bring you a speed increase to certain applications. Whether or not it's necessary is the question. I think the X15 project shows quite clearly the move isn't necessary, and a well coded, designed application is better.
2.4 is such a smooth kernel though, it really begins to make the whole debate moot. This is something not true of the windows world, where one still has to be a lot more careful about thrashing context switches.
Less Talk, More Beer.
nope, it's rule by river horse. Sounds like the name of a movie - "The River Horse Rulers"
X15 is very fast because someone tried to put a webserver in kernel space ie Tux and because of that experiment bottlenecks were found in the kernel and fixed that allowed many apps to become faster.
I see it as a good idea of trying to stick things in kernel space with the idea that it will never actually be put in. Think of this as a profiling project with real world data. At one point someone was talking about integrating CORBA into the kernel. I think this is a good idea since it really shows where things can be sped up.
This is one of the advantages of having the sourcecode. You can try something like this and see how it works and it helps spur development a lot. Right now I think efforts like this are going to be where a lot a linux's advantages come from over the next few years.
Computer modeling for biotech drug manufacturing is HARD!
You're missing some other critical points as well.
Not only is the read latency a heck of a lot less on the NT box due to the extra two spindles in the RAID array, it is configured with logging disabled and updating atime disabled.
Since it has less writes to the disk than the Linux box, it has more time to serve up content.
Oh, almost forgot, the NT box has 6 fewer client systems flogging the crap out of it.
These are just the obvious things from the results page, I'm sure there's more differences that don't get mentioned.
--
Matt
Matt
Of course they do. That was my point. I was just trying to say that if you have 1.5 Mbit bandwidth, it doesn't matter if Apache is slower than IIS or Tux/Apache or anything else. Your Apache is going to serve up enough to saturate your channel before you are constrained by any other resource.
;-)
People get so hung up on "speed" when it simply is not and should not be a factor. Don't kid yourself. I have worked for people who switched to IIS from Apache because it was "faster." We had a dozen separate web servers each serving up a different department's intranet content, all joined to the rest of the enterprise by a T1. There might have been good reason to switch (although I don' think so), but speed was a lousy one. Each box could saturate the the T1, even the one that was doing perl CGIs full time, without maxing any other resource. That's the point.
Also I was well aware that databases are frequently on separate servers from the web. I've worked on clustered database servers that have a dozen "servers" providing one database to hundreds of web servers. I'm just saying that this scale is a relatively small population. There are probably fewer than 5000 such sites in the world (Caution! That figure was pulled directly from the terminal end of my alimentary canal and I can't back it up with anything but my fists!
I would add that speed is a selection criterion for only a very small number of sites. Most corporate web servers I've worked on are served by anywhere from xDSL-class to T3 class speeds. Apache on a high-end Lintel box would keep that pipe full without being overloaded. (depending on the complexity of what's being served, of course! A lot of servlets that do 9-table joins in a Sybase database, all on the same box as the web server is quite different from serving only static HTML) So would IIS and Tux, since they both perform better. For that small number of sites (of the slashdot size, perhaps? ;-) that have pipes big enough to keep several server farms busy, ten percent less CPU demand can be big $$$ savings.
"Optimization" sounds like it is a single thing, but my "optimal" might be very diffeetn from yours. It is, as always, a cost/benefit question.
IIS has had kernel code since IIS 1. IIS used to bluescreen NT if it received an unexpected DNS response. Now that is the great "advantage" of a kernel-based application.
cpeterso
There are some research operating systems (such as University of Washington's Opal, I think) that use a single address space for all user processes. That does not mean there is no process protection (like Windows 9x), just that the the processes share the same address space. Each process still has its own page table (I believe), but the CPU's TLB doesn't need to be flushed because the mappings are still valid for all processes. Of course you run out of VM real quick, so this is only viable for 64 bit computers.
cpeterso
Why is running Tux inside the kernel so great? IIS has had a kernel module since IIS 1.0. And Microsoft got hell when it moved NT's graphics code into the kernel in NT 4.0.
;-)
This reminds me of a joke my CS professor made about operating system research: the "endo-kernel". Microkernel researchers try to move OS features from the kernel to userspace processes for extra protection and modularity. Other researchers (such as UW's SPIN OS and now Tux) move application "modules" from userspace into the kernel to boost performance. So now the "endo-kerenl" OS will be upside-down: OS running in userspace processes for protection, but applications running in kernel space for performance!
cpeterso
Excellent question. If your only goal is speed, then Tux 2.0 is the way to go. If, however, your goal is stability, then this article does nothing whatsoever to help you with a solution. Maybe Tux 2.0 is ultra stable. Maybe not. Who knows?
Thus the falacy of benchmarks.
Like the recent benchmark pitting Linux, WinY2K and FreeBSD against each other for serving speed. FreeBSD wasn't designed for speed. So what was the point? That Linux was better for a print server than FreeBSD? There is no way to know, because no one but an anal tech reporter cares how fast a print server serves up print jobs!
A Government Is a Body of People, Usually Notably Ungoverned
> Hypocracy: Tyrannical rule by Hippos.
Au contraire, Hippos gave us good government and low taxes. It was, however, somewhat embarassing when we had to explain to visiting dignitaries why we were ruled by a horse.
[Sorry: pedantic note follows. This does not make your post any less funny.]
Hippocracy: Rule by Hippos (or by horses).
Hypocracy: "Sub-rule", "under-rule", or perhaps "rule from beneath", as in "The Low Dwarves enforced a hypocracy on the High Dwarves, and even tried to extend it to surface dwellers".
--
Sheesh, evil *and* a jerk. -- Jade
Wasn't the latest flap-doodle from Microsoft a claim that Opne Source couldn't innovate.
Tux this.
As an administrator of several web servers (personal and educational), I must say that I've had to patch the IIS servers more times in the past year than the 1 time upgrade of Apache servers. I'm sure that's no surprise to many, but sometimes I consider the horde of flaws in IIS inexcusable.
Anyway, back on topic, I can see Tux as really cool, but how many security nuts out there (including myself) would be willing to run something so integrated with the kernel. Ironically, I could see this being likened to the flaws that IIS has...being so close to the core of the OS.
By the way, it's hard to post when you log in under www.slashdot.org, and the URL's keep bouncing over to slashdot.org....just in case one of you slashdot admins read this. (I know, bitch bitch, whine whine...)
Sometimes I doubt your commitment to Sparkle Motion.
http://www.microsoft.com/technet/security/bulletin /MS01-033.asp
posted yesterday.
'nuff said.
ditto.
At least there is the choice. Free Software.
Why are we pushing for faster and faster web server software?
When the Mindcraft fiasco first erupted, the standard response was "What does it matter, it's already fast enough to saturate the network?" That hasn't changed.
The speed of the web server itself doesn't even register on the radar. It's the dynmic part of the sites and the network itself that are slow, folks. If you have to serve up pages 0.05 seconds faster or you fail, you're too close to the edge of the cliff already.
Amusingly, the story also mentions that IIS (which pulled off 5,137 transactions per second) beat Apache (4,602 tps) in the performance tests. I wouldn't be so trollish as to guess why the Slashdot editor didn't note that in the story.
What's your damage, Heather?
Well, there were comparisons to IIS, and IIS beat Apache by about 10%. That gives you some idea to the relevance. The Slashdot editor could have just as easily said that Tux nearly doubled IIS's performance, and that's just as impressive - especially given that ZDNet is usually very kind to IIS.
What's your damage, Heather?
how did it handle dynamic content? Oh wait, they probably didn't think to test THAT out.
Well, from the article:
"...found that Tux was able to perform nearly three times faster than current Web server mainstay Apache (12,792 transactions per second vs. 4,602 tps) when running a mix of dynamic and static Web content.
Oh wait, you probably didn't think to read THAT before you posted.
What's your damage, Heather?
Tux is a static web server, whereas Apache and IIS are both full-blown dynamic web servers.
Where is everybody getting that Tux 2.0 is a static webserver? Here's the quote direct from Redhat's page:
TUX is a kernel-based, threaded, extremely high performance HTTP server. It is able to efficiently and safely serve both static and dynamic data.
ZD's test was a mix of 60% static and 40% dynamic. So...???
What's your damage, Heather?
Not that a lot of this wouldn't have happened anyway, but a lot of the impetus here is from the much-decried Mindcraft benchmarks.
Now all we need is for Microsoft to pay for a benchmark of SQL Server performance against, say, Interbase, and we could all direct our energies into a great open source DBMS.
No, MySQL does not count.
[duck]
--
--
E_NOSIG
Agreed, for the most part.
.|` Clouds cross the black moonlight,
I did a simple benchmark of _boa_ versus apache the other day. On the same box, delivering the regular static page that is Debian's splash-screen, I got twice as many hits per second and twice as much traffic per second using boa than I did with apache.
I suspect the reason is that all this `pool of servers' and particularly the `how well am I doing? oops, must throttle back, kill these daemons' concepts mean it spends all its time sorting its act out and not so long actually delivering results.
I'm of the opinion that something other than apache, for static pages, with proxy-pass back to apache for php/cgi would be the best way to go. Gimme the raw speed except where I don't expect it.
~Tim
--
~Tim
--
Rushing on down to the circle of the turn
What was the editors part in this again?
--
--
My comments and opinions completely reflect those of anyone and anything I am remotely associated with.
Can no one tell the difference between quoted submissions and editors comments?
--
--
My comments and opinions completely reflect those of anyone and anything I am remotely associated with.
Would that be a stoned OS? Just provide pot and wait for the computer to decide to start processing...
- I don't need to go outside, my CRT tan'll do me just fine.
Before people continue to fly off the handle about kernel bloat, kernel-space vs. user-space, et al, please take the time to read one of Ingo Molnar's comments on X-15 vs. TUX.
n el /0104.3/0814.html
http://www.uwsg.indiana.edu/hypermail/linux/ker
Apparently there is so little time spent in TUX-specific code (~2% of the total transaction), that other implementations, even user-space solutions, end up using a large portion of what we would consider TUX code. That shared codebase is known as the 2.4 kernel. The arguments thus far may have more to do with aesthetics than functionality or security.
- I don't need to go outside, my CRT tan'll do me just fine.
Faster than TUX, I can see. 2-3 times faster than TUX 1.0, I could possibly swallow. 2-3 times the speed of TUX 2.0 is just plain wrong.
Moderators! Don't you even bother looking for the supporting data? The item about Cheetha being 100-1000 times faster should have tipped you off that this person pulled those numbers out of his ass! If the Cheetha server can do what it says -- I for one am skeptical given this guy's list of "facts" so far -- it most certainly isn't running on anything remotely resembling a Dell 4400.
Point number two: TUX and Apache do not compete. If TUX finds that it the file you requested does not exist or that you requested a URL that has been flagged as unserveable (dynamic content), it passes the request on to user-space for something like Apache to handle. Apache, in this case, knows nothing about the go-between and reacts as though it were the only web server on the system.
Moderators! Send this guy to the hole! Meta-moderators! Make sure that the people who modded this up get slapped!
- I don't need to go outside, my CRT tan'll do me just fine.
If people are really worried about TUX which only handles static files by default and is fairly strict in the requests it will serve, what about NFS?
NFS has been in the kernel for a long time, does just everything that TUX does (network file distribution) and more, is far more complex, has had well known security problems, has had well known performance problems, and people are worried about hypothetical, *potential* problems in TUX!?!
- I don't need to go outside, my CRT tan'll do me just fine.
Smart coding pays off
Yup. It's pretty hard to write kernel code to give you a root shell on either system. The way most script kiddies would do it is wait for someone to publish an exploit and then tinker with it using a hex editor to make it do what they wanted.
If you subvert the system call table on either system you can gain a root shell fairly quickly, even from a web server like Tux or IIS.
Fear: When you see B8 00 4C CD 21 and know what it means
Exactly how is Linux kernel mode any safer than NT kernel mode? Once I'm in kernel mode I can do absolutely anything, regardless of the CAP functions - just hack up the kernel memory space and make all sorts of function calls around them. Code running in a processor's priviledged mode is (by definition) trusted code.
Personally, I'd be suggesting that the NT kernel space may be marginally more effective given that the kernel can be paged in and out which makes writing kernel buffer overrun stuff slightly more error prone (BSOD).
It comes down to the fact that if someone can run arbitrary code in kernel mode, they can relatively easily (at a minimum) switch out of protected mode, format all your hard drives, erase any tapes that may be in the machine (via BIOS calls) and basically render your machine worthless. This is WITHOUT calling any kernel functions!!
Of course, if you want to be more subtle, just rewrite the syscall interface table to some hooks that subvert the security of the system and let it appear to continue running normally while allowing you access to stuff you shouldn't (like passwords of users that logon to the site and other fun things).
Fear: When you see B8 00 4C CD 21 and know what it means
This isn't really a new idea. For instance, the SPIN OS offers extensibility which permits web servers to operate within the kernel. Additionally, exokernel systems offer the same potential. Still, it's good to see it finally happen - I'm surprised it hasn't shown up sooner in the more popular OS options.
Slashdot me and my kernel panics, fun.
How we know is more important than what we know.
Posted yesterday, yet another IIS sploit, I will ignore details and skip to the funniest section of the notice:
Funny:
Some people might wonder why this advisory does not contain the typical eEye
humor like most of our other advisories. Basically, the reason is that this
is our 4th remote SYSTEM level IIS vulnerability and well...we've run out of
jokes.
How we know is more important than what we know.
Yes, but it has a very restrictive license. Screw it.
Oh yeah, in case you don't know how to make your browser, undoubtedtly MSN-IE, go to a url that isn't a link, here you go idiot.
Of course there's always one more asshole out there. Right?
What's needed is less arrogance, and more understanding that Small Is Beautiful (And Bloody Fast).
>>>>>>>>>>>>>>>>
Good god. If only the Linux GUI developers would think the way the networking developers do!
BTW> This was directly inspired by the recent GNOME article...
A deep unwavering belief is a sure sign you're missing something...
It was compared to IIS as well, and with the waining percentages of other webservers, many of which are slow as dogs, there really wasn't any need. I think their points were abundantly clear.
Interested in open source engine management for your Subaru?
Nothing like a real world test
I understand that the Tux in-kernel webserver stuff is pretty minimal, but isn't running anything as notoriously security-risky as a webserver directly from kernel space a Really Bad Idea? I understand that Tux is fairly simple & open to peer review, but it seems like any tiny unchecked buffer or similar security hole could easily result in a remote root exploit, or at least a DOS atack (i.e. forcing a kernel panic).
The whole idea is pretty neat, though, and if there really isn't any risk of security problems, this could be a huge boon to busy web sites everywhere...
----
---- I made the Kessel Run in under 11 parsecs.
You're committing the age-old fallacy of assuming that all of us slashdotters are of one and the same ideology.
Have you found any of the same posters that criticized IIS and ALSO praised TUX? If so, then you have a valid response. If not (which I'm assuming), then SHUT the HELL UP!
I've said it before and I'll say it again. Slashdot readers are not of one common philosophy. We're a community of various people with various beliefs, who live in various countries, who use various software, etc. STOP assuming that we're all one and the same!
If Joe Linux complains about IIS, fine. If Mary Linux praises TUX, that's fine. It's NOT hypocrisy when different people give their opinions on different subjects! .V / _` (_-<_-<
.\_/\_/\__,_/__/__/
__ __ ____ _ ______
\ V
make world, not war
Given the usual creedence of such speculation on Slashdot, I'd say probably not.
---
Hypocrisy: Duplicitous behavior.
(Much respect.)
---
Given the never-ending security flaws found in other webservers, has a major turning point in web server design come about?
Let's see... I can make Apache or IIS run as a specific user whose access I can (largely) control, or I can run my web server in kernel space....
This is going to end "security flaws"?
Just a friggin benchmark.
It is cool though, since it beats Microsoft at the benchmark game.
It's basically worthless though, your webserver will bottleneck on a million other things before serving static html pages becomes a problem.
I'm sure others will point this out as well...
Sticking feathers up your butt does not make you a chicken - Tyler Durden
That's good news.
But the catch is TUX is a fully functional web server capable of dynamic content on its own. It can run CGI's and custom userspace modules.
Obviously it doesn't have all the features of apache, but in time those will be ported to the TUX architecture.
Dont confuse khttpd with TUX. khttpd is a static only web server and TUX is a fully dynamic web server that can complete the SpecWEB99 benchmark test on its own. That test contains 60% static content and 40% dynamic content, accurately refelcting the average content spectrum of today's web serving load.
No. He said that would be the most common approach because many many people/businesses have invested alot of effort and resources in developing Apache-specific content. Look at slashdot. It is apache specific and would take an equal amount of porting effort to bring it up on IIS as it would TUX.
"teg" is not saying that the only way is to use apache for dynamic. He's saying that will be a common way for the time being.
Due to the close positioning between the words security flaws and the major turning point regarding running it in kernel space, I think Tux is revolutionary in that it will let us completely destroy the server, rather than just DOS the http daemon.
That is what makes it such a major turning point.
kernal adj, 1. Relating to the technical appetites: kernal desire, kernal panic. 2. Holy or unworldly: kernal hacker, kernal space.
--
--
Artix
Your Linux, your init.
Statement: Hey, everybody, IIS is blazing fast because it runs in Kernal space!
Response: That's stupid! It'll crash the server! It'll compromise security!
LOL. As I understand it (and the article seems to back me up), the current version of IIS is userspace like it's always been. And yet it still manages to be ridiculously insecure. And, the benchmarks show that Tux is 2x as fast as IIS. So either IIS is userspace and your're wrong, or IIS is kernel space and you're wrong [because if it's kernel space too and still only half as fast as Tux, well that just plain sucks]
Basically, your whole argument makes no sense. How about this one:
DOS 5 is an operating system.
Linux is an operating system.
DOS 5 doesn't support SMP Alpha machines.
Thus Linux doesn't either.
Just because IIS 6 and Tux are both kernel-space web servers, does not mean they share anything else in common. Current IIS is really insecure, and I don't see how moving that into the kernel will help out a whole lot. OTOH, it's at least possible that Tux is secure. It's too soon to tell, as it has basically no history (unlike Microsoft in general and IIS in particular)
Anybody out there care to comment *intelligently* about Tux vs. AOLserver? I've heard very good things about the latter (granted, mostly from parties with a vested interest in promoting AOLserver) but I've never had a chance to use/benchmark it.
-- You are in a maze of twisty little passages, all alike.
>> Frankly, from a security perspective, having a public-facing daemon running in kernel space is
>> utterly frightening.
> Maybe, but that's exactly what NFS does...
* Actually, on "real" NFS implementations the kernel does some suport for serving NFS, but the daemons still run in user space.
* You don't serve NFS to clients you don`t trust - so it's not public facing (unless you are doing something wrong)
* NFS is only "static content".
* NFS is usually served over fast LAN connections (Fast Ethernet Full-Duplex or Gigabit Ethernet) even with moderate machines (e.g. I'm doing NFS with a K6@350 with IDE discs over 100MBit/s-FDX)---and even more important---the clients usually suck (and push) data at the same rate.
Absolutely nobody who has to serve web stuff that fast will do only static pages and not have the money to buy better additional hardware.
Summa summarum: Putting some parts of NFS server code in kernel space does make sense, putting an entire web server into kernel not - except for some embedded applications maybe (or beating others in benchmarks).
I see Tux as a "because-we-can" thing without real use.
That's great! So don't put it in your kernel. That's one of the wonderful things about Linux and the like. You can decide what goes into your system. The complaint with MicroSoft is that you don't have the option.
--Ty
I was refering to the IE on the desktop comment in respect to MicroSoft. There isn't really a practical way to keep it from being there. Wasn't refering to a web server.
--Ty
"Gee, what kernel is that?"
"Oh, it's the amazing, slices, dices, does it all more securely and faster Tux 2.0! Run out and get one today!"
The folks at Redomond are hiring PR flacks, maybe they should talk to the Tux people. ;-)
Read the EFF's Fair Use FAQ
So why don't you just allow the previous story today on the same topic to bubble up on the main headline list?
You know the one .
"Provided by the management for your protection."
that's easy /
;-)
chmod -R 000
Delrin
Has anyone looked on Netcraft to see who's even running Tux? Maybe the lack of people using it can explain the lack of security problems? ;-)
"The Speed Demon that Is Tux 2.0"
Shouldn't that be Daemon?
- --
- --
"I Hate Quotes" -- Samuel L. Clemens
I am not a developer (slowly learning C++ and will be in pre-CS @ James Madison U) nor am I a sysadmin, but I'm wondering.... what are the stability issues here? It would seem to me that unless Tux 2.0 is really a quality work then it could really give Microsoft grounds to make Linux look like a trashy webserver because if Tux crashes, wouldn't that often take down the kernel too?
Zeus is not a threaded server, or even like Apache, it uses a select() based model where one process can handle many hundreds of simultaneous connections.
Nitpick.
. html for more info.
I believe Zeus uses something similar to SGI's state threads, coupled with one heavyweight process per CPU. It's basically I/O multiplexing in multiple processes - a one to many process/connection relationship as opposed to a one-to-one relationship. The "threads" don't have any kernel entity associated with them, and aren't fully preemptive.
Check out http://oss.sgi.com/projects/state-threads/docs/st
Perhaps, but does the average user know enough to "secure the system fully"? I was taking issue with the article's implication that this would revolutionize web serving and increase security at the same time. I maintain that increasing the size of the trusted code base does NOT increase security, in fact, at worst it does the opposite.
I'm not so sure putting the web server (ie, more code) in the kernel is a good route to better security; it increases the trusted codebase. Perhaps the simplicity of the server makes up for this, but that's because it's simple, not because it's in the kernel.
Kernel-space web servers are a good idea for people who need super high-volume serving of static content. Those people hopefully also have the resources to maintain something as potentially dangerous as that. It's good for benchmarks, too.
But most people do not need this kind of speed; serving up static content, I'm sure a T1 would max out before a modest desktop machine would max out its CPU running apache. What people do need is safe software which needs little maintenance -- experience has shown that many users do not stay up-to-date on patches. Therefore, I say that moving to yet lower levels than userspace C (ie, the kernel) is a bad idea, in fact, we should be moving to higher level languages where more safety properties are guaranteed. Presumably, while this might lead to slower web servers (I don't think it would be more than a few percent), it would also lead to fewer bugs and lower maintenance costs. That's the real cost of software, after all!
--
So TUX is about 3 times faster than Apache?
Woohoo! Zeus is about 3 times faster than Apache as well, but doesn't compromise security by running in the kernel.
Apache's process model sucks badly (having a single process (or even a single thread) per connection is utterly wasteful of CPU resources when you can use non-blocking IO (like Squid) to handle tens of thousands of simultaneous connections from a single single-threaded process). You can get 95%+ of the performance benefits of TUX by writing a userspace web server with a sensible process model. There's absolutely no need to start delving around inside the kernel.
This is the principal reason that Zeus has dominated the SpecWEB benchmarks for the last 5 years; if you're after a fast web server, Zeus is a sensible alternative to TUX.
-------
-------
"don't smoke, don't drink, don't fuck
at least i can fucking think"
Minor Threat
Vielen danken for the correction.
Vintage computer games and RPG books available. Email me if you're interested.
IIS has always been a kernel space server. Or, I should say, has always had the option of running in kernel space. Similarly, NT 3.x had the graphical subsystem in userspace, but moved it into kernel space in the 4.x version.
Vintage computer games and RPG books available. Email me if you're interested.
Buddy, when I posted that comment, there was, I believe, one comment that I could read at my +1 threshold. I was railing against the poster and the slashdot editor, not against slashdot at large.
Vintage computer games and RPG books available. Email me if you're interested.
Statement: Hey, everybody, IIS is blazing fast because it runs in Kernal space!
Response: That's stupid! It'll crash the server! It'll compromise security! Statement: Hey, everybody, TUX is blazing fast because it runs in Kernal space!
Response: Wooohooo! This is a major turning point in web servers! Yay Linux!
Vintage computer games and RPG books available. Email me if you're interested.
I'm curious how people are going to use Tux. They said something about forwarding requests to other web servers. Does this mean that it is intelligent to know that *.jsp (*.pl, whatever) needs to be forwarded to the application server?
Looks like this performance would benefit web sites that have lots of static content, but won't help those of us who do very dynamic sites. I could see, however, a high volume site using Tux for /index.html even if they had lots of dynamic content...
A lot of servlets that do 9-table joins in a Sybase database, all on the same box as the web server is quite different from serving only static HTML ... For that small number of sites (of the slashdot size, perhaps? ;-) that have pipes big enough to keep several server farms busy
Slashdot and similarly-sized sites (such as Everything) generally run their database on a separate server from the web server, on a switched 100baseT or faster Ethernet. Larger sites probably run an Oracle parallel enterprise server anyway.
Will I retire or break 10K?
Do you know how many hits per day 4000 per second is? Think anyone will ever get that?
Two words: Slashdot effect.
Will I retire or break 10K?
Most of the time, it's not the web serving software that dies, but rather the connection to the internet that gets saturated.
If it supports cgi, it supports PHP as a CGI script. Applications should support databases, not the web server itself. I don't know about MOD_SLL, but if you read the article you might have seen that it says, "Tux's main weakness is that it doesn't support Secure Sockets Layer traffic, a feature planned for a future version."
With some caching techniques, or for less dynamic files, background processing (e.g. a perl script making a static file that is updated periodically), you could maximize the speed boost. And yes, running PHP as a CGI is going to be much slower on any web server most likely.
But if a security flaw is found, because the web server is part of the kernel, a h4x0r could take out the whole server. Then the only way to get it back would be a hard reset by a watchfull sysadmin, or a watchdog card. Dangers about young kernel users.
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
The SPECweb99 benchmark uses both static and dynamic content, and there are results from a variety of servers.
I think a comparison between TUX, Zeus, AOLServer, Apache, etc. might have given more useful results.
For all the web sites I've managed in my career, static page delivery has never been the chokepoint. Not even once. Even a sluggish web server can easily saturate a typical network connection serving just static content.
Besides, few web sites ever register that much traffic. Look at Apache's server status sometime. At the moment, it's pushing 1.2 MB/sec, and the CPU load isn't even close to the single digits.
As nifty and cool as Tux seems, I have a fear it wasn't created to solve real problems, but to win benchmarks.
MIT claims that cheetah is 3 to 4 times faster than IIs, which would be just about exactly the same as TUX 2.
I'm in the pro-Linux camp myself, but anyone who can't see that the parent poster has a valid point is full of themselves.
Opinion: Scientology is a cult you should avoid. Follow the
Actually TUX can do dynamic content itself via CGI - either standard CGI which is run in userspace and does not benefit significantly from TUX's speed, or as a CGI written to use the new TUX syscalls (a la ISAPI/NSAPI I guess), which does benefit a great deal. TUX does have the ability to transparently pass requests it cannot handle (e.g. pages that use mod_perl, mod_php) up to another webserver that can, but it's not necessary to do this to serve dynamic content.
Read the TUX 2 manual here and you'll see that this is true.
My guess is that the dynamic content in the TUX 2 benchmarks was produced using CGIs that were written specifically for TUX (it makes sense if you're trying to achieve the highest benchmark figures right?) and thus a static content-only test would make little difference to the scores.
Perhaps you were thinking of the venerable khttpd that has been in the kernel since early 2.2 days? That was the early testbed for in-kernel webserving for Linux and TUX is based on many of the same ideas although little code is shared. khttpd does indeed suffer from not being able to serve dynamic content itself, and this was one of the reasons why TUX was created.
Then I stand partially corrected; there have been plenty of stories before on this combination, and I don't care for any more while reading Slashdot. Is this Ziff's fault? Nope. Is it Slashdot's? Nope. I'd still like a check box, though.
Monotony is monotonous, and I didn't read this specific story since there didn't seem to be much of a point after reading the title. I've wasted time on fluff and untimely pieces before -- Ziff-originated and not -- and I honestly don't want to even know about them in the future. If I'd have to limit myself to blocking Ziff-originated stories only -- even when occasioally loosing out -- the trade-off seems reasonable.
This might not seem fair, but I personally have only so much time to look at any specific article -- there is too much good stuff available from other sources including mailing lists, newsgroups, and more focused zines (online and offline).
Also, I think that painting all stories from all Ziff-Davis publications with the same brush is too broad a generalization. ... You're more likely to find stories you like by following the work of particular authors or publications than the activities of an entire publisher.
Agreed on specifc authors and some articles in specific publications. From a larger perspective, after many years of reading publications from Ziff-owned sources, I've personally found little value in them that I can't get elsewhere; the hit to miss ratio is just too low. Others might find otherwise, as is thier choice.
As such, from experience, I'd really really like to filter out stories from Ziff-owned sources when visiting Slashdot. [frustrated]
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
I am honestly sick of Ziff, though. They are the Mickey-D's of the computer press, and while they have thier place, and offer up the occasional useful story, I would really like to carve out a Ziff-free, or at a minimum a Ziff-limited one.
Plea: Could the great and all-powerful Slash web meisters add a check box for blocking Ziff stories?
Thanks for listening!
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
It might just be me, but I'm a *little* wary of the security implications of something running right in the kernel of the operating system. I smell security breach *somewhere* lurking in this product.
But, it is always nice to see progress, and I'm glad that part of the credit is given to the kernel developers and their speed improvements in the 2.4 kernel over the 2.2 kernel.
--You will rephrase your request for me to go to hell. Goto statements are not acceptable programming constructs
--
In spite of the suggestions and all the tests that I have made, I have not cavato a spider from the hole.
Hmm...just what religion do you think Jesus was?
Not sure? I'll tell you. Jesus Christ was JEWISH.
Therefore, YOU, Mr. Jew-Hater, hate Jesus Christ. You cannot be both a Christian and a Jew-Hater.
Sorry. You are going to Hell.
No, Thursday's out. How about never - is never good for you?
Remember, you can't neglect PHYSICAL security! I'm ordering Wood today. Or is it Free?
Uh, you don't need to use kernel space to achive this kind of performance in linux... Check this out...
X15 alpha release: as fast as TUX but in user space.
It's a beginning of a new era alright. An era of putting code that is destined to open us all up to a mess of portability, compatibility and security problems. That has no reason being in the kernel, for those of us that have respect for the basic decency of the UNIX programming model... And in the end, for no real benefit. Hooray! pfft.
who gave this +1 insightful
ask yourself how many web servers serve up lots and lots of images.
if you had a webfarm, you could move your images to another server (images.slashdot.org) and serve images using that and keep your perl code in an apache server (www.slashdot.org).
or simply serve the images from the kernel and pass up the dynamic requests to the userland daemon.
But Axe 1.0 can crack it in under 6 seconds!
Firethorn
I don't read AC A human right
With gigabyte RAM available to even small companies now the question of disc access is relatively unimportant.
TW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
I believe that the next release of IIS (6.0??) will involve moving things into the XP kernel space, to emulate the speed of tux. Microsoft is slowly learning from us I guess.....
there are no stupid questions, but there are a lot of inquisitive idiots
Found in the Linux kernel. Play with it, bench it, enjoy it. 'nough said, eh?
Microshaft still OWNZ JOO!
SIG: HUP
Autistics or those with aspergers are too inclosed in their won world to care or even process the idea that someone from outside their little world can hack into a corporate server.
Aspergers individuals are truly retarded people who think they know a few things in their specialized area's in their own slim view of the world.
Infact at work we fired someone because he had aspergers. He seemed very smooth in the interview but in work performance (a desktop support job)he was a moron. He would not say the right things to the right people and only cared about computers in his own obbsessions. He also would not help people and comfort them like any desktop support person rightously would. It was like he didn't see their problems or did not care. The funny thing is now several months later he works at a McDonalds!
Just because he had an mcse he expected to know his stuff. Well, someoeboyd autistic or aspergers really does not belong in the corporate environment. I am sure he will work fine in a fast food place considering they are midly smarter then somone with down syndrome.
Well, mmol, would you like any fries with that ?
http://saveie6.com/
One of the most important OpanSource advantages is reusablity of Code.
Apache is an exsiting and very complex Web SErver having many exciting fetures. I question wether it is possible to add Apache to the Kernel.
I don't have the experience to comment this, but is it possible to do this? Of course there would be a rewrite of the Libc calls translating them into Kernel calls.
Nice to see it trouncing IIS like that even if it is Red Hat. Maybe this webserver is the reason that Microsoft was so intent on delaying the kernel.
Simple, you define your "target mix" (see here) for the test to include no dynamic content. Or you choose "dumb" dynamic code that really isn't dynamic (the benchmarker gets to pick his own dynamic code).
Also note that this article does not say that the specweb99 benchmark was used this time, it only says that eWEEK worked closely with Dell, who did some specweb99 benchmarks of Tux before.
So basically we have 1) no indication that the specweb99 benchmark was used this time, and 2) no requirement that dynamic content handling is needed to complete the specweb99 benchmark.
And while it is entirely possible that Tux does indeed do dynamic content and is very fast at it, this article offers no proof of it. It would help a lot if they actually mentioned what benchmark they used, and gave some more results than just the few numbers given. It would be even better if benchmark results applied to real-life situations as well.
To make it worse, on most Unices (Linux, BSD, Solaris...), "non-blocking" disc IO does in fact block! To get around it you either have to have a separate process for each asynchronous disc request or use non-portable asynchronous IO APIs. Have a look at the Flash web server to see how these problems are tackled for real (Flash beats the pants off Apache and Zeus.)
- Ralph
They laughed at my CLI-less Mac and then at my GUI-less BSD box. KDE shut them up.
so did an amiga. :)
--saint----
Ideas cannot be owned, so they cannot be stolen.
C//
The next version of IIS (which ships with Microsoft Corp.'s Whistler project) uses several ideas introduced by Tux, including the kernel-space design.
So we'll bash OpenSource all to hell, but yet we'll steal the standards and ideas adopted by Open Source applications. Is this their idea of 'embrace and extend'... ? I may just be uptight, but this pisses me off....
"Pussy: You spend 9 months trying to get out of it, and the rest of your life trying to get back in..."
I lost my concept of community when my community lost all concept of me.
You can't lump Tux in with general Web servers, since it's rather limited as to what it can do - remember, it's only for STATIC pages. You still need an additional Web server for CGI programs or any sort of dynamic site or one that relies on modules like PHP.
Used correctly, and in conjunction with Apache (or another server) Tux is an *extremely* welcome addition to the stable. Props to the people involved on this.
So yes, that is cool that tux uses kernal space to speed up its transactions. Seems like cheating, but whatever works, right?
I wonder how tux compares to a threaded Apache? such as Zeus. Zeus is one of the fastest Apache servers that I know of, mainly because it is threaded. I would like to see that comparison.
Also, this can't be as stable as a per-process version of Apache. If one of the Apache processes dies, Apache just spawns a new one. This is why we still use good 'old vanilla Apache. I guess we just don't trust our custom modules as much as we should; or maybe we trust them just as much as we should. (;-)
room101 -- how much can you stand before they break you?
(they always break you eventually)
WIRED: EEye alerted Microsoft's security team immediately upon discovery of the vulnerability several weeks ago and has worked closely with Microsoft on the development of a patch and the expeditious alerting of system administrators worldwide.
ZDNN: "It's just far too complicated--one new capability, one new feature can open holes in an operating system that was thought to be air-tight," Wheatman said. "Security is never done. It's part of the development process."
On that basis, Microsoft scores highly for its response, said International Security Systems' Rouland.
"If you compare the speed at which Microsoft responds to these vulnerabilities, it's incredible," he said. "They get through with the information and the fix much quicker than you'd see with open-source software."
(emphasis mine...)
Fair to say that M. Rouland just scored a huge A+ in my "troll of the year" quest...
But does someone knows what the hell is International Security Systems, except a lame sounding name?
The closest I could find is a Christopher J. Rouland working for X-Force @ Internet Security Systems (xforce.iss.net)...
-- p a n a p i c - panoramas des alpes: Mont-Blanc, Mont-Rose, Cervin, etc...
Speed is the easy problem to solve. They solved it the same way IT has solved client/server capacity problems in the past. More memory, more threads, fewer I/O bottlenecks. This isn't news.
Why doesn't someone solve the real web problems. Why doesn't someone revise HTTP and HTML so that all browsers work the same way? Why doesn't someone make a really usable client-side environment? Why can't someone figure out how to make money from the web without popping all those fscking add windws!
- Sig this!
by IBM. Even Microsoft is using ideas like this in new versions of IIS.
--- Don't be a player hater: I meta-mod ALL negative mods as Unfair.
The article doesnt mention what version of apache was used. I'd be interested to see how the new Apache 2 stood up in the benchmarks.
This is all just comparing apples and oranges though.
Tux is a static web server, whereas Apache and IIS are both full-blown dynamic web servers.
Sure, we can compare them as this article did, but the results don't mean shit.
No Comment.
that's not exactly what this guy is saying.
as a summary he says tux can handle dynamic requests by forwarding them to apache (or any other web server).
so, who is right or wrong ?
Arrggg!
Why can't people read? Tux can handle dynamic content. If it couldn't, it wouldn't be able to run the SpecWeb benchmarks. The reason why Tux is fast is *not* because it supposedly cannot run dynamic content. It can. The reason that it is fast is because it runs in the kernel and is highly optimized.
Those of you who think that Tux can only handle static pages are thinking of khttpd.
Do your bloody research! At least read the story linked to.
Hear hear. I've always thought that TUX was a terrible idea that exists only for the sake of creating artificially inflated benchmark scores.
I notice that several posters comment that "TUX runs dynamic content", etc., etc. Yeah, it runs arbitrary dynamic content in my kernel where it will take down my whole system! No thank you. Oh, and by "dynamic content", they mean my own binaries; forget about all of those nice Apache modules you were planning on using.
And even the most basic HOWTO on setting up httpd starts with "make the daemon run as nobody". But TUX does away with that: run not only your http process but all dynamic applications as root! Wow this is dumb.
On the other hand, X15 has an intelligent model (Apache's model, in fact), and leverages the most popular web server ever, namely Apache. And in fact, it does appear to greatly improve my performance.
If you think you need to make your regular Apache install run faster, avoid TUX and try X15.
Invisible Agent
Invisible Agent
This post is a mirror; when a monkey stares in, no hacker gazes out.
I agree with most of your post, but I don't get how X15 has a "restrictive license"; they just want some money for it, that's all. This may get me tarred and feathered, but I for one am glad that there are independent commercial s/w houses trying to make a buck by writing to the Linux platform.
<rant>
IMO, Microsoft has destroyed independent for profit s/w development on their platform, and Linux could revitalize that sort of work (which consequently moves people off of MS platforms onto Linux, which is a Good Thing). Open source and commercial software can live together.
</rant>
That said, I wonder if you're right that "teams of geeks" will make something as good as X15. Maybe, but lots of good people have been working on both TUX and Apache (and many other web servers) for a long time, but X15 is still faster. Same goes for ChiliSoft - you don't see Open Source ASP clones either.
Invisible Agent
Invisible Agent
This post is a mirror; when a monkey stares in, no hacker gazes out.
Tux won't be cross platform like Apache does, unless you want to run RH Linux/Tux server for the rest of life. in addition, Tux would pose even bigger security change, wouldn't it ?
> Oh wait, you probably didn't think to
> read THAT before you posted.
THAT didn't say how it performed doing static content. THAT said how it performed doing a MIX of static and dynamic content.
Since Tux only does static content, and hands everything else off to a full blown web server, it is a reasonable question: just how fast is it for PURELY static content? And how fast is it for PURELY dynamic content?
One would naturaly expect a much bigger performance boost for pure static content, and probably slower performance for pure dynamic content.
--
Lets point a front page slashdot story to a Tux 2.0 webserver and see how it'll handle the slashdot effect.
And in other breaking news today, the latest web server, Foo, has found to blow away Tux, Apache, and IIS in terms of speed.
Although the initial install is slow -- as the entire Internet gets downloaded to your hard drive -- after that, nothing else even comes close in terms of performance.
There are three major possibilities:
Does anybody know what the "Requested Connections" parameter is for (down at the bottom right)? If the value represents the limit to which the servers were pushed, it looks like TUX wasn't pushed to the limit...weird (if that's even what the value represents).
One thing that has been hinted to, but not completely stated, is that the kernel (at least in Linux) is the interface between the applications you wish to run and the hardware. For lack of a better term, it's an API for your computer's hardware. That's why Linus wrote a kernel, because he liked to mess around with hardware. A web server is an application. It opens files, sends out TCP/IP packets, etc...and this should all be done through system calls to the kernel. And that's that...
"Karma can only be portioned out by the cosmos." -Homer Simpson
Since this is generic technology that is now part of the kernel, there is no reason why Squid (a full-featured, but rather slow caching proxy application) can't take advantage of this too! I would love to see some free software that outperforms all the proprietary crap that companies like Network Appliance, Inktomi, Infolibria, and others charge tens of thousands of dollars for. Perhaps it would trickle down to becoming cost-effective enough to embed a caching proxy into a $200 DHCP/NAT box to speed up all users. Just wishful thinking out loud from someone who can't get a high-speed connection at home.
A lot of /.'ers have mentioned security issues, and that tux has no valid uses.
However, this is a perfect solution for embedded or Linux running on a CD-ROM. Look at ThinkNIC, they use the fast boa webserver to locally serve the "desktop" of the NIC. The faster and small footprint the better in this situation.
If tux is bound only to the local loopback and is only serving local pages fast, then there are no security issues.