Well, my personal experience has been, that Linux' performance
deteriorates pretty rapidly as the load increases (be it one user
running more jobs or more users being logged in). You, probably,
know, that Digital Unix 4.0 is capable of supporting 4000 users
(so they claim). It has got fail over features (clustering), it
scales to more processors than Linux does, it's got logical
volume manager, journaling file system, and the list goes on
and on. And it knew how to do those things 5 years ago.
As of this moment Linux can't do any of these. Sure,
it will, eventually. But this is a catching up mode. When Linux
catches up with DEC on these or other features, DEC will have
something else up their sleeves. I hope I am wrong, but so
far, my impression has been, that very little innovation comes from
the Linux camp: all we do is trying to outperform others in
things they had been able to do years before Linux' ( or even
Linus' :-) ) conception. And they honestly don't care. Who
cares that OSF's kernel is 8 MB if AlphaStation comes with
64 MB minimum, and memory prices keep going down? If you
were Digital, wouldn't you rather concentrate on the features your
customers demand, than optimizing every line of code in the
> > but let's be honest - there is no way that a group of people, most
> > of who hold daytime jobs, can compete with the multibillion
> > corporations, which employ some of the best minds on this planet.
> I beg to differ. And every benchmark we have floating around says just who
> is winning.
See above. In addition to that, let me add, that user's perspective
of what OS is, is quite different from yours, Linux major contributor.
As a user, I don't run kernel tcp/ip benchmarks, I run ftp instead.
And what I see is that ftping from Solaris 2.4/Sparc2 to AlphaStation
on a different subnet delivers 660KB/s on average. The Linux box,
which hardware wise should beat the crap out of an ancient Sparc
delivers 250 KB/s. I can't tell you, what the deal is. It might be,
that Linux is not very good, when there are collisions on the
ether. Or maybe Linux' ftp server is not too good. I don't know.
But the latter brings up another point: in many cases optimizing an
application can do a whole lot more than optimizing the operating
system. In the case of commercial Unices, that is precisely,
what is going on. Unlike Linux' distributions, where only the
kernel is being heavily optimized, and other parts being rather
generic, Unix vendors sell complete optimized solution, which
might well be the reason for the better "real life" results,
I mentioned above. They may loose on some rather artificial kernel
benchmarks, but their products may do a better job OVERALL.
>You might want to look at the kind of people Linux hackers are
> working for in their non spare time, and the sort of people who are hiring
> them ...
That's beyond the point. Linux developers may be as bright or brighter
than those who work for DEC or Sun, or whoever. However, they are
still very much disadvantaged by the simple num_of_people *\
time_avail * money arithmetic. The only, and I must admit a huge
advantage, that Linux enjoys is the number of testers available,
and the speed at which bug fixes can be implemented and re-tested.
I suspect this is the only reason, why Linux has been able to do so
much of catching up in such a short period of time.
>The place stuff like OSF/1 should still win is going to 12
> processor .5Gb Alpha's. The really big stuff, and thats primarily because we
> don't have any of those handy for a Linux port and to do all the tuning.
That's precisely what they are after. It appears to me, that neither
Sun nor Dec are after mass market. They are keeping to themselves
the workstation users by spewing out a better hardware every once
in a while, and trying to expand in their "really big" stuff.
> > Now, assuming that you can buy Solaris x86 + Sun's Workshop (the best
> > C++ implementation, debugger with the support for multi-threading,
> > multiprocessor tools) for around say $300, and you have to pay
> > similar amount for Linux distribution (just stretch your
> > imagination), what would you rather have?
> Given the performance, the hideous TCP problems with Solaris, the fact Linux
> is faster, has source, has more useful tools I think most of us here know.
> My SMP box is happily doing bbthreaded stuff, PvmPovray etc. (PVMPovray is
> funky btw..)
I think both of us show some bias. BTW, about useful tools. Can you
recommend a nice C++ compiler for Linux ? Don't tell me that g++ is
nice - it will be, when it supports ANSI C++ working papers. How
about P6 specific optimizations? When are they coming? Wouldn't
they do more for the kernel performance, than all the optimizing in
the next 10 years?
I tried to illustrate two points:
- viewed across the board, free software can't keep up with the
- kernels are only as useful, as the applications running on top of
them. If I need to write a C++ application, which has to be portable
across several platforms with a minimum effort, I want the
standards compliant compiler. It will save me a lot of time,
much more time, in fact, than the small time savings, coming from
a better performance of some kernel on some tasks.
I guess, I should've made it clearer, that I treat the term "OS", as
an environment to do something useful, not just a kernel, which can be
bench-marked favorably. Despite Linux has done wonders in this respect,
I am afraid, that its usability is never going to be as high, as the
one of the commercial Unices, just because there are much
more people, who are ready to write software for money, as opposed
to writing it as a means of self expression. And this suggests the way
how to really improve Linux' chances on BIG success - make it EASY
for the commercial entities to write for Linux. It means supporting
Spec 1170, instead of POSIX. The reason for that is, that people,
who sell their software into commercial Unix marketplace, should be
able to simply recompile their applications for Linux, without
an extensive rewrite, which is a strong possibility wright now.
It does not matter, if SysV implementation of something is silly
or not. It might, well, be. But it's what people are used to using, and
if correcting this silliness means the headaches for the commercial
software developers, it should be avoided. Or, else, provide
some Spec 1170 compatibility library. And don't worry about
performance that much - it should only be good enough. 10%
improvement is not worth your effort, those 10% can be recovered
elsewhere much easier, as an added functionality for example.
I read your answer to Alexey regarding STREAMS. I am sure, you
are right that it's slower than sockets, but it does not matter.
If someone recompiles or starts developing an application for
Linux because of this feature, it will benefit Linux much more
than a better benchmarks with no applications to use.
Let me sum things up: Linux has not conquered the world yet,
but keep up a great job, guys.
P.S. I just wanted to re-instill the sense of reality on this
mailing list :-)