hello,

> 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?

in very compressed summary, yeah. 

> 
> 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

thelicense gives you access to the source code and the right to use, 
modify, etc do what you like with it. its the missing piece for the older
releases which contain (or which AT&T's lawyers claimed contained) 
encumbered code. basically, thelicense covers all research UNIX and 32V and
their derivants, except systemV and its children. Since berkeley forked
off from bell labs UNIX after 32V, and is 'derived' from it, all BSD
releases are covered. the BSD code is licensed from the university of
california- UCB distributed their code free, under the BSD license, but
the portions that were covered by the AT&T copyright were what you had a 
UNIX license for. by 4BSD the amount of AT&T code left was very small,
but somehow they claimed there was something still in there until the
net2 release. 

as for complete, it is indeed a complete system! 

if you want to check out a 4.3tahoe system, contact me offline for
an account on my used-to-be-public VAX (i shut off the guest account 
temporarily) and you can see what its like. 

> 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.
> 

some BI , but not much. no XMI. the CSRG diverged from the VAX for a 
while, to a machine called the tahoe (hence the name) , and in the mean 
time, DEC rolled out lots of BI stuff, and then when BSD came back to the 
VAX, the 80s were getting close to over, and reno was ported to half a dozen
machines, including the popular suns and HPs and stuff. so, thenewer 
vaxen never got support. the main reason, though, is that DEC was 
extremely secretive about BI and XMI stuff specs were not so readily 
available, nor was programming information. 


> 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? 

no SMP. i think some people have hacked it in, but in the CSRG sources, 
theres no support for it. 

> 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? 

its more conceptual bloat then physical bits, i think.. it is not too 
hard to hack them in. some people did. 4.3reno started inforporating many 
of these things and 4.4 had most of them


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

it isnt so bad
 yes a lot of modern stuff wont compile under it
but capability wise, it is more that stuff liek shm make things easy for 
a certain way of solving problems, which have other kinds of solutions too


> 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.

i think the acrobatics that must go on behind the scenes to make it 
possible are really ugly, and in order to do shared libs, you must 
destroy a much simpler and more elegant model of an executable. also, 
i have objections to programs whose code isnt there. a binary should
stand on its own. it's one thing to depend on the operating system, that
is fine- what's in the kernel is not a problem to depend on being there
because a: the interface does not change nearly as much, and usually
it only changes by the presenceor absence of some syscalls, not in 
show-stopping differencesin the way a given syscall operates, and b: the 
kernel is guaranteed to be there if youre able to even try to run the 
thing in the first place. 
when i have a binary that i have no chance of finding source for anymore,
it is stuck on the machine that it lives on, imprisoned by its shared 
libraries- if it dependson a version of the shared libs that another 
machine doesnt have, then i'm SOL when i want to move that thing to
another system. sure, if i have the permissions i can copy the shared 
libs over too... one should expect to have root on every system one uses. 
what then of the forest of multiple versions of shared libs one 
accumulates over time? i dont think the savings in disk space is really 
all that great (aside from having _lots_ of X stuff) when you start having
four and five different versions of libc because different things demand 
different versions. i think that's pathetic. 
plus, if i'm just joe Q user, and the sysadmin 'upgrades' the shared 
libs, and my binaries break, theres nothing i can do. if i had the 
source, i could _rewrite_ it to work with the newer libraries, which is
NOT just the same as recompiling them sometimes, but if it was statically 
linked, then that binary has a much longer life, namely, the length of
time that that architecture and a mostly compatible kernel stay in 
service. I can still run a.out binaries from ten years ago, for example 
on sparc boxen, that were compiled under sunos and now still run under 
solaris 2.8. 
the very fact that a shared library can change without the program or
its author doing anythign to change it, and by doing so change the 
operation of that program, i think that is abhorrent. a program is supposed
to be predictable, entirely duplicatable (internally, you cant
assure i/o and external conditions will ever be duplicatable of coure) 
and behave in a known manner. When some of its code can change at the
whim of someone else, without any notice or knowledge of it til things 
start behaving differently, that is really wrong. i compile my programs
statically on systems with shared libs, and it is amazing how much more 
convenient it is when i have to move them from machine to machine, esp 
when i am not the sysadmin on all the machines, or i cant be installing 
the same mountains of libraries on all the machines. 
This also has a security aspect: a program whose code isnt entirely in 
itself, but is at the mercy of someone else's libraries, is much more 
vulnerable to deliberate as well as inadvertent malfunction or insecurity 
due to an unwanted change. notnoly could a malicious intruder replace 
shared libs with trojanned versions, but because everythign depends on 
them, he could cause almosy any command on the system to run almost 
anythign he wished, and almost as bad as trojanning the kernel, it is 
that much harder to detect. Not like it happens every day, but if it 
does, it makes the attack a _lot_ worse. in this respect, its a multiple 
points of failure and dependent recovery mechanisms kind of issue. 

> 
> > 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.

a 6000 isnt gonna run any of them, but if you have a uvII, thats a nice 
small machine that will run all of them from 4.3 onward. ive heard that 
poeple have shoehorned 4.2 onto a uVAX sometimes too.. 

happy hacking,
isildur