Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.Hawaii.Edu!news.uoregon.edu!arclight.uoregon.edu!enews.sgi.com!www.nntp.primenet.com!nntp.primenet.com!howland.erols.net!news.mathworks.com!uunet!in3.uu.net!news.va.pubnix.com!not-for-mail From: lidl@va.pubnix.com (Kurt J. Lidl) Newsgroups: comp.unix.bsd.bsdi.misc,comp.os.linux.misc Subject: Re: BSDi + AHA2944W + Eclipse RAID Date: 18 Nov 1996 19:47:13 -0500 Organization: UUNET Technologies -- Fairfax, Virginia, USA Lines: 55 Message-ID: <56r02h$leo@arrow.va.pubnix.com> References: <55j0ci$8l8@gol1.gol.com> <56glrn$c1k@olympus.nwnet.net> <56iu1n$3qt@arrow.va.pubnix.com> <56qmrs$ooa@olympus.nwnet.net> NNTP-Posting-Host: arrow.va.pubnix.com Xref: euryale.cc.adfa.oz.au comp.unix.bsd.bsdi.misc:5304 comp.os.linux.misc:142460 Anthony Talltree <aad@nwnet.net> wrote: >I really don't care about rebuilding /var/spool/news, and having it broken >isn't going to stop my OS from booting. I want plain stripes to aggregate >multiple disks over multiple controllers for the news article store. All you said was that RAID arrays were expensive. You didn't say why you wanted them. You certainly didn't make it clear that you only wanted striping for disk performance on your news spool. For that, the 'cd' driver the BSDi ships with 2.1 works perfectly well. I should know, we use it on enough systems here. I would imagine that the 3.0 splice driver would work even better. >>>Albeit with some major faults -- eg., no real patch management. >>I'll take BSDi's system over something like the "system" that SunOS/Solaris >>has anyday. > >So you don't care about the facts that BSDI's patches: > >o Ranlib updated libraries, making them difficult to track with > Tiger or Tripwire. Unaugmented uuencode isn't a reasonable way to include > binaries in a patch. Nope. I rebuild everything from scratch that really matters to me. I wouldn't think of installing patch binaries. (I only run the BSDi shipped binaries long enough to compile the system from scratch.) >o Don't apply without manual intervention -- it's pretty weak to just call > 'patch' to apply OS patches, especially when there are foo.orig files > left over from previous patches. Such cause patch to ask me if it wants > to overwrite them. Huh? They work for me when I have tried it without using RCS. If you use RCS on your kernel source tree, however, you will cause problems for yourself. Since not using a revision control system would be a bigger problem, I accept the problems and move on. It's not that big a deal. >o Effectively can't be uninstalled since they don't save state in a reasonable > fashion. This is a valid complaint. >o Aren't indexed in a documented way when installed. Single lines are added > to seperate log files for userland and kernel patches. Those lines don't > include any description, nor do they include a list of affected files. I'm trying to figure out what the problem is. The patch files themselves have this information in the top of the file. -Kurt -- /* Kurt J. Lidl (lidl@va.pubnix.com) UUCP: <Earth>!uunet!lidl */ /* Don't confuse my opinions with my employer's opinions! */