Thor Lancelot Simon <tls(a)rek.tjls.com> wrote:
When it "drives" most VAXen, I encourage you
to let me know. It won't even
run on most of the VAXen I have, and I don't expect that to change any
time soon.
Eventually I will support almost every VAX ever made, just like Ultrix. There
is no reason why it can't be done. If Ultrix, a close 4.3BSD derivative, could
do this, so can 4.3BSD-* itself.
If you want to speed it up, tell me what hardware do you have, and maybe then
we can replace this flame war with a fruitful technical discussion of its
buses, devices, and registers, eventually culminating with writing of the
necessary drivers. The primary difficulty with expanding hardware support is
the lack of hardware. If you have the hardware and want it supported, volunteer
to be a guinea pig for driver testing. I already have several ideas on how to
add support for certain machines, and if someone volunteers to be a guinea pig,
I will be happy to send him/her some code to try firing up.
Oh, BTW, it should already be possible to run my system's userland on almost
every VAX ever made by running it atop of an Ultrix kernel. Ultrix is a close
4.3BSD derivative, and its system calls are a proper superset of the 4.3BSD
ones. Ultrix runs 4.3BSD binaries natively, without invoking any special
"emulation" or "compatibility code", since every syscall that is
native for
4.3BSD is also native for Ultrix. A system composed of an Ultrix kernel and the
userland from my latest release (without recompilation!) should run even better
than pure Ultrix.
But if your definition of "the way it's
supposed to be driven"
is "not at all", I guess I have no quibble with your logic, at least.
No, this is not my definition.
I
want support for the hardware I own
This will be done if you are willing to cooperate.
and features like mmap() and NFS.
Sorry about mmap(), but I definitely will implement NFS.
Between those, I think you'll find quite a bit of
the bloat you're
complaining about.
Hardware support expansion, NFS, and even mmap() affect the kernel only.
4.3BSD-Reno blows up the userland by a factor 2, and 4.4BSD is even worse.
You do understand that "CSRG's own
convention" involved increasing the value
of the "BSD" symbol in the user namespace with each release?
I just checked, and CSRG did not bump this symbol for the 4.3BSD-Tahoe release,
it still says 43, just like for plain 4.3BSD. If CSRG didn't bump it for Tahoe,
I don't have to bump it for Quasijarus either.
As
I said, I have an interest in old Unices mostly for historical reasons;
you appear to have an interest because you want to branch new development
from them -- fine, that's as may be, who cares? There's certainly room
for both points of view, and I fail to see why you're being so combative.
I'm being combative only when others are. If someone challenges my job as the
current principal maintainer of Berkeley VAX UNIX, I have to defend it, that's
all.
I personally don't read the statement "If
you want CSRG, here I am" quite
like that, but whatever. You might not want to say things like that in
the future if you don't want to confuse and possibly irritate a fair
number of people who have a great deal of respect for CSRG and what they
did.
I respectfully disagree. I'm not taking any credit away from CSRG, but just
because Marshall Kirk McKusick and his fellows no longer do this job doesn't
mean that I can't do it. As I said, Kirk has practically passed the torch to me
himself.
It's nice to see someone working on any Berkeley
UNIX.
Exactly, and let's switch from flames to something more useful so that I and
other 4.3BSD-* contributors can do our jobs and prove ourselves with deeds
instead of words.
Michael Sokolov
TUHS 4BSD Coordinator
4.3BSD-* Maintainer
Quasijarus Project Principal Architect & Developer
Phone: 440-449-0299 or 216-217-2579
ARPA Internet SMTP mail: mxs46(a)k2.scl.cwru.edu
TUHS WWW page:
http://minnie.cs.adfa.edu.au/TUHS/
Quasijarus WWW page:
http://minnie.cs.adfa.edu.au/Quasijarus/