Tech Insider					     Technology and Trends


			      USENET Archives

Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!usc!sdd.hp.com!
news.cs.indiana.edu!tpbbs!charon.bloomington.in.us!sgberg
From: sgb...@charon.bloomington.in.us (Stefan G. Berg)
Newsgroups: comp.os.linux
Subject: linux a real unix?
Message-ID: <sgberg.27o4@charon.bloomington.in.us>
Date: 24 Apr 93 22:41:10 EST
Reply-To: sgb...@charon.bloomington.in.us (Stefan Berg)
Distribution: world
Organization: Not an Organization
X-NewsSoftware: GRn 1.16f (10.17.92) by Mike Schwartz & Michael B. Smith
Lines: 21

Don't take the subject line too seriously... :-)

I was just wondering how linux compares to the commercial Unix systems
you find in Sun's, HP's, etc... Reading all these postings about "ported
blabla to linux", it seems that linux does not yet do too good in terms
of compatibility. And how about in terms of efficiency? Seems that linux
runs in very little memory, so it does seem to be more memory efficient
than those commercial unix's, but how about speed?

I would just like to hear a few comparing notes between these two rather
different implementations (one costing thousands of $'s and the other
one being free).

Stefan

-- 
,-------------------------------------------------------,
|Usenet   sgb...@charon.bloomington.in.us Stefan G. Berg|
|Internet sgb...@ucs.indiana.edu               // AMIGA |
|Bitnet   sgberg@iubacs   GE Mail  s.berg5   \X/ w/ bms |
`-------------------------------------------------------'

Path: gmd.de!Germany.EU.net!news.dfn.de!darwin.sura.net!
howland.reston.ans.net!usc!cs.utexas.edu!rutgers!igor.rutgers.edu!
geneva.rutgers.edu!hedrick
From: hedr...@geneva.rutgers.edu (Charles Hedrick)
Newsgroups: comp.os.linux
Subject: Re: linux a real unix?
Message-ID: <Apr.25.13.32.25.1993.4924@geneva.rutgers.edu>
Date: 25 Apr 93 17:32:27 GMT
References: <sgberg.27o4@charon.bloomington.in.us>
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 82

sgb...@charon.bloomington.in.us (Stefan G. Berg) writes:

>I was just wondering how linux compares to the commercial Unix systems
>you find in Sun's, HP's, etc... Reading all these postings about "ported
>blabla to linux", it seems that linux does not yet do too good in terms
>of compatibility. And how about in terms of efficiency? Seems that linux
>runs in very little memory, so it does seem to be more memory efficient
>than those commercial unix's, but how about speed?

At this point I think Linux is about as "compatible" as most of the
commercial Unices.  Porting depends upon the nature of the package.
For simple software that sticks to ANSI C, you may not have to do
anything.  For more complex things, typically there's a configuration
file or header file that defines the combination of features
appropriate for each variant of Unix.  So if nobody has built it for
Linux yet, you've got to set that up.  At this point Linux has a
fairly good libc.  The primary problems at the moment are in areas
outside what I'd call the central core of Unix features: shared
memory, IPC, etc.  There's code for System V versions of that, but
based on postings here it's not clear how stable it is.

The few benchmarks that have been posted suggest that basic Unix
facilities, e.g. fork and exec, are comparatively fast under Linux.
I/O is going to depend upon which type of controller you use and which
file system.  There are a few commercial versions of Unix designed for
use in server environments.  They have been tuned to support multiple
processors, intelligent disk controllers, etc.  Linux can't provide
competition in that area.  For a typical system with an IDE disk, I
think it does fine, and it sounds like with certain SCSI controllers
it's OK as well (but I'm not up to date on SCSI support).

I have a 486/33 with one IDE disk and a generic ET4000 SVGA
controller.  Until recently I had a Sun IPC on my desk at Rutgers,
with two SCSI disks.  I found that the overall "feel" was fairly
similar.  Certainly text scrolling in xterm was faster on the Sun
(because it has hardware bitblt, and the ET4000 doesn't).  Presumably
use of an intelligent SVGA card (e.g. S3) would fix that.  (I have
compared detailed X benchmarks.  The ET4000 actually does pretty well
against the IPC until you get to things that involve working with
areas.  That's where intelligent display hardware helps.  For my
normal usage -- which is primarily with text -- scrolling is the main
place where I see a difference.  I have to say that I find the slow
scrolling with an ET4000 annoying.)  I also have the feeling that
doing a compile in one window has a bit less impact on response in
other windows on the Sun.  This would make me suspicious of what would
happen if you put a lot of people on a Linux system.  The SLS
distribution seems to include most of the standard free software that
we make available to people on our Suns.  But we've spent a fair
amount of time collecting that software and setting it up for
distribution on campus.  A full SLS distribution would make a lot more
interesting system than a Sun as it comes "out of the box".  (In case
you wonder about the past tense -- currently I have a SparcClassic.
It is noticably faster than a 486/33, which should not be surprising
given some basic information about the processors.  It's possible that
a 486/66 would be comparable.)

I have to say that my experience with commercial Unix on Intel has not
been encouraging.  I had Microport SVr2 on a 286 for a couple of
years.  Linux is infinitely better, in features, reliability, and
support.  I've also used ATT's SVr4, but not enough that I want to
comment on it in detail.  Note that I haven't used any of the high-end
Unix ports, e.g. SCO, Destiny, or Solaris.  They would be more likely
to have advantages over Linux for commercial users, though not
necessarily for most of the current Linux user base.

I think it's important not to oversell Linux, or people may be
disappointed.  I think it's a great system for home use, both for
faculty and students.  It has most of the the Unix software I use on
Suns at Rutgers, and it performs very well.  I know there are places
that use it for commercial work successfully.  I think if I had a
small company and wanted to support somebody on the console and a
couple of terminals, and I was developing my own software (i.e. I
didn't need commercial database packages, etc.) I might consider it.
But it's not the system I'd choose to support 50 timesharing users (we
do have Suns used that way), nor is it one I'd use for our
university-wide administrative database system.  I don't see any
reason to be apologetic about its capabilities.  It does just as well
as a delivery vehicle for software from the university/research
community as commercial Unices do as delivery vehicles for commercial
applications.  Not everybody in the world wants to run TeX, Common
Lisp, Interviews, etc.  But enough do to provide a continuing place
for Linux or similar systems.

Newsgroups: comp.os.linux
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!noc.near.net!mv!
jeck!smoke.marlboro.vt.us!jhood
From: jh...@smoke.marlboro.vt.us (John Hood)
Subject: Re: linux a real unix?
References: <sgberg.27o4@charon.bloomington.in.us>
Organization: Domestic Vorpal Bunny Breeder's Association
Date: Mon, 26 Apr 1993 06:16:29 GMT
Message-ID: <1993Apr26.061629.28118@smoke.marlboro.vt.us>
Lines: 38

In article <sgberg.2...@charon.bloomington.in.us> sgb...@charon.bloomington.in.us 
(Stefan Berg) writes:
>Don't take the subject line too seriously... :-)
>
>I was just wondering how linux compares to the commercial Unix systems
>you find in Sun's, HP's, etc... Reading all these postings about "ported
>blabla to linux", it seems that linux does not yet do too good in terms
>of compatibility. And how about in terms of efficiency? Seems that linux
>runs in very little memory, so it does seem to be more memory efficient
>than those commercial unix's, but how about speed?

In terms of porting stuff to Linux, it's fairly easy.  No Unix system
can be perfect in this regard, and Linux is about as good as any.

In terms of features, Linux does well for a single-user system.  It
lacks a lot of features that make administration easier on multi-user
or networked systems.  Fine by me, so far.

In terms of bugs, well, I've had a rough three weeks. (sigh) I moved
all my stuff from a rock-solid, stone-age Xenix/386 system, and had a
couple of weeks of tearing hair out because of things that couldn't be
configured correctly, frequent kernel panics and various things
getting minorly trashed.  However, all those bugs are fixed now, and I
just get the occasional dying process or file-system hiccup now.  So,
it's definitely not as stable as most of the commercial unices, but
it's definitely usable.

Linux has several problems and design limitations that make it a Bad
Idea for a system with high or variable load just now, including a
rather low limit on the number of open files and VM unfriendliness
when your system starts running low on memory.  I don't suggest it for
more than, say, two or three simultaneous users.  But it's great as a
workstation-type system.

  --jh
-- 
John Hood					Cthulhu-- just imagine it!
jh...@smoke.marlboro.vt.us

Newsgroups: comp.os.linux
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!agate!doc.ic.ac.uk!
uknet!cf-cm!cybaswan!iiitac
From: iii...@swan.pyr (Alan Cox)
Subject: Re: linux a real unix?
Message-ID: <1993Apr26.173758.3666@swan.pyr>
Organization: Swansea University College
References: <sgberg.27o4@charon.bloomington.in.us> 
<1993Apr26.061629.28118@smoke.marlboro.vt.us>
Date: Mon, 26 Apr 1993 17:37:58 GMT
Lines: 28

In article <1993Apr26.061629.28...@smoke.marlboro.vt.us> 
jh...@smoke.marlboro.vt.us (John Hood) writes:
>
>In terms of bugs, well, I've had a rough three weeks. (sigh) I moved
>all my stuff from a rock-solid, stone-age Xenix/386 system, and had a
>couple of weeks of tearing hair out because of things that couldn't be
>configured correctly, frequent kernel panics and various things
>getting minorly trashed.  However, all those bugs are fixed now, and I
>just get the occasional dying process or file-system hiccup now.  So,
>it's definitely not as stable as most of the commercial unices, but
>it's definitely usable.

I've had no problems with a fairly heavily loaded non tcp/ip system, and
minor hiccups (a reboot every 3 days or so) with a very loaded tcp/ip
based system, as well as the odd annoying tcp/ip connection hanging
>
>Linux has several problems and design limitations that make it a Bad
>Idea for a system with high or variable load just now, including a
>rather low limit on the number of open files and VM unfriendliness

Well it copes with 8 users in 4Mb of RAM ok. The number of open files
is configurable and upping that solves that little problem. The VM 
unfriendliness is best dealt with using rlimit. I keep meaing to fix
the system so that it never overcommits on memory, and ensures that the
maximum it could be asked for is something like Swap + Physical - 128K

Alan

Newsgroups: comp.os.linux
Path: gmd.de!ira.uka.de!math.fu-berlin.de!unidui!easix!exnet2!exnet!
dcs.ed.ac.uk!sct
From: s...@dcs.ed.ac.uk (Stephen Tweedie)
Subject: Re: linux a real unix?
In-Reply-To: hedrick@geneva.rutgers.edu's message of 25 Apr 93 17:32:27 GMT
Message-ID: <SCT.93Apr26181444@ascrib.dcs.ed.ac.uk>
Sender: cn...@dcs.ed.ac.uk (UseNet News Admin)
Organization: University of Edinburgh Dept. of Computer Science, Scotland
References: <sgberg.27o4@charon.bloomington.in.us>
	<Apr.25.13.32.25.1993.4924@geneva.rutgers.edu>
Date: Mon, 26 Apr 1993 18:14:44 GMT
Lines: 58

In article <Apr.25.13.32.25.1993.4...@geneva.rutgers.edu>, 
hedr...@geneva.rutgers.edu (Charles Hedrick) writes:

> At this point I think Linux is about as "compatible" as most of the
> commercial Unices.  ... The primary problems at the moment are in
> areas outside what I'd call the central core of Unix features:
> shared memory, IPC, etc.  There's code for System V versions of
> that, but based on postings here it's not clear how stable it is.

The latest version does seem to be reliable; in fact, I would hope
that it becomes a standard kernel feature soon.

> I have to say that I find the slow scrolling with an ET4000
> annoying.

Granted.

> I also have the feeling that doing a compile in one window has a bit
> less impact on response in other windows on the Sun.

I have generally had the opposite experience, except for one thing -
because (as you have already mentioned) X is a bit slower on
Linux/ET4000 than on a Sun ELC, it gets disproportionately affected by
heavy load.  If you are running in text mode, Linux is *amazingly*
responsive even while running a couple of parallel compilations.  It
is not the kernel but the speed of X which causes the apparent
degradation in response when running X under load.

> This would make me suspicious of what would happen if you put a lot
> of people on a Linux system.

A bigger concern would be the compile-time limits on the number of
open files/inodes and the tasks limit in the kernel.

> currently I have a SparcClassic.  It is noticably faster than a
> 486/33, which should not be surprising given some basic information
> about the processors.  It's possible that a 486/66 would be
> comparable.

Well, on compute-bound *integer* tasks, (the 486's fp performance is
pretty poor,) my 486DX/33 runs my simulations faster than a
SparcStation 1+, a SparcStation 2, a Sparc ELC or a SparcServer 10.
I've done controlled, timed tests to do proper comparisons.

> I think it's important not to oversell Linux, or people may be
> disappointed.  I think it's a great system for home use, both for
> faculty and students.

Indeed.  People just have to realise that it is still developing - and
rapidly.  The installation and maintainence is pretty easy for a
single user, but configuring X and setting up a network is *not* for
the faint of heart.  It is not desparately tricky, but you may need to
be persistant.

Cheers,
 Stephen Tweedie.
---
Stephen Tweedie <s...@uk.ac.ed.dcs>   (Internet: <s...@dcs.ed.ac.uk>)
Department of Computer Science, Edinburgh University, Scotland.

Newsgroups: comp.os.linux
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!noc.near.net!mv!
jeck!smoke.marlboro.vt.us!jhood
From: jh...@smoke.marlboro.vt.us (John Hood)
Subject: Re: linux a real unix?
References: <sgberg.27o4@charon.bloomington.in.us> 
<1993Apr26.061629.28118@smoke.marlboro.vt.us> <1993Apr26.173758.3666@swan.pyr>
Organization: Domestic Vorpal Bunny Breeder's Association
Date: Tue, 27 Apr 1993 05:24:11 GMT
Message-ID: <1993Apr27.052411.637@smoke.marlboro.vt.us>
Lines: 41

In article <1993Apr26.173758.3...@swan.pyr> iii...@swan.pyr (Alan Cox) writes:
>In article <1993Apr26.061629.28...@smoke.marlboro.vt.us> 
jh...@smoke.marlboro.vt.us (John Hood) writes:

>>...  So,
>>it's definitely not as stable as most of the commercial unices, but
>>it's definitely usable.
>
>I've had no problems with a fairly heavily loaded non tcp/ip system, and
>minor hiccups (a reboot every 3 days or so) with a very loaded tcp/ip
>based system, as well as the odd annoying tcp/ip connection hanging
>>
>>Linux has several problems and design limitations that make it a Bad
>>Idea for a system with high or variable load just now, including a
>>rather low limit on the number of open files and VM unfriendliness
>
>Well it copes with 8 users in 4Mb of RAM ok. The number of open files
>is configurable and upping that solves that little problem. The VM 

What are those 8 users *doing*?  Using a BBS?  Compiling X11r5?  Big
difference between the two :)

Lurking just behind the open files limit is a limit on the number of
open *inodes*, and that can't be pushed beyond 2^8 just now.  256 open
files is not many for a Unix system.

I really should have said "implementation limitations" rather than
"design limitations."

>unfriendliness is best dealt with using rlimit. I keep meaing to fix
>the system so that it never overcommits on memory, and ensures that the
>maximum it could be asked for is something like Swap + Physical - 128K

The couple of times I've had my system go wedge itself, nothing larger
than a kernel compile has been running.  That was annoyingly large on
a 4M system, but there was 16M of swap behind it.

  --jh
-- 
John Hood					Cthulhu-- just imagine it!
jh...@smoke.marlboro.vt.us

Newsgroups: comp.os.linux
Path: gmd.de!Germany.EU.net!mcsun!news.funet.fi!hydra!klaava!torvalds
From: torva...@klaava.Helsinki.FI (Linus Torvalds)
Subject: Re: linux a real unix?
Message-ID: <1993Apr27.120149.21183@klaava.Helsinki.FI>
Organization: University of Helsinki
References: <1993Apr26.061629.28118@smoke.marlboro.vt.us> 
<1993Apr26.173758.3666@swan.pyr> <1993Apr27.052411.637@smoke.marlboro.vt.us>
Date: Tue, 27 Apr 1993 12:01:49 GMT
Lines: 41

In article <1993Apr27.052411....@smoke.marlboro.vt.us> 
jh...@smoke.marlboro.vt.us (John Hood) writes:
>
>Lurking just behind the open files limit is a limit on the number of
>open *inodes*, and that can't be pushed beyond 2^8 just now.  256 open
>files is not many for a Unix system.

Actually, there is no such limit at all.  There is a implementation
limit of 256 open files *per process*, but that should be no problem at
all: most "real" unixes have the same (or even worse) limit.  The main
reason for the per-process open file limit is (a) the fd_set structure
and (b) the fact that the task-structure gets hairy if you want truly
dynamic nr of open files/process. 

As to the number of open files on a system-wide scale: no problem - just
up NR_INODE to 1024 and NR_FILE to 768, and you shouldn't have any
problem with that for quite a while.  I already have patches that make
this dynamic, but I'm worried about races, so I haven't actually used
them yet. 

>I really should have said "implementation limitations" rather than
>"design limitations."

The reason for the small number of inodes in the default configuration
of linux is two-fold: (a) it helps on machines with only 2MB of memory,
and (b) the 'iget()' function is a piece of cr*p, and I haven't got
around to code it more efficiently.  I should add hashing to the inode
structures, but right now it uses a simple linear search, and it's
noticeable if you have 1024 inodes.  This is another thing to be fixed
with the dynamic code, but I just haven't got around to it. 

>The couple of times I've had my system go wedge itself, nothing larger
>than a kernel compile has been running.  That was annoyingly large on
>a 4M system, but there was 16M of swap behind it.

Sounds like a driver (or possibly hardware) problem.  Hmm.  It should
work fine - every once in a while I limit my memory to 4MB and start up
X11 + olvwm + a kernel compile just to check that the memory management
works after any changes.  It gets slow as molasses, but it shouldn't
wedge. 

		Linus

Newsgroups: comp.os.linux
Path: gmd.de!newsserver.jvnc.net!darwin.sura.net!howland.reston.ans.net!
torn!nott!bnrgate!bnr.co.uk!uknet!cf-cm!cybaswan!iiitac
From: iii...@swan.pyr (Alan Cox)
Subject: Re: linux a real unix?
Message-ID: <1993Apr28.083717.4010@swan.pyr>
Organization: Swansea University College
References: <1993Apr26.061629.28118@smoke.marlboro.vt.us> 
<1993Apr26.173758.3666@swan.pyr> <1993Apr27.052411.637@smoke.marlboro.vt.us>
Date: Wed, 28 Apr 1993 08:37:17 GMT
Lines: 28


To quote our machine:-

  2:56pm  up  9:20,  11 users,  load average: 0.56, 0.48, 0.30
User     tty       login@  idle   JCPU   PCPU  what
zaphod   ttys0     2:17pm           29     17  rlogin sunacm
zaphod   ttys3     1:29pm     1     19     17   (mw)
anarchy  ttys1     2:13pm           47         w
luggy    ttyp0     2:24pm           54     20  /usr/games/lib/nethackdir/nethac
belgrat  ttyp1     1:47pm         1:33     25  /usr/games/lib/nethackdir/nethac
arthur   ttyp2     1:50pm            1         
arthur   ttyp3     2:33pm     1     24      5   (csh)
romana   ttyp4     2:55pm            5      4   (mw)
mimas    ttyp5     2:40pm     2     12          (write)
dick     ttyp6     2:44pm           12      3  mw
bbs      ttyp7     2:47pm     9                 (mw)

It takes a couple of things - a reboot a day to clear hung sockets, which
slowly take up file slots and a sensible rlimit. Getting decent performance
also includes using a smaller shell than bash (vomit). If we had a small
C compiler then then world would be a happy place indeed. As it is its
down to software choice. GCC isnt the most computer friendly compiler
on planet earth.

Once the socket stuff is fixed properly the daily reboot should become
unneccessary too.

Alan

			        About USENET

USENET (Users’ Network) was a bulletin board shared among many computer
systems around the world. USENET was a logical network, sitting on top
of several physical networks, among them UUCP, BLICN, BERKNET, X.25, and
the ARPANET. Sites on USENET included many universities, private companies
and research organizations. See USENET Archives.

		       SCO Files Lawsuit Against IBM

March 7, 2003 - The SCO Group filed legal action against IBM in the State 
Court of Utah for trade secrets misappropriation, tortious interference, 
unfair competition and breach of contract. The complaint alleges that IBM 
made concentrated efforts to improperly destroy the economic value of 
UNIX, particularly UNIX on Intel, to benefit IBM's Linux services 
business. See SCO vs IBM.

The materials and information included in this website may only be used
for purposes such as criticism, review, private study, scholarship, or
research.

Electronic mail:			       WorldWideWeb:
   tech-insider@outlook.com			  http://tech-insider.org/