[comp.sys.3b1] Not again

jeffrey@sci.ccny.cuny.edu (Jeffrey L Bromberger) (03/22/91)

In article <1228@organpipe.UUCP> tom@afthree.as.arizona.edu (Thomas J. Trebisky) writes:
>Another twist - what about a port of 4.3BSD to the Unix PC (note: I don't
>want to enter into a potential firestorm of System V versus BSD debate here.)
>I have been taking a hard look at porting 4.3BSD to the CT miniframe for
>some time now (and was thinking of pressing my newly acquired unix-PC into
>service on this project as development systems).

While I may not be as much as an old-timer here, I've been around long
enough to hear the same things go around again.  For those who 
have forgotten the Summer '89 BOF  at Usenix, let me quickly rehash:

"We're starting a company to get 3B1 source"
"We're going to port SVR3 on top of the 3B1 specific stuff"
"We're going to keep the loadable drivers for the boards"
"We're also thinking about putting in BSD stuff"
"We're going to sell it to our shareholders real cheap"

We're still waiting.

As much as I'd like to believe that this whole thing is going to come
true, I must remain a bit sceptical.  C'mon people!  Let's do a simple
poll.

Everybody stand up.
Sit if you're not really well versed in kernel to port one.
Of those remaining, sit if you don't have the time to port a new OS.

Damn, I see a lot of $$ pledges, and lots of moral support, but nobody
has the time, experience, or *whole hearted desire* to put BSD (or
minix or SVR3 or ...) on this machine.

My simple-minded suggestion is this:  Now that we have the .o files
for 3.51m, it will be easier to port over what is broken.  Alex Crain
had at one time (before his latest venture) a semi-stable namei.  It
did symbolic links.  Admittedly, there were bugs, but it was a step in
the *only reasonable direction*.  

Just for fun, is anyone here friendly enough with CSRG to ask them how
long it took them to port 4.3BSD (old VAX version) to support the
newer Tahoe processors?  Make sure to find out how many man-hours it
took.  And ask if they had any problems with finding out about
bizarre hardware timings.  And if the Tahoe people were friendly and
helpful about their product.

If no one else has leads into Bezerkeley, *I'll* ask these questions.

Jeez, I guess I really am an old-timer.  I sure don't buy these pipe
dreams anymore.  While I would *LOVE* someone to prove me wrong to the
masses with a stable BSD port, I'm not holding my breath.

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

john@chance.UUCP (John R. MacMillan) (03/22/91)

|Damn, I see a lot of $$ pledges, and lots of moral support, but nobody
|has the time, experience, or *whole hearted desire* to put BSD (or
|minix or SVR3 or ...) on this machine.

That's why we chose Minix, it's small and simple, and a port already
exists for similar processors.  I certainly don't have the time (or
inclination) to port BSD to the 3B1, but I really do think we can pull
Minix off.

We're ahead of the talk that's gone around before: we've started.
We've got the Minix source (so we've laid out some (minor) dollars),
it's on the 3B1, we've written a console driver, and done a fair bit
of playing on the bare 68010 (no os running).  We have access to the
hardware ref, kernel experience, a spare PC7300, and the desire.

It's possible that for unforseen reasons we won't finish.  It's almost
certain that it will take longer than we'd like.  But I would (and
have) bet the price of Minix on doing it ($187 Cdn).

We would like to get a minimal port (16 bit ints, no memory
protection) up and then post or make available the diffs so that
anyone who wants to can play, and help make the port more full-
featured.  Until that time, I don't think we need any help.

kak@hico2.UUCP (Kris A. Kugel) (03/22/91)

In article <1991Mar21.163810.27903@sci.ccny.cuny.edu>, jeffrey@sci.ccny.cuny.edu (Jeffrey L Bromberger) writes:
> In article <1228@organpipe.UUCP> tom@afthree.as.arizona.edu (Thomas J. Trebisky) writes:
> >Another twist - what about a port of 4.3BSD to the Unix PC (note: I don't
> >want to enter into a potential firestorm of System V versus BSD debate here.)
> >I have been taking a hard look at porting 4.3BSD to the CT miniframe for
> >some time now (and was thinking of pressing my newly acquired unix-PC into
> >service on this project as development systems).
> 
> "We're also thinking about putting in BSD stuff"
> 
> Just for fun, is anyone here friendly enough with CSRG to ask them how
> long it took them to port 4.3BSD (old VAX version) to support the
> newer Tahoe processors?  Make sure to find out how many man-hours it
> took.  And ask if they had any problems with finding out about
> bizarre hardware timings.  And if the Tahoe people were friendly and
> helpful about their product.
> -- 
> Jeffrey L. Bromberger
> jeffrey@sci.ccny.cuny.edu			jeffrey@ccnysci.BITNET
> 	Anywhere!{cmcl2,philabs,phri}!ccnysci!jeffrey

If anybody is still dreaming these dreams,
there is a BSD version running on SMALL machines
current call-numbers 2.10 or 2.11.
We used to have this running on PDP11's
where I used to work.   I'd start any BSD port
using this as a base.

I agree with Jeffrey, most of these ideas sound too big
for the number of man-hours we could devote to them.

And if I were planning this kind of effort, I'd want
to be doing it for an upward-compatable platform.
The unix-pc IS, in a way, but . . . .

Still, we DID get MGR.
                               Kris A. Kugel
                             ( 908 ) 842-2707
                      uunet!tsdiag.ccur.com!hico2!kak
                        {daver,ditka,zorch}!hico2!kak
                      internet: kak@hico2.westmark.com

wwm@wa8tzg.mi.org (Bill Meahan) (03/24/91)

In article <1316@hico2.UUCP> kak@hico2.UUCP (Kris A. Kugel) writes:
>In article <1991Mar21.163810.27903@sci.ccny.cuny.edu>, jeffrey@sci.ccny.cuny.edu (Jeffrey L Bromberger) writes:
>> In article <1228@organpipe.UUCP> tom@afthree.as.arizona.edu (Thomas J. Trebisky) writes:
>> >Another twist - what about a port of 4.3BSD to the Unix PC (note: I don't
>> >want to enter into a potential firestorm of System V versus BSD debate here.)
>> >I have been taking a hard look at porting 4.3BSD to the CT miniframe for
>> >some time now (and was thinking of pressing my newly acquired unix-PC into
>> >service on this project as development systems).
>> 
>> "We're also thinking about putting in BSD stuff"
>> 
>> Just for fun, is anyone here friendly enough with CSRG to ask them how
>> long it took them to port 4.3BSD (old VAX version) to support the
>> newer Tahoe processors?  Make sure to find out how many man-hours it
>> took.  And ask if they had any problems with finding out about
>> bizarre hardware timings.  And if the Tahoe people were friendly and
>> helpful about their product.
>> -- 
>> Jeffrey L. Bromberger
>> jeffrey@sci.ccny.cuny.edu			jeffrey@ccnysci.BITNET
>> 	Anywhere!{cmcl2,philabs,phri}!ccnysci!jeffrey
>
>If anybody is still dreaming these dreams,
>there is a BSD version running on SMALL machines
>current call-numbers 2.10 or 2.11.
>We used to have this running on PDP11's
>where I used to work.   I'd start any BSD port
>using this as a base.
>
>I agree with Jeffrey, most of these ideas sound too big
>for the number of man-hours we could devote to them.
>
>And if I were planning this kind of effort, I'd want
>to be doing it for an upward-compatable platform.
>The unix-pc IS, in a way, but . . . .
>
>Still, we DID get MGR.
>                               Kris A. Kugel
>                             ( 908 ) 842-2707
>                      uunet!tsdiag.ccur.com!hico2!kak
>                        {daver,ditka,zorch}!hico2!kak
>                      internet: kak@hico2.westmark.com

My $.02:

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

What I WOULD like to see from this effort are:

    * bug fixes
    * SCSI support, especially for SCSI hard disks and file systems
    * better disk management (fragmentation control)
    * improved serial I/O

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


As for MGR:

I will probably install MGR (using the software vidpal) in the next week
or so.  Still: where are any applications for MGR??  Yes, there is a
ported TeX previewer, but beyond that ???

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.
-- 
Bill Meahan (WA8TZG)             |   Programming is simple:
wwm@wa8tzg.mi.org  OR            |
uunet!mailrus!sharkey!wa8tzg!wwm |   All you have to do is put the right
"Home for Cybernetic Orphans"    |   numbers in the right memory locations!

dt@yenta.alb.nm.us (David B. Thomas) (03/24/91)

wwm@wa8tzg.mi.org (Bill Meahan) writes:

>I will probably install MGR (using the software vidpal) in the next week
>or so.  Still: where are any applications for MGR??  Yes, there is a
>ported TeX previewer, but beyond that ???

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

Well, MGR comes with a complete programmer's interface guide, and it's
a great interface.  You can pretty much do anything you want!  I'll agree
that so far there's a shortage of aps, but so what?  Any curses-based
ap will run in an MGR window, so with MGR, you have a super unix workstation,
regardless of any special aps.  I'm happy with MGR all by itself.

Porting to MGR should be a breeze, anyway.  I've written some piddly little
MGR programs, like a daemon that runs in a window and shows the date and time
and who's on the system and stuff like that.  Naturally, if I write anything
worthwhile, I'll post it.  I'm planning on writing a font editor.

					little david
-- 
Bottom of stack = 0x40000
Stack pointer   = 0x3fffe
Don't push it!

jeffrey@sci.ccny.cuny.edu (Jeffrey L Bromberger) (03/26/91)

In article <1991Mar23.180427.812@wa8tzg.mi.org> wwm@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@sci.ccny.cuny.edu			jeffrey@ccnysci.BITNET
	Anywhere!{cmcl2,philabs,phri}!ccnysci!jeffrey

john@chance.UUCP (John R. MacMillan) (03/27/91)

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

Doesn't qualify you as a heretic in my book...and some claim that V7
was the last decent UNIX.  The only thing I disagree with is that SysV
is small, especially V.4.

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

Like Minix... :-)

|As for MGR:
|
|I will probably install MGR (using the software vidpal) in the next week
|or so.  Still: where are any applications for MGR??  Yes, there is a
|ported TeX previewer, but beyond that ???
|
|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.

Even without a lot of tools it's still a good environment; they're
aren't too many tools for the native window system either.

john@chance.UUCP (John R. MacMillan) (03/27/91)

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

As a long term user myself, I agree that 3.51m is pretty good, and I
now have hope that we'll see a few tweaks I'd like (like support for
all 4 drives of JBM's HD2 card).

And I have to agree that if it happens it would be a LONG time before
any other port caught up in terms of being useful.  But I'm doing it
for the fun of it, and who knows, maybe that long time will come.  I
certainly don't expect to replace 3.51m with Minix in the near future,
but one of the goals I do have is to be able to boot either on my
machine.

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

There are descriptions in the Hardware Ref manual.  They're not as
complete as I'd like, but they're probably good enough.

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

That's not really as true as you might think.  There's nothing magical
about OS code, it's just C like everything else, and it turns into
bits just like everything else.  It's harder to debug, and the bugs
can be more disastrous, but it's not a black art.

|Does anyone
|have not only the time and experience, but the machine to experiment
|on?

Yep. :-)

|Good question.  Everyone loves MGR (myself included) but to this date,
|nothing fancy has been written for it.

True.  As much as I love MGR, nifty applications for it are at the
bottom of my already too full project list.