Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!osuunx.ucc.okstate.edu!moe.ksu.ksu.edu!vixen.cso.uiuc.edu!howland.reston.ans.net!usc!cs.utexas.edu!uunet!spcvxb!terry From: terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.) Newsgroups: comp.os.386bsd.misc Subject: Re: BSD/386 Commercial Product Message-ID: <1993Jul27.053721.6646@spcvxb.spc.edu> Date: 27 Jul 93 05:37:21 EDT References: <1778.2C53F9EF@mechanic.fidonet.org> <23136o$aa6@pdq.coe.montana.edu> Organization: St. Peter's College, US Lines: 73 In article <23136o$aa6@pdq.coe.montana.edu>, osyjm@cs.montana.edu (Jaye Mathisen) writes: > BSDI is a fine product, with good support *if* you happen to have the > *exact* hardware that they support, and BSDI is/has been phenomenally > slow in adding new stuff. (And things have been changed enough that > taking drivers from 386bsd is not a simple drop-in). I'm not sure what you mean about *exact* hardware. With the exception of SCSI controllers, there is wide support for most common PC hardware - most Ethernet boards and the Xircom Pocket Ethernet adapter, Microsoft/Logitech bus mice, lots of VGA cards, a good number of multiport serial cards (with more coming), etc. As far as "drop-in" drivers go, my impression (from running 386bsd 0.1 a long time ago) is that BSDI is closer to current CSRG driver methodology, while 386bsd is a unique beast (or several, these days). > BSDI has good support for Adaptec scsi, no support for anything else. True, but I haven't seen lots of requests for other boards. If I were go- ing to add one, I'd add the Future Domain 1800-class (like the TMC-1680), and maybe the 950-class (like the TMC-885). The BSDI SCSI stuff is rather clean- ly split into a class/port architecture so much of the common SCSI code lives in another module and shouldn't need to be changed. It also uses the new auto config stuff. > Putting in new funky things like Terry's LKM stuff, bde's intr stuff, > npx code, sio, etc, are futile exercises under BSDI. I'm unaware of the details of the packages you're discussing here. However, back in BSDI's 0.9.4 release I added the latest bpf and some Sun "nit" stuff and it went in easily. > If you want to hack, and try the latest stuff, forget it. [I'm going to reorder this comment up one paragraph here to make my explan- ation shorter] Some folks want to hack the kernel; others the utilities; still others want to develop/port applications; and yet more just want a platform to run somebody else's application. Depending on which of those categories a user falls into, they might want one of the "free" systems like 386bsd, NetBSD, Linux, etc., or a commercial system like BSDI's BSD/386, or they might even want a System V-based system (if they're running a canned application). > In short, if you don't mind being trailing edge, and just want > a solid platform to run X, and some TeX, and News, and SLIP, and > stuff like that, then it's fine. And they have excellent technical > support people available. I wouldn't characterize BSDI as "trailing edge". Development and user interest is less obvious because it isn't done in newsgroups. From what I've read of BSDI's plans (ftp to BSDI.COM and read the literature there), they are planning SCO compatibility and SPARC support for an upcoming release. I would assume some sort of shared library support as well. They are also com- mitted to tracking the 4.4BSD release (presumably, after the "Lite" kit is released). I'd be quite surprised if any of these things make it out in an official "free" release first. And, as you point out, the technical support is excellent. I've used CSRG BSD releases since 4.1BSD/2.9BSD, and the out-of-the-box software quality in BSDI is much higher, and the system is treated just that way, as a "sys- tem". I've been able to rebuild the system with a great deal of ease, with a single "make all" in /usr/src/sys, which was never possible on 4BSD - there was too much stuff that was just compiled, tested, and plopped in without being integrated. And when you have a question with BSD/386 you have folks who are guaranteed to be there to answer it, something that wasn't there in CSRG releases (it wasn't in the CSRG's charter). Terry Kennedy Operations Manager, Academic Computing terry@spcvxa.bitnet St. Peter's College, Jersey City, NJ USA terry@spcvxa.spc.edu +1 201 915 9381