Very Computer

Could the reason be that SUN is afraid of the competition from FreeBSD?
 If Java worked easily in FreeBSD, why would anyone use Solaris 10
(especially since one has to jump through hoops to get it and since SUN
cut off patch support for people without paid support)?  I suspect SUN
knew that Linux was no competition for Solaris, but they wanted to
counter the "source" issue put out there by the GNU advocates.  They
knew that any OpenSolaris distro would not be ready for prime time
production use for at least 2 years...So marketing could claim to be
open source and yet the only production capable server would magically
be Solaris 10.

Linux is not gaining much ground anymore.  All the price sensitive
customers are on it already.  After all, FreeBSD is real UNIX unlike
Linux which is a knockoff clone.  If linux were real UNIX, then it
would be under comp.UNIX.linux and not OS.

FreeBSD is rapidly gaining on Solaris, with the only advantages Solaris
has now is DTrace and its muli CPU support.  But now that OpenSolaris
source is out, there is nothing stopping a freebsd developer from
mousing over to the Open Solaris source and putting it into FreeBSD.

So in short, I believe SUN does not allow FreeBSD to have JAVA because
a Java enabled BSD would eat Solaris' lunch in most instances.  Most
servers are not anything larger than an 8 way server, as most business
in the world a small or medium sized.  Sure there is some demand for
the big iron, but look at what happened to Cray!

Ok, I don't get this!  Why would they thread a kernel for single
processor machines!?  Isn't that stupid?  Why not just have specific
kernels depending on the number of CPUs you computer has?  I think that
is what is hurting solaris and gave it the reputation as slowaris.  If
they released kernels specific to the number of CPUs your computer had,
the system would fly!  In fact, there could be a check at boot to see
how many you have, and then load a kernel specific to your system.

This way FreeBSD 5.x would rock in terms of speed as much as the 4.x
series did on a single CPU system as it would be basically the 4.x
kernel without the thread locks stuff in the kernel.  Solaris would
benefit from the same treatment if they threw out the 100 cpu thread
locking kernel code for single cpu systems.

How about NetBSD?  It's the one that keeps being used in the Internet2
speed record exercises that get reported every now and then.

Quote:>> - Linux is by far the better OS in multiprocessor, although FreeBSD 4.x
>> is about as fast as linux with 2 processors for raw networking
>> performance. 5.x is a work in progress that still needs a lot of work.
>> Can you say 7.0?

>> Once you thread the kernel (as FreeBSD did in 5.x and linux did ages
>> ago), you lose performance that you can't get back until you have very
>> efficient MP. Its sort of like a 2 man relay team vs 1 guy in a 100
>> yard dash.. The handoff requires a loss of momentum that takes a lot of
>> time to get back.

> Ok, I don't get this!  Why would they thread a kernel for single
> processor machines!?  Isn't that stupid?

Threading the kernel allows pre-emption, and with that an approach to
real-time performance, which is often necessary in the embedded markets
that are increasingly starting to use full-blown Unix (phones, routers,
network-attached whatevers...)

Quote:>  Why not just have specific
> kernels depending on the number of CPUs you computer has?

Because no-one wants to have to maintain two separate code bases, and
because the number of situations where maximum single-task performance is
important but where real-time responsiveness isn't, and
where multi-processors aren't available is vanishingly small.

Quote:>  I think that
> is what is hurting solaris and gave it the reputation as slowaris.  If
> they released kernels specific to the number of CPUs your computer had,
> the system would fly!  In fact, there could be a check at boot to see
> how many you have, and then load a kernel specific to your system.

> This way FreeBSD 5.x would rock in terms of speed as much as the 4.x
> series did on a single CPU system as it would be basically the 4.x
> kernel without the thread locks stuff in the kernel.  Solaris would
> benefit from the same treatment if they threw out the 100 cpu thread
> locking kernel code for single cpu systems.

FreeBSD still compiles differently if you enable the SMP option or not.
The code structures are the same, and the threading is still intact, but
the actual thread locking and signalling mechanisms that are used are
lighter-weight, since they don't require the logic for inter-processor
interrupts and the like.

A system that ships as a binary, though, has to be able to cater to
whatever systems you want to run it on.  I think that FreeBSD still ships
a uni-processor kernel as GENERIC, though.  You have to recompile the
kernel to get the heavy-weight SMP locks and features, to make use of the
other processors (or the other HYPERTHREADs) in your shiny new box.

--
Andrew

Except the license?

That's one good reason.  Another is that it's possible to optimize the
implementation of the necessary locking mechanisms for MP to the point
where they're effectively without cost when uncontended (no more
expensive than reading a memory location), and that makes the MP
support on Solaris, and likely other well-designed systems as well,
essentially a non-issue.

I seriously doubt that any claimed performance issues have much, if
anything, to do with failing to littering the code with #ifdefs in
order to do a special "uniprocessor only" compilation of the kernel.

--

Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677