On 5 May 1996, Bruce Toback wrote:
 
> This is interesting. I have found it extremely stable; all my unplanned
> shutdowns have been caused by hardware problems -- which has not been the case
> with our NT system. What versions of Linux did you run, and what kinds of
> applications? I'm using 1.2.13; it's being used for software development,
> routing, and Internet services (mail, ftp, www). I also run X clients on it,
> though not an X server.
 
  We use(d) our Linux machine for virtual hosts (web hosts, mail, ftp for
multiple virtual machines).    There was the idea to set up INN on the
machine; however after discovering all the extra configuration required
(as Linux doesn't have a real /bin/sh, just a bash) it didn't seem
feasible.  The Linux-based news server at an upstream site was judged to
be a very poor performer, as connections and stability lagged.  That
system ran on Linux 1.2.8.
  2-3 Linux machines either in the office or belonging to
clients have all recently had file system failures.  We have had our
machines occasionally lock.  We ran 1.2.13 until we needed to extend our
virtual hosting clientele, at which time it became more feasible to hop
to a well tested 1.3.59 kernel and use the built in IP aliasing support
in lieu of the dummy modules.  Linux does not seem to function under extreme
pressure.  FreeBSD on the other hand, does suit well, especially
considering Walnut Creek CDROM, supplier of one of the largest available
Internet archives, can handle up to 1250 users on _1_ FreeBSD machine.
We are now migrating slowly to that platform, and have so far been very
pleased at the performance and overall total speed and power increase
over Linux.
 
> In my admittedly limited experience, Unix performace problems are more related
> to applications. This is a bigger problem than on MPE, since Unix provides
> very few application services of its own, meaning that application designers
> must supply more of the necessary scaffolding. A Unix DBMS must either live on
> top of Unix services or replace them entirely; MPE's IMAGE and KSAM are
 
  Hmm... DBMS is becoming quite intertwined into newer UNIX platforms.
BSD 4.4 systems, and perhaps even the newer SysVR4 systems (Solaris 2.5
for example) rely quite heavily on NDBMS/DBMS databases to maintain the
password databases (the databases which are used in some cases over the
/etc/passwd flatfiles).  Solaris' ncsd package even caches name server,
password (if so set up), and other databases to allow for optimal system
performance.  ncsd does come standard with newer releases of Solaris
2.x.  To perhaps say that UNIX database management or utilization at the
system level is nearly non-existant or pathetic is like saying TCP/IP and
general networking is pathetic in MPE... it was, until now. :)
 
> them rather than thinking up better ways to do things. When the development
> applications are scaled up, the limitations of the services become apparent.
> One old example of this is the file system: it's optimized for access to
> fairly small files, but it's VERY good with them. So developers rely on
> sequential access to small files, but this doesn't scale well to large
> applications. (Unix file systems are improving in this regard, so this
> statement is no longer true of many commercial implementations.)
 
  Isn't this true with everything?  In fact, one major reason why I hated
Linux is because the scaling up of development applications (major libc
releases, a.out and ELF libs, svgalib, X libs, etc) meant that I would in
most cases need to do a complete OS reinstall, as library or include file
upgrades seldom seemed to work well, and things would break.  I could not
run the newest stuff because it would require functions only available in
the newest libraries.  Things change too much in Linux to make it worth
while.  MPE is the same way IMHO.  Just go through the mail list,
especially referring back to discussions of job queueing and the creation
of queues with different classifications... tell me that won't cause
at least some ripples in how certain proprietary apps work when they need to
stream background jobs...
 
> Another example is that process launching under Unix is quite fast. Not
> blinding, but quite fast. So developers rely on launching a lot of processes.
> But again, this doesn't scale well.
 
  How fast should it be?  It needs to allocate memory, check permissions,
limits, etc.  To go any faster would be to possibly risk POSIX
compliance, and hence get rid of why UNIX is what it is.
 
> These two programs perform the same functions, but HP's implementation,
> optimized to take advantage of things MPE does well (and avoid the ones it
> does poorly) runs several times faster.
 
  A program such as a web server, for the most part, is a collection of
library and intrinsic calls.  Perhaps it is HP's lack of optimization in
the POSIX development areas that cause this performance degradation in
the first place?  After all, HP _DOES_ write the libraries which are
ultimately responsible for how the code is executed.
 
Daniel Kosack
[log in to unmask]
 
-- My opinions are my own and do not necessarily reflect the opinions of
   my employers at FredNet or the National Cancer Institute FCRDC.