Slashdot Mirror

Read the roadmap; usability and import/export are at the top of the list.

Let's hope that Microsoft's move to XML formats is going to happen for real; that should greatly simplify the creation of import/export filters for OOo and other applications.

I fully agree: as far as I'm concerned, I don't miss MS Office at all. And OOo keeps getting better; have a look at the roadmap for OOo 2.0. The people working on it are fully aware of what users need and want most.

And not only that, but they've hired Dan Kegel. Do a search for "kegel" and see what you find...

I've got the laptop in question right here, (I'm typing on it now) and yeah, I dual-boot Linux (Knoppix knx-hdinstall) and Windows 2000 SP4. I need to upgrade the hard drive to give both systems the space they need to coexist happily, but even now they both are happy together. The hard drive is 10GB, there is 228MB of RAM in here, and I have both a wired NIC and a Prism-based 802.11b card to use with it. It won't run Neverwinter Nights or Doom 3, or anything like that, but from what I understand Starcraft will probably run on this. I can certainly play KMahjongg on this until the cows come home.

However, I intend to use this machine primarily on Linux...*especially* when it is hooked up to the University network. Everyone knows just how good OpenOffice.org is as an Office alternative, and how much it needs to evolve, so I won't say much about that. However, the SPSS requirement is something that takes some thought.

After some judicious googling, I found two SPSS alternatives: The R Project and GNU/PSPP. I don't know much about either program, (nor do I know much about SPSS) but it's good to know there are at least two alternatives that leap out at you when you look for it.

Linux should be a supported alternative at all Universities and Colleges throughout the world. Actually, I think Linux should be promoted over Windows, and I am not alone in thinking this..

Linux solves a lot of problems that bedevil IT departments at Colleges and Universities. It comes with great Free/Open Source alternatives to widely-bootlegged proprietary software. It is less prone to malware, viruses and trojans. It is more secure than Windows. And if you look beyond full-figured GUIs like GNOME and KDE and use trim window managers like IceWM, BlackBox, XFCE and so on, you can run graphical Linux on modest computers. Linux + KDE is actually quite nimble on my 400MHz ThinkPad 600E, and I have seen it run OK on 233MHz Pentium systems with 128MB RAM or better. If Windows 2000 will run on a machine, Linux and KDE will also run.

All these problems the article we're discussing enumerates would be ameliorated if not completely sidestepped by encouraging alternatives to a Windows Monoculture.

This is one of the excellent reasons why school districts and university systems need to think seriously about moving to Free/Open Source Software. Schools are hurting for money, they have impossible budgets, so who wouldn't be surprised that there might be a few warezed copies of expensive software floating around?

Since the BSA seems to have cojones of steel and no compunctions about storming into Junior and Missy's school and busting teachers and pupils, it is incumbent on school districts and university systems to reduce their exposure to this quasi-legal extortion. The best way is to wean themselves from proprietary software.

I am a student at a Los Angeles Community College District campus, Los Angeles Valley College. The school is running almost exclusively on Microsoft products. Are they 100% paid up? Can they whip out COAs on all their software on the BSA's whim? I am reasonably sure, in spite of the strong precautions taken on the student-accessible end of their network, (you cannot install anything on any of the student computers and even trying will get you banned from the network) that they are not 100% locked down.

However, if they were running a Free and/or Open Source operating system (technically the *BSDs are non-Free in the Stallman sense of the word) and F/OSS they would have no reason to worry. Even on the machines that absolutely, positively HAVE TO run on Windows, (some courseware is Windows-only and requires brain-dead Windows only tech like Active-X) they could protect themselves by running Win32 F/OSS like the Windows port of OpenOffice.Org, The GIMP, Mozilla Firefox, and so on.

This is an excellent article by Dan Kegel about the case for Linux in Universities. Just about all the arguments about Linux in Universities apply with equal veracity to Linux in Primary and Secondary schools.

Any Arizona LUG people out there? I suggest going to your local school district and volunteering your services to help migrate their computers to F/OSS.

Also, a couple years ago, I experimented with gnome's corba implementation, Orbit. It was pretty darn lightweight and fast. Since then, Orbit has made so much progress, maybe I should have a look at it again, and see how hard it'd be to add support for that to crosstool, so Corba could be an easy option for people using crosstool-generated toolchains.

The new linux kernel is great, but the reason the this particlular kernel results is better performance ("5 times better") is because the application framework it is testing is horrible.

All of the "enterprise" applications in this test have several performance cripling features in common: socket per thread connections, fundemental reliance on threads, and massive memory foot print. Apache has one thread/process (the diff is a stack) per connections. Java requires a sizable multiple of memory usage as most other application languages (C/C++ obviously, but also Perl, Python, and PHP). J2EE is an inherently thread driven programming framwork.

So yes, Linux 2.6 ameliorates the downsides of unnecessary use of threading. It makes thread creation and context switching even faster on the Linux platform.

And Yes, Linux 2.6 memory management is fundementally better. Reverse Page Table Entry mappings make finding victim pages better; and it is designed to avoid victimizing active pages better.

But could you all imagine if people were designing fundementally better application framworks? Event driven application architectures like TwistedPython and POE, or Event-thread hybrid systems like SEDA.

The performance stats given in that article are shit, complete utter shit. I know. In the proprietary world I work in, I code faster programs on the same Linux platform on a daily basis; orders of magnitude faster.

All the accomplishments of Linux 2.6 can be used for true performance programming. I plead with you all, stop using Threads until you know what they are good for. Stop using the stack to maintain your program state. Throw off the shackles and learn to program network servers.

FreeBSD can do some really nifty stuff that Linux can't. Like jails.

I'm curious, how are FreeBSD jails different than a chrooted process or a jailshell under Linux?

I read this piece yesterday. Here's a tip for those of you who may currently or need to work on building an x86 to x86_64bit cross-compiler under the Linux operating system.

One of my tight friends, Dan Kegel (cute pic of him here, oh and he works for Google, so he's super-smart and rich! :-*), has something called the CrossTool at http://kegel.com/crosstool that should be of major help to anyone working with 64-bit Linux systems.

You may even be able to list it as COTS on your project even though it's free as in beer. In any case, I've tried it, it's sweet, you should try it, it works great for what it does, just like most *nix apps. I prefer having one small tool do something really well than one large software package do a bunch of things really crappily.

Anyway, stop by Dan's page and say hi. Tell him I sent ya ;-)

I read this piece yesterday. Here's a tip for those of you who may currently or need to work on building an x86 to x86_64bit cross-compiler under the Linux operating system.

One of my tight friends, Dan Kegel (cute pic of him here, oh and he works for Google, so he's super-smart and rich! :-*), has something called the CrossTool at http://kegel.com/crosstool that should be of major help to anyone working with 64-bit Linux systems.

You may even be able to list it as COTS on your project even though it's free as in beer. In any case, I've tried it, it's sweet, you should try it, it works great for what it does, just like most *nix apps. I prefer having one small tool do something really well than one large software package do a bunch of things really crappily.

Anyway, stop by Dan's page and say hi. Tell him I sent ya ;-)

Hey folks, I'm the guy who wrote the cross-compiler build script he used to compile the drivers, busybox, and snort. In case anyone needs to do something similar with other devices in the future, it's quite likely that ptxdist will be able to do it out-of-the-box. It already builds busybox for you, and I have a feeling it'll also build snort for you pretty soon. ptxdist is THE distro for embedded devices that use glibc, IMHO. It doesn't support many apps yet, but it's very cross-compile friendly, and I plan on using it for all my embedded development needs in the future.

Could this be used to establish ssh tunneling from clients to the AP? That would, in my eyes, be far preferable to the somewhat lacking link security that 802.11 offers today.

For sure, i bet it would be a simple hack to the cross-comiling build script for mips found here to include a suitable build of sshd.
Oh, and if you do let me know i'd wouldn't mind a copy. ;)

I'm very interested in the non-speed problems your folks have been encountering. OpenOffice 1.1 beta 2 is out; it would be good to know what issues still remain. Perhaps a few of them can be addressed before 1.1 final is out. See my page on the subject. If you have any documents that can't be opened in OO1.1beta2, please send me a copy, I'll light a fire under the developers. Or file your own issues if you're motivated.

You probably know about this paper already, but just in case you don't:

The C10K problem

The paper deals with web servers handling ten thousand simultaneous TCP connections. But most of it is not particularly related to HTTP or web problems, but with more general socket I/O stuff --particulary with the ways of dealing with readiness/error notifications (e.g. select(), poll(), asynchronous signals, etc.). It also discusses other kind of limits (threads, processes, descriptors).

It is quite enlightening. It may be a bit outdated --I remember reading it about the time Netcraft was doing all that noise about Windows being faster than Linux as a web server-- but I'm sure most of it is very relevant.

wget is the god of resuming either ftp or http. I have yet to see either fail, and don't notice too much of a difference in speed.

There are many, many ftpds where there is one prevailing httpd. Apache is very good at shoveling things across a network to be sure, but there seems to be an ftp for any particular purpose. Lots of more commercial OSen use ProFTPD for its recognizable config file and configurability, also, check out kernel.org's bandwidth meter. I don't know how shoveling out 50-100mbits/sec of data to thousands of users at all times washes with people, but it seems to lend credibility to the idea that ftp is a performer. ncftpd also has legendary performance.. Let's not forget VSFTPD, ftp.redhat.com, ftp.openbsd.org and ftp.suse.com are vsftpd.

All in all, wget, apache, a good ftpd [take your pick, PRP, VS or NC] and ncftp are required for sane internet usage.

And I've never seen wget fail a re-get...

and death to IIS ;p

Ace's Hardware needs to research real servers before talking about their "scalable" servers. Their numbers are really saying that their box performs like a dog.

For those of you interested in this topic here is a few pointers and words of wisdom.

Server scalabilty and performance has three basic metrics, thruput (urls/sec), simultaneous connections, and performance while overloaded. Of course, you could add latensy but I'd argue that with the correct design latency is directly proportional to the real work you are doing, bad design insertes arbitrary waits.

I know of a HTTP Proxy by a large ISP that does user authentications & URL authorization (re: database), header manipulation, and on-the-fly text compression at 3000 urls/sec for 2000-4000 simultaneous connections and maintains that performance under load by sheding connections, all this on a dual 1GHz Intel PIII box running a Open Source OS that starts with "L". That is a maximum of 260 Million URL/day, three orders of magnitude greater performance than Ace's Hardware stats.

The simple answer to the question "How do I create a scalable fast network server?" is Event-driven GOOD & Threads BAD. Event driven network communication is two to three orders of magnitude better performing than thread/thread-pool based network communications. See Dan Kegel's C10K web page. That means you must use non-blocking IO to client sockets and databases. Once you accomplish that small feat, dynamic content just consumes CPU; with 2.8 Ghz Xeon processors you have plenty of cycles for parsing HTML markup or whatever. Threads cause cache thrashing, and context switching. While thread programmers don't see the cost in their code, just read the kernel code and you'll see how much work HAS TO BE DONE to switch threads. Event driven programming just takes some state lookups (array manipulation) and a callback (push some pointers onto the stack and jump to a function pointer).

Desgin is FAR MORE IMPORTANT than which runtime you use (execution tree, byte code, or straight assembly). I have done some very high load network programming with Perl using POE.

Python has Twisted Python

Java has the java.nio and the brilliant event/thread hybrid library SEDA by Matt Welsch.

I am also looking into the programming language Erlang which builds concurrancy and event driven programming into the language. Further, Erlang is used by some big telco manufacturers to great effect (high performance and claimed 99.9999999% nine-nines reliability on a big app).

may no be what you'r looking for, but gives a lot of insight into different ways of dealing with this (prosesses, thread etc) problem. from Dan Kegel The C10K problem

It's time for web servers to handle ten thousand clients simultaneously, don't you think? After all, the web is a big place now.

And computers are big, too. You can buy a 1000MHz machine with 2 gigabytes of RAM and an 1000Mbit/sec Ethernet card for $1500 or so. Let's see - at 20000 clients, that's 500KHz, 100Kbytes, and 50Kbits/sec per client. It shouldn't take any more horsepower than that to take four kilobytes from the disk and send them to the network once a second for each of twenty thousand clients. (That works out to $0.08 per client, by the way. Those $100/client licensing fees some operating systems charge are starting to look a little heavy!) So hardware is no longer the bottleneck.

The first generations (601, 603/604 and the ?aborted? 620) of the PowerPC line were scaled-back versions of the Power and Power2 architectures respectively [the original Power architecture was mounted on a 3x5 daughter card with 4-5 separate chips [I'll have to go looking for my tech papers] making-up the core ... because of this the migration of everything into one die for the PowerPC was amazing.

The PowerPC 601 was not a scaled back version of the Power series. To say this would imply that they took the design and modified it. In fact, they took the Power instruction set, modified that and then designed the processor to support it for the target markets.

The 64 bit PowerPC 620 was not "aborted" per se (like the PowerPC 615 was), rather IBM decided that its role was filled by the higher clocked 604 series and the then soon-to-come IBM Rochester, MN designed 64 bit PowerPC 630 (aka Power 3).

To verify my claim that the PowerPC 620 was not aborted, Motorola got suckered into manufacturing them for Bull.

And does this mean the Java will start to really scale on linux?

OK, I'm not a Linux man: but I didn't think Linux actually supported proper asynchronous I/O. And the acryonym, for better or for worse, is still LAMP and not FAMP or SAMP (or even SAOP). (WISA, anyone? :-) ) Sure, you can pass a shed-load of sockets into a select() call but I can't see select()'s efficiency being even close to linear in set size.

Linux does not support the POSIX AIO interface with a standard kernel (SGI has an implementation available). The supported Linux method is realtime signals. While there is probably a good reason that they chose this non standard, Linux specific method (besides the "because we can"), I haven't seen anything documenting the reasoning.

Another method, /dev/epoll, is somewhat similar to Solaris' /dev/poll. It is more efficient and has (IMHO) a cleaner interface than the realtime signals. Hopefully this patch will make it into the mainstream kernel.

The following page is an excellent reference on I/O models: http://www.kegel.com/c10k.html

Common, have you tried to tune Apache? Process-per-connection not a problem - you just have to keep process pool big enough.. There are some other tricks, but you could saturate 100Mbit network with p3/500 and Apache as well.

I seriously doubt it, not in real world conditions. When you include things like mod_php and mod_perl, those Apache processes get big. Our hosting servers (running Zeus) get 15-20 thousand hits a minute. That's ~333 hits per second. Say each client is downloading 50k images at 2k per second. That means you have 300+ new connections opening per second, that stay open for 25 seconds. So you need to be handling 7500+ concurrent connections.

I don't know whether select() would scale; apparently it scales linearly, which is fine when n=20 but not when n=10000. I think if you are going to go with select() you need an implementation that scales logarithmically.

Anyway, to answer my own initial question, there is a paper which I found with a google query and seems interesting.

Okay, so let's say threads are evil.

Okay.

But processes as provided by current operating systems are too expensive to use.

No, they aren't. Have you measured fork() speeds under Linux vs. pthread_create() speeds()? Sure, Windows and Solaris blow at process creation (and Windows doesn't have a reasonable fork() alternative--it conflates fork() and exec() into CreateProcess*()), but that doesn't make all OSes brain-dead.

If I have a network server (e.g. a httpd) that has to create a process for each network request, it will never scale.

Right. And if you create a new thread for each network request, you'll never scale--give it a try some time. Good servers that use a thread/process for every connection do so with pre-fork()'d/pre-pthread_create()'d/whatever pools. Apache, for instance, uses multiple processes (but no multithreading, except in some builds of 2.x) but pre-forks a pool of them. This is really basic stuff, even an introductory threading book will talk about pooling and other server designs.

Really scalable/fast implementations don't even do that. They use just one process (or one per CPU) and multiplex the I/O with something like select, poll, queued realtime signals (Linux), I/O completion ports (NT), /dev/poll (Solaris), /dev/epoll, signal-per-fd, kqueues (FreeBSD), etc. (select and poll don't scale well to 10s of thousands of connections when most are idle, but some of the others are highly scalable). See e.g. Dan Kegel's c10k page for specifics.

Obviously, the OS needs to change, and give use something (maybe a hybrid between processes and threads) that more closely meets applications needs

http://www-124.ibm.com/pthreads/ proposes an M:N threading model and offers an implementation, but it still has the shared memory problems of threads. multiprocessing may not be sexy but it's really a lot cleaner for most problems and can be more efficient in a lot of domains.

Sumner

Using TrueType Fonts with Red Hat Linux

Because of benchmarks like this? (Note how, ignoring the hardware cost for a moment, the top-of-the-line 16-processor IBM pSeries machine running zeus supports 2.5x more users than the best-available 8-processor IIS server.) Also, zeus (and, may be, netscape enterprise, etc.) is known to have better single-machine scalability because of serveral interesting I/O techniques it tends to use---these benefits are more pronounced when run on operating systems like solaris that support fine-grained user-level threads to kernel-level thread mappings. On top of the raw performance, many also support application-level clustering and redundancy (may be important for some portal sites that demand underlying data consistency, and, which, therefore, require more app-level work to scale-up/failover than just adding more server instances). However, for the vast majority of the sites out there that serve out mostly static and simple dynamic traffic, I think apache is more than sufficient (these sites tend to be bottlenecked by the n/w, not by the server), and I would pick apache anyday over IIS for simplicity, stability, and security reasons (even the humble tux server almost matches the best-available IIS5.0 on the same hardware in the benchmark above in terms of performance; there is no need to go into security/stability comparisons).

as noted here, why would Be want to hold onto an OS it doesn't want to sell? It will become as irrelevant eventually as Dr. DOS

I suggest you look at http://www.kegel.com/c10k.html for a great description on all the different types of architectures there are for webservers

The Slashdot discussion encouraged people to send form letters: cut and paste text from various sources and mail it. Evidently all such mailings were discarded.

Forunately, it appears that more serious feedback from folks like Eben Moglen and Dan Kegel will be taken seriously, but much of the Slashdot-generated discussion will not be.

One word: "doh!"

But then after a bit of research, I don't feel so bad. See Dan Kegel's comments . Read down to "The PFJ Fails to Prohibit Anticompetitive Practices Towards OEMs":

The PFJ Fails to Prohibit Anticompetitive Practices Towards OEMs

The PFJ allows Microsoft to retaliate against any OEM that ships Personal Computers containing a competing Operating System but no Microsoft operating system.

The PFJ allows Microsoft to discriminate against small OEMs -- including regional 'white box' OEMs which are historically the most willing to install competing operating systems -- who ship competing software.

The PFJ allows Microsoft to offer discounts on Windows (MDAs) to OEMs based on criteria like sales of Microsoft Office or Pocket PC systems. This allows Microsoft to leverage its monopoly on Intel-compatible operating systems to increase its market share in other areas.

So even though I didn't read the PFJ, as you state, my points have merit since they reflect exactly the problems presented by the above links.

One word: "doh!"

But then after a bit of research, I don't feel so bad. See Dan Kegel's comments . Read down to "The PFJ Fails to Prohibit Anticompetitive Practices Towards OEMs":

The PFJ Fails to Prohibit Anticompetitive Practices Towards OEMs

The PFJ allows Microsoft to retaliate against any OEM that ships Personal Computers containing a competing Operating System but no Microsoft operating system.

The PFJ allows Microsoft to discriminate against small OEMs -- including regional 'white box' OEMs which are historically the most willing to install competing operating systems -- who ship competing software.

The PFJ allows Microsoft to offer discounts on Windows (MDAs) to OEMs based on criteria like sales of Microsoft Office or Pocket PC systems. This allows Microsoft to leverage its monopoly on Intel-compatible operating systems to increase its market share in other areas.

So even though I didn't read the PFJ, as you state, my points have merit since they reflect exactly the problems presented by the above links.

One word: "doh!"

But then after a bit of research, I don't feel so bad. See Dan Kegel's comments . Read down to "The PFJ Fails to Prohibit Anticompetitive Practices Towards OEMs":

The PFJ Fails to Prohibit Anticompetitive Practices Towards OEMs

The PFJ allows Microsoft to retaliate against any OEM that ships Personal Computers containing a competing Operating System but no Microsoft operating system.

The PFJ allows Microsoft to discriminate against small OEMs -- including regional 'white box' OEMs which are historically the most willing to install competing operating systems -- who ship competing software.

The PFJ allows Microsoft to offer discounts on Windows (MDAs) to OEMs based on criteria like sales of Microsoft Office or Pocket PC systems. This allows Microsoft to leverage its monopoly on Intel-compatible operating systems to increase its market share in other areas.

So even though I didn't read the PFJ, as you state, my points have merit since they reflect exactly the problems presented by the above links.

One word: "doh!"

But then after a bit of research, I don't feel so bad. See Dan Kegel's comments . Read down to "The PFJ Fails to Prohibit Anticompetitive Practices Towards OEMs":

The PFJ Fails to Prohibit Anticompetitive Practices Towards OEMs

The PFJ allows Microsoft to retaliate against any OEM that ships Personal Computers containing a competing Operating System but no Microsoft operating system.

The PFJ allows Microsoft to discriminate against small OEMs -- including regional 'white box' OEMs which are historically the most willing to install competing operating systems -- who ship competing software.

The PFJ allows Microsoft to offer discounts on Windows (MDAs) to OEMs based on criteria like sales of Microsoft Office or Pocket PC systems. This allows Microsoft to leverage its monopoly on Intel-compatible operating systems to increase its market share in other areas.

So even though I didn't read the PFJ, as you state, my points have merit since they reflect exactly the problems presented by the above links.

Is there a finished version of this document?
http://www.kegel.com/remedy/remedy2.html

I like the work done by Mr. Kegel and wish to contribute my affirmation of his analysis... I just need a completed document to agree to.

If you know an American citizen, you can always send them a link to Dan Kegel's site and ask them to sign his petition.

In one of the pages that are linked to, you can read that the deadline is January 28th, 2002.

Looking at Dan Kegel's letter the one thing that's striking me about this issue is...
Microsoft is global company causing global problems not just to the development process inside the US but outside it as well - especially as alot of open source projects have a wide range of international contributors, but as things stand only US points of view can be submitted to the courts.

While I agree that as this case is being brought in the US weighting ought to be given to US residents as this affects everyone people outside the US ought to have some scope to feed comments into the process. I know the EU is looking at (or are they still?) bringing its own case against MS but again this only will take account of EU concerns.
For matters of this nature which are truely global a global perspective needs to be presented.

You indicate that your scalability problem kicks in at around 64000 simultaneous clients. Having developed high-performance scalable servers I would recommend taking a look at The C10k Problem, which is rather sobering: handling 10000 simultaneous connections is already a bitch.

Basically if you are using select() or poll() and have 10000 connections, you can expect 30% of your timeslice (on a fast machine) to be taken scanning the connection list for available data. Your performance also goes down the drain after about 250 connections (empirical observation; our server handles async requests which are offloaded to a hardware device for processing, so most server overhead is packet handling).

To get more connections than that you need to look at OS-specific methods: IOCompletion ports on NT, /dev/poll on Linux & Solaris, and kqueue on FreeBSD. These scale must more linearly out to 10000 connections (depending of course on if your server can handle the total load), but still don't give you the ability to scale endlessly.

Finally, I know of no intrinsic reason (although OS implementations may have arbitrary limits) why a server should be restricted to 64k connections. A TCP/IP connection is defined by two endpoints, each being an IP address/port cobination. Your server's ip/port is always one of those endpoints, and the client are unique. Client connections on the other hand are limited by the number of available port on the computer, i.e. 64k.

For fault tolerance, your best bet is to look at the architecture of Enterprise Java servers. Effectively you have a load balancer up front which redirects packets to one of several application servers; any persistent information must be saved off to a database server, and if necessary two or more database servers must be configured to synchronise with each other on a continual basis.

I am not aware of any software that can magically do this for an arbitrary application, although you may find network shared memory libraries which can more or less accomplish this. But if you are concerned about performance, you are unlikely to find COTS software to do the job (since the current business model is to throw more computing power at it).

Thanks very much for reminding us of that page. I'll include those suggestions in www.kegel.com/remedy.html before I submit it as a comment to the DOJ.

Please have a look at it, and let me know if you think I'm on the right track.

Also, I've set up a mailing list on this topic; to subscribe, go to http://groups.yahoo.com/group/ms-remedy/ or send a message to ms-remedy-subscribe@yahoogroups.com

Looking forward to your feedback. I'm hoping that I can come up with a document that a significant number of Free Software supporters can sign on to, which will get the attention of the States' attournys-general, and which has a good chance of influencing the judge to impose a settlement which won't leave the Free Software community out in the cold.

- Dan

I would expect that if any benchmarks came out favoring Windows, and if they were reported here

Benchmarks did come out favoring Windows. They were indeed loudly shot down with criticisms of the testing protocol, and with criticisms of the (Microsoft-funded, in this case) bias of the testing agency. And yes, both those criticisms were just as valid: e.g. not very.

The testing protocol, just as in this case, deliberately chose an aspect of performance that didn't have much practical meaning (load balancing between many 100MB NICs rather than using one GB card; using pipes on Windows instead of sockets/COM).

The testing agency, just as in this case, was horribly biased.

So what was the difference? Well, first of all, the biases were a lot more real before. People pointed out hand-tuning that was applied to NT and not Linux, hardware choices that seemed to deliberately use the least supported options, and misconfigurations of the Linux software. Do you have any similar things to point out here, other than "Everybody knows you shouldn't use pipes on Windows"?

The second difference? Even after those biases were taken into account, there was still aspects in which Linux's performance could be improved, and so it was, gradually over the next 18 months, until it now beats Windows in the same configurations. Do you think that the converse will be true, and Windows 2003 will have blazing performance in all forms of IPC? Would you like to bet money?

Sam developed SDL *before* Loki existed. That's one of the reasons I recommended him to Scott back when Scott was forming Loki and looking to hire his first programmer.
-- Dan Kegel

Well made observations, but there are of course no rules without exceptions - either way. The biggest problem in X is however, getting good enough fonts. No free distribution packages good fonts simply because the best ones are commercial.

Here's a resource to obtain fonts, free or not:
http://www.linux.org/docs/ldp/howto/Font-HOWTO-10. html
The easiest way is to just copy fonts from your Windows-partition or CD (if you have Windows at all, but some of them may be downloaded too).

I found this resource good when I did this on Mandrake 7.2 (before I saw the option in DraConfig->fonts to automagically install Windows fonts):
http://www.linuxdoc.org/HOWTO/mini/FDU/index.html

I got this page from this resource (containing alot of links):
http://www.kegel.com/linux/tt.html

Everybody who have Linux should do this. You will not want to barf at your screen again. You will enjoy Linux and browsing web-pages is like browsing with Internet Exploder. That's partly unfortunately since both Nutscrape and Konqueror is just as stable. However, it's free and it's improving alot!

- Steeltoe

I've also been tracking the Linux-Kernel mailing list for notes about bottlenecks that probably affected the original benchmarks, and their resolution; see http://www.kegel.com/mindcraft_redux.html.

Finally, for server programmers, I've been collecting a page of tips on how to write high performance server software for Linux/Unix; see http://www.kegel.com/c10k.html.

I've also been tracking the Linux-Kernel mailing list for notes about bottlenecks that probably affected the original benchmarks, and their resolution; see http://www.kegel.com/mindcraft_redux.html.

Finally, for server programmers, I've been collecting a page of tips on how to write high performance server software for Linux/Unix; see http://www.kegel.com/c10k.html.

I've also been tracking the Linux-Kernel mailing list for notes about bottlenecks that probably affected the original benchmarks, and their resolution; see http://www.kegel.com/mindcraft_redux.html.

Finally, for server programmers, I've been collecting a page of tips on how to write high performance server software for Linux/Unix; see http://www.kegel.com/c10k.html.

For info about my internship program, see http://www.kegel.com/academy/

There have been a lot of good posts on this subject, but all that I've read missed the one obvious problem with Dell's claim (or the post):
100k hits per day is just over ONE PER SECOND. A 486 could do better than that. ;)

Even if you assume that peak time on the site is a 6 hour period, you're getting close to four and a half hits a second, which is no big deal.

For some good information on the state and progression of Linux, look at http://www.kegel.com/mindcraft_redux.html

For more details, see On Mindcraft's April 1999 Benchmark.

http://www.kegel.com/nt-linux-benchmarks.html has a summary of the recent SPECweb99 benchmarks comparing Linux and Windows 2000. I should have database benchmarks for Win2k there soon, too.