Subject: Re: Why do I keep hearing 4.3 BSD these days? (was: Re: The unbearable
To: Lord Isildur <mrfusion@umbar.vaxpower.org>
From: Gunther Schadow <gunther@aurora.regenstrief.org>
List: port-vax
Date: 05/26/2001 01:31:34
Aha, I gather that SCO now owns Unix. It went through ridiculously
many hands after AT&T sold it. Even Novell owned it for a while,
sure they had no clue what to do with it, hihi :-) So, now Unix
is back with someone who know what it is :-) and SCO has done the
right thing. Is this a correct summary of the history?

Now the key question is: is 4.3 BSD (tahoe, as you say) complete?
I mean, will it run on my VAX and your VAX just so, like Ultrix
supposedly does? But you said tahoe "and sometimes reno", does
that mean after signing the SCO license agreement you can choose
from all kinds of releases? I would love to start off with 4.3
BSD instead of Ultrix, yet I'm afraid they don't support the 
latest in VAX 6000 400 stuff, or did they? XMI, BI? Probably not.

So, we agree that we love BSD. Small is beautiful, I agree. However, 
why not discussing a few different viewpoints too :-) 

Lord Isildur wrote:

> however, 4.3tahoe is fast and lean largely because of two things:
> 1, it predates POSIX by a year. so, theres none of the POSIX bloat 
> in it.

allright. No kernel threads either, I gather. What about multi-
processor systems? 

> 2, it has not systemV compatibility.

no shm, sem, and msg. Well, it is a problem if you have no semaphores
or shared memory offered by the operating system. However, I can't 
see why that should be very difficult or kernel-bloating to support
on a VAX, or can you? 

...
> zippy. you cant have things like mmap very easily at all, the way it is
> done, so there are some features that a lot of people commonly rely on
> now that are absent in 4.3

so neither shm nor mmap, that means no shared memory at all, right?
I can't quite agree that that is so good. ...

> also, there are no shared libraries (which i think is a good thind, i
> think shared libraries are an abomination, a security and reliability
> disaster, and an administration pain in the ass, as well as plain ugly)

here we disagree most. Especially on small machines, shared libraries
are a tremendous relief. All the binaries are smaller both on disk AND
in memory. I think this is a very important achievement of the shared
libraries. I can't see why those should be a security risk, as long
as the code lives in write-protected shared memory pages. The versioning
approach with the .so files works pretty well for me. I have not wiped
out my FreeBSD system since 3 years or so; I always simply upgraded by
writing the new stuff over old stuff. My oldest binaries in /usr/local/bin
are from May 1998 (shared a.out) and still work with their version of 
libc.so and the latest stuff (ELF) works as well. It was no hassle at all 
to manage this!

Most of all I think it is a beautiful design concept to let not only
multiple processes share the same code text but even different programs
share as much code text, on disk and most importantly in memory. That's
efficient and beautiful.

> one that i personally find very comfortable and a wonderful environment,
> its tiny, it's fast, and once you get the (now free) UNIX source license
> from SCO, you can try it out yourself, too! i'm one of the distributors
> of the PUPS archive, so once you get your license, i can send you a CD or
> tape of it.

I'll want to try it, if I can use it on my hardware.

thanks,
-Gunther


-- 
Gunther Schadow, M.D., Ph.D.                    gschadow@regenstrief.org
Medical Information Scientist      Regenstrief Institute for Health Care
Adjunct Assistent Professor        Indiana University School of Medicine
tel:1(317)630-7960                         http://aurora.regenstrief.org