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.