Not again (BSD etc. ports)

[Jeffrey L Bromberger]

In article <1991Mar23.180427.812 at wa8tzg.mi.org> wwm at wa8tzg.mi.org (Bill Meahan) writes:
>
>I realize that I may be a MAJOR heretic in the UNIX world, but I really
>don't regard BSD as the Holy Grail of UNIX-dom.  I'd MUCH rather keep a
>small, fast kernel ( the SYS-V approach ) rather than the giant kernel
>of the BSD systems.  Given the 4MB address space of the 3B1 (et. al.) it
>makes much more sense to adhere to the KISS principle (Keep It Simple, S...)

I'm not claiming that BSD *is* the be-all-and-end-all to unix (unless
you know me better :-), but it has some things going for it.  First
off, parts are AT&T free - and readily available from almost
everywhere.  The stuff that *is* still under the licence restrictions
need only a 32V or Version 7 licence, not one of the new expensive
SVR? jobbies.  While I kind of agree that a GENERIC BSD kernel is
bloated, if you took the time to reconfig the system, and *leave out*
the drivers you had no hardware for, then things got smaller.  Really
now, how many VAX users had RX02 8 inch floppies for folks to use??
Finally, before I give up the BSD soapbox, it has all the socket/network
code in it.  SLIP is there, with no fudging around.  Symlinks also
look nice.  I've grown very accustomed to these things, and if I'm
going to spend time to port something the size of a kernel, I'm gonna
port one that has everything I want.  And SVR4 is $$$out$$$ of the
question.

Rumours have it that 4.4 will run on a (urgh) 386 box.  That might be
fun - maybe not, come to think of it.  MtXinu got 4.3 up earlier this
year.

>    * bug fixes

Bug fixes are fine *if you have source code*.  Binary patching sucks,
pardon my terminology.  Ask folk who have released them.  And remember
that the licence you have with AT&T for the 3.51 operating system
prevents you from "taking any steps, such as reverse assembly or
reverse compilation".  So, you can't take apart what you have.
Meaning that you can only replace bad subunits.  Like I said, now that
we have the .o files for the kernel, it is within our rights to make a
rewrite of stuff like the tty driver and namei routines to suit our
needs.  No need to take apart the kernel, we have the pieces already
there!

>    * SCSI support, especially for SCSI hard disks and file systems

Without any additional hardware, forget it.  Our best shot is Thad's
connection for that RLL daughterboard.  I hate to be pesimistic, but
forget SCSI.  For the time and effort in making it come true, you
could've had a SS1+.

>    * better disk management (fragmentation control)

Not without the BSD FFS.  And I just got bitten by that - my one and
only superblock got trashed. The old filesystem had just one.  Kirk
McKusick made sure the FFS had one for each cylinder group, because it
was so valuable.  Does anyone out there really know for sure if SVR3
(prior to the BSD throw-ins) did fragment management??

>    * improved serial I/O

Forget that.  The main logic board was not, well, planned right. We
suffer from that today.  Gil has documented dropped characters at 9600
baud because of timing problems.  His solution (a simple one at that)
was to make a simple smart terminal card.  Run a fast UART off it.
Have it take care of fast io and pass it to the machine at a
reasonable speed.   He mentioned this baack in either summer89 or
winter90 BOF at usenix. Nobody took up the challenge.  Even now, with
the driver available for the 386 kernel for a 16550 (?) chip, nobody
has touched it.

>This may not be very ambitious, but it would be of much greater
>immediate use.

Right now, believe it or not, I have fallen under the beliefs of other
long-term users.  Namely that there is not all that much wrong with
3.51m unix.  There'd be too much lost by starting over again.  I'm
saying that as someone who uses tape, ethernet, voice, combo, and
sometimes dos cards.  Nobody has the specs for those things.  So I'd
end up losing what I have. No way, not after all I've laid out for
them.  For the things that our kernel is missing, like symlinks and
UIPC, well, there's the hope of loadable drivers.  And the same few
are still cranking them out.  Names like Mike Ditto, Alex Crain and
David Herron.  These are our kernel hackers.  People,
there are only a few who are skilled at kernel.  Sure, anyone can
write regular code, but stuff like drivers is different.  Does anyone
have not only the time and experience, but the machine to experiment
on?  I can't afford to use my one machine to do kernel testing.  What
happens if one trashes their disks?

>Still: where are any applications for MGR??  Yes, there is a
>ported TeX previewer, but beyond that ???

Good question.  Everyone loves MGR (myself included) but to this date,
nothing fancy has been written for it.  Nothing like a tek terminal
emulator, nor games; nothing but the demo programs.  Some stuff is out
there (like mgrload and mgreyes), but those are cute showpieces.  If I
had to convince someone to trash the UA for mgr, there's be (to them)
everything to lose and nothing to be gained.  As most of the folks I
work with say "Where are the games?"  They like mahjongg, klondike,
even that chess program from the STORE, but so far nada.

>We need at least a port of [x]fig, plus other USEFUL tools, else it's
>just a pretty demo of what could be/have been.

Amen, brother.  Now that John has blessed us with the vidpal emulator,
and people can see what they've been missing, this is where our
development sould be.  Personally, I'd like to see a voice editor,
since the distributed one dosen't work without the wind driver.  But
there are TONS of things to do.  Some brave soul suggested the
monumental task of porting the Xlibs to work under mgr.  Now *there's*
ambition.  

Maybe I've rambled on too much.  Maybe I've just been holding a lot of
this back for a while.  Everybody and their brother can knock our
machines, but they're *ours*.  We get to choose how fast they outlive
their usefulness, not AT&T.  Is anybody willing to talk a bit about
what projects they're working on?  Wouldn't be better if we stopped
working as individuals, and worked as a whole to one goal, namely
making this machine work up to it's potential?  

It's late, so I'll spare y'all from another 3 meg rant.

j
-- 
Jeffrey L. Bromberger
System Operator---City College of New York---Science Computing Facility
jeffrey at sci.ccny.cuny.edu			jeffrey at ccnysci.BITNET
	Anywhere!{cmcl2,philabs,phri}!ccnysci!jeffrey