Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

RedHat Sparc Linux user speaks.

15,571 views
Skip to first unread message

deny everything

unread,
Oct 10, 1996, 3:00:00 AM10/10/96
to

I am currently running redhat linux rembrandt on a sun sparcstation lx. i know that there aren't that many people running this type of configuration yet, but i wanted to just tell people how great it is.

my system is a sparcstation lx (16/424) and it was running solaris 2.5.1.. the drive was pretty much maxed out and the performance of openwindows left something to be desired. after one night's worth of work i am now running sparc linux from redhat. it installed rather easily. now the system is considerably faster and the my whole setup, including the gnu tools and compiler, apache web server, bsd games, lots of x stuff, fvwm and fvwm95 and tons of other goodies are only taking up about 50% of the drive.. the performance under fvwm95 is much faster than that of openwindows on the same system.

redhat sparc linux.. i think it's definitely an alternative to slowaris on personal sparc workstations.. has anyone else installed it yet?

john abella
pas...@eden.rutgers.edu

ps i am _not_ an employee of redhat.

Daniel Leeds

unread,
Oct 10, 1996, 3:00:00 AM10/10/96
to

deny everything (pas...@eden.rutgers.edu) wrote:
: I am currently running redhat linux rembrandt on a sun sparcstation lx. i know that there aren't that many people running this type of configuration yet, but i wanted to just tell people how great it is.

[snip]

Anyone else fail to see the point in running linsux on sparcs?

If one wishes to run linsux, buy a peecee. Hey, Im no solaris user
myself, but it seems pointless to buy sparc hardware if all your gonna do
is run a free os...

I await the deluge of "LiNuX ruL3Z d00D" email, I am sure to receive.


--

===========================================================================
Daniel Leeds gue...@rand.org
RAND cos...@misery.winter.org
===========================================================================

Richard Jones

unread,
Oct 10, 1996, 3:00:00 AM10/10/96
to

gue...@wilde.rand.org (Daniel Leeds) writes:

>deny everything (pas...@eden.rutgers.edu) wrote:
>: I am currently running redhat linux rembrandt on a sun sparcstation lx. i know that there aren't that many people running this type of configuration yet, but i wanted to just tell people how great it is.

>[snip]

>Anyone else fail to see the point in running linsux on sparcs?

>If one wishes to run linsux, buy a peecee. Hey, Im no solaris user
>myself, but it seems pointless to buy sparc hardware if all your gonna do
>is run a free os...

I think you are missing the point, according to the previous users
post the point here is not the cost of the os but the performance it gives,
if the free os performs better than the commercial one (as it appears
to, at least for this guys applications), then why pay out the $'s for
something with less performance?

>I await the deluge of "LiNuX ruL3Z d00D" email, I am sure to receive.

"LiNu...." nah...

Richard Jones

Donnie Barnes

unread,
Oct 11, 1996, 3:00:00 AM10/11/96
to

>>deny everything (pas...@eden.rutgers.edu) wrote:
>>: I am currently running redhat linux rembrandt on a sun sparcstation lx. i know that there aren't that many people running this type of configuration yet, but i wanted to just tell people how great it is.
>
>>Anyone else fail to see the point in running linsux on sparcs?
>
>>If one wishes to run linsux, buy a peecee. Hey, Im no solaris user
>>myself, but it seems pointless to buy sparc hardware if all your gonna do
>>is run a free os...
>
> I think you are missing the point, according to the previous users
>post the point here is not the cost of the os but the performance it gives,
>if the free os performs better than the commercial one (as it appears
>to, at least for this guys applications), then why pay out the $'s for
>something with less performance?

Appears? How about some lmbench numbers? See:

L M B E N C H 1 . 0 S U M M A R Y
------------------------------------

Processor, Processes - times in microseconds
--------------------------------------------
Host OS Mhz Null Null Simple /bin/sh Mmap 2-proc 8-proc
Syscall Process Process Process lat ctxsw ctxsw
--------- ------------- ---- ------- ------- ------- ------- ---- ------ ------
trombetas Linux 2.0.21 50 15 4.1K 57.8K 156K 181 56 71
geneva.ru SunOS 5.5 50 31 33.7K 148.2K 274K 596 174 205
negro.rut SunOS 4.1.3_U 49 124 18.3K 63.9K 110K 470 152 262

*Local* Communication latencies in microseconds
-----------------------------------------------
Host OS Pipe UDP RPC/ TCP RPC/
UDP TCP
--------- ------------- ------- ------- ------- ------- -------
trombetas Linux 2.0.21 201 985 1620 1198 2212
geneva.ru SunOS 5.5 530 1563 2080 1354 2398
negro.rut SunOS 4.1.3_U 890 1375 2287 1573 2804

*Local* Communication bandwidths in megabytes/second
----------------------------------------------------
Host OS Pipe TCP File Mmap Bcopy Bcopy Mem Mem
reread reread (libc) (hand) read write
--------- ------------- ---- ---- ------ ------ ------ ------ ---- -----
trombetas Linux 2.0.21 9 7.3 24.1 23.0 19 25 40 37
geneva.ru SunOS 5.5 8 7.0 12.6 19.5 18 18 40 36
negro.rut SunOS 4.1.3_U 4 2.0 19.5 8.2 18 24 41 36

Memory latencies in nanoseconds
(WARNING - may not be correct, check graphs)
--------------------------------------------
Host OS Mhz L1 $ L2 $ Main mem TLB Guesses
--------- ------------- --- ---- ---- -------- --- -------
trombetas Linux 2.0.21 49 20 172 180 600 No L2 cache?
geneva.ru SunOS 5.5 49 - - - - Bad mhz?
negro.rut SunOS 4.1.3_U 49 20 175 183 659 No L2 cache?


Note that all of those are on identical hardware. The *only* place that
a Sun OS beats linux is /bin/sh and Mem read. /bin/sh is due to the
fact that we use bash for everything and Sun has a lighter sh. The
memory ready is a negligable difference. Also, note that it's the
*unsupported* Sun OS that beats us, not the supported one.


--Donnie

--
Donnie Barnes http://www.redhat.com/~djb "Bah."
d...@redhat.com http://www.turner.com/lazarusman/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
_Things You'd NEVER Expect A Southerner To Say_ by Vic Henley:
** I hate the long version of ``Free Bird''.


Jim Mintha

unread,
Oct 11, 1996, 3:00:00 AM10/11/96
to

gue...@wilde.rand.org (Daniel Leeds) writes:

>> deny everything (pas...@eden.rutgers.edu) wrote: : I am currently
>> running redhat linux rembrandt on a sun sparcstation lx. i know
>> that there aren't that many people running this type of
>> configuration yet, but i wanted to just tell people how great it is.

> Anyone else fail to see the point in running linsux on sparcs?
>
> If one wishes to run linsux, buy a peecee. Hey, Im no solaris user
> myself, but it seems pointless to buy sparc hardware if all your gonna do
> is run a free os...
>

> I await the deluge of "LiNuX ruL3Z d00D" email, I am sure to receive.

No "LiNuX ruL3Z d00D" here, althought the first post was a bit of a
troll, I'll respond...

True buying sparc hardware just to run linux seems a bit silly, but
many of us have old sun boxen (1, 1+, SLC) with small amounts of
memory. While I don't consider Solaris slow, it does have a larger
memory footprint which makes it seem slow on machines with 16MB or
less. Linux is very compact and ends up running very fast and given
the choice I'll take an older Sun over a PC box anyday.

Jim

--
Jim Mintha (min...@geog.ubc.ca) Home: (604) 731-7240 or: 737-6094
Geography System Administrator Work: (604) 822-2174 Fax: 822-6150
Home Page: http://www.geog.ubc.ca/~jim/
>>> SARCAST \'sar-kast\ v. 1. To engage in the art of sarcasm <<<

Jeff Bacon

unread,
Oct 11, 1996, 3:00:00 AM10/11/96
to

Donnie Barnes (d...@redhat.com) wrote:
: > I think you are missing the point, according to the previous users

: >post the point here is not the cost of the os but the performance it gives,
: >if the free os performs better than the commercial one (as it appears
: >to, at least for this guys applications), then why pay out the $'s for
: >something with less performance?

: Appears? How about some lmbench numbers? See:

of course, then, the obvious question that comes up is WHY is it that
solaris has such higher overhead costs in doing things?

obviously there's more code to work through to do any given thing.
someone must have thought it necessary. but...why?

obviously it's got lots of extra crud from SVR4. why not pitch it?

of course various things that make life nicer for us (automount,
nameservice switch) involve more code. but how much do they really
add to the overall overhead of relatively basic functionality,
in terms of the effect on a loaded timesharing system?

(actually, IMHO the door interface is a highly nifty answer to
the small-msg IPC problem, and I'd love to see that interface
integrated into more of the OS.)

sure, lots of things get moved into the kernel cause it's faster than
the having extra kernel/user/kernel copy and the context switch to run
things in user space. why not speed up context switches and memcopies?

and of course this is just a benchmark. does this translate to real-world
practice? I'd imagine so, just following threads.

don't get me wrong, I run 5.5.1 on my desktop and have no intention of
changing anytime soon. performance isn't an issue; this box is plenty
fast enough for my needs and then some. (throw more hardware at the
problem! honest, I'm not a democrat too!) besides, I doubt Linux supports
my rasterflex and I'm not about to go write a driver. :) I like solaris,
and like a lot of what it offers me. but...one wonders.

and please, don't tell me I should just get a PeeCee and run linux
or why don't I run sunos4x or get an alpha or run a M$O$. I don't care
to, and that's not the point of the questioning; I'd more like to know
what sort of reasonings surround the design and programmer-power-
resource-allocation issues.

-bacon
--
= Jeff Bacon General Systems Hack at Large, Oldenburg, Germany =
= ba...@twinight.org IBMWR DoD#2110 BMWMOA BMWRA '85 BMW K100RS I'm the NRA =

Johan Grape

unread,
Oct 11, 1996, 3:00:00 AM10/11/96
to

Daniel Leeds (gue...@wilde.rand.org) wrote:

: deny everything (pas...@eden.rutgers.edu) wrote:
: : I am currently running redhat linux rembrandt on a sun sparcstation lx. i know that there aren't that many people running this type of configuration yet, but i wanted to just tell people how great it is.

: [snip]

: Anyone else fail to see the point in running linsux on sparcs?

Well, I, for one, fail to see the point of running linux on
a PEECEE when you can run it on a sun or alpha. :-)

Johan

--
Johan A. Grape, Ph.D. Office: (603) 646-3763
Research Associate http://seedless.dartmouth.edu/~grape
Thayer School of Engineering
Dartmouth College "The more things change,
Hanover, NH 03755 the more they stay insane"

Thorbjoern Ravn Andersen

unread,
Oct 11, 1996, 3:00:00 AM10/11/96
to Daniel Leeds

Daniel Leeds wrote:


> Anyone else fail to see the point in running linsux on sparcs?
>

> If one wishes to run linsux, buy a peecee. Hey, Im no solaris user
> myself, but it seems pointless to buy sparc hardware if all your gonna do
> is run a free os...

You might even get a reasonable performance from the old 8Mb ELC
standing in the corner.

Linux definitively has its merits on hardware which doesn't quite
make it for Solaris.

Regards,
--
Thorbjørn Ravn Andersen "...and...Tubular Bells!"
http://www.dit.ou.dk/~ravn

Michael Engel

unread,
Oct 11, 1996, 3:00:00 AM10/11/96
to

Daniel Leeds (gue...@wilde.rand.org) wrote:
: deny everything (pas...@eden.rutgers.edu) wrote:
: : I am currently running redhat linux rembrandt on a sun sparcstation lx. i know that there aren't that many people running this type of configuration yet, but i wanted to just tell people how great it is.

: [snip]

: Anyone else fail to see the point in running linsux on sparcs?

No, you must be the only one ;-)

: If one wishes to run linsux, buy a peecee. Hey, Im no solaris user


: myself, but it seems pointless to buy sparc hardware if all your gonna do
: is run a free os...

Hmmm, several reasons for this:

* There are lots of inexpensive old Sparc on the used equipment market.
These are often sold without an operating system or valid license.
Linux is an alternative to buying a more-or-less expensive SunOS/Solaris
license.

* There are a lot of sites (like us ...) who run a couple of older
workstations (Sparc1, IPC, SLC/ELC etc ...). Solaris 2 is IMO nearly
unusable on these machines due to lack of memory and performance. Linux
is a lot less memory hungry.

* If you're running different hardware on your site, you get the chance to
have an identical operating system (built from the same sources, but of
course not binary compatible between the different platforms) that runs on
Sparc, intel, Alpha, PowerPC, MIPS, ARM and PowerMacs.

I had RedHat 3.0.4 (a beta release, this is also known as "Picasso") running
on a Sparc 5/70MHz for about six weeks nox. I just yesterday upgraded to
the (final) RedHat 4.0 for Sparc release. Installation went like a charm:
insert boot disk, enter disk (file systems to use etc) and network (IP-Address,
netmask etc.) parameters and then install from an _ftp-server_ !

The whole installation process took only 14 minutes plus the time needed for
creating the boot disk (this is just a dd of a file to a floppy disk, but it
took _ages_ on our old AIX machine :)). I admit there are still some problems
with Linux (e.g. the RedHat Appletalk module doesn't work), but this is the
same with SunOS and Solaris ...

: I await the deluge of "LiNuX ruL3Z d00D" email, I am sure to receive.

Hey no ! That's WiNdOzE rooLLLL3ZZ. Most Linux users (and especially the
developers) are well-educated people ... Just because a product comes from
some PC people doesn't mean it's bad. I am using SunOS since 1992 (that's
when I got my 3/60 ... yeah, my first Sun !) and am system administrator for
10 Sparcs here at Siegen Univ. Plus, I have a few running at home. I prefer
running Linux to running SunOS on my IPX. It just feels faster and more
modern than SunOS. And I wouldn't dare running Solaris on a 16 MB IPX...

just my $0.02,
regards,
Michael Engel (en...@unix-ag.uni-siegen.de)


David Andrew Thompson

unread,
Oct 12, 1996, 3:00:00 AM10/12/96
to

In article <53jqjt$k...@rand.org>, gue...@wilde.rand.org (Daniel Leeds) writes:
> deny everything (pas...@eden.rutgers.edu) wrote:
> : I am currently running redhat linux rembrandt on a sun sparcstation lx. i know that there aren't that many people running this type of configuration yet, but i wanted to just tell people how great it is.
>
> [snip]
>
> Anyone else fail to see the point in running linsux on sparcs?
>
> If one wishes to run linsux, buy a peecee. Hey, Im no solaris user
> myself, but it seems pointless to buy sparc hardware if all your gonna do
> is run a free os...
>
> I await the deluge of "LiNuX ruL3Z d00D" email, I am sure to receive.
>

A definite point. Every [new] Sparc that I have seen sold around here somes
with a Solaris 2.5 license. It seems rather pointless to install an inferior
OS on a system that already comes with a perfectly good OS. If one is that
hooked on Linux, buy a PC so you can run Windows, too.

Martin Hargreaves

unread,
Oct 12, 1996, 3:00:00 AM10/12/96
to

d...@redhat.com (Donnie Barnes) wrote:

>Appears? How about some lmbench numbers? See:

> L M B E N C H 1 . 0 S U M M A R Y
> ------------------------------------

<snip>

>Note that all of those are on identical hardware.

You didn't tell us what hardware. Memory is very important to 5.x
SunOS. I run Solaris 2.5.1, and SunOS 4.1.4 on a 16 Mb SPARCstation
LX, Solaris _is_ slow, it's not meant to be run in 16 Mb, I accept
that. I run BSDI on a 16 Mb 486/66, it's faster than the LX.

If I wanted performance I'd buy a PC and run a free OS, they're cheap
and fast. I absolutely would not spend money on a SPARC to run Linux
on it, when PC hardware is so much cheaper and and Linux's original
home. Maybe if someone gave you a SPARC and you hate Solaris, you'd
run it - but you'd probably be better off selling the SPARC and buying
a pentium with the money, if you want to run Linux. I used to, and now
I don't.

>The *only* place that
>a Sun OS beats linux is /bin/sh and Mem read. /bin/sh is due to the
>fact that we use bash for everything and Sun has a lighter sh. The
>memory ready is a negligable difference. Also, note that it's the
>*unsupported* Sun OS that beats us, not the supported one.

SunOS is supported. It's no longer actively developed. Also it depends
on your hardware, I'd imagine Solaris would beat SparcLinux on a 20
CPU E6000, with over a Terabyte of disk, and 3 Gb RAM? We'll probably
stick to Solaris at work then....

M.


Martin Hargreaves

unread,
Oct 12, 1996, 3:00:00 AM10/12/96
to

ba...@mtu.edu (Jeff Bacon) wrote:

>and please, don't tell me I should just get a PeeCee and run linux
>or why don't I run sunos4x or get an alpha or run a M$O$. I don't care
>to, and that's not the point of the questioning; I'd more like to know
>what sort of reasonings surround the design and programmer-power-
>resource-allocation issues.

I think the upshot is that Solaris provides a lot more functionality
than Linux/SunOS and is larger. Ultra's were on the way, and although
you _can_ run Solaris on old hardware, it's targetted at the _new_
hardware, the very fast, large memory systems. It's supports them very
well. It's nice to be able to run it on older kit to learn Solaris
though (and for right or wrong, a lot more people pay you for knowing
about Solaris than for Linux).

It's a newer system, with more functionality, and code bloat. It's
aimed at new fast systems, that's about it, I think.

M.


Donnie Barnes

unread,
Oct 12, 1996, 3:00:00 AM10/12/96
to

>: Appears? How about some lmbench numbers? See:
>
>of course, then, the obvious question that comes up is WHY is it that
>solaris has such higher overhead costs in doing things?

Actually, there are cases where Solaris *cheats* to have less overhead
in doing things. An example is TCP loopback. Solaris skips some
layers and doesn't do checksums to achieve fast loopback performance.
Linux doens't do that. We go through all layers and do some nice
tricks and optimize the code better.

>obviously there's more code to work through to do any given thing.
>someone must have thought it necessary. but...why?
>
>obviously it's got lots of extra crud from SVR4. why not pitch it?
>
>of course various things that make life nicer for us (automount,
>nameservice switch) involve more code. but how much do they really
>add to the overall overhead of relatively basic functionality,
>in terms of the effect on a loaded timesharing system?

Sorry, but Red Hat Linux/SPARC 4.0 includes automount and nsswitch.
That doesn't effect the lmbench numbers.

>sure, lots of things get moved into the kernel cause it's faster than
>the having extra kernel/user/kernel copy and the context switch to run
>things in user space. why not speed up context switches and memcopies?

memcpy was recently highly optimized to achive a couple of these
categories, yes.

>and of course this is just a benchmark. does this translate to real-world
>practice? I'd imagine so, just following threads.
>
>don't get me wrong, I run 5.5.1 on my desktop and have no intention of
>changing anytime soon. performance isn't an issue; this box is plenty
>fast enough for my needs and then some. (throw more hardware at the
>problem! honest, I'm not a democrat too!) besides, I doubt Linux supports
>my rasterflex and I'm not about to go write a driver. :) I like solaris,
>and like a lot of what it offers me. but...one wonders.

No, I don't think we do rasterflex. But, think of the performance
boost if we did. :-)

>and please, don't tell me I should just get a PeeCee and run linux
>or why don't I run sunos4x or get an alpha or run a M$O$. I don't care
>to, and that's not the point of the questioning; I'd more like to know
>what sort of reasonings surround the design and programmer-power-
>resource-allocation issues.

It appears your questions are directed at the Sun folks...I'll let
them try to defend their OS now. ;-)

Donnie Barnes

unread,
Oct 12, 1996, 3:00:00 AM10/12/96
to

>>and please, don't tell me I should just get a PeeCee and run linux
>>or why don't I run sunos4x or get an alpha or run a M$O$. I don't care
>>to, and that's not the point of the questioning; I'd more like to know
>>what sort of reasonings surround the design and programmer-power-
>>resource-allocation issues.
>
>I think the upshot is that Solaris provides a lot more functionality
>than Linux/SunOS and is larger. Ultra's were on the way, and although
>you _can_ run Solaris on old hardware, it's targetted at the _new_
>hardware, the very fast, large memory systems. It's supports them very
>well. It's nice to be able to run it on older kit to learn Solaris
>though (and for right or wrong, a lot more people pay you for knowing
>about Solaris than for Linux).

Well, the bad part is that Solaris won't be supporting sun4c systems
much longer. Linux will be the only supported OS there.

>It's a newer system, with more functionality, and code bloat. It's
>aimed at new fast systems, that's about it, I think.

That's the worst argument I've heard. Yes, Solaris supports the
Ultra. We will to (soon...soon). But, the performance of current
systems will not suffer for that, nor should it.

Donnie Barnes

unread,
Oct 12, 1996, 3:00:00 AM10/12/96
to

>>Appears? How about some lmbench numbers? See:
>
>> L M B E N C H 1 . 0 S U M M A R Y
>> ------------------------------------
>
><snip>
>
>>Note that all of those are on identical hardware.
>
>You didn't tell us what hardware. Memory is very important to 5.x
>SunOS. I run Solaris 2.5.1, and SunOS 4.1.4 on a 16 Mb SPARCstation
>LX, Solaris _is_ slow, it's not meant to be run in 16 Mb, I accept
>that. I run BSDI on a 16 Mb 486/66, it's faster than the LX.

Sorry, I don't have the exact config handy. I believe the
machine in question is a Classic with 24M of memory.

This machine is doing the benchmarking becaue the *real* machines
are busy running SPARC/Linux and doing real work. Trust me, the
numbers stay very much the same on machines with more memory and
faster CPUs.

>If I wanted performance I'd buy a PC and run a free OS, they're cheap
>and fast. I absolutely would not spend money on a SPARC to run Linux
>on it, when PC hardware is so much cheaper and and Linux's original
>home. Maybe if someone gave you a SPARC and you hate Solaris, you'd
>run it - but you'd probably be better off selling the SPARC and buying
>a pentium with the money, if you want to run Linux. I used to, and now
>I don't.

What if you have several sun4c boxes sitting around collecting dust
and you need a decent web server? You gonna run Solaris on that?
I hope not. But, Linux will make them nice web servers.

The point of my post was not to say "if you want raw unadulterated
performance go get an old SPARC and run Linux on it." My point was
it will outperform Solaris on the same machine. For many people,
this reason is enough to switch (or at least give it real consideration).

>>The *only* place that
>>a Sun OS beats linux is /bin/sh and Mem read. /bin/sh is due to the
>>fact that we use bash for everything and Sun has a lighter sh. The
>>memory ready is a negligable difference. Also, note that it's the
>>*unsupported* Sun OS that beats us, not the supported one.
>
>SunOS is supported. It's no longer actively developed. Also it depends

Okay, let's get pedantic then. Sun doesn't consider the TCP SYN
attacks as "bugs", so there is no SunOS fix. So, if you need that
fix your only two choices are to use Linux or Solaris. Oh, and
be prepared to wait much longer for the Solaris fix, too.

>on your hardware, I'd imagine Solaris would beat SparcLinux on a 20
>CPU E6000, with over a Terabyte of disk, and 3 Gb RAM? We'll probably
>stick to Solaris at work then....

Good point. I'll bow to that. You're better off using Solaris on
that machine. But, what about the Fujitsu AP-1000+? 64 CPUs each with
64M of RAM running in parallel. Hmm...SPARC/Linux kicks butt on that
machine. And we'll be running on the Enterprise machines in less than
a year...and likely doing some nice performance numbers there, too.


--Donnie

--

Donnie Barnes

unread,
Oct 12, 1996, 3:00:00 AM10/12/96
to

>A definite point. Every [new] Sparc that I have seen sold around here somes
>with a Solaris 2.5 license.

That will change. The clone vendors will be selling SPARC machines
at a reduced cost here very soon...and some will be selling them with
Linux installed (obviously a choice for the customer, not on all machines).

Just like buying a PeeCee with windoze, you pay for that OS. It's
just built into the cost. Now, that can all change...

>It seems rather pointless to install an inferior
>OS on a system that already comes with a perfectly good OS. If one is that
>hooked on Linux, buy a PC so you can run Windows, too.

This isn't a question of choice or being "hooked" on anything. That's
silly to even think. Anyone who really thinks that is living in a
nice bubble provided to them by glossy ads and sales droids.

It's a question of which OS performs the job *you need it to* on
the hardware you have or want. For many, SPARC/Linux will perform
the tasks they need much better than Solaris. For many it won't.
Boiling it down to using it simply because you are "hooked" on an
OS is avoiding all technical issues completely.


--Donnie

Aaron Brown

unread,
Oct 13, 1996, 3:00:00 AM10/13/96
to

Donnie Barnes (d...@redhat.com) wrote:
: Attribution lost wrote:
: >I think the upshot is that Solaris provides a lot more functionality

: >than Linux/SunOS and is larger. Ultra's were on the way, and although
: >you _can_ run Solaris on old hardware, it's targetted at the _new_
: >hardware, the very fast, large memory systems. It's supports them very
: >well. It's nice to be able to run it on older kit to learn Solaris
: >though (and for right or wrong, a lot more people pay you for knowing
: >about Solaris than for Linux).
:
: Well, the bad part is that Solaris won't be supporting sun4c systems
: much longer. Linux will be the only supported OS there.

This is just plain wrong. NetBSD/sparc has supported sun4c systems
since at least version 1.0, released in October 1994, long before
Linux even had a chance of running on a sun4c system. Please get
your facts right before posting flamebait in the future.

NetBSD still works great on sun4c systems today. And for those of
us who prefer a true BSD-style system as opposed to the Linux
mismash of BSD and SVR4 it, along with its derivate OpenBSD, is
the only choice for a still-developed Sparc OS (I'm excluding SunOS
4.x since, although supported, it is apparently no longer being
actively worked on).

<flamebait mode on--I'm going to regret this, I fear...>
Besides, NetBSD 1.2 can claim to officially support some Sun4m machines
before Linux, as it was officially released several hours :-) before
RedHat.
</flame>

--Aaron

Donnie Barnes

unread,
Oct 13, 1996, 3:00:00 AM10/13/96
to

>: Well, the bad part is that Solaris won't be supporting sun4c systems
>: much longer. Linux will be the only supported OS there.
>
>This is just plain wrong. NetBSD/sparc has supported sun4c systems
>since at least version 1.0, released in October 1994, long before
>Linux even had a chance of running on a sun4c system. Please get
>your facts right before posting flamebait in the future.

"supported"

That word carries certain connotations. Sure, NetBSD runs on them,
and may do so quite well. I didn't mean to imply it wouldn't. My
point was that you can go buy the OS on CD, do a 'boot cdrom' to
install it, and if you have problems you can call the company you
got it from and get help. To my knowledge you can't do this with
NetBSD.

><flamebait mode on--I'm going to regret this, I fear...>
>Besides, NetBSD 1.2 can claim to officially support some Sun4m machines
>before Linux, as it was officially released several hours :-) before
>RedHat.
></flame>

While I won't argue the validity of this (though I think I could), I
am glad NetBSD is available for the SPARC.

Kevin P. Neal

unread,
Oct 13, 1996, 3:00:00 AM10/13/96
to

d...@redhat.com (Donnie Barnes) wrote:

>"supported"

>That word carries certain connotations. Sure, NetBSD runs on them,
>and may do so quite well. I didn't mean to imply it wouldn't. My
>point was that you can go buy the OS on CD, do a 'boot cdrom' to
>install it, and if you have problems you can call the company you
>got it from and get help. To my knowledge you can't do this with
>NetBSD.

NetBSD and OpenBSD have a different focus than Linux.

NetBSD and OpenBSD don't have "flavors", or "distributions."

They have releases, with the kernel and the userland being supported
by the same group of people. There are no programs or drivers added
into the system by some company somewhere that is selling a
distribution.

NetBSD never went through a phase where there were x different NetBSDs
out there with different filesystem layouts.

When I say I am running NetBSD 1.2, that means that *everything* on my
system (outside of /usr/local) came through the NetBSD group. I don't
have to specify which kernel I'm running, or where I got my code, or
any of that mess.

I mean, if you say you are having problems with Linux 2.0, the next
question is "Which one?".

Yes, the BSD's have splintered a bit. But, so has Linux, just in a
different way.

NetBSD focuses on building a superb system that is written very well,
and has an excellent design. This means that features that Linux has
take a while to show up in NetBSD, because NetBSD adds stuff in with
lots of care. This is not to detract from the Linux design (ok, so it
is, sorry) but NetBSD is working very hard on MI device drivers -- you
write a driver for a chip and then each port has bindings to that
driver. One driver, many machines, different boards for the chip to
sit on. Neat. There are countless other things that NetBSD has that
were carefully designed and then carefully implemented.

NetBSD people care more about security. From what I get reading the
mailing lists, nobody on there would even _think_ about loading and
unloading kernel modules on the fly in multi-user mode. This is just a
default, and can be changed on either system -- but many people never
change many of the defaults. Can we say "Gotcha!"? I knew we could.

Linux has lots of features and lots of hardware support that NetBSD
doesn't have on the PC. That's nice. But if your focus is to read and
learn from good code, then Linux would not be your first choice --
NetBSD would be the first choice.

If you like reading good code, you like compiling programs yourself,
you like having a unified userland on all NetBSD machines, etc etc
etc, go NetBSD. If you have a different focus, one that is more Linux
in nature, then by all means go Linux. If you have oddball hardware,
go Linux. If you have hardware that is really shitty, Linux probably
supports it, BSD is less likely to.

So your Linux distribution can boot from the HD and install itself.
Great! I still don't care. I don't run NetBSD because it installed
easily (actually, when I installed pre-1.0, it was pretty difficult.
Course, Unix in 2mb of RAM isn't pretty anyway). I have other reasons
for running it. Pretty installs don't sway me away from NetBSD.

If you like the easy installs of Linux, you have a PC, and you want
some of the features of NetBSD -- unified userland, etc, perhaps
FreeBSD should get your attention. FreeBSD also makes a *great* OS for
a server -- the best example of this to my knowledge is ftp.cdrom.com.
It's a FreeBSD box that can handle ~1250 people hitting it at the same
time through ftp. Wow!

Look, we have Linux, and Free/Net/OpenBSD. All four of them have
strong points and weak points. All four have a place where they fit
well (and some places where they _don't_). Plus, some people just
*like* BSD vs SYSV. That's fine, whatever works for you.

There is no One True OS. There is no One True Unix. There is no "best"
Unix in general (specific applications _can_ have a "best" Unix).
There is no point in having a Holy OS war over this.

Can we stop penis measuring already? Can we not be so damn religious
about our OSs? Sheesh. Enough already. If I wanted to talk religion,
I'd go find asdamick (an English/Communications double major).

Can we stop asking questions like "why would you want to use an old
workstation when a PC will be much faster?". Because I *LIKE* old
workstations, now go away.

Can we stop asking questions like "Why would you want to do X when Y
will be better for reason Z?" Because I have my reasons that I feel
are pretty damn good enough for me.

Enough. I've lost friends because of Holy OS wars, and I'm pretty damn
tired of them. Forgive me if I've offended anybody, I'm short tempered
today (had a car wreck yesterday, I'm not a happy camper). I'm also
sick of these arguments.

Feel free to save this post and repost it when needed.
--
XCOMM Kevin P. Neal, Sophomore, Comp. Sci. \ kpn...@pobox.com
XCOMM "Corrected!" -- Old Amiga tips file \ kpn...@eos.ncsu.edu
XCOMM Visit the House of Retrocomputing: / Perm. Email:
XCOMM http://www.pobox.com/~kpn/ / kevi...@bix.com


Matthew Sloan Evans

unread,
Oct 14, 1996, 3:00:00 AM10/14/96
to

Donnie Barnes (d...@redhat.com) wrote:
: Okay, let's get pedantic then. Sun doesn't consider the TCP SYN

: attacks as "bugs", so there is no SunOS fix. So, if you need that
: fix your only two choices are to use Linux or Solaris. Oh, and
: be prepared to wait much longer for the Solaris fix, too.
:
: --

: Donnie Barnes http://www.redhat.com/~djb "Bah."
: d...@redhat.com http://www.turner.com/lazarusman/
: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
: _Things You'd NEVER Expect A Southerner To Say_ by Vic Henley:
: ** I hate the long version of ``Free Bird''.

never mind that linux was the worst affected OS out of any of the tested ones.
Linux needs the patches just to become usable. IRIX 6.2 on an indy R4000
dies for about 1 mintue with SYN floods..our linux machine running
apache died for about 20...same size synflood...it was a indy vs a p100
the author of neptune.c even made a special case for linux and how poorly
it sucked when hit with the SYN floods. did some testing on it myself
and sure enough, linux bites when attacked with SYN floods, as the times
above would indicate. linux is a wonderful operating system and its
what got me started using unix at home. linux may be "faster" then solaris
on the same machine. dos is faster then os/2 on all machines. OS/2 does
a hell of a lot more. OS/2 is also much more stable. read into that
what you want to. how many people are running critical applications on
linux machines ? linux is an operating system thats in continual change
and continual development. it has gone from being a silly 20k .tar file
to an excellent operating system for many different types of things.

running the hospital medical database isn't a good example of one of them.
running an intranet (believe me i hate buzzwords) type server for a department
is an excellent role. the customers dont whine if it dies because they dont find out. linux is an excellent choice for an individuals workstation. its
not something i'd ever trust anything "important" to because of my experience
with it on PCs. perhaps linux for sparcs eliminates all the problems
inherent with the PC architecture. it would be very cool to see it running
on real machines with real architectures and os/hardware integration.
even so, i personally feel it isn't a viable solution to "mission critical"
(damn another buzzword) type situtions. i was attempting to convince some
people at work that more things should be put onto inexpensive linux boxes.
these people are real linux heads themselves. they told me it had stability
problems to which i immediately took offense, being very much a linux afficiando at the time. but then they told something that makes a damn lot of sense.
"stable doesn't mean you are there to catch it when it falls. stable means
it doesn't fall". how many die hard linux fans have never had a machine crash
have never had a machine mysteriously lockup ? i've had this sparc IPX
about 1 year and its running sol 2.5 on 32 megs of ram. it does lots of NFS
and has several remote users. in that years time its locked up once.
(thats was about 2 weeks ago) and my guess is that it swamped itself
syslogging a media defect that it found while a user ran a find /
after fixing the media error on the scsi disk, the machine booted right back up.some people would rather have a track record of stability and a number to call
if they can't figure out what the hell is going on. those people will use
solaris regardless of how many jaded benchmarks or even realistic benchmarks
linux nazi's can find. linux has its place just like all the other OS's.
i am becoming alarmed at the number of linux people that are reminding me of
Amiga people. Linux is not the solution to every problem.

-rant mode off


--
***********************************************************
* Matt Evans *
* University of Nebraska, Lincoln work: bma...@ntr.net *
* Computer Engineering Major school: mev...@cse.unl.edu *

Steve Stevers! Coile

unread,
Oct 14, 1996, 3:00:00 AM10/14/96
to

If you're going to compare the BSD variants to something in the Linux
world, compare apples to apples and compare your BSD variants to Linux
distributions. Compare your NetBSD, FreeBSD, or OpenBSD to Red Hat
Linux or Slackware or Caldera Network Desktop or Linux-FT, not "Linux",
because "Linux" isn't an operating system.

As a Red Hat user, I know where my updates are coming from. I know
who's looking out for the integrity of the operating system. I know
where to go for support. I know that the operating system is being
planned and developed, and will be around. What am I missing there
that Free/Net/OpenBSD would offer me?

-S

John Carr

unread,
Oct 14, 1996, 3:00:00 AM10/14/96
to

In article <slrn55vfu...@redhat.com>,
Donnie Barnes <d...@redhat.com> wrote:

>Well, the bad part is that Solaris won't be supporting sun4c systems
>much longer. Linux will be the only supported OS there.

Sun hasn't announced end of life for sun4c yet, so I expect it to be
supported for at least 2 years. Solaris 2.6 will be released next year
with sun4c support and will probably remain the current release for a year.
Even if the next release after 2.6 drops support, patches should still be
available for 2.6 for a while after that.

--
John Carr (j...@mit.edu)

Paul J Forman

unread,
Oct 15, 1996, 3:00:00 AM10/15/96
to

Daniel Leeds (gue...@wilde.rand.org) wrote:

: deny everything (pas...@eden.rutgers.edu) wrote:
: : I am currently running redhat linux rembrandt on a sun sparcstation lx. i
: : know that there aren't that many people running this type of
: : configuration yet, but i wanted to just tell people how great it is.

: [snip]

: Anyone else fail to see the point in running linsux on sparcs?

: If one wishes to run linsux, buy a peecee. Hey, Im no solaris user
: myself, but it seems pointless to buy sparc hardware if all your gonna do
: is run a free os...


Interesting statement. "All you're gonna do is run a free OS." Why does
Solaris' (hefty) price tag imply that it is superior? Furthermore, why
does SunSoft market Solaris for the PC, if it is useless hardware?

The entire point of Linux is to have usable, free UNIX on available hardware.
Why were the evil PeeCees used first? They were cheap and lots of people
had them. These days, when 1s, IPCs, IPXs are laying around sites
unused, it makes plenty of sense to run a smaller UNIX on them, to
utilize the performance that is in these machines. Boxes that a bloated
commercial UNIX would simply crush under their load are usable again.

More power to SPARC/Linux, and Linux on all platforms.

: I await the deluge of "LiNuX ruL3Z d00D" email, I am sure to receive.

Gotta say it -- LiNuX R00lZ d00d!

--
/-----------------------------------------------------------------\
| PF Paul Forman for...@cs.unr.edu aka KM |
|-----------------------------------------------------------------|
| MANIAC: Screams at users until they go away. Sometimes barters |
| knowledge for powerful drink and/or sycophantic adulation. |
\-----------------------------------------------------------------/

Martin Hargreaves

unread,
Oct 15, 1996, 3:00:00 AM10/15/96
to

d...@redhat.com (Donnie Barnes) wrote:

>It appears your questions are directed at the Sun folks...I'll let
>them try to defend their OS now. ;-)

Can't speak for them, but at least SunOS/Solaris has adb. :-)

Or does Linux have adb too now?

BTW how would I tune stuff like DNLC size on Linux while the (live,
24/7) system was running? This matters to me, not only because I'm
sad, but because I recently had to do it...

M.


Gian-Paolo D Musumeci

unread,
Oct 15, 1996, 3:00:00 AM10/15/96
to

Al Potter <apo...@epix.net> writes:
> Bubba, do your homework. It (SparcLinux) out-performs, out-features,
> and most definitely out-costs the SunSoft products. Support of the big
> iron (Ultras and 4d's) is around the corner, as is stable support for
> SunOS and S(l)o(w)laris binaries.

Now, this I don't buy. I sure haven't heard of any free software approximating
the SunSoft compiler tools; the SUNWspro package, for example, or SPARCworks
iMPact. Not that gcc is bad...but the visual development tools just aren't
there, and on large projects those tools come in real damn handy.

gdm

Casper H.S. Dik

unread,
Oct 16, 1996, 3:00:00 AM10/16/96
to

d...@redhat.com (Donnie Barnes) writes:

>Appears? How about some lmbench numbers? See:

Interesting numbers, they also lay to rest the myth that "SunOS is
faster than Solaris". (Solaris 2.x could improve on the dynamic'linker startup, especially the four or so libs pulled in w/ /bin/sh)

> L M B E N C H 1 . 0 S U M M A R Y
> ------------------------------------

> Processor, Processes - times in microseconds


> --------------------------------------------
>Host OS Mhz Null Null Simple /bin/sh Mmap 2-proc 8-proc
> Syscall Process Process Process lat ctxsw ctxsw
>--------- ------------- ---- ------- ------- ------- ------- ---- ------ ------
>trombetas Linux 2.0.21 50 15 4.1K 57.8K 156K 181 56 71
>geneva.ru SunOS 5.5 50 31 33.7K 148.2K 274K 596 174 205
>negro.rut SunOS 4.1.3_U 49 124 18.3K 63.9K 110K 470 152 262

/bin/sh on SUnOS 4.x is statically linked, that's probably why it's beating
you here. (bash is bigger and dynamically linked)

This is on an LX or Classic or some such? I don't have numbers for those.

>Host OS Pipe TCP File Mmap Bcopy Bcopy Mem Mem
> reread reread (libc) (hand) read write
>--------- ------------- ---- ---- ------ ------ ------ ------ ---- -----
>trombetas Linux 2.0.21 9 7.3 24.1 23.0 19 25 40 37
>geneva.ru SunOS 5.5 8 7.0 12.6 19.5 18 18 40 36
>negro.rut SunOS 4.1.3_U 4 2.0 19.5 8.2 18 24 41 36

Bcopy results look funny. Why is bcopy(hand) faster than bcopy(libc)
on SunOS 4.x/Linux but not on Solaris 2.x? What compilers did you use?

The file re-read results for Solaris look strange, typically file reread
is about as fast or faster than mmap re-read for the results I have.

Mem-read/Mem-write are probably all within the limits of errors, so no
need to say that "SunOS 4.x is faster here".

>Host OS Mhz L1 $ L2 $ Main mem TLB Guesses
>--------- ------------- --- ---- ---- -------- --- -------
>trombetas Linux 2.0.21 49 20 172 180 600 No L2 cache?
>geneva.ru SunOS 5.5 49 - - - - Bad mhz?
>negro.rut SunOS 4.1.3_U 49 20 175 183 659 No L2 cache?

Looks like a Classic/LX then.

I'm glad to see that linux networking performance has finally improved to a
point where it can compete.

>*unsupported* Sun OS that beats us, not the supported one.


Mem read looks more like a statistical error, and for many things,
Solaris and Linux are pretty close.

Are you planning on testing SPEC benchmarks such as LADDIS, SPECint/SPECfp?
Or TCP-C and such?

Casper
--
Casper Dik - Sun Microsystems - via my guest account at the University
of Amsterdam. My work e-mail address is: Caspe...@Holland.Sun.COM
Statements on Sun products included here are not gospel.
Unsolicited e-mail advertisements will be proofread for $250.

Casper H.S. Dik

unread,
Oct 16, 1996, 3:00:00 AM10/16/96
to

mar...@datamodl.demon.co.uk (Martin Hargreaves) writes:

>You didn't tell us what hardware. Memory is very important to 5.x
>SunOS. I run Solaris 2.5.1, and SunOS 4.1.4 on a 16 Mb SPARCstation
>LX, Solaris _is_ slow, it's not meant to be run in 16 Mb, I accept
>that. I run BSDI on a 16 Mb 486/66, it's faster than the LX.

It's most likely an LX/CLassic; I doubt you see much difference with the
amount of memory in this particular benchmarks.
(Which accidently seems to proof that Solaris 2.5 is faster to much faster
in networking and many other things than SunOS 4.x)

David Hickman

unread,
Oct 16, 1996, 3:00:00 AM10/16/96
to

deny everything (pas...@eden.rutgers.edu) wrote:
: I am currently running redhat linux rembrandt on a sun sparcstation lx. i know that there aren't that many people running this type of configuration yet, but i wanted to just tell people how great it is.

Well here is something i found out...

I have a 4/330... Linux is not out for it yet.. I run linux on my pc.. To
tell you the truth, I hate it.. Yes linux is faster than any other os.. But
it lacks the solidness of a complete os..

Now I will agree with you one one thing, openwinblows sucks!... You want to know
how i fixed that.. I compiled X11R6.1.. It uses much less memory, smaller, etc...

When linux does come out for it i will try it out.. But one thing is certain..
I will probally never run it as my primary os on my sparc... For one major reason.. The lack of comercial software... Like Netscape... Java.. etc... Yes, there
are intel versions of all of this but guess what, there will probally be a Alpha
version long before I will see a sparc version of the software..

One of the main reasons I run solaris, is due to the fact, that if a new program
is going to be ported to a unix, solaris is almost always the first to get it..
Like castanet, or realaudio( yes i know there is linux versions but it took over
a year for it to happen..)

Now if I get a little headless ipc.. Linux will porbally be a choice for it..

dhh

--
/ \
/ ^ \ ======================================
/ / \ \ || David Harrison Hickman mom96 ||
/ / \ \ || Active, Triangle Fraternity ||
/ / \ \ || 506 East 6th St., Rolla MO 65401 ||
/ ------- \ || Hm 573-341-5516 Cell 573-368-6373||
/ _____ _____ \ ||----------------------------------||
/ / | | \ \ || Computer Science Major ||
/ /_____| |_____\ \ || University Of Missouri:Rolla ||
/___________________\ ======================================

Aaron Brown

unread,
Oct 16, 1996, 3:00:00 AM10/16/96
to

David Hickman (dhic...@rocket.cc.umr.edu) wrote:

: deny everything (pas...@eden.rutgers.edu) wrote:
: : I am currently running redhat linux rembrandt on a sun sparcstation lx. i know that there aren't that many people running this type of configuration yet, but i wanted to just tell people how great it is.
:
: Well here is something i found out...
:
: I have a 4/330... Linux is not out for it yet.. I run linux on my pc.. To
: tell you the truth, I hate it.. Yes linux is faster than any other os.. But
: it lacks the solidness of a complete os..
:
[snip]
: When linux does come out for it i will try it out.. But one thing is certain..
: I will probally never run it as my primary os on my sparc... For one major reason.. The lack of comercial software... Like Netscape... Java.. etc... Yes, there
: are intel versions of all of this but guess what, there will probally be a Alpha
: version long before I will see a sparc version of the software..
:
: One of the main reasons I run solaris, is due to the fact, that if a new program
: is going to be ported to a unix, solaris is almost always the first to get it..
: Like castanet, or realaudio( yes i know there is linux versions but it took over
: a year for it to happen..)

Just wanted to point out that it is completely feasible to run the
commercial sunos/solaris applications under a free OS that supports
emulation. For example, I routinely run FrameMaker, Adobe Acrobat,
Sun WABI, HoTMeTaL, and Mathematica under NetBSD/sparc's Solaris and
SunOS emulations. These are system-call-level emulations, so they do
not inflict the performance hit that, say, processor-level emulators
(like SoftPC) do.

I don't know if Linux supports this kind of emulation yet, but it seems
completely possible that they could do so.

--Aaron

Carl S Shapiro

unread,
Oct 16, 1996, 3:00:00 AM10/16/96
to

Donnie Barnes (d...@redhat.com) wrote:

[...]

: Okay, let's get pedantic then. Sun doesn't consider the TCP SYN
: attacks as "bugs", so there is no SunOS fix. So, if you need that
: fix your only two choices are to use Linux or Solaris. Oh, and
: be prepared to wait much longer for the Solaris fix, too.

This statement is false, since there exists some other OS that
this has been fixed in one form or another (NetBSD, OpenBSD).

: Good point. I'll bow to that. You're better off using Solaris on


: that machine. But, what about the Fujitsu AP-1000+? 64 CPUs each with
: 64M of RAM running in parallel. Hmm...SPARC/Linux kicks butt on that
: machine. And we'll be running on the Enterprise machines in less than
: a year...and likely doing some nice performance numbers there, too.

There is a big diffrence between a parallel "super" computer and
a shared memory multiprocessor machine such as the Ultra Enterprise 6000
as previously mentioned. Also, define "kicks butt". From what I have
read on the web page, the AP-1000+ sacrafices a fair amount of bandwith
for low latency on it's network/switch. I really do not know how such a
scientific machine could ever be suited for the same tasks as an UE6k.
I like how you are announcing Linux ports well in advance of their
release. Kind of reminds me of Microsoft :-) I am also pretty sure
that Linux will do just fine on the UltraEnterprise with it's toy SMP
implementation which reminds me so much of the one that was grafted on to
SunOS.

Carl

James Youngman

unread,
Oct 17, 1996, 3:00:00 AM10/17/96
to

In article <84512278...@datamodl.demon.co.uk>,
mar...@datamodl.demon.co.uk says...

>I think the upshot is that Solaris provides a lot more functionality
>than Linux/SunOS and is larger. Ultra's were on the way, and although
>you _can_ run Solaris on old hardware, it's targetted at the _new_
>hardware, the very fast, large memory systems. It's supports them very
>well. It's nice to be able to run it on older kit to learn Solaris
>though (and for right or wrong, a lot more people pay you for knowing
>about Solaris than for Linux).

This is indeed very true. Solaris 2.5.2 on an UltraSparc is the system that
comes closest to Linux in TCP latency measurements (with Linux on a P166).

--
James Youngman VG Gas Analysis Systems |The trouble with the rat-race
Before sending advertising material, read |is, even if you win, you're
http://www.law.cornell.edu/uscode/47/227.html|still a rat.


James Youngman

unread,
Oct 17, 1996, 3:00:00 AM10/17/96
to

In article <84542163...@datamodl.demon.co.uk>,
mar...@datamodl.demon.co.uk says...

>Can't speak for them, but at least SunOS/Solaris has adb. :-)
>
>Or does Linux have adb too now?

'fraid not, sorry. Kernel variables are modified by writing to interface files
in /proc/sys, so adb is not required for that, and the kernel debugger is kgdb,
so I guess nobody wanted adb enough to get it done.

James Youngman

unread,
Oct 17, 1996, 3:00:00 AM10/17/96
to

In article <32630D96...@epix.net>, apo...@epix.net says...
> The principal vendor of PC based commercial Unix (SCO) figured it out.
>SCO binaries tend to run faster under IBCs w/ Linux than in native SCO.
>Two years ago they were laughing at the "free unix." Now, they're
>GIVING SCO away! ( http://www.sco.com )

IMHO that's to beat off NT in the server market by increasing the use of SCO on
the desktop. I don't think they care about Linux and don't see it as a threat
to their penetration of the server market (yet....)

James Youngman

unread,
Oct 17, 1996, 3:00:00 AM10/17/96
to

In article <53lab8$s...@namib.north.de>, ba...@mtu.edu says...

>obviously it's got lots of extra crud from SVR4. why not pitch it?
>
>of course various things that make life nicer for us (automount,
>nameservice switch) involve more code. but how much do they really
>add to the overall overhead of relatively basic functionality,
>in terms of the effect on a loaded timesharing system?

??? Linux has both of these.

James Youngman

unread,
Oct 17, 1996, 3:00:00 AM10/17/96
to

In article <53jqjt$k...@rand.org>, gue...@wilde.rand.org says...

>Anyone else fail to see the point in running linsux on sparcs?

Well, for a start, Linux is the only OS that runs on SPARCs for which the
SYN-flood security hole (well, D.O.S. risk) has been fixed yet.

James Youngman

unread,
Oct 17, 1996, 3:00:00 AM10/17/96
to

In article <slrn55vgh...@redhat.com>, d...@redhat.com says...

>Okay, let's get pedantic then. Sun doesn't consider the TCP SYN
>attacks as "bugs", so there is no SunOS fix. So, if you need that
>fix your only two choices are to use Linux or Solaris. Oh, and
>be prepared to wait much longer for the Solaris fix, too.

There _are_ source patches for SunOS 4.1.3 patches available (unsupported). I
haven't installed them on our 4.1.x systems because they are all protected by
our (Linux) firewall anyway...

James Youngman

unread,
Oct 17, 1996, 3:00:00 AM10/17/96
to

In article <53jqjt$k...@rand.org>, gue...@wilde.rand.org says...
>
>deny everything (pas...@eden.rutgers.edu) wrote:
>: I am currently running redhat linux rembrandt on a sun sparcstation lx. i
know that there aren't that many people running this type of co
>
>[snip]

>
>Anyone else fail to see the point in running linsux on sparcs?

Well, it _is_ marginally faster and runs Solaris binaries too.

John Turner

unread,
Oct 17, 1996, 3:00:00 AM10/17/96
to

d...@redhat.com (Donnie Barnes) writes:

> Well, the bad part is that Solaris won't be supporting sun4c systems
> much longer. Linux will be the only supported OS there.

Well, I would have stayed out, but I'm a bit peeved about RedHat's idea
of "support" at the moment, so I can't help myself.

I've used many Unix workstations for many years. I finally got a Pentium
box, and since I had heard good things about the RedHat Linux distribution,
I bought it.

Not to go into details, but I had some problems early on and decided to
submit a support request. I did the proper registration, submitted the
request, received a ticket number, etc.

That was 9/5/96. Six weeks ago. I haven't heard a *word* back. Nothing.
Total silence.

I can tell you that Solaris support (at least for us) beats the *heck*
out of that.

Now this was an experiment, so it didn't matter much, but this Lab is
starting to look seriously at alternative platforms. There are many
extremely conservative folks here who are already leery of "that free
stuff". You can imagine what this kind of thing does to those of us
who are actually proponents of free software.

---
John A. Turner
Los Alamos National Laboratory, MS B226, Los Alamos, NM 87545
Group: XTM (Radiation Transport Methods)
Location: TA-3, Bldg. 43, Rm. D150
Phone: 505-665-1303 e-mail: tur...@lanl.gov

r...@rhwsun.wooten.net

unread,
Oct 17, 1996, 3:00:00 AM10/17/96
to


> The principal vendor of PC based commercial Unix (SCO) figured it out. > SCO
> binaries tend to run faster under IBCs w/ Linux than in native SCO.
> Two years ago they were laughing at the "free unix." Now, they're
> GIVING SCO away! ( http://www.sco.com )

Al,
Thanks, I think you said it (the OS issue) very well. I use Linux for some
things and Solaris 2.4 for others. Oh, and AT&T SVR3.2.3 on a 3b2 1000/70 for
yet another. In short, I use the OS that works for what I want it to do...


Cheers,
Richard <flamebait-2>

Steve Stevers! Coile

unread,
Oct 18, 1996, 3:00:00 AM10/18/96
to

John Turner (tur...@branagh.lanl.gov) wrote:
[...]
: Not to go into details, but I had some problems early on and decided to

: submit a support request. I did the proper registration, submitted the
: request, received a ticket number, etc.
:
: That was 9/5/96. Six weeks ago. I haven't heard a *word* back. Nothing.
: Total silence.

And you haven't contacted them again?

You aren't giving them much of a chance, are you?

I'm sure Sun support has lost support requests. *No* support
organization is perfect.

Given that plenty of people are in regular contact with Red Hat
support, both official (which you used) and unofficial (Red Hat
sponsored and monitored mailing lists) and plenty of them get quick,
helpful responses, I can assure you that your case is an exception
rather than the rule.

-S

Donnie Barnes

unread,
Oct 18, 1996, 3:00:00 AM10/18/96
to

>: Okay, let's get pedantic then. Sun doesn't consider the TCP SYN

>: attacks as "bugs", so there is no SunOS fix. So, if you need that
>: fix your only two choices are to use Linux or Solaris. Oh, and
>: be prepared to wait much longer for the Solaris fix, too.
>
> This statement is false, since there exists some other OS that
>this has been fixed in one form or another (NetBSD, OpenBSD).

Yada-yada. Sorry to stick my nose in the air sometimes...Yes,
I suppose NetBSD does fall in that category. Let me restate in
more concise terms: So, if you need that fix, you're only two
choices of a *supported* OS are Linux and Solaris.

>: Good point. I'll bow to that. You're better off using Solaris on
>: that machine. But, what about the Fujitsu AP-1000+? 64 CPUs each with
>: 64M of RAM running in parallel. Hmm...SPARC/Linux kicks butt on that
>: machine. And we'll be running on the Enterprise machines in less than
>: a year...and likely doing some nice performance numbers there, too.
>
> There is a big diffrence between a parallel "super" computer and
>a shared memory multiprocessor machine such as the Ultra Enterprise 6000
>as previously mentioned. Also, define "kicks butt". From what I have
>read on the web page, the AP-1000+ sacrafices a fair amount of bandwith
>for low latency on it's network/switch. I really do not know how such a
>scientific machine could ever be suited for the same tasks as an UE6k.

No, they are not suited for the same tasks, and I never said they were.
As for a "fair amount of bandwidth", I think you'll find that the guys
who did the port are just a little overly-critical of themselves sometimes.

> I like how you are announcing Linux ports well in advance of their
>release. Kind of reminds me of Microsoft :-) I am also pretty sure

Sure, if you can't think of anything *good* to say, compare the other
guy to MS. Man, I love that tactic. Besides, you'd have to wait
two years to actually prove that "reminder" to be true.

I never announced anything formally. Just passing on information that
was made public to me and several hundred other folks on various mailing
lists by the folks doing the code.

>that Linux will do just fine on the UltraEnterprise with it's toy SMP
>implementation which reminds me so much of the one that was grafted on to
>SunOS.

It's *not* a great SMP implementation, I'll admit. But, it will get
much better really fast now that the kernel has gone to 2.1. Oops,
man, did I announce things in advance of the release again? Shame
on me. So, does NetBSD have SMP? Again, I'm showing my *BSD
ignorance again....hmm...I don't see *any* mention of it on the
NetBSD home page. Ooh, man the supported SPARC hardware list is
pretty lame, too.

Oh, one other interesting thing...someone said in this thread that
NetBSD announced 1.2 *before* we announced formally. Sorry, but
both happened the same day.


--Donnie

Donnie Barnes

unread,
Oct 18, 1996, 3:00:00 AM10/18/96
to

>> Well, the bad part is that Solaris won't be supporting sun4c systems
>> much longer. Linux will be the only supported OS there.
>
>Well, I would have stayed out, but I'm a bit peeved about RedHat's idea
>of "support" at the moment, so I can't help myself.
>
>I've used many Unix workstations for many years. I finally got a Pentium
>box, and since I had heard good things about the RedHat Linux distribution,
>I bought it.
>
>Not to go into details, but I had some problems early on and decided to
>submit a support request. I did the proper registration, submitted the
>request, received a ticket number, etc.
>
>That was 9/5/96. Six weeks ago. I haven't heard a *word* back. Nothing.
>Total silence.

Okay, now *this* is a problem. I'm not making *excuses*, but I will make
a defense. We have had some problems with our support system and things
could have gotten lost. We answer every piece of mail we see, and we try
to do it in a timely manner.

We are experiencing support problems right now as well, due to another
system problem and due to a huge load. The "system" problems are actually
just software problems with our support handling programs. The big
companies can spend big bucks on systems to help track and manage
support, but we can't do that yet. We're working on our own software,
and a system that is good takes time to work out.

>I can tell you that Solaris support (at least for us) beats the *heck*
>out of that.

Yes, I'm sure it does. Could you please send me the ticket number?
I'd like to track that down.

Also note, I'm *sure* even IBM and Sun have lost a support request or
two by accident.

>Now this was an experiment, so it didn't matter much, but this Lab is
>starting to look seriously at alternative platforms. There are many
>extremely conservative folks here who are already leery of "that free
>stuff". You can imagine what this kind of thing does to those of us
>who are actually proponents of free software.

Please also note that we are a free software company. We're small and
we give away all software that we develop. We're working hard to help
everyone, but there are growing pains and inherent problems when
working in the free software community (picture trying to get terms
or financing with companies who don't grok free software...conversations
happen like: "You want financing for producing CDs? What does your
company do?" You explain and they think you're crazy...you couldn't
possibly be *selling* free software and making *money*).

I'm not trying to make excuses, just enlighten folks about the situations
you are facing. We're attempting to do something no other company has
done, and that's take free software into the mainstream and support it
at the same time. There *will* be problems. All I ask is that before
giving up, folks come to us directly with problems. All our developers
read Usenet to some extent (at least the comp.os.linux.* groups) and
*are* reachable directly. Try that at the big companies...you'll find
a few soft-hearted net-junkies who hang out, but not the bulk of them,
not even close.

Miguel de Icaza

unread,
Oct 18, 1996, 3:00:00 AM10/18/96
to

> Good point. I'll bow to that. You're better off using Solaris on
> that machine. But, what about the Fujitsu AP-1000+? 64 CPUs each with
> 64M of RAM running in parallel. Hmm...SPARC/Linux kicks butt on that
> machine. And we'll be running on the Enterprise machines in less than
> a year...and likely doing some nice performance numbers there, too.

Right. Neither SunOS or Solaris can run on the Multicomptuer Fujitsu
SuperSparc based machines.

Work has now started on supporting the SS1000 and SS2000 machines.
The OS should boot on those before christmas.

Miguel.
--
mig...@roxanne.nuclecu.unam.mx
The GNU Midnight Commander: http://www.linux.org/mc
Linux/SPARC project: http://www.geog.ubc.ca/sparclinux.html

Gert Doering

unread,
Oct 18, 1996, 3:00:00 AM10/18/96
to

In article <53jqjt$k...@rand.org>, gue...@wilde.rand.org says...
>
>deny everything (pas...@eden.rutgers.edu) wrote:
>: I am currently running redhat linux rembrandt on a sun sparcstation lx. i
know that there aren't that many people running this type of co
>
>[snip]
>
>Anyone else fail to see the point in running linsux on sparcs?

You get the sources.

gert
--
Yield to temptation ... it may not pass your way again! -- Lazarus Long
//www.muc.de/~gert
Gert Doering - Munich, Germany ge...@greenie.muc.de
fax: +49-89-3243328 gert.d...@physik.tu-muenchen.de

Gert Doering

unread,
Oct 18, 1996, 3:00:00 AM10/18/96
to

dhic...@rocket.cc.umr.edu (David Hickman) writes:

>When linux does come out for it i will try it out.. But one thing is certain..
>I will probally never run it as my primary os on my sparc... For one major reason.. The lack of comercial software... Like Netscape... Java.. etc... Yes, there
>are intel versions of all of this but guess what, there will probally be a Alpha
>version long before I will see a sparc version of the software..

SparcLinux is fully binary compatible with SunOS4 - Netscape runs, with
Java!. Binary compatibility for Solaris2 is being worked on.

Miguel de Icaza

unread,
Oct 18, 1996, 3:00:00 AM10/18/96
to

> Besides, NetBSD 1.2 can claim to officially support some Sun4m machines
> before Linux, as it was officially released several hours :-) before
> RedHat.

You can claim that.

We can claim Linux runs on more Sun4m machines than NetBSD can
currently. HyperSparcs, Swift, Tsunami, Cypress are all supported in
Linux/SPARC.

David S. Miller

unread,
Oct 18, 1996, 3:00:00 AM10/18/96
to

ba...@mtu.edu (Jeff Bacon) writes:

Since I have been able to find an intelligent posting in this thread,
I will respond to it and explain what I can as chief architect of the
SparcLinux port.

> of course, then, the obvious question that comes up is WHY is it that
> solaris has such higher overhead costs in doing things?
>
> obviously there's more code to work through to do any given thing.
> someone must have thought it necessary. but...why?

>
> obviously it's got lots of extra crud from SVR4. why not pitch it?
>

The answer to this is pretty straight forward actually. The main
points of interest are:

1) Solaris's networking stack, in all of it's incantations (one breed
of it was the Lochman code in 2.0, 2.1 and early 2.2 releases, then
it was rewritten by another company for 2.3 onward) is SVR4 streams
based. The performance penalty, even with lots of tricks, for
using a SVR4 streams networking architecture is well known.
Someone who happens to have a 2.2 Solaris CD around, or even a 2.3
Solaris CD, should install that thing and run lmbench on it to see
what "pure Streams based networking" without the tricks can really
do.

Linux on the other hand has a "no bullshit" networking architecture
that is not streams based. Yet we also take advantage of the many
known networking performance enhancements that exist in the
research realm (ie. copy/checksum, the van jacobson hacks, etc.)

2) Linux is light weight, Solaris is a pig.

One of the most critical things that contributes to performance
is cache/tlb footprint of the operating system. Linux being small
(yet still provide a full POSIX unix environment!) solves the cache
footprint problem in a big way. I've solved the TLB footprint
using Linux's small size and a Sparc specific trick.

The MMU's present on the sun4m/sun4d line of Sun machines possess a
three level page table scheme. Using this, one has the capability
to use the normal 4k sizes pages, and also larger 256k and 16MB
sized pages. The average TLB on these machines has 32 or 64
entries to cache these pte's, if the entry is not in the TLB
hardware has to go out to the memory bus and walk the software page
tables to "reload" the TLB so that the translation can be
satisfied.

This "miss processing" is very expensive. Under SunOS and Solaris,
they do not take advantage of the 16MB and 256k sized pages to map
the operating system. Therefore those two systems take many misses
in the TLB during even the most rudimentary trap into the kernel.
However under Linux the TLB misses for the OS are quite minimal.
In fact I will gave an example:

On your average SparcClassic with a 32 entry TLB, consider such
a machine with 24MB of memory installed. Under Linux I can map
the entire operating system (sans IO device register mappings
and Lance Ethernet DMA) in 3 (count 'em, 3!) TLB entries. These
3 entries are enough to allow the kernel to access an arbitrary
physical page from kernel space.

Under Solaris, the OS would need 3 + (24MB / 256K) + (24MB / 4K)
TLB entries to map this same amount of space. For a great many
number of operations, it is quite easy for an OS with this page
table strategy to blow the entire user context out of the
hardware TLB. Which in turn means more processor stalls (in
fact many) for both the user level processes and the operating
system.

Result? Severe degradation in performance for the latter
scheme.

3) Every BSD and SVR4 based system today, except for Linux, has a very
broken System call mechanism.

You'd think that when people put together function call conventions
for a particular processor, the OS people would take a look at this
and find a way to take advantage of this. In fact, believe it or
not, they have not to this very day.

Linux from day one, takes advantage of the procedure call
conventions on a particular architecture so that it can process
system calls in the most expediant way possible. I will give
an example on the Sparc to prove this:

Consider your average 3 argument system call. The user level
code does something like this:

mov %arg0, %o0
mov %arg1, %o1
mov %arg2, %o3
mov SYSTEM_CALL_NUMBER, %g1
t SYSCALL_TRAP

At this point control reaches the operating system, it must
prepare to handle this request from the user. On the Sparc, this
is either a two step or a three step process depending upon
whether you are doing it in the traditional broken UNIX way or the
clean, fast, and superior Linux way. First I will show the Linux
method for doing this:

1) Step one, jump onto the kernel stack for this task
and make sure the kernel has a register window to
operate in safely.

For Linux the code path for this runs at ~18 instructions
for the common case (the kernel already has a valid
register to use so now saving needs to be done). It runs
at ~42 instructions for the second most common case (the
kernels needs to allocate a new register window and the
user has a valid stack pointer) and ~82 instructions for
the least common case (kernel needs a window, user has
an invalid stack pointer, thus the kernel needs to save
the user's window into a special per-task save area).

2) Take the system call number, check for valid value, use
this to offset into a table of system call function ptrs.
Move arguments into place and perform the syscall.

Basically this is a simple operations a looks something
like:

sll %g1, 2, %l4 ! produce offset
ld [%l7 + %g1], %l7 ! syscall ptr base was in %l7
SAVE_ALL ! perform step #1 above
mov %i0, %o0
mov %i1, %o1
mov %i2, %o2
mov %i3, %o3
mov %i4, %o4
jmp %l7, %o7
mov %i5, %o5

That is it, that is the entire system call under Linux.

Under Solaris/SunOS things are wildly different. Step one is
basically the same, but step 2 is disgustingly inefficient for
those systems. Basically they do:

2) Call common system_call() C function.

3) This routine allocates a "system call argument package"
structure on the kernel stack. This is wasteful because
we already have all of this information in registers or
in guarenteed save areas.

4) Then this routine determines the function to call, and
passed this "package" of arguments to the routine.

5) Every system call which expects arguments then must
"unpack" this structure to get at the copy of the arguments
again highly inefficient.

For every system call the system performs, you eat this unnecessary
overhead under SunOS/Solaris, under Linux only the bare minimum is
performed to do the system call successfully.

4) Solaris cannot even do it's own optimizations correctly because
SunPRO is a broken compiler.

I won't make such a statement without explaining this with real
facts, here goes.

A neat part of the Sparc ABI is that it leaves you with a few
processor registers that the C compiler is not allowed to use
in the code it produces. Two of which are "%g6" and "%g7".
A problem in unix kernels is that you are constantly accessing
the current tasks control structure ('proc' and 'uarea' on
traditional UNIX's, the 'task_struct" under Linux). Hey, why
not put these pieces of information in those "extra" registers
and avoid the address computation all the time? Yes, very
brilliant idea.

Under Solaris the trap entry code places the uarea and proc ptr
in %g6 and %g7. Under Linux the trap entry code places the
current processes task_struct in %g6. Now here comes where the
implementations differ.

Under Solaris all of the so called "locore" (basically all the
gook which has to be written in raw assembly) code can directly
take advantage of this. However, the C code cannot do this
because SunPRO lacks a way for you to tell the compiler that
"hey you don't need to load things, it's already in these
hard coded registers" So they have the C code call these little
assembly stubs to get the values:

get_uarea:
retl
mov %g6, %o0

get_proc:
retl
mov %g7, %o0

That is gross, why even do the optimization in the first place?

Now GCC has a way to fully take advantage of such an optimization,
basically all I have to do is put the following in a header file.

register struct task_struct *current asm("g6");

Tada, now GCC will fully understand what I have done for it.
Under SparcLinux this optimization alone took away 115 instructions
in the scheduler sources, and it took ~50 instructions out of the
exit() handling, and it took ~65 instructions out of the fork()
handling.

So my question always is, in matters such as these. Who are these
processor cycles for anyways, the kernel or the user? Think about
this when you consider how much overhead is being saved from one OS to
another, and to what scale this is occurring.

I hope that explains some of it, and gives people at least some sort
of idea of the kinds of things that makes Linux scream on just about
any hardware. If people would like more explainations like the above,
I'd be more than happy to chat with you via email about it or
similar. I love talking about performance issues on various
processors and systems.

Oh, and one thing that has not been mentioned yet in this thread (and
yes NetBSD/OpenBSD both have this as well, good work guys). That
SparcLinux kernel that gets all of this incredible performance runs on
both sun4c and sun4m machines. Sun Engineers way back when scratched
their heads for months and couldn't figure out a way to pull it off
(you need a seperate kernel image depending upon whether you are
running on a sun4m or a sun4c, for SunOS/Solaris). And on top of that
Linux obviously pulls it off efficiently.

One final note. When you have to deal with SunSOFT to report a bug,
how "important" do you have (ie. Fortune 500?) to be and how big of a
customer do you have to be (multi million dollar purchases?) to get
direct access to Sun's Engineers at Sun Quentin? With Linux, all you
have to do is send me or one of the other SparcLinux hackers an email
and we will attend to your bug in due time. We have too much pride in
our system to ignore you and not fix the bug.

David S. Miller
da...@caip.rutgers.edu


S. Newhouse

unread,
Oct 20, 1996, 3:00:00 AM10/20/96
to

This post (and the whole thread) is another one of those indicating how
useful it would be to have ALL THE SOURCE FREELY AVAILABLE.

It is not there yet, but if some more ways can be found to support the
free software developers to allow them to do their thing, then one can
expect to see them win the performance and design battles. Solaris has
many good concepts in it, but as long as it remains in the hands of a
few, and remains proprietary, it won't achieve its maximum potential.

It is amazing to see the achievement and speed of development of
Linux. If I were a Sunsoft developer or project manager, I wouldn't
talk about the things Solaris can presently do and the things Linux
can't do, I would think about how long it took Solaris to get to where
it is now, and I would compare its development history and model to that
of Linux. I know what my conclusions about this are.

-sen

David Hickman

unread,
Oct 20, 1996, 3:00:00 AM10/20/96
to

Miguel de Icaza (mig...@sphinx.nuclecu.unam.mx) wrote:

: > Besides, NetBSD 1.2 can claim to officially support some Sun4m machines


: > before Linux, as it was officially released several hours :-) before
: > RedHat.

: You can claim that.

: We can claim Linux runs on more Sun4m machines than NetBSD can
: currently. HyperSparcs, Swift, Tsunami, Cypress are all supported in
: Linux/SPARC.

Well how about sun4 support.. I know openbsd has supported for a while... I
wish linux would..

dhh

: --

--

Miguel de Icaza

unread,
Oct 20, 1996, 3:00:00 AM10/20/96
to

> Well how about sun4 support.. I know openbsd has supported for a while... I
> wish linux would..

There is a team working on that, we will have that support sooner or later.

But right now, Linux/SPARC supports most of the high end SPARC
hardware out there: the HME scsi and ethernet chips; the cg14 video
card; the Leo video driver is working; all kind of lance-derived
ethernet cards (those with lebuffers as well). And all those new and
fast CPUs out there. We do support and take advantage of multiple
processors where available (thank Dave Miller, the team leader).

Our code also have workarounds for about every bug in the Sun
hardware, so you can still run your machines with Linux without having
it crash for misterious reasons.

I really would like to encourage people to try Linux on a SPARC, the
Red Hat distribution, as shipped, comes with lots of goodies and nice
programs you will enjoy. Imagine: never having to download half of
prep to put your machine in an usable state. No need to spend a
weekend getting all the TeX stuff tuned on your machine. All the cute
toys that made Linux popular in the i386 world are available in the
SPARC now, with no extra effort.

Security fixes? Red Hat releases security fixes within hours of the
security announcement. You just cut and paste a line (from the
security alert): Presto! you have the security fix installed or major
bug fixes in place (pgp signed and all that stuff).

Cheers,
Miguel.

Gian-Paolo D Musumeci

unread,
Oct 20, 1996, 3:00:00 AM10/20/96
to

Miguel de Icaza <mig...@sphinx.nuclecu.unam.mx> writes:
> But right now, Linux/SPARC supports most of the high end SPARC
> hardware out there: the HME scsi and ethernet chips; the cg14 video
> card; the Leo video driver is working; all kind of lance-derived
> ethernet cards (those with lebuffers as well). And all those new and
> fast CPUs out there. We do support and take advantage of multiple
> processors where available (thank Dave Miller, the team leader).

Dare I mention that all of these are _also_ supported under Solaris 2.5.1?

> Our code also have workarounds for about every bug in the Sun
> hardware, so you can still run your machines with Linux without having
> it crash for misterious reasons.

This still totally lacks any advantage over Solaris: the patching mechanism
exists for a reason...

> I really would like to encourage people to try Linux on a SPARC, the
> Red Hat distribution, as shipped, comes with lots of goodies and nice
> programs you will enjoy. Imagine: never having to download half of
> prep to put your machine in an usable state. No need to spend a
> weekend getting all the TeX stuff tuned on your machine. All the cute
> toys that made Linux popular in the i386 world are available in the
> SPARC now, with no extra effort.

A few minor comments;
(a) My SPARCstation runs just fine with a clean install of Solaris 2.5.1
straight off the CD. I installed the recommended patches, but it worked
just fine before I did that.

(b) The TeX comment is worthwhile, and if I used it, I would consider this
a point in SPARC/Linux's favor.

(c) I didn't buy a Sun for cute toys. If I wanted cute toys, I would have
bought a PC. I bought a Sun because I wanted something that I knew would
work.

Maybe I'm being hardheaded; I have a lot more faith in Solaris than I do
in _any_ Linux variant, and I'll take the minor speed penalty to run an OS
that is supported by the manufacturer.

Note, too, that you lose things when you install Linux. CDE, for one.
Again, I can't speak for everyone, but if you're working in an environment
with large numbers of machines from different manufacturers (IBM RS/6000's,
HP 9000-series, Sun SPARCs, etc), CDE is a godsend. Professional-class
compilers, for another; I don't believe that gcc optimizes quite as tight
as the SUNWspro package, nor do you get the truly useful MP development
tools of SPARCworks iMPact.

Rebuttals welcomed. :-)

gdm

Donnie Barnes

unread,
Oct 21, 1996, 3:00:00 AM10/21/96
to

On 20 Oct 1996 23:51:15 GMT, Gian-Paolo D Musumeci <g...@kestrel.scs.uiuc.edu> wrote:
>Miguel de Icaza <mig...@sphinx.nuclecu.unam.mx> writes:
>> But right now, Linux/SPARC supports most of the high end SPARC
>> hardware out there: the HME scsi and ethernet chips; the cg14 video
>> card; the Leo video driver is working; all kind of lance-derived
>> ethernet cards (those with lebuffers as well). And all those new and
>> fast CPUs out there. We do support and take advantage of multiple
>> processors where available (thank Dave Miller, the team leader).
>
>Dare I mention that all of these are _also_ supported under Solaris 2.5.1?

Those comments were directed at the *NSD camp, who cannot support those
devices yet. You won't hear the SPARC/Linux camp trying to compare
hardware support any time soon with Solaris...there are a ton of boards
left that Solaris supports that SPARC/Linux doesn't (but we'll support
the bulk of them in due time :-).

>> Our code also have workarounds for about every bug in the Sun
>> hardware, so you can still run your machines with Linux without having
>> it crash for misterious reasons.
>
>This still totally lacks any advantage over Solaris: the patching mechanism
>exists for a reason...

Well, while the patching mechanism may exist, you are still bound to
Sun for the fixes. With Linux it's usually fixed before you know
the problem exists.

>> I really would like to encourage people to try Linux on a SPARC, the
>> Red Hat distribution, as shipped, comes with lots of goodies and nice
>> programs you will enjoy. Imagine: never having to download half of
>> prep to put your machine in an usable state. No need to spend a
>> weekend getting all the TeX stuff tuned on your machine. All the cute
>> toys that made Linux popular in the i386 world are available in the
>> SPARC now, with no extra effort.
>
>A few minor comments;
>(a) My SPARCstation runs just fine with a clean install of Solaris 2.5.1
>straight off the CD. I installed the recommended patches, but it worked
>just fine before I did that.

Good point. Miguel's point was very valid as well, however. For *many*
folks out there, downloading most of prep.ai.mit.edu is the standard
thing to do when they setup a new system.

>(b) The TeX comment is worthwhile, and if I used it, I would consider this
>a point in SPARC/Linux's favor.

TeX isn't the only thing that comes ready to run. We include things
that are important to *many* folks, like apache, wu-ftpd, gopher, xv,
games, etc.

>(c) I didn't buy a Sun for cute toys. If I wanted cute toys, I would have
>bought a PC. I bought a Sun because I wanted something that I knew would
>work.

Well, your idea of "toys" and Miguel's are quite different then. He is
referring to all the applications and such that people *expect* to work
under Linux, but are *not* stock parts of the commercial Unices like
Irix, HP-UX, and Solaris.

>Maybe I'm being hardheaded; I have a lot more faith in Solaris than I do
>in _any_ Linux variant, and I'll take the minor speed penalty to run an OS
>that is supported by the manufacturer.

That would be a good point two years ago. Right now I don't think it
is (though I do agree it is a debatable point). When you buy a $99
copy of SPARC/Linux from Red Hat, you get free installation support.
If you want more support, you have the *choice* to pay extra for it.
If you would rather, you can just come to the *ultimate* support
center, the Internet. We had TCP SYN fixes far before you could get
them from Sun. We have sendmail fixes announce *in* the CERT advisories.
I could go on...

You feel more comfortable, but I can't for the life of me see why.

>Note, too, that you lose things when you install Linux. CDE, for one.
>Again, I can't speak for everyone, but if you're working in an environment
>with large numbers of machines from different manufacturers (IBM RS/6000's,
>HP 9000-series, Sun SPARCs, etc), CDE is a godsend.

This is a valid point right now, but we do have CDE on the Intel side.
Once SPARC/Linux has grown some, we'll have it there, too.

>Professional-class
>compilers, for another; I don't believe that gcc optimizes quite as tight
>as the SUNWspro package, nor do you get the truly useful MP development
>tools of SPARCworks iMPact.

Please, use both and test the results...the Sun compilers have proven
brain dead in very many respects. As for MP development, they probably
do have us beat right now. That shouldn't last much longer... :-)

Tim Spence

unread,
Oct 21, 1996, 3:00:00 AM10/21/96
to

In article <53n418$a...@usenet.rpi.edu>, tho...@smegma.stu.rpi.edu says...
>A definite point. Every [new] Sparc that I have seen sold around here somes
>with a Solaris 2.5 license. It seems rather pointless to install an inferior
>OS on a system that already comes with a perfectly good OS. If one is that
>hooked on Linux, buy a PC so you can run Windows, too.

Solaris? Perfectly good? Let me guess - you log on once a month to check your
mail. The problem that I have with Solaris is the high _labor_ cost of making
it useful. It comes with a lousy shell, no C compiler for crying out loud, and
a generous assortment of useless utilities. So I would have to spend a couple
of days installing bash, tcsh, gcc, ncftp, etc. The truly tragic thing is that
most Solaris users don't have any idea how pitiful the tools are. Ignorance is
indeed bliss. On the other hand, Solaris has the advantage of commercial
application support. Fortunately for me, Linux has flawless SunOS
compatibility, which lets me run the commercial apps that I need.

Tim Spence
Linux - Because a Sun is a terrible thing to waste.


Elizabeth Schwartz

unread,
Oct 21, 1996, 3:00:00 AM10/21/96
to JYou...@vggas.com

In article <544u8u$m...@halon.vggas.com> JYou...@vggas.com (James
Youngman) writes:

>Well, for a start, Linux is the only OS that runs on SPARCs for which the
>SYN-flood security hole (well, D.O.S. risk) has been fixed yet.

They *fixed* the SYN-flood security hole? How????

I was under the impression that this hole was, in theory, un-fixable,
although there are various ways to slow down the effects of the
attacks. Please,, tell me more. How did they fix it?

thanks Betsy
(seriously, I real
--
System Administrator Internet: bet...@cs.umb.edu
MACS Dept, UMass/Boston Phone : 617-287-6448
100 Morrissey Blvd FAX : 617-287-6499
Boston, MA 02125-3393 Staccato signals of constant information....

Jeff Bacon

unread,
Oct 21, 1996, 3:00:00 AM10/21/96
to

Donnie Barnes (d...@redhat.com) wrote:

: On 20 Oct 1996 23:51:15 GMT, Gian-Paolo D Musumeci <g...@kestrel.scs.uiuc.edu> wrote:
: >Miguel de Icaza <mig...@sphinx.nuclecu.unam.mx> writes:
: >> Our code also have workarounds for about every bug in the Sun

: >> hardware, so you can still run your machines with Linux without having
: >> it crash for misterious reasons.
: >This still totally lacks any advantage over Solaris: the patching mechanism
: >exists for a reason...
: Well, while the patching mechanism may exist, you are still bound to
: Sun for the fixes. With Linux it's usually fixed before you know
: the problem exists.

well, one is bound to the linux folk for the most part for patches as well.

consider this: s'pose someone puts a trojan in solaris that sends all my
company secrets somewhere else. I can sue Sun. they're big, I might lose,
but if I win, I get a lot of recompense. There's a big corporate
entity standing behind the idea of "honest, it's ok". now suppose
I'm running Linux. Who do I sue, Red Hat? Miguel? good chance
I'll win, but what do I get? Miguel's Toyota? :)

(don't laugh. this seems funny, but liability IS an issue. one
can say "Linux folk will fix the bugs faster" but ..)

one can say that the source is freely available, but how many of us
really have time to figure out and fix the source? not damn many.

: >(a) My SPARCstation runs just fine with a clean install of Solaris 2.5.1


: >straight off the CD. I installed the recommended patches, but it worked
: >just fine before I did that.
: Good point. Miguel's point was very valid as well, however. For *many*
: folks out there, downloading most of prep.ai.mit.edu is the standard
: thing to do when they setup a new system.

many? some.
consider how many people whose idea of a User Interface is MSOffice.
not even Windows, just Office - Windows is just a way you start Office.
some people use GNU. I use a bit of it. not all. most all of my users
don't even know GNU exists - they don't care, they wanna run SDRC I-DEAS
or WhizBangPkg X. Solaris or whatever is just a way to get there.
just looking at the statistics of the college students I've "processed",
that defines most of 'em, not the wanna-use-cool-GNU-toys folks.

: >(c) I didn't buy a Sun for cute toys. If I wanted cute toys, I would have


: >bought a PC. I bought a Sun because I wanted something that I knew would
: >work.

: Well, your idea of "toys" and Miguel's are quite different then. He is
: referring to all the applications and such that people *expect* to work
: under Linux, but are *not* stock parts of the commercial Unices like
: Irix, HP-UX, and Solaris.

1) should Sun/SGI/etc compile and load GNU tools for you? it costs money
to do so - by including it, they're picking up the liability for support.
no matter how much you say "we don't support this, we're just including it",
it doesn't matter, folks will call you, cause it was on the Solaris CDROM,
and expect you to support it, so you're stuck.

2) Sun/etc, being large corporate entities, have lawyers. Lawyers
probably frown on GNUware just on principle; the concept of including
it in the OS CDROM of a multibillion $$ company probably gives them fits.

3) see above about what users expect.

on top of this, SDRC doesn't run on SPARC/Linux. nor many other things.
at least not to my knowledge. this is a major problem.

the perspective is different.

SPARC/Linux fits many bills. certainly not all.

: >Professional-class


: >compilers, for another; I don't believe that gcc optimizes quite as tight
: >as the SUNWspro package, nor do you get the truly useful MP development
: >tools of SPARCworks iMPact.
: Please, use both and test the results...the Sun compilers have proven
: brain dead in very many respects. As for MP development, they probably
: do have us beat right now. That shouldn't last much longer... :-)

in most tests I've run on things I do, the sun compilers generally
make faster code, and do so reasonably simply. that is of course just
personal experience and YMMV. to each their own on that one. but
I do find myself specifying --with-cc=/opt/SUNWspro/bin/cc by and large.


of course all of this wandered well-off-path of what I asked originally;
Miguel was the only one that came close (thanks for an intelligent look),
but still doesn't answer the fundamental question...

-bacon
--
= Jeff Bacon General Systems Hack at Large, Oldenburg, Germany =
= ba...@twinight.org IBMWR DoD#2110 BMWMOA BMWRA '85 BMW K100RS I'm the NRA =

Miguel de Icaza

unread,
Oct 21, 1996, 3:00:00 AM10/21/96
to

> I was under the impression that this hole was, in theory, un-fixable,
> although there are various ways to slow down the effects of the
> attacks. Please,, tell me more. How did they fix it?

Read the Linux netdev mailing list, the archive is on
ftp.nuclecu.unam.mx:/lists/netdev

Miguel


Jim Kingdon

unread,
Oct 21, 1996, 3:00:00 AM10/21/96
to

> Note, too, that you lose things when you install Linux. CDE, for one.

I think that Red Hat Motif (http://www.redhat.com/products/rhm.html)
supports CDE (I didn't see anything about a sparc version). At one
time I thought I heard something about TriTeal's CDE
(http://www.triteal.com) on linux too, but I'm not sure what became of
that. Disclaimer: I haven't actually run any of these products.

> Professional-class compilers, for another; I don't believe that gcc
> optimizes quite as tight as the SUNWspro package

I'm sure the people at Cygnus would be glad to discuss this with you,
at least if you are thinking of buying one of Cygnus's support
contracts. My last information on this is at least a year or two old,
but my vague recollection is that they were within 10% or so. GCC
continues to evolve and I imagine that is probably true of SUNWspro
too, so I wouldn't even venture to guess how they stack up today.

> Maybe I'm being hardheaded; I have a lot more faith in Solaris than I do
> in _any_ Linux variant

Oh, I don't know. I've run SunOS and (x86) linux, and used Solaris
machines, and I wouldn't say that any one of them had grossly more
problems than the others. Different problems, but not necessarily
better or worse (in terms of bugs and hassles, I'm not talking about
features and speed).

> I'll take the minor speed penalty to run an OS that is supported by
> the manufacturer.

I'd like support too, and I'll agree that linux is weak here. Red Hat
has installation support and Yggdrasil has pay-by-the-minute phone
support. Craftworks seems to better understand what people of the
sort who might buy Suns mean by "support", but their linux
distribution itself is lame, so unless they start supporting the Red
Hat distribution or something I wouldn't recommend that.

Curt Sampson

unread,
Oct 21, 1996, 3:00:00 AM10/21/96
to

In article <slrn56e21...@redhat.com>,
Donnie Barnes <d...@redhat.com> wrote:

>We're attempting to do something no other company has
>done, and that's take free software into the mainstream and support it
>at the same time.

I can't let this one slide by. Cygnus has been `taking free software
into the mainstream and supporting it' for years. I recently had
the pleasure of working with Cygnus first-hand when I found a couple
of problems with Gnu binutils-2.7. I identified two specific
problems, submitted problem reports in the evening in each case,
and both times I had a patch by the middle of the next business
day.

I would presume the support from them you pay for is at least as
good as the support you get for free.

cjs
--
Curt Sampson cu...@portal.ca Info at http://www.portal.ca/
Internet Portal Services, Inc.
Vancouver, BC (604) 257-9400 De gustibus, aut bene aut nihil.

John Turner

unread,
Oct 21, 1996, 3:00:00 AM10/21/96
to

Miguel de Icaza <mig...@sphinx.nuclecu.unam.mx> writes:

> the
> Red Hat distribution, as shipped, comes with lots of goodies and nice
> programs you will enjoy. Imagine: never having to download half of
> prep to put your machine in an usable state. No need to spend a
> weekend getting all the TeX stuff tuned on your machine.

That would be really useful if things like the Wintertime/Summertime
CDs and sites with binaries of everything imaginable available for
Solaris (SPARC or x86) in pkgadd format didn't exist.

But they do.

That's not to knock the RedHat Linux. Just realize that similar things
exist for Solaris.

+-----------------------+--------------------------------------------------+
|John A. Turner |"Music is the cup which holds the wine of silence;|
|Los Alamos Natl. Lab. | sound is that cup, but empty; |
|e-mail: tur...@lanl.gov| noise is that cup, but broken." |
| | - Robert Fripp |
+-----------------------+--------------------------------------------------+

Travis Hassloch x231

unread,
Oct 21, 1996, 3:00:00 AM10/21/96
to

In article <544u8u$m...@halon.vggas.com>,

James Youngman <JYou...@vggas.com> wrote:
>In article <53jqjt$k...@rand.org>, gue...@wilde.rand.org says...
>>Anyone else fail to see the point in running linsux on sparcs?
>
>Well, for a start, Linux is the only OS that runs on SPARCs for which the
>SYN-flood security hole (well, D.O.S. risk) has been fixed yet.
>--
>James Youngman VG Gas Analysis Systems |The trouble with the rat-race

Bzzt, wrong again... as I and many others mentioned, OpenBSD and NetBSD
both run on SPARCs and have patches for the SYN-flood security hole.
Not that it's that important, mind you.

They are similar, however, in that you get source and so could fix the
bugs with a small amount of effort in either system. BSD marginally favored
since they have are a TCP reference implementation (practically).

Linux might be a bit faster since (at least on the x86) they chose to pass
arguments in registers rather than on a stack. Not sure why BSD does this;
I guess it means you can write the backend of the system call in C instead
of assembler.

Net/OpenBSD have a huge number of binary compatibilities, too....
--
tra...@evtech.com | I don't speak for ETI. | P=NP if (N=1 or P=0)
WARNING: Unsolicited commercial e-mail: $500 per message
Never trust advice from a person with a doubled sigfile.
Never trust advice from a person with a doubled sigfile.

Travis Hassloch x231

unread,
Oct 21, 1996, 3:00:00 AM10/21/96
to

There's also NetBSD and OpenBSD for the SPARC. I am not aware of their
current state, but should be quite good. These groups are doing a lot
in the way of multiplatformness. One source tree means that there's
little/no delay in fixes/improvements to migrate to the other relevant
architectures. Most of the kernel is MI. ISA drivers, for example, get
shared among many architectures, even multiple PCI/ISA bridges...
There are many hurdles to cross to assure this level of code sharing.
It's code base is BSD, so it's very mature, and the TCP/IP has been rock
solid.
I'm kind of jealous of the Linux crowd since they leapfrogged 386BSD during
the lawsuit era. Back when I chose between them BSD had long filenames
and a mature FFS, and Linux's ext*fs was still in beta. I chose BSD.

Other than that I don't harbor any grudges. Linux has good support for
many devices due to it's popularity. This is less important for
workstations.

Anyway, just thought I'd throw that out there.
check out
http://www.freebsd.org
http://www.netbsd.org

Oh yeah, and Solaris works just fine for me here at work.

Donnie Barnes

unread,
Oct 22, 1996, 3:00:00 AM10/22/96
to

>: Well, while the patching mechanism may exist, you are still bound to
>: Sun for the fixes. With Linux it's usually fixed before you know
>: the problem exists.
>
>well, one is bound to the linux folk for the most part for patches as well.

No, you are not "bound" to anybody. You *can* fix it yourself if you
know how to program in C. Or, you can pay a programmer of your choice
to fix it for you. Trust me, it would be pretty easy to find someone.

>consider this: s'pose someone puts a trojan in solaris that sends all my
>company secrets somewhere else. I can sue Sun. they're big, I might lose,
>but if I win, I get a lot of recompense. There's a big corporate
>entity standing behind the idea of "honest, it's ok". now suppose

Well, I can see why that might be an argument, but it's a really
stupid one. The key here is that thousands of sites around the
world use Linux for their business operations. Lots of those sights
to have folks adept at looking at kernel sources and running machines
and would *see* that kind of blatant breach. I mean come on, kernel
code that could allow something like that would stick out like a sore
thumb.

Look at this situation: You are a company who writes a database
server. Sun decides to buy your best competitor. Now, do you trust
the OS that Sun sells you, or one you have source code to? *Even*
if you *could* sue Sun, who do you want to trust?

In the free software community, that *last* thing you have to worry
about is someone writing trojan code.

>I'm running Linux. Who do I sue, Red Hat? Miguel? good chance
>I'll win, but what do I get? Miguel's Toyota? :)

Miguel is in Mexico. Good luck in the international courts. :-)

>(don't laugh. this seems funny, but liability IS an issue. one
>can say "Linux folk will fix the bugs faster" but ..)
>
>one can say that the source is freely available, but how many of us
>really have time to figure out and fix the source? not damn many.

And you don't have to. The fact that the source is available just
means that *someone* will do it. And they'll do it long before Sun
gets their version released.

>: Good point. Miguel's point was very valid as well, however. For *many*
>: folks out there, downloading most of prep.ai.mit.edu is the standard
>: thing to do when they setup a new system.
>
>many? some.
>consider how many people whose idea of a User Interface is MSOffice.
>not even Windows, just Office - Windows is just a way you start Office.
>some people use GNU. I use a bit of it. not all. most all of my users
>don't even know GNU exists - they don't care, they wanna run SDRC I-DEAS
>or WhizBangPkg X. Solaris or whatever is just a way to get there.
>just looking at the statistics of the college students I've "processed",
>that defines most of 'em, not the wanna-use-cool-GNU-toys folks.

I'm not trying to get the unwashed masses to use Linux. It probably
isn't for them, yet. The point was that if the first thing you do
is cuss your new box for not having bash installed, you *might* be
a Linux candidate.

>: Well, your idea of "toys" and Miguel's are quite different then. He is
>: referring to all the applications and such that people *expect* to work
>: under Linux, but are *not* stock parts of the commercial Unices like
>: Irix, HP-UX, and Solaris.
>
>1) should Sun/SGI/etc compile and load GNU tools for you? it costs money
>to do so - by including it, they're picking up the liability for support.
>no matter how much you say "we don't support this, we're just including it",
>it doesn't matter, folks will call you, cause it was on the Solaris CDROM,
>and expect you to support it, so you're stuck.

You're arguing with yourself here. I don't think Sun should do that.
The point was, for those that want it, we already *do* do it.

>2) Sun/etc, being large corporate entities, have lawyers. Lawyers
>probably frown on GNUware just on principle; the concept of including
>it in the OS CDROM of a multibillion $$ company probably gives them fits.

Yep...they'd be wrong, but I can understand that.

>3) see above about what users expect.
>
>on top of this, SDRC doesn't run on SPARC/Linux. nor many other things.
>at least not to my knowledge. this is a major problem.
>
>the perspective is different.
>
>SPARC/Linux fits many bills. certainly not all.

That point has been made, and I certainly don't argue it.

Tim Spence

unread,
Oct 22, 1996, 3:00:00 AM10/22/96
to

In article <54edtj$e...@vixen.cso.uiuc.edu>, g...@kestrel.scs.uiuc.edu says...

>(c) I didn't buy a Sun for cute toys. If I wanted cute toys, I would have
>bought a PC. I bought a Sun because I wanted something that I knew would
>work.

And if you really feel that Solaris works, then that's fine. But I would
wager that a lot of people are accustomed to the much more powerful GNU
tools, and frustrated at the investment in time it takes to make Solaris
usable. Personally, I feel insulted that I have to pay good money for Solaris
and then spend a couple of days adding the basics: shells, gcc, etc.

>Maybe I'm being hardheaded; I have a lot more faith in Solaris than I do

>in _any_ Linux variant, and I'll take the minor speed penalty to run an OS


>that is supported by the manufacturer.

I would think that's due more to a lack of familiarity with Linux than
anything else. If you're comfortable with Solaris, I can see why you would be
nervous about switching. However, I don't see what Sun could possibly have
done to instill faith in you regarding Solaris. Oh, and "minor speed
penalty"? I think David Miller's benchmarks show otherwise.

>Note, too, that you lose things when you install Linux. CDE, for one.

>Again, I can't speak for everyone, but if you're working in an environment
>with large numbers of machines from different manufacturers (IBM RS/6000's,

>HP 9000-series, Sun SPARCs, etc), CDE is a godsend. Professional-class


>compilers, for another; I don't believe that gcc optimizes quite as tight

>as the SUNWspro package, nor do you get the truly useful MP development
>tools of SPARCworks iMPact.

Yes, there are cases when Linux just doesn't make sense for you. CDE is one
example (although someone is working on a commercial CDE for Linux). Motif is
another example. Solaris binary compatibility is another (we have one machine
with Solaris to run Oracle). Anytime you get locked into something
proprietary, you could have a problem. Fortunately, the SunOS emulation if
terrific, and most of the apps I need are SunOS.

I've read good things about the SUNWspro package, though I've never used it.
I would think any code optimization advantage would be lost at the first
system call, though. Seems like a shame to spend money on an optimizing
compiler, shave the odd cycle here and there, then have the kernel eat them
for breakfast.

Tim Spence

--------------------------------------------------------------------
| Suffering from nasty Solaris build-up on your CPU and hard drive? |
| Try industrial strength SPARC/Linux! Cleans and freshens, too! |
| Available at a Red Hat dealer near you. |
--------------------------------------------------------------------


Gian-Paolo D Musumeci

unread,
Oct 22, 1996, 3:00:00 AM10/22/96
to

tsp...@bdm.com (Tim Spence) writes:

>In article <54edtj$e...@vixen.cso.uiuc.edu>, g...@kestrel.scs.uiuc.edu says...
>> (c) I didn't buy a Sun for cute toys. If I wanted cute toys, I would have
>> bought a PC. I bought a Sun because I wanted something that I knew would
>> work.
> And if you really feel that Solaris works, then that's fine. But I would
> wager that a lot of people are accustomed to the much more powerful GNU
> tools, and frustrated at the investment in time it takes to make Solaris
> usable. Personally, I feel insulted that I have to pay good money for Solaris
> and then spend a couple of days adding the basics: shells, gcc, etc.

The gnu tools - gcc, for example - are not necessarily the greatest tools
in the world, although they're quite nice for being free. I don't have gcc
installed on my Solaris machine; why would I bother, when /opt/SUNWspro/bin/cc
works better?

I must be missing something about the shells. I always liked plain /bin/csh,
because it requires zero maintainance. :)

>> Maybe I'm being hardheaded; I have a lot more faith in Solaris than I do
>> in _any_ Linux variant, and I'll take the minor speed penalty to run an OS
>> that is supported by the manufacturer.
> I would think that's due more to a lack of familiarity with Linux than
> anything else. If you're comfortable with Solaris, I can see why you would be
> nervous about switching. However, I don't see what Sun could possibly have
> done to instill faith in you regarding Solaris. Oh, and "minor speed
> penalty"? I think David Miller's benchmarks show otherwise.

"Minor speed penalty" is correct. I place precisely zero faith in benchmarks;
I find them uninformative at best and downright misleading at worst. Sun
instilled faith in me about Solaris by providing a respectable operating
system that *doesn't* require me to take the kernel apart and put it back
together again.

gdm

Steve Stevers! Coile

unread,
Oct 22, 1996, 3:00:00 AM10/22/96
to

Gian-Paolo D Musumeci (g...@kestrel.scs.uiuc.edu) wrote:
[...]

>The gnu tools - gcc, for example - are not necessarily the greatest
>tools in the world, although they're quite nice for being free. I
>don't have gcc installed on my Solaris machine; why would I bother,
>when /opt/SUNWspro/bin/cc works better?

Because it costs money and isn't delivered on a stock Solaris box? If
you're going to put the effort into installing a C compiler, why not go
with one that is (a) free and (b) is better supported by the UNIX
community?

>I must be missing something about the shells. I always liked plain
>/bin/csh, because it requires zero maintainance. :)

Yes, you must be missing something.

[...]


>Sun instilled faith in me about Solaris by providing a respectable
>operating system that *doesn't* require me to take the kernel apart and
>put it back together again.

Of course, you couldn't even if you had to to correct a problem, such
as a security bug. Thank GOD Sun and other big companies are so
responsive and release significant new enhancements and bug fixes so
frequently and make them so accessible! Bah!

My feeling is that if a company is going to dedicate someone to
managing a box and the company doesn't require software that is only
available for a particular flavor of UNIX, the best bet is to go with
the free stuff because it is more flexible (you can obtain and modify
the sources as necessary), improves quicker (because the developers
aren't concerned about the bad press surrounding major bug fixes, and
because they aren't burdened with supporting old versions since the
developers don't usually provide support), and has better support from
the community (because more people are using it and because more people
know more about the software since so much information about the
software (i.e. the source code) is readily accessible).

-S

Daniel Leeds

unread,
Oct 22, 1996, 3:00:00 AM10/22/96
to

Steve "Stevers!" Coile (sco...@mason2.gmu.edu) wrote:

: Because it costs money and isn't delivered on a stock Solaris box? If


: you're going to put the effort into installing a C compiler, why not go
: with one that is (a) free and (b) is better supported by the UNIX
: community?

Wait a sec here...

Because something is "free", it is better?

And while I am not busting on GCC or any other GNU util, because I like
them very much, this logic is majorly flawed.

Define better supported....if any free util flops and say erases my hard
drive, who do I go to then? They are not *responsible* for anything bad
that their product may have caused. Sure, they will look into it and I
assume work dillegently to fix it, but they are not *required* to do so.

However, a supported product from a manufacturere carries with it a
guarantee that they will replace the defective product and/or fix it.

Please, no flames over how long it takes etc, that isnt the issue here,
the bottom issue is this, if a free product hoses your system, tough luck
they dont *HAVE* to do anything about it. A commercial product on the
other hand must make amends due to the support contract.

: My feeling is that if a company is going to dedicate someone to


: managing a box and the company doesn't require software that is only
: available for a particular flavor of UNIX, the best bet is to go with
: the free stuff because it is more flexible (you can obtain and modify
: the sources as necessary), improves quicker (because the developers
: aren't concerned about the bad press surrounding major bug fixes, and
: because they aren't burdened with supporting old versions since the
: developers don't usually provide support), and has better support from
: the community (because more people are using it and because more people
: know more about the software since so much information about the
: software (i.e. the source code) is readily accessible).

When you are at home hacking around on your box, this logic makes perfect
sense.

However, if I am at work where I daily work with *classified* material,
using a free OS with sources *anyone* and their mother can obtain, this
starts to worry me.

The bugs may get fixed faster, true....but the hordes of competent systems
crackers that have those sources have many a chance to discover and
exploit holes with an ease that will make any admins head swim.

sure, new holes in commercial OS's are found almost daily...but try and
imagine how many would be found if say, Sun released Solaris source trees
to anyone via anon ftp...

(they would probably get fixed faster tho... :) )

my .02


===========================================================================
Daniel Leeds gue...@rand.org
RAND cos...@misery.winter.org
===========================================================================

Travis Hassloch x231

unread,
Oct 22, 1996, 3:00:00 AM10/22/96
to

Before you consider this a flame, please read it all. I hope my tone
has stayed somewhat playful even when criticizing. Sorry otherwise.

>> ba...@mtu.edu (Jeff Bacon) writes:
>> 3) Every BSD and SVR4 based system today, except for Linux, has a very
>> broken System call mechanism.

I disagree with "broken", except if you generalize it to "inefficient".
Your fanaticism is showing :)

>> You'd think that when people put together function call conventions
>> for a particular processor, the OS people would take a look at this
>> and find a way to take advantage of this. In fact, believe it or
>> not, they have not to this very day.

Actually, OS people have done this A LOT. Just look at L3.
Microkernel dudes have put out plethoras of papers on reducing system
call overhead, particularly since their system calls require two
kernel-boundary crossings.
Critical code paths are not unrepresented in the literature.

>> whether you are doing it in the traditional broken UNIX way or the
>> clean, fast, and superior Linux way. First I will show the Linux

Again, this sort of emotional arguing isn't likely to win Linux any converts.
The terms "clean" and "superior" aren't supported by your arguments.
It is definitely faster. However, the thing you haven't answered here
is "what do you lose by doing it this way?". The answer is "portability".
You now have to write the backend of every system call in assembler
(but see below!).

>> basically the same, but step 2 is disgustingly inefficient for

Heheh, agreed.
But as far as I remember, NetBSD doesn't do any complicated unpacking,
but simply writes the args onto a contiguous memory area, but I could
be wrong -- perhaps there is an extra copy in there.

>> 4) Solaris cannot even do it's own optimizations correctly because
>> SunPRO is a broken compiler.

^^^^^^
Again, I'd say it compiles code just fine. "Broken" simply isn't
supported by your argument. It doesn't have a feature gcc has.
That's all.

>> and avoid the address computation all the time? Yes, very
>> brilliant idea.

Well, clever, anyway...

>> gook which has to be written in raw assembly) code can directly
>> take advantage of this. However, the C code cannot do this
>> because SunPRO lacks a way for you to tell the compiler that
>> "hey you don't need to load things, it's already in these
>> hard coded registers"

Gee, I'm shooting in the dark here, but is it maybe because it's not part
of the C standard?

Although I realize you are enthusiastic (and should be, especially if
you are trying to "convert" people over), beware of marginalizing your
"competitors" or their products. You're speaking to a wide range of
audiences, and calling something broken when it isn't is not a good idea.
We can all find a feature Linux (or one of it's flavors, anyway) doesn't
have, can't we?

>> That is gross, why even do the optimization in the first place?

:) :)

[of course, maybe it _is_ faster than not doing it at all..
have you measured it?]

>> Now GCC has a way to fully take advantage of such an optimization,
>> basically all I have to do is put the following in a header file.
>> register struct task_struct *current asm("g6");

Very, VERY cool! When was this added to gcc?
Of course, you realize that this necessarily machine-dependent.
It is also limited to globals or autos, from what it appears.
And if you use it on automatic variables, I would guess, you couldn't
put it in a header file. And it has to be a register gcc won't trounce.

I was mulling over how one could get the effect of passing-by-register
in C, and do so while eliminating or isolating any MD portions into a
small portion of the code. This combines the
1) portability advantage of stack-based passing like BSD,
with the
2) speed of register passing like Linux.

We have three pieces of data:
1) the MD locore stuff which is written in assembler
2) the MI system call stuff written in C
3) the MD mapping so that (2) can get the data written into registers by (1).

So here's a strawman idea, I'm sure everyone will help me burn it :)

Idea 1

Write all system calls with no parameters, and use C globals (arg1..argN)
pass in the data, with their declarations and asm() stuff above isolated
into a MD header file.
The globals would obviously have to be void or void *, since different
system calls have different type args, or you'd have to have a different
global name for different types (e.g. argi1 vs argvp1). But it's not much
of an issue since you don't have language-enforced typesafety when calling
a system call anyway. Since it's 'static area parameter passing' -
you pay a slight penalty in readability, and it is harder to call recursively.
(Hey, I have to point out the drawbacks, no matter how small right?) :)

GCC would have to be smart enough to not use the registers corresponding to
arg1 ... argN when compiling a C function which included this header
without saving the values away first. This doesn't seem too hard.
The rest of the design is oriented towards minimizing this penalty.
If you can make gcc smarter here, you can make the rest of the design
simpler.

Based on this limitation, you can minimize the performance impacts by
partitioning the arg1 ... argN declarations into N header files.
Then, make sure each C function only includes the header files for
the number of arguments it needs. And make sure any internal functions
don't include any.

Idea 2

How about some kind of linkage map to break/loosen C argument passing
standards. On static functions, this optimization could be done entirely
in gcc, and may already be done - at the penalty of screwing up debuggers.
(Personally, I'd love to see it inline functions away when told :)

Involving non-static functions would obviously require modifications to the
linker. Since we're concerned primarily with non-static functions, let's
assume we have to modify ld. The (3) above could be a link-map, a special
piece of data which you give the linker to tell it what kind of argument
passing to use. Or, (3) could be data embedded in the .o file, which
was created by the C compiler (and probably would require changes to
the object file format).

In either case, the C compiler would leave the procedure entry and exit
"unfinished", and the linker would have to have some smarts;
it would be writing very small bits of "glue code" to pull parameters
from the stack for standard C/Pascal linkage, and to do similar fixups at
the end.

I'm not familiar with gcc, so I'm not confident at all that this is
practical. I'm guessing potential pitfalls are:
1) the linker has to be too smart
2) the compiler has to leave the procedure entry and exit points in
such a generic state that certain optimizations cannot be performed
3) you lose the distinction between compiler and linker -- you start
wondering, "gee, can I do some interprocedural dataflow analysis in
here" and pretty soon you are requiring every part of the code
to be resident in order to do those optimizations

>> Tada, now GCC will fully understand what I have done for it.
>> Under SparcLinux this optimization alone took away 115 instructions
>> in the scheduler sources, and it took ~50 instructions out of the
>> exit() handling, and it took ~65 instructions out of the fork()
>> handling.

Nice... I'm including this one in here for the NetBSD folks to consider...

>> I hope that explains some of it, and gives people at least some sort
>> of idea of the kinds of things that makes Linux scream on just about
>> any hardware.

Remember folks, maximum velocity is very important, but it ain't the whole
story. As one of my friends vitriolized; "sure, if you're one of those
classless morons who only cares about top speed". Rude, true, and
unforgettable.

>> I'd be more than happy to chat with you via email about it or
>> similar. I love talking about performance issues on various
>> processors and systems.

I am eagerly awaiting constructive responses. I don't care about OS
religious wars, but I'd love to do something to improve the situation for
one or for all.

I also do not intend to follow up on the newsgroup since the topic has
drifted considerably. In your replies, you might suggest a relevant forum!

>> David S. Miller
>> da...@caip.rutgers.edu

Kevin P. Neal

unread,
Oct 23, 1996, 3:00:00 AM10/23/96
to

cu...@cynic.portal.ca (Curt Sampson) wrote:

>In article <slrn56e21...@redhat.com>,
>Donnie Barnes <d...@redhat.com> wrote:

>>We're attempting to do something no other company has
>>done, and that's take free software into the mainstream and support it
>>at the same time.

>I can't let this one slide by. Cygnus has been `taking free software
>into the mainstream and supporting it' for years. I recently had
>the pleasure of working with Cygnus first-hand when I found a couple
>of problems with Gnu binutils-2.7. I identified two specific
>problems, submitted problem reports in the evening in each case,
>and both times I had a patch by the middle of the next business
>day.

>I would presume the support from them you pay for is at least as
>good as the support you get for free.

Yup yup yup.

When we were trying to get our Amigas (NetBSD boxes) to do the
AFS/Kerberos/Zephyr thing on campus (NCSU), we tried the MIT Kerberos
distribution.

It really blew chunks. Never did get it to compile.

Then we went for the cygnus distribution.

No sweat getting it compiled and running.
--
XCOMM Kevin P. Neal, Sophomore, Comp. Sci. \ kpn...@pobox.com
XCOMM "Corrected!" -- Old Amiga tips file \ kpn...@eos.ncsu.edu
XCOMM Visit the House of Retrocomputing: / Perm. Email:
XCOMM http://www.pobox.com/~kpn/ / kevi...@bix.com


Curt Sampson

unread,
Oct 23, 1996, 3:00:00 AM10/23/96
to

In article <54jlef$8...@rand.org>, Daniel Leeds <gue...@wilde.rand.org> wrote:
>However, a supported product from a manufacturere carries with it a
>guarantee that they will replace the defective product and/or fix it.

That guarantee does not necessarially exist, and even when it does
it may still be useless. I have personally experienced this. A
certain backup product used at a place where I used to work turned
out to have a bug in it that did not allow one to retrieve data
from the second and subsequent tapes of a multi-volume backup set.
We discovered this bug the hard way, and when we contacted the
manufacturer, they told us it had been fixed for some time, and
gave us new software. Unfortunately, though the new software wrote
new multi-volume backups correctly, it could still not read the
old multi-volume backups. When we asked about this, we were firmly
told that the data on the old backups were gone, and there was no
possible way we could get them back.

Had we been able to get any sort of specifications for the tape
format, we might have been able to hire a programmer to write some
custom software to get the data off the tapes. But of course the
vendor wouldn't let us have that, either.

>However, if I am at work where I daily work with *classified* material,
>using a free OS with sources *anyone* and their mother can obtain, this
>starts to worry me.
>
>The bugs may get fixed faster, true....but the hordes of competent systems
>crackers that have those sources have many a chance to discover and
>exploit holes with an ease that will make any admins head swim.

This is security through obscurity, and it doesn't work. The only
way you can have a truly secure system on a public network is to
have an administrator who can close holes as quickly as anyone else
can find them. This happens best if you've got a source licence.

Of course, now that you're paying somone $50K/year or more to do this
for you, your `free' software isn't very free....

Steve Stevers! Coile

unread,
Oct 23, 1996, 3:00:00 AM10/23/96
to

First, let me say that we appear to be comparing different things.
From some of the things you write, it appears you're arguing for
custom software written under contract for your specific requirements,
whereas I'm arguing about generic software written for general use.

Daniel Leeds (gue...@wilde.rand.org) wrote:


: Steve "Stevers!" Coile (sco...@mason2.gmu.edu) wrote:
: : Because it costs money and isn't delivered on a stock Solaris box? If
: : you're going to put the effort into installing a C compiler, why not go
: : with one that is (a) free and (b) is better supported by the UNIX
: : community?
:
: Wait a sec here...
:
: Because something is "free", it is better?

Not at all, but when cost is a factor, free is a big deal.

[...]
: Define better supported....if any free util flops and say erases my hard


: drive, who do I go to then? They are not *responsible* for anything bad
: that their product may have caused. Sure, they will look into it and I
: assume work dillegently to fix it, but they are not *required* to do so.

Hmmmm...I doubt Sun or any other software developer would. I'm not
current on the Sun licenses, but most software licenses out there
explicitly *disclaim* responsibility should the software fail and a
loss of data results.

The only thing you get from commercial products is the guarantee that
someone will answer a phone and promise a fix. When you get that fix
is entirely up to the vendor. Maybe you get a special patch that only
your site ever sees (which means you have to ask for an update to the
patch every time a new minor version is release), or maybe you wait
until the next major release (which means your system may be vulnerable
until then, where "then" could be next year). That's assuming you can
convince them your problem is actually a bug.

: However, a supported product from a manufacturere carries with it a


: guarantee that they will replace the defective product and/or fix it.

Only if the vendor chooses to offer such a guarantee. I'm not aware of
many off-the-shelf software publishers that guarantee that they'll
replace of fix a "defective" software package. This gets back to that
explicit disclaimer of responsibility most of them put in their
licenese.

: Please, no flames over how long it takes etc, that isnt the issue here,


: the bottom issue is this, if a free product hoses your system, tough luck
: they dont *HAVE* to do anything about it. A commercial product on the
: other hand must make amends due to the support contract.

Depends on the support contract. Support contracts typically cost lots
of money on multi-user systems, which brings us back to the cost
issue.

If you're doing anything that has to do with money (payroll,
accounting, etc.) *BY ALL MEANS* get a well-supported, commerical
product. If you're providing Internet services, don't waste your money
(IMHO).

[...]
: However, if I am at work where I daily work with *classified* material,


: using a free OS with sources *anyone* and their mother can obtain, this
: starts to worry me.

I guess you don't believe in the "security through obscurity is no
security at all" adage, eh?

: The bugs may get fixed faster, true....but the hordes of competent systems


: crackers that have those sources have many a chance to discover and
: exploit holes with an ease that will make any admins head swim.

It also means there are a greater number of competent systems managers
out there that would catch the attacks and plug the holes. If you've
got a customized system, it's going to take a lot longer to patch holes
once their found. You can *hope* nobody discovers the holes, but if
they do, you've got a much bigger problem on your hands.

: sure, new holes in commercial OS's are found almost daily...but try and


: imagine how many would be found if say, Sun released Solaris source trees
: to anyone via anon ftp...
:
: (they would probably get fixed faster tho... :) )

Bingo!

All this is not to say that I don't believe in commercial products.
I'm just trying to play devil's advocate here.

-S

hac...@user1.channel1.com

unread,
Oct 23, 1996, 3:00:00 AM10/23/96
to

gue...@wilde.rand.org (Daniel Leeds) writes:

>
> : Because it costs money and isn't delivered on a stock Solaris box? If
> : you're going to put the effort into installing a C compiler, why not go
> : with one that is (a) free and (b) is better supported by the UNIX
> : community?
>
> Wait a sec here...
>
> Because something is "free", it is better?

Of course not. You are reading more into the statement than is there.

> Define better supported....if any free util flops and say erases my hard
> drive, who do I go to then? They are not *responsible* for anything bad

Again, you are generalizing in a non general case. You can BUY support
for GCC (and most other GNU software).

> However, a supported product from a manufacturere carries with it a
> guarantee that they will replace the defective product and/or fix it.

But when? It may have been strange conditions (educational
institution) but we had a VERY hard time getting updates from Sun.

> Please, no flames over how long it takes etc, that isnt the issue here,

Timing is everything. If a product isn't working the way you need it
to, and you are losing production time because of it, you are losing money.

> the bottom issue is this, if a free product hoses your system, tough luck
> they dont *HAVE* to do anything about it. A commercial product on the
> other hand must make amends due to the support contract.

What sort of amends? Will they pay for your business insurance? Will
they pay for the commercial third party product you bought to save
your ass while they twiddled their thumbs?

> However, if I am at work where I daily work with *classified* material,
> using a free OS with sources *anyone* and their mother can obtain, this
> starts to worry me.

Having the sources means little. Sure it makes it easier for
crackers. But it also makes it easier for folks like Dan Farmer, who
has the cracker knowledge, but is cool enough to let everyone know so
they can fix things.

--
-####------------> Nipple!, Is qui iacit in hamas marsupiales. | Melior
#### Rev. Irreverend Hacksaw, Omnibenevalent Polyparrot (ULC) | amans
#### http://www.channel1.com/users/hacksaw/ | per
#### <-- Tartan of the ScotchBrite Masons (Are you two of us?) | chemia

Jim Wahlstrom

unread,
Oct 23, 1996, 3:00:00 AM10/23/96
to

Daniel Leeds wrote:
> Define better supported....if any free util flops and say erases my hard
> drive, who do I go to then? They are not *responsible* for anything bad
> that their product may have caused. Sure, they will look into it and I
> assume work dillegently to fix it, but they are not *required* to do so.

Read the licensing agreement for your software, VERY few software
companies give you any kind of garantee that there software will perform
to spec. And they make sure you can't hold them responsible for damage
caused by the product.

If you find a company that do stand behind there products, let me know.

/Jim

PS. If they did M$ would owe be a bundle :-)

Miguel de Icaza

unread,
Oct 23, 1996, 3:00:00 AM10/23/96
to

> These groups are doing a lot in the way of multiplatformness. One
> source tree means that there's little/no delay in fixes/improvements
> to migrate to the other relevant architectures.

This is the same case for Linux. Linux currently runs in the Intel
i386 family; MIPS in both big endian and little endian modes; Alpha;
SPARCs; Power PC computers and Apple PowerPC's (running on top of Mach
3); Motorola 68k and there is an ongoing port for Strong ARM machines
as well.

> Most of the kernel is MI. ISA drivers, for example, get shared
> among many architectures, even multiple PCI/ISA bridges...

Just like Linux :-).

> I'm kind of jealous of the Linux crowd since they leapfrogged 386BSD during
> the lawsuit era. Back when I chose between them BSD had long filenames
> and a mature FFS, and Linux's ext*fs was still in beta. I chose BSD.

I like to think the reason Linux is more popular is because of the
GPL; Because we have a charming leader; because they have clear goals
and becase they want their work to be public and not hoarded by some
company in the future.

Miguel.

Tim Spence

unread,
Oct 24, 1996, 3:00:00 AM10/24/96
to

In article <54j25c$m...@vixen.cso.uiuc.edu>, g...@kestrel.scs.uiuc.edu says...

>The gnu tools - gcc, for example - are not necessarily the greatest tools
>in the world, although they're quite nice for being free. I don't have gcc
>installed on my Solaris machine; why would I bother, when /opt/SUNWspro/bin/cc
>works better?

No, you certainly wouldn't.

>I must be missing something about the shells. I always liked plain /bin/csh,
>because it requires zero maintainance. :)

I think if you tried something like tcsh, you'd like it. Once you get used to
it, csh just won't do. In fact, that's kind of like Linux for me. Nothing
terribly wrong with Solaris. But now it just won't do.

>"Minor speed penalty" is correct. I place precisely zero faith in benchmarks;

>I find them uninformative at best and downright misleading at worst. Sun


>instilled faith in me about Solaris by providing a respectable operating
>system that *doesn't* require me to take the kernel apart and put it back
>together again.

I guess I thought that since Solaris was such a dog, it wouldn't be hard to
believe that another OS was a lot faster, regardless of your faith in
benchmarks. I've been using Suns for a long time. The SunOS years, the
transition from Sun 3 to Sun 4 (and anyone remember the 386i?), the terribly
painful early Solaris 2 versions, to 2.5 on SPARC and X86. The OS has gotten
bigger and slower (esp. on smaller machines) and I find it hard to believe that
people _want_ to use Solaris (you've already outlined some cases where it makes
sense, even if you don't necessarily want to). Now that there's an alternative,
it seems like people should be booting SPARC/Linux in droves. However, I
realize that some people will just be more comfortable with the status quo. But
for those of you willing to take the plunge, I don't think you'll ever go back!

R I Bagnall

unread,
Oct 24, 1996, 3:00:00 AM10/24/96
to

> Because something is "free", it is better?
>
> Define better supported....if any free util flops and say erases my hard
> drive, who do I go to then? They are not *responsible* for anything bad
> that their product may have caused. Sure, they will look into it and I
> assume work dillegently to fix it, but they are not *required* to do so.
>
> However, a supported product from a manufacturere carries with it a
> guarantee that they will replace the defective product and/or fix it.

I'd like to see them replace all the data from your erased HDD. The
only fix for this is regular backups (assuming they're robust) and
then you're safe on both counts (free/commercial).

Rob.


Martin Hargreaves

unread,
Oct 24, 1996, 3:00:00 AM10/24/96
to

JYou...@vggas.com (James Youngman) wrote:

>In article <84542163...@datamodl.demon.co.uk>,
>mar...@datamodl.demon.co.uk says...

>>Can't speak for them, but at least SunOS/Solaris has adb. :-)
>>
>>Or does Linux have adb too now?

>'fraid not, sorry. Kernel variables are modified by writing to interface files
>in /proc/sys, so adb is not required for that,

So *how* would I change things like the DNLC size by writing to an
interface file?

>and the kernel debugger is kgdb,
>so I guess nobody wanted adb enough to get it done.

I'd prefer adb, but the enough part is exactly right... ;-)

M.


Andrew Lynch

unread,
Oct 24, 1996, 3:00:00 AM10/24/96
to

Daniel Leeds wrote:
>
> Define better supported....if any free util flops and say erases my hard
> drive, who do I go to then? They are not *responsible* for anything bad
> that their product may have caused. Sure, they will look into it and I
> assume work dillegently to fix it, but they are not *required* to do so.
>
> However, a supported product from a manufacturere carries with it a
> guarantee that they will replace the defective product and/or fix it.
>
> Please, no flames over how long it takes etc, that isnt the issue here,
> the bottom issue is this, if a free product hoses your system, tough luck
> they dont *HAVE* to do anything about it. A commercial product on the
> other hand must make amends due to the support contract.
>

What products and manufacturers are you talking about???

I happen to have here in front of me one of the leaflets that came
with our German Microsoft Windows NT Server package. Quote:

"WEDER MICROSOFT NOCH DIE LIEFERANTEN VON MICROSOFT SIND FUER
IRGENDWELCHE SCHAEDEN [...] ERSATZPFLICHTIG, DIE AUFGRUND DER
BENUTZUNG DIESES MICROSOFT-PRODUKTES [...] ENTSTEHEN, SELBST
WENN MICROSOFT VON DER MOEGLICHKEIT EINES SOLCHEN SCHADENS
UNTERRICHTET WORDEN IST"

I'm not sure about the corresponding US-Version, but this translates
roughly into

"neither Microsoft nor its suppliers are in any way liable for *any*
damage caused by the use of this Microsoft product, even if Microsoft
was made aware of the possibility of such damage"

The first [...] contains a long list of damages that are explicitly
included in the "any", such as loss of business. The second basically
says the damage might also have been caused because you were to stupid
to use a Microsoft product.


So, if a Microsoft product hoses your system they will tell you to
f*ck off. I am fairly certain that a lot of other software companies
would do the same.


Andrew.

--
+----------------------------------------------------------------------+
| Andrew Lynch, MEng / ly...@cci.de | Run, run, as fast as you |
| CCI GmbH / aly...@iee.org | can. You can't catch me, |
| Lohberg 10 /ly...@ug.cs.york.ac.uk | I'm the gingerbeard man! |
| D-49716 Meppen / Tel. ++49 5931 805-243 | .sig by Anna Gramme |
+----------------------------------------------------------------------+

David S. Miller

unread,
Oct 24, 1996, 3:00:00 AM10/24/96
to

mar...@datamodl.demon.co.uk (Martin Hargreaves) writes:

> >'fraid not, sorry. Kernel variables are modified by writing to interface files
> >in /proc/sys, so adb is not required for that,
>
> So *how* would I change things like the DNLC size by writing to an
> interface file?

Ummm...

echo 65536 >/proc/sys/nr_fds
echo 3 >/proc/sys/secure_level
echo foo >/proc/sys/my_favorite_kernel_tunable

etc... you get the idea. It's procfs done right.

David S. Miller
da...@caip.rutgers.edu


Martin Hargreaves

unread,
Oct 24, 1996, 3:00:00 AM10/24/96
to

JYou...@vggas.com (James Youngman) wrote:

>In article <53jqjt$k...@rand.org>, gue...@wilde.rand.org says...

>>Anyone else fail to see the point in running linsux on sparcs?

>Well, for a start, Linux is the only OS that runs on SPARCs for which the
>SYN-flood security hole (well, D.O.S. risk) has been fixed yet.

It's just the bug of the week, how many other ways can you think of to
deny service to an Internet connected box? Dozens? Thought so. Number
one would of course be to SYN bomb its upstream router....

M.


Curt Sampson

unread,
Oct 26, 1996, 3:00:00 AM10/26/96
to

In article <s8d8y9g...@sphinx.nuclecu.unam.mx>,

Miguel de Icaza <mig...@sphinx.nuclecu.unam.mx> wrote:
>
>> Most of the kernel is MI. ISA drivers, for example, get shared
>> among many architectures, even multiple PCI/ISA bridges...
>
>Just like Linux :-).

Umm...from my reading of the source code, Linux still has a way to
go in this area. I can't see any sign that the drivers are split
into MI and MD parts. As a matter of fact, a quick look at the code
for various drivers indicates that a chip driver has to know how
to scan a bus, which is a bit silly. That should be in a separate
place, so that you can add new bus types without having to disturb
the driver itself. Then you won't need separate drivers for the
3c509 and the 3c590 in PIO mode, for example. And your NCR 5380
driver won't even have to know whether it's using memory-mapped or
I/O-space I/O, much less not be able to work with two controllers
that each use a different method.

I'm not saying that NetBSD doesn't have a way to go in this area,
too, however. We still don't have MI ISA DMA. (You should be able
to take an Adaptec 1542, plunk it into a DEC Alpha, and it should
Just Work. At this point all of our PCI cards should do that, but
very few ISA cards do.)

This is also not to say that Linux won't be able to do this soon.
I'm fairly impressed by the speed of its advance. After all, it
wasn't so long ago that the Linux kernel still had IP addresses in
Ethernet card drivers. (Although one might question why anyone
would let such a thing happen in the first place--it brings to mind
phrases like `unmitigated architectural disaster.' :-))

Curt Sampson

unread,
Oct 26, 1996, 3:00:00 AM10/26/96
to

In article <54gump$e...@midway.evtech.com>,

Travis Hassloch x231 <tra...@evtech.com> wrote:
>In article <544u8u$m...@halon.vggas.com>,
>James Youngman <JYou...@vggas.com> wrote:
>>
>>Well, for a start, Linux is the only OS that runs on SPARCs for which the
>>SYN-flood security hole (well, D.O.S. risk) has been fixed yet.
>
>Bzzt, wrong again... as I and many others mentioned, OpenBSD and NetBSD
>both run on SPARCs and have patches for the SYN-flood security hole.
>Not that it's that important, mind you.

Actually it was fixed in SunOS 4 at the same time as it was fixed
in *BSD (not surprisingly, since the networking code is practically
identical). Someone with a source licence posted some new object
files you could link in to your kernel to fix the problem.

John Turner

unread,
Oct 27, 1996, 2:00:00 AM10/27/96
to

tsp...@bdm.com (Tim Spence) writes:

[snip]

> And if you really feel that Solaris works, then that's fine. But I would
> wager that a lot of people are accustomed to the much more powerful GNU
> tools, and frustrated at the investment in time it takes to make Solaris
> usable. Personally, I feel insulted that I have to pay good money for Solaris
> and then spend a couple of days adding the basics: shells, gcc, etc.

[snip]

As I've said elsewhere in this thread, that simply is no longer necessary.

There are now CDs available and sites with binaries of all the GNU stuff
and more for Solaris (both SPARC and x86).

See:

http://smc.vnet.net/solaris_2.5.html
http://www.eis.com/software/summertime

I'm not anti-Linux at all, even though it may seem that way. I'm a huge
proponent of free software. I just hate to see misinformation.

---

John Turner

unread,
Oct 27, 1996, 2:00:00 AM10/27/96
to

sco...@mason2.gmu.edu (Steve "Stevers!" Coile) writes:

> John Turner (tur...@branagh.lanl.gov) wrote:

> : That was 9/5/96. Six weeks ago. I haven't heard a *word* back. Nothing.
> : Total silence.
>
> And you haven't contacted them again?
>
> You aren't giving them much of a chance, are you?

OK, I sent them another msg. on 10/17 asking for status. Included
all relevant info.

Ten more days of silence.

Martin Hargreaves

unread,
Oct 28, 1996, 3:00:00 AM10/28/96
to

>mar...@datamodl.demon.co.uk (Martin Hargreaves) writes:

>Ummm...

I see. Is there a list of tunables anywhere?

The nice thing about the Solaris way of doing things is that
/etc/system is read and the freshly booted kernel adb patched. So you
can tune all sorts of things that aren't supposed to be tuned to get
around all sorts of problems that never ought to happen.

I like the linux way a lot though, nice interface.

M.


Bryan Cantrill

unread,
Oct 29, 1996, 3:00:00 AM10/29/96
to

In article <54990q$n...@caip.rutgers.edu>,
David S. Miller <da...@caip.rutgers.edu> wrote:
>ba...@mtu.edu (Jeff Bacon) writes:
>
>Since I have been able to find an intelligent posting in this thread,
>I will respond to it and explain what I can as chief architect of the
>SparcLinux port.
>
>> of course, then, the obvious question that comes up is WHY is it that
>> solaris has such higher overhead costs in doing things?
>>
>> obviously there's more code to work through to do any given thing.
>> someone must have thought it necessary. but...why?
>>
>> obviously it's got lots of extra crud from SVR4. why not pitch it?
>>
>
>The answer to this is pretty straight forward actually. The main
>points of interest are:
>
>1) Solaris's networking stack, in all of it's incantations (one breed
> of it was the Lochman code in 2.0, 2.1 and early 2.2 releases, then
> it was rewritten by another company for 2.3 onward) is SVR4 streams
> based. The performance penalty, even with lots of tricks, for
> using a SVR4 streams networking architecture is well known.
> Someone who happens to have a 2.2 Solaris CD around, or even a 2.3
> Solaris CD, should install that thing and run lmbench on it to see
> what "pure Streams based networking" without the tricks can really
> do.
>
> Linux on the other hand has a "no bullshit" networking architecture
> that is not streams based. Yet we also take advantage of the many
> known networking performance enhancements that exist in the
> research realm (ie. copy/checksum, the van jacobson hacks, etc.)
>
>2) Linux is light weight, Solaris is a pig.
>
> One of the most critical things that contributes to performance
> is cache/tlb footprint of the operating system. Linux being small
> (yet still provide a full POSIX unix environment!) solves the cache
> footprint problem in a big way. I've solved the TLB footprint
> using Linux's small size and a Sparc specific trick.
>
> The MMU's present on the sun4m/sun4d line of Sun machines possess a
> three level page table scheme. Using this, one has the capability
> to use the normal 4k sizes pages, and also larger 256k and 16MB
> sized pages. The average TLB on these machines has 32 or 64
> entries to cache these pte's, if the entry is not in the TLB
> hardware has to go out to the memory bus and walk the software page
> tables to "reload" the TLB so that the translation can be
> satisfied.
>
> This "miss processing" is very expensive. Under SunOS and Solaris,
> they do not take advantage of the 16MB and 256k sized pages to map
> the operating system. Therefore those two systems take many misses
> in the TLB during even the most rudimentary trap into the kernel.
> However under Linux the TLB misses for the OS are quite minimal.
> In fact I will gave an example:
>
> On your average SparcClassic with a 32 entry TLB, consider such
> a machine with 24MB of memory installed. Under Linux I can map
> the entire operating system (sans IO device register mappings
> and Lance Ethernet DMA) in 3 (count 'em, 3!) TLB entries. These
> 3 entries are enough to allow the kernel to access an arbitrary
> physical page from kernel space.
>
> Under Solaris, the OS would need 3 + (24MB / 256K) + (24MB / 4K)
> TLB entries to map this same amount of space. For a great many
> number of operations, it is quite easy for an OS with this page
> table strategy to blow the entire user context out of the
> hardware TLB. Which in turn means more processor stalls (in
> fact many) for both the user level processes and the operating
> system.
>
> Result? Severe degradation in performance for the latter
> scheme.

>
>3) Every BSD and SVR4 based system today, except for Linux, has a very
> broken System call mechanism.
>
> You'd think that when people put together function call conventions
> for a particular processor, the OS people would take a look at this
> and find a way to take advantage of this. In fact, believe it or
> not, they have not to this very day.
>
> Linux from day one, takes advantage of the procedure call
> conventions on a particular architecture so that it can process
> system calls in the most expediant way possible. I will give
> an example on the Sparc to prove this:
>
> Consider your average 3 argument system call. The user level
> code does something like this:
>
> mov %arg0, %o0
> mov %arg1, %o1
> mov %arg2, %o3
> mov SYSTEM_CALL_NUMBER, %g1
> t SYSCALL_TRAP
>
> At this point control reaches the operating system, it must
> prepare to handle this request from the user. On the Sparc, this
> is either a two step or a three step process depending upon

> whether you are doing it in the traditional broken UNIX way or the
> clean, fast, and superior Linux way. First I will show the Linux
> method for doing this:
>
> 1) Step one, jump onto the kernel stack for this task
> and make sure the kernel has a register window to
> operate in safely.
>
> For Linux the code path for this runs at ~18 instructions
> for the common case (the kernel already has a valid
> register to use so now saving needs to be done). It runs
> at ~42 instructions for the second most common case (the
> kernels needs to allocate a new register window and the
> user has a valid stack pointer) and ~82 instructions for
> the least common case (kernel needs a window, user has
> an invalid stack pointer, thus the kernel needs to save
> the user's window into a special per-task save area).
>
> 2) Take the system call number, check for valid value, use
> this to offset into a table of system call function ptrs.
> Move arguments into place and perform the syscall.
>
> Basically this is a simple operations a looks something
> like:
>
> sll %g1, 2, %l4 ! produce offset
> ld [%l7 + %g1], %l7 ! syscall ptr base was in %l7
> SAVE_ALL ! perform step #1 above
> mov %i0, %o0
> mov %i1, %o1
> mov %i2, %o2
> mov %i3, %o3
> mov %i4, %o4
> jmp %l7, %o7
> mov %i5, %o5
>
> That is it, that is the entire system call under Linux.
>
> Under Solaris/SunOS things are wildly different. Step one is

> basically the same, but step 2 is disgustingly inefficient for
> those systems. Basically they do:
>
> 2) Call common system_call() C function.
>
> 3) This routine allocates a "system call argument package"
> structure on the kernel stack. This is wasteful because
> we already have all of this information in registers or
> in guarenteed save areas.
>
> 4) Then this routine determines the function to call, and
> passed this "package" of arguments to the routine.
>
> 5) Every system call which expects arguments then must
> "unpack" this structure to get at the copy of the arguments
> again highly inefficient.
>
> For every system call the system performs, you eat this unnecessary
> overhead under SunOS/Solaris, under Linux only the bare minimum is
> performed to do the system call successfully.

>
>4) Solaris cannot even do it's own optimizations correctly because
> SunPRO is a broken compiler.
>
> I won't make such a statement without explaining this with real
> facts, here goes.
>
> A neat part of the Sparc ABI is that it leaves you with a few
> processor registers that the C compiler is not allowed to use
> in the code it produces. Two of which are "%g6" and "%g7".
> A problem in unix kernels is that you are constantly accessing
> the current tasks control structure ('proc' and 'uarea' on
> traditional UNIX's, the 'task_struct" under Linux). Hey, why
> not put these pieces of information in those "extra" registers

> and avoid the address computation all the time? Yes, very
> brilliant idea.
>
> Under Solaris the trap entry code places the uarea and proc ptr
> in %g6 and %g7. Under Linux the trap entry code places the
> current processes task_struct in %g6. Now here comes where the
> implementations differ.
>
> Under Solaris all of the so called "locore" (basically all the

> gook which has to be written in raw assembly) code can directly
> take advantage of this. However, the C code cannot do this
> because SunPRO lacks a way for you to tell the compiler that
> "hey you don't need to load things, it's already in these
> hard coded registers" So they have the C code call these little
> assembly stubs to get the values:
>
> get_uarea:
> retl
> mov %g6, %o0
>
> get_proc:
> retl
> mov %g7, %o0

>
> That is gross, why even do the optimization in the first place?
>
> Now GCC has a way to fully take advantage of such an optimization,
> basically all I have to do is put the following in a header file.
>
> register struct task_struct *current asm("g6");
>
> Tada, now GCC will fully understand what I have done for it.
> Under SparcLinux this optimization alone took away 115 instructions
> in the scheduler sources, and it took ~50 instructions out of the
> exit() handling, and it took ~65 instructions out of the fork()
> handling.
>
>So my question always is, in matters such as these. Who are these
>processor cycles for anyways, the kernel or the user? Think about
>this when you consider how much overhead is being saved from one OS to
>another, and to what scale this is occurring.

>
>I hope that explains some of it, and gives people at least some sort
>of idea of the kinds of things that makes Linux scream on just about
>any hardware. If people would like more explainations like the above,

>I'd be more than happy to chat with you via email about it or
>similar. I love talking about performance issues on various
>processors and systems.
>
>Oh, and one thing that has not been mentioned yet in this thread (and
>yes NetBSD/OpenBSD both have this as well, good work guys). That
>SparcLinux kernel that gets all of this incredible performance runs on
>both sun4c and sun4m machines. Sun Engineers way back when scratched
>their heads for months and couldn't figure out a way to pull it off
>(you need a seperate kernel image depending upon whether you are
>running on a sun4m or a sun4c, for SunOS/Solaris). And on top of that
>Linux obviously pulls it off efficiently.
>
>One final note. When you have to deal with SunSOFT to report a bug,
>how "important" do you have (ie. Fortune 500?) to be and how big of a
>customer do you have to be (multi million dollar purchases?) to get
>direct access to Sun's Engineers at Sun Quentin? With Linux, all you
>have to do is send me or one of the other SparcLinux hackers an email
>and we will attend to your bug in due time. We have too much pride in
>our system to ignore you and not fix the bug.
>
>David S. Miller
>da...@caip.rutgers.edu
>

Have you ever kissed a girl?

- Bryan

----------------------------------------------------------------------
Bryan Cantrill, Solaris Performance. b...@eng.sun.com (415) 786-3652

Brian Perkins

unread,
Oct 31, 1996, 3:00:00 AM10/31/96
to

Well Cantril; can I take it to mean that the reason that SPARC Linux
outperforms Slowlaris is that the authors of the former have more time on
their hands than the authors of the latter?

: Have you ever kissed a girl?

captain.sarcastic

unread,
Oct 31, 1996, 3:00:00 AM10/31/96
to

Brian Perkins (bper...@netspace.org) spewed:

|
| Well Cantril; can I take it to mean that the reason that SPARC Linux
| outperforms Slowlaris is that the authors of the former have more time on
| their hands than the authors of the latter?
|
| : Have you ever kissed a girl?

| :
| : - Bryan
| :
| : ----------------------------------------------------------------------
| : Bryan Cantrill, Solaris Performance. b...@eng.sun.com (415) 786-3652
|

Cantrill's post was one of the funniest things I've read on usenet to date.
I laughed out loud, even.


--
captain.sarcastic -> on the www: http://www.sarcasm.com/ <-
mailto:i...@sarcasm.com -> free delivery service <-
Whenever I hear the word "culture", it makes me want to reach for my revolver.

Daniel Leeds

unread,
Oct 31, 1996, 3:00:00 AM10/31/96
to

Bryan Cantrill (b...@kiowa.eng.sun.com) wrote:

[entire quote deleted]

: Have you ever kissed a girl?

: - Bryan


Such a snappy response, you'd think that you could have said that without
quoting his entire post and tagging your one liner at the end.

--

David Miller

unread,
Nov 2, 1996, 3:00:00 AM11/2/96
to

In article <5543dq$q...@engnews2.Eng.Sun.COM>, b...@kiowa.eng.sun.com (Bryan Cantrill) writes:
>
> Have you ever kissed a girl?
>
> - Bryan

No, but I can kiss the sky:

$Id: bw_tcp.c,v 1.3 1995/06/21 21:02:49 lm Exp $
Socket bandwidth using xenophanes: 10.49 MB/sec

And I know how to make it even faster.

> ----------------------------------------------------------------------
> Bryan Cantrill, Solaris Performance. b...@eng.sun.com (415) 786-3652

^^^^^^^ ^^^^^^^^^^^
More like lack thereof. Bryan, your professionalism was really showing there.
Why not go and assert your effort towards making Solaris go faster so
I do not get bored, instead of wasting your energy with your childish
response to being one up'd by SparcLinux.

--------------------------------------------////
Yow! 10.49 MB/s remote host TCP bandwidth ////
over 100Mb/s ethernet. Beat that! ////
-----------------------------------------////__________ o
David S. Miller, da...@caip.rutgers.edu /_____________/ / // /_/ ><

Donnie Barnes

unread,
Nov 2, 1996, 3:00:00 AM11/2/96
to

On 31 Oct 1996 23:07:33 GMT, Daniel Leeds <gue...@wilde.rand.org> wrote:
>Bryan Cantrill (b...@kiowa.eng.sun.com) wrote:
>
>[entire quote deleted]
>
>: Have you ever kissed a girl?
>
>: - Bryan
>
>

>Such a snappy response, you'd think that you could have said that without
>quoting his entire post and tagging your one liner at the end.

Actually, judging from the "Solaris Performance" in his sig, I'd say
he's a bit miffed at the moment...but, heh, with good reason. With
any luck, he's back hard at work trying to beat the Linux numbers.
Even if he does, my money's on Dave to come out on top. :-)


--Donnie

--
Donnie Barnes http://www.redhat.com/~djb "Bah."
d...@redhat.com http://www.turner.com/lazarusman/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
_Things You'd NEVER Expect A Southerner To Say_ by Vic Henley:
** I hate the long version of ``Free Bird''.


Miguel de Icaza

unread,
Nov 3, 1996, 3:00:00 AM11/3/96
to

> >David S. Miller
> >da...@caip.rutgers.edu
> >
>
> Have you ever kissed a girl?
>
> - Bryan
>
> ----------------------------------------------------------------------
> Bryan Cantrill, Solaris Performance. b...@eng.sun.com (415) 786-3652

Now, this is not the kind of response I was expecting from a Sun
"Solaris Performance Engineer". I mean, David posted a bunch of
information on how to make an OS faster on your machines. His
knowledge was gained from several months of work and peaceful
discussion, and all you can do is attack him?

Gosh, you should be learning from the research people at universities
and not attacking them.

No wonder Sun operating systems perform so bad nowadays, the
performance people when confronted with a lengthy and detailed post on
how to make their OS faster instead of sitting down to code they just
get their paychecks and post personal attacks.

Fortunatelly, now I have a chance to run a fast, small and reliable
operating system on my SPARC machines thanks to GNU and the Linux
crowd.

Miguel.
--

Miguel de Icaza

unread,
Nov 3, 1996, 3:00:00 AM11/3/96
to

Bryan said:

> Linux is a toy, Solaris is an industrial-strength SMP operating
> system.

By industrial strenght you mean that the system can be crashed in 5
seconds? Or just that you can bring all of the networking down with a
userland command?

> On a SPARClassic Linux most likely outperforms Solaris, but how does
> Linux do on a 30-way E6000, a 20-way SC2000, or even a 4-way SS10?
> Linux _does_ _not_ _scale_. I'm emphasizing this because it isn't
> easy to parallelize complex subsystems like virtual memory; it took
> us until 2.5 to get it to scale linearly to 30 CPUs.\

Linux will get there. The solution to that is easy: the best
programmers work at it; they get the best feedback from their users
and users have ways to check for themselves what is wrong, since our
sources are freely available. The free software comunity does not
have to rush to deliver it's code in a hurry with hacks all over the
place: they sit, they think, discuss and then they implement the right
solution.

> This point really doesn't merit a response; why the hell would we
> "scratch our heads" trying to figure out how to get two different
> chips, two different architectures and (most importantly) two different
> MMU's to share the same image? (hint: we wouldn't -- it's stupid)
> Paradoxically, you berate Solaris for being bloated, and yet pull
> asinine stunts like this...

Because it is easy once you have thought about the problem? Because
users will thank you?

Miguel.

Neil Clifford

unread,
Nov 3, 1996, 3:00:00 AM11/3/96
to

Bryan Cantrill (b...@kiowa.eng.sun.com) wrote:
|>Have you ever kissed a girl?
|>
|> - Bryan
|>
|>----------------------------------------------------------------------
|>Bryan Cantrill, Solaris Performance. b...@eng.sun.com (415) 786-3652
^^^^^^^^^^^^^^^^^^^
This is the joke right? Perhaps if you spent more time on your job
instead of on the job....

--
Neil Clifford <n.cli...@physics.oxford.ac.uk>
Migrating from SunOS to SPARCLinux. By-passing Slowlaris.

David Miller

unread,
Nov 4, 1996, 3:00:00 AM11/4/96
to

In article <55i0fu$s...@engnews2.Eng.Sun.COM>, b...@kiowa.eng.sun.com (Bryan Cantrill) writes:
> In article <55fe0o$4...@romulus.rutgers.edu>,

>
> >
> > Linux on the other hand has a "no bullshit" networking architecture
> > that is not streams based. Yet we also take advantage of the many
> > known networking performance enhancements that exist in the
> > research realm (ie. copy/checksum, the van jacobson hacks, etc.)
>
> Okay, a couple of points here. First of all, the stock SVR4 networking
> code from Lachman never shipped with Solaris. The basis for the Solaris
> 2.0 code came from a company by the name of Mentat. In any case, over
> time we have made critical improvements to both throughput and latency.
> You're going to be hard pressed to find any TCP/IP implementation
> which delivers similar throughput without making sacrifices in modularity.
>

Agreed, I was misinformed of where the true source of your code base
was. I apologize for this.

I seem to be getting better latencies and bandwidth than your stack,
and although the linux networking stack may be messy it is modular.

How come I can push more over a 100baseT connection on an SS10 than
Solaris can on a uniprocessor UltraSparc? How come I have better
latencies as well? (oh btw, I don't have full 64 byte SBUS dvma
bursts enabled yet in the driver, so expect the numbers to get better
in the near future)

> A major limitation with a STREAMS based implementation, however, is that
> connection establishment and teardown are expensive. Connection-intensive
> (i.e. braindead) protocols like HTTP highlight this limitation. For
> this reason, we implemented in-kernel sockets in both 2.6 and the now-shipping
> 2.5.1 ISS release (marketing came up with the term "SISS" for the release,
> but I can't bring myself to call it that for obvious reasons). The
> raw Linux numbers are certainly appealing, but how well does the
> implementation scale to large numbers of connections? With ISS and 2.6,
> we have systems which have similar throughput with many tens of thousands
> of connections.
>

The following numbers are not that indicative of scalability, but I
will present them anyways. As usual on my two SparcClassic's each
with 24MB of ram I ran 20 ttcp's in parallel to see what the per
connection throughput would be at that point. Any larger number of
connections ran the server end out of memory.

Each connection running in parallel like this over 100baseT received
the following results with a 6KB/s of average variance amongst the runs
as a whole:

ttcp-t: 16777216 bytes in 73.14 real seconds = 224.00 KB/sec +++
ttcp-t: 2048 I/O calls, msec/call = 36.57, calls/sec = 28.00
ttcp-t: 0.0user 3.2sys 1:13real 4% 0i+0d 0maxrss 0+2pf 0+0csw

For a single connection all by itself, this machine can push:

ttcp-t: 16777216 bytes in 3.98 real seconds = 4120.28 KB/sec +++
ttcp-t: 2048 I/O calls, msec/call = 1.99, calls/sec = 515.04
ttcp-t: 0.0user 3.0sys 0:03real 78% 0i+0d 0maxrss 0+2pf 0+0csw

Over 100baseT.

This means nothing, you refer to scalability in terms of 100's and
1000's of connections, with many of them being bad connections which
are closing (ie. typical big web server) so your in a timer abundance
situation.

This situation will only not scale that well under Linux because of
certain aspects of our tcp timers. Linus and myself are already
working on a heap based solution to this problem which will allow it
to scale linearly.

> Linux is smaller (and ergo, in some respects, faster) than Solaris...
> they compete in different spaces.

I agree with this.

> Linux is a toy, Solaris is an
> industrial-strength SMP operating system.

I don't feel this is true at all, Linux is not a toy in my eyes.

[ Corporate Lingo Mode Enabled ]

"I believe SparcLinux is very close to being ready for the Enterprise."

[ Corporate Lingo Mode Off ]

> On a SPARClassic Linux
> most likely outperforms Solaris, but how does Linux do on a 30-way
> E6000, a 20-way SC2000, or even a 4-way SS10?

It does just as well on other sun4m uniprocessors as it does on the
Classic, as I have at least shown for 100baseT bandwidth on an SS10.

Thats nice to bring up all sorts of expensive hardware that I do not
access to. I tend to do pretty well with getting access to most
moderate end to high end hardware, but it is not as easily accessible
to me as it is to you as a Sun Engineer.

It seems that no matter what Linux is being compared to, someone will
bring up some new argument up once we supplant the old ones. BSD
people used to go "your networking stack is slow, therefore Linux is
no good", we started outperforming them in the areas they criticized
beforehand, and now it is some new argument. I believe this argument
cycle will continue forever.

> Linux _does_ _not_ _scale_.

I agree, for the SMP cases, no we do not scale at all in high system
activity situations. This problem we will solve eventually, but
certainly not in the way Solaris does it.

> it took us until 2.5 to get
> it to scale linearly to 30 CPUs.

Here is your very own gold star.

> Boy, that _is_ tricky. Good thing we've been doing this for three years.
> And 2.6 will see at least the modules join the kernel on a 4 meg page on
> sun4u (or a 256K page on sun4[md], or a 2M page on i86pc).

Even on sun4m (yes I have been informed recently that solaris does use
256k pages on sun4[md]) the performance improvement does not show
dramatically until you start using the 16MB pages. At least this is how
the numbers ran out for me. You get it to the point where the kernel
(except in very rare situations) will use 2 tlb entries max for nearly
all kernel requests from the user. This makes your cache miss
processing faster since the tlb will less often have to do a tree walk
in physical memory to get the translation. 256k pages do not cut it.

> What version of Solaris have you been looking at? The system call
> mechanism was rewritten in 2.5. Pre-2.5 was no doubt braindead,
> but currently system calls are quite snappy.

Again, I stand corrected. Good work.

> Incidently, be careful
> if you use a write to /dev/null as a null system call (as lmbench
> is wont to do). A write to /dev/null under Solaris isn't special-cased
> to pop back to user land;

I agree here, only because the complaints are usually of the form
"hey, our vfs subsystem is different than Linux's is, and you do not
have to do the same things we do to perform that operation".
Therefore it is the case the lmbench is really not measing what it
claims to for all systems.

> measuring getpid() is much more accurate.

Nope, getpid() is cached by libc on many systems.

> That said, system call time affects null system call benchmarks, but
> doesn't have much of an effect on most realistic workloads (try running
> vmstat(1) while your machine is enduring a heavy workload...take the
> number of system calls and multiple by 2 usec...needless to say, there
> are much bigger fish to be fried).

That is not to say it is not a worthwhile fish to fry. One thing you
fail to mention is that an improved system call entry/exit can be done
in such a way that you save an entire stack frame for each call, this
can work wonders for the cache patterns of all threads.

> Time to upgrade, big guy. With the 4.2 compilers, the source for
> getpid():
>

Again, I stand corrected, Greg Onufer pointed out this to me. But I
don't think it is all that great.

> So...what was the point again?

The point is different, the interface SunPRO provides an abortion
compared to gcc's.

Hmmm, let's compare:

.inline
get_curthread:
retl
mov %g6, %o0
.end

to...

register struct task_struct *current asm("g6");

Or something similar in the kernel:

.inline
get_psr:
retl
rd %psr, %o0
.end

verses...

extern __inline__ unsigned int get_psr(void)
{
unsigned int psr;
__asm__ __volatile__("rd\t%%psr, %0" :
"=r" (psr));
return psr;
}

I think the latter (GCC's way) is much cleaner than the inline files
you must pass to the SunPRO code generation engine.

> This point really doesn't merit a response; why the hell would we
> "scratch our heads" trying to figure out how to get two different
> chips, two different architectures and (most importantly) two different
> MMU's to share the same image? (hint: we wouldn't -- it's stupid)
> Paradoxically, you berate Solaris for being bloated, and yet pull
> asinine stunts like this...

I think it's a win. Say I have a site with 300 some odd Sun's. I
have everything from a sun4c to a sun4d. Now I can't do things like
just clone a disk from an abitrary machine to make a system for
another if the kernels are arch-specific.

Plus I think it says something that I get the performance I do with
all of that "bloat" in there. My SparcLinux kernels thats support
every arch hit around 1.3MB in size with everything compiled in. How
big does Solaris get once all the standard driver modules have been
loaded into the bare boot kernel image?

This "bloat" I have isn't the same kind of bloat that Solaris has, the
support for multiple arch's totals around 80k, this is nothing
compared to what gets stuffed into Solaris, by far.

> And we don't have pride in our system? It's ranting paragraphs like
> this that really leave me perplexed. Why do you hate Solaris so much?

I hate Solaris, for the politics behind it, how it came to be, and
the people who were personally hurt by it's existance and those who
created it.

I'm sure you have pride in your system.

My problem is that I am highly competitive, I'm always trying to get
that edge over whatever is the "best" out there. (and the fact that I
rant against Solaris directly you should receive as a completement, it
means that I consider it the best compared to everything else out
there, except for Linux in certain key areas) I tend to make my
competitive nature look like an attack on the other end.

> Contrary to your maniacal anti-Solaris zealotry, we are not the enemy.
> Microsoft is the enemy. If you're the type of person who needs to
> hate something, hate them.

I agree, the shit in Redmond is what we need to worry about first.
But secondly any entity which hoardes something which is so critical
in the computing field, that being OS technology, needs to be stamped
out next. Linux is going to do that.

> In any case, despite your ad hominem attacks, I still believe that Linux
> serves a very important purpose. It encourages interest in kernel
> implementation, and is a test bed for new technology.

I half agree, Linux is beginning to serve a new purpose other than the
one you describe. I bring Solaris boxes down in a few minutes tops
with crashme runs, people run it for days under Linux. It is things
like these, and others which are still in the works, that will make
Linux a very viable thing in production environments. In fact some
sites have completely switched to Linux technology for their
production systems. I expect this trend to continue.

> Solaris _scales_, while providing mission-critical reliability.

Solaris, run crashme, it goes boom. End of story. Any user can run
that code, or come up with the sequences it generates, yet most of the
time I have seen sun classify "crashme style" bug reports as non
critical. How mission-critical and reliable is this.

As previously mentioned, I do appreciate the fact that Solaris does
scale in situations where Linux currently does not. But don't worry,
we'll tackle this barrier just like we have for every other challenge
that has me the Linux developers.

> No matter how much you jump up and
> down, stamp your feet, or pout, Linux just doesn't.

It does or it will.

> So if you're interested in further attacking Solaris, be prepared to
> provide numbers. And frankly, lmbench is bush league. Where are the
> TPC numbers? Kenbus? SPEC-SFS (LADDIS)?

How convient, benchmarks I have to pay a ton of money for, and are
therefore out of my personal reach to acquire and use for tuning my
code. Only the hoarders create a situation like this for the free
software people.

Donnie Barnes

unread,
Nov 4, 1996, 3:00:00 AM11/4/96
to

>> Oh, and one thing that has not been mentioned yet in this thread (and
>> yes NetBSD/OpenBSD both have this as well, good work guys). That
>> SparcLinux kernel that gets all of this incredible performance runs on
>> both sun4c and sun4m machines. Sun Engineers way back when scratched
>> their heads for months and couldn't figure out a way to pull it off
>> (you need a seperate kernel image depending upon whether you are
>> running on a sun4m or a sun4c, for SunOS/Solaris). And on top of that
>> Linux obviously pulls it off efficiently.
>
>This point really doesn't merit a response; why the hell would we
>"scratch our heads" trying to figure out how to get two different
>chips, two different architectures and (most importantly) two different
>MMU's to share the same image? (hint: we wouldn't -- it's stupid)
>Paradoxically, you berate Solaris for being bloated, and yet pull
>asinine stunts like this...

Two points: 1) the folks build the OS appreciate it immensely
and 2) you can still build an arch specific kernel and omit the
"asinine" things.

The first is the most important. Following the KISS principle, folks
need an OS that is easy to install if we (ie Linux) is to compete.
To that end, having *one* boot image for sun4c and sun4m machines
is very important. While *you* may see it as common knowledge to
know what arch your machine is, end users do *not* always know. While
we *could* do loader tricks from the CD-ROM to automatically load the
right kernel, that doesn't help for those who net-boot.

>> One final note. When you have to deal with SunSOFT to report a bug,
>> how "important" do you have (ie. Fortune 500?) to be and how big of a
>> customer do you have to be (multi million dollar purchases?) to get
>> direct access to Sun's Engineers at Sun Quentin? With Linux, all you
>> have to do is send me or one of the other SparcLinux hackers an email
>> and we will attend to your bug in due time. We have too much pride in
>> our system to ignore you and not fix the bug.
>

>And we don't have pride in our system? It's ranting paragraphs like
>this that really leave me perplexed. Why do you hate Solaris so much?

>Contrary to your maniacal anti-Solaris zealotry, we are not the enemy.
>Microsoft is the enemy. If you're the type of person who needs to
>hate something, hate them.

You are wrong. Proprietary operating systems are the enemy. Having
the source available to an OS is important and may be the only thing
that can put a dent in the MS juggernaut...

>In any case, despite your ad hominem attacks, I still believe that Linux
>serves a very important purpose. It encourages interest in kernel

>implementation, and is a test bed for new technology. We are in
>_different_ spaces, however. Solaris _scales_, while providing
>mission-critical reliability. No matter how much you jump up and

>down, stamp your feet, or pout, Linux just doesn't.

Well, you are wrong again. Solaris does scale better than Linux, I
admit. But, Linux can provide very mission critical reliability.
Saying it does not is simply ignoring the obvious thousands of users
that use it every day for very important tasks.

Where is the "mission critical reliability" when a bug *is* found?
Oh, it's a month or so around the corner whilst we wait on the fix
to materialize...

I'll let the more technical folks speak to the technical points
you made...

Dan Razzell

unread,
Nov 5, 1996, 3:00:00 AM11/5/96
to

In article <55fe0o$4...@romulus.rutgers.edu>,
da...@romulus.rutgers.edu (David Miller) writes:

> ...


> No, but I can kiss the sky:

> ...

No way, man. Hendrix originally wrote: "Scuse me while I kiss this guy"

(Sorry, I'm just wasting some time while on hold for tech support from
Live Girls. You know, they seem so friendly, kept on saying how they
would really, really, like to listen to my frustrations. We were doing
just great until I mentioned that I was putting together a RAID system.
Then they put me on hold for some reason. They must be super busy or
something.)

--
.^.^. Dan Razzell <raz...@cs.ubc.ca>
. o o . Laboratory for Computational Intelligence
. >v< . University of British Columbia
_____mm.mm_____ http://www.cs.ubc.ca/nest/lci

Jeffrey Potoff

unread,
Nov 5, 1996, 3:00:00 AM11/5/96
to

Dan Razzell wrote:
>
> In article <55fe0o$4...@romulus.rutgers.edu>,
> da...@romulus.rutgers.edu (David Miller) writes:
>
> > ...
> > No, but I can kiss the sky:
> > ...
>
> No way, man. Hendrix originally wrote: "Scuse me while I kiss this guy"

Uh, no he didn't.

Martin Hargreaves

unread,
Nov 10, 1996, 3:00:00 AM11/10/96
to

da...@romulus.rutgers.edu (David Miller) wrote:

>In article <55i0fu$s...@engnews2.Eng.Sun.COM>, b...@kiowa.eng.sun.com (Bryan Cantrill) writes:
>> In article <55fe0o$4...@romulus.rutgers.edu>,

>For a single connection all by itself, this machine can push:

>ttcp-t: 16777216 bytes in 3.98 real seconds = 4120.28 KB/sec +++
>ttcp-t: 2048 I/O calls, msec/call = 1.99, calls/sec = 515.04
>ttcp-t: 0.0user 3.0sys 0:03real 78% 0i+0d 0maxrss 0+2pf 0+0csw

>Over 100baseT.

>This means nothing, you refer to scalability in terms of 100's and
>1000's of connections, with many of them being bad connections which
>are closing (ie. typical big web server) so your in a timer abundance
>situation.

How about situation with thousands of users logged in by telnet? Or
client-server apps which don't use silly/abused protocols like HTTP?

>> Linux is a toy, Solaris is an
>> industrial-strength SMP operating system.

>I don't feel this is true at all, Linux is not a toy in my eyes.

I'm undecided.

>[ Corporate Lingo Mode Enabled ]

>"I believe SparcLinux is very close to being ready for the Enterprise."

>[ Corporate Lingo Mode Off ]

Which Enterprise exactly? Most want big RDBMS systems accessed via
commodity PCs. Solaris fits in the datacentre here with some M$ crap
on the desktop and TCP/IP in the middle. Where does SPARCLinux fit in
the enterprise?

>> Linux _does_ _not_ _scale_.

>I agree, for the SMP cases, no we do not scale at all in high system
>activity situations. This problem we will solve eventually, but
>certainly not in the way Solaris does it.

Any plans on how? I'm interested...

>This "bloat" I have isn't the same kind of bloat that Solaris has, the
>support for multiple arch's totals around 80k, this is nothing
>compared to what gets stuffed into Solaris, by far.

However... I have a SPARCstation LX at home. It's a sun4m but not
fast. I bought it because I want to do useful stuff that will benefit
me. In this case that means ISDN via it's internal interface, ORACLE,
and self-teaching OS stuff. Learning Solaris via answerbook and man
pages.

Now if I run SPARCLinux then I don't get any of this (admittedly
answerbook isn't very fair, but it does bring up the point that
learning Solaris in your spare time is far more useful careerwise than
learning Linux...).

I guess you're in different spaces, but until Linux gets serious
commercial applications I think it's going to be regarded as a toy. If
anyone's ported ORACLE, Sybase, Informix, etc. then it's time for some
RDBMS numbers....

>I hate Solaris, for the politics behind it, how it came to be, and
>the people who were personally hurt by it's existance and those who
>created it.

Which people were hurt?

>I half agree, Linux is beginning to serve a new purpose other than the
>one you describe. I bring Solaris boxes down in a few minutes tops
>with crashme runs, people run it for days under Linux. It is things
>like these, and others which are still in the works, that will make
>Linux a very viable thing in production environments. In fact some
>sites have completely switched to Linux technology for their
>production systems. I expect this trend to continue.

Errrm. I've _never_ heard about any production Linux sites (other than
WWW sites) other than cases cited by the Linux fans, who seem to
recycle them. This isn't to say they aren't out there.

>> Solaris _scales_, while providing mission-critical reliability.

>Solaris, run crashme, it goes boom. End of story. Any user can run
>that code, or come up with the sequences it generates, yet most of the
>time I have seen sun classify "crashme style" bug reports as non
>critical. How mission-critical and reliable is this.

I would imagine someone more knowledgeable will reply, but I think
from the point of view of malicious users being able to trash the
system Solaris and Linux are about neck and neck in the security
holes/month stakes. Nearly all of these holes are in bundled
applications, so the old argument of "it's not Linux, it's the
software it was distributed with that has the hole" doesnt wash. It's
the same for the commercial systems.

>> No matter how much you jump up and
>> down, stamp your feet, or pout, Linux just doesn't.

>It does or it will.

which?

>How convient, benchmarks I have to pay a ton of money for, and are
>therefore out of my personal reach to acquire and use for tuning my
>code. Only the hoarders create a situation like this for the free
>software people.

Calm down. It's not like it's a global conspiracy - it's only
software.

>Yow! 10.49 MB/s remote host TCP bandwidth ////
>over 100Mb/s ethernet. Beat that! ////

Now all you need is some serious striping to lay that amount of data
onto a platter...

;-)

M.


Mike Shaver

unread,
Nov 11, 1996, 3:00:00 AM11/11/96
to

Martin Hargreaves wrote:
> Errrm. I've _never_ heard about any production Linux sites (other than
> WWW sites) other than cases cited by the Linux fans, who seem to
> recycle them. This isn't to say they aren't out there.

Firewalls.
News servers.
Name servers.
General-use ISP machines.

As examples, we have news, name and WWW servers here running Linux, and
engsoc.carleton.ca is full of Linux machines, from `X terminals' to
100-user systems.

Mike
(yeah, I'm a Linux fan)

--
#> Mike Shaver (sha...@ingenia.com) Ingenia Communications Corporation
#> Paranoid for money. Sarcastic for kicks.
#>
#> "They already *KNOW* I am a whacko, Karen.
#> That doesn't mean I am *WRONG*." -- m...@clark.net

Iain Lea

unread,
Nov 12, 1996, 3:00:00 AM11/12/96
to

Mike Shaver <sha...@neon.ingenia.com> wrote:

> Martin Hargreaves wrote:
> > Errrm. I've _never_ heard about any production Linux sites (other than
> > WWW sites) other than cases cited by the Linux fans, who seem to
> > recycle them. This isn't to say they aren't out there.
>
> Firewalls.

Looking into this option but taking my time as I always do where firewalls
and security are concerned.

> News servers.

Now here I have a BIG success story. We replaced our aging IPX/56MB/8GB
running SunOS 4.1.4 that was feeding 7 full feeds and at peak times 60
nnrpd reader processes. Load average never come down below 3-4 (ouch!).

The new system is a SS20/128MB/9GB system running Redhat 4.0 & INN 1.4 unoff4.
We now have 7 full feeds & 60 nnrpd processes running with 0.2-1.5 loadavg :).
The machine has 3x2GB stripped with the MD filesystem which really rocks as
well as a 1GB disk for the Overview data.

> Name servers.

Running a couple of LX's with 32MB Ram as Internal root servers for our
internal domains. Took 20 minutes from TFTP boot to reboot and having a
running system. A further 15 minutes of finetuning and the machines have
been going strong for the last 2 weeks. Easy install & configure and best
of all the normal PD stuff that one always has to retrofit onto Slow...is
is ready to go out of the box.

Just to show that I am not a Linux zealot heres what we use on our
gateway systems for a userbase of 20,000 users:

Proxy/Squid servers SGI Challenge DM/L 2-4CPU's 256-512MB 12-16GB Irix
Mail servers SGI Challenge S 1CPU 128MB 2-4GB Irix
SUN SS20 1CPU 128MB 2-4GB SunOS
SUN SS20 1CPU 128MB 2-4GB Solaris
DNS servers SUN SS20 1CPU 64MB 2GB SunOS
SUN LX 1CPU 32MB 1GB Linux
News servers SUN SS20 1CPU 128MB 9GB Linux
SGI Challenge S 1CPU 128MB 12GB Irix
FTP servers SNI PC 1CPU 64MB 22GB Linux
SNI RM600 6CPU's 384MB 16GB Sinix

As you can see Linux is being used for tasks that it can do out of the box
ie. DNS/News and will soon be used for our mail servers. The one task that
the SGI's will be used in for a long time to come is central proxy servers
that take 750K-1.2M requests a day.

--
Iain Lea Siemens Business Services, Germany
ia...@sbs.de <http://www.sbs.de/~iain> +49 911 978 3120

It is loading more messages.
0 new messages