Return to BSD News archive
Newsgroups: comp.unix.bsd Path: sserve!manuel!munnari.oz.au!mips!decwrl!sdd.hp.com!cs.utexas.edu!hellgate.utah.edu!fcom.cc.utah.edu!gateway.univel.com!gateway.novell.com!thisbe!terry From: terry@thisbe.npd.Novell.COM (Terry Lambert) Subject: Re: 4.4BSD-alpha CDROM Message-ID: <1992Jul10.154332.18687@gateway.novell.com> Sender: terry@thisbe (Terry Lambert) Nntp-Posting-Host: thisbe.eng.sandy.novell.com Organization: Novell NPD -- Sandy, UT References: <2278@nic.cerf.net> <1992Jul9.140537.2208@ntuix.ntu.ac.sg> <1992Jul10.024627.9909@servalan.servalan.com> Date: Fri, 10 Jul 1992 15:43:32 GMT Lines: 60 In article <1992Jul10.024627.9909@servalan.servalan.com>, rmtodd@servalan.servalan.com (Richard Todd) writes: |> eoahmad@ntuix.ntu.ac.sg (Othman Ahmad) writes: |> |> >In article <2278@nic.cerf.net> richter@nic.cerf.net (Adam J. Richter) writes: |> |> >Isn't it easier to just use BSD fs? This has it's portability problems, but a SunOS UFS CD would be my first choice, given that Sun is distributing all it's software that way, and I think their drives are more prevalent. Since it's UFS, it's also more likely to be usable with little change under 386BSD. ISO9960 has traditionally been a PC format, and, while we *are* using PC hardware for the most part, we generally aren't running DOS on that PC hardware -- we're running 386BSD, for which UFS is the native FS. Another reason for going with Sun is the fact that the CSRG distribution tape is supposedly going to provide support for SPARC (but not support SPARC explicitly!). The code would be more useful in that format. |> Oh, one more point re: ISO9960 availability. The standard MS-DOS software |> for reading CD-ROMs (MSCDEX, or something like that), handles ISO9960 |> filesystems. You can't *get* much more available than something that can be |> read on a PeeCee. :-). DOS isn't very useful in general, and with the sad fact being that it can't be used as a cross-compilation environment for 386BSD, I don't think the utility would be there. You'd have to find some way of getting it to a real OS. Not only do you have the problem of buying a CD-ROM that lives on DOS, you also have to buy networking software or guarantee Kermit will run for a **LONG** time, and that you can copy an entire directory tree. While the terrible fact of it being a DOS CDROM drive rather than a UNIX one, which you already have or have access to if you have a Sun machine and can load any recent software, is bad enough, the 8.3 file name restriction and POSIX-noncompliant case-folding is doubly damning. Even without ISO9960 restrictions to this effect, DOS would still impose them on you. The fact of a DOS-centric CDROM player is only somewhat mitigated by the fact that, if it was a SCSI dirve, and if 386BSD fully supported SCSI, and if the DOS CD-ROM software supported SCSI CD-ROM drives in the first place, and if you had an ISO9960 FS for your 386BSD, and if it worked, you could use the CD-ROM drive under 386BSD to load the large number of 386BSD software packages being sold on CD-ROM by software retailers everywhere (NOT!). The other point to consider is that, even if it`s only Sun, modifying the file /usr/include/make/default.mk to relocate objects, or mounting via a translucent file system, or running "Terry's-marvelous-but-as-yet-unreleased-severely- tortured-version-of-GNUmake", you can compile directly off the CD-ROM if it's in a mountable format. Since 386BSD only supports one of the 3 approaches (That being "Terry's-marvelous-but-as-yet-unreleased-severely-tortured-version-of- GNUmake"), crosscompilation, probably from Sun, is the only way to make it work. Terry Lambert terry_lambert@gateway.novell.com terry@icarus.weber.edu --- Disclaimer: Any opinions in this posting are my own and not those of my present or previous employers.