Date: Fri, 2 Feb 1996 10:19:32 -0600 (CST) From: "Karl Denninger, MCSNet" <karl@mcs.com> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: hackers@freebsd.org Subject: Re: And the winner is! Message-ID: <m0tiOCz-000IDUC@venus.mcs.com> In-Reply-To: <700.823231940@time.cdrom.com> from "Jordan K. Hubbard" at Feb 1, 96 07:32:20 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > a) What code base would you use? Pointers to supfiles please; > > I have the one for -STABLE, but I bet its out of date. I > > To be honest, I'd probably start supping the CVS tree to some local > location on your site and just check a -stable tree out of it for your > builds. This gives you the highest degree of flexibility should > something pop up in -current which turns out to be the answer to some > prayer and you need to do a little mucking around with CVS in order to > merge it across into your -stable tree. Ok. > > b) How to handle replication? I know how to do this on BSDI, > > but on FreeBSD it has always eluded me. Presume that there > > You want to be able to stamp out multiple machines from one build, > or..? I'm afraid that "replication" is a little ambiguous in this > context. Due to a number of historical bogons in our build process, I > still recommend that each and every machine have its own copy of > /usr/src, the problems with shared obj links otherwise becoming a real > pain. No, we want to be able to have a "code server" which can load, and keep updated, multiple machines. That is, when I have system #15 to load, I want to plug in the Ethernet, point the new box at the server, and say "go fetch your load, kid". Also, the ability to somehow have this update process automated (so that I only have to make a code change on *ONE* machine) would be nice. I don't care about /usr/src; the production machines don't have to have the storage, or the ability, to customize things *for themselves only*. There are a couple of files that don't get screwed with (obviously -- they are different, such as the stuff in /etc) but the rest should be able to be kept current without hassling over doing it by hand. > > and the companion "I want to add a disk and not do a disktab > > by hand -- since I have a ZBR disk and don't KNOW the right > > That's still kind of rough, yes. I understand it can be done with /stand/sysinstall. True? > > d) How about stability in general? PCI Ethernet card drivers? > > PCI disk drivers? NFS stability problems (we used to have > > those up the wazoo). Support for >64M without kludges? Any > > surprises I should expect (and benefits of current .vs. > > stable, etc)? > > Stability in general is good. PCI ethernet drivers good. PCI disk > drivers, getting better. NFS stability problems are bad. Most people > trying to seriously beat up on NFS find that it beats back. A lack of > NFS experts with spare time is a big problem for us right now or we'd > fix it. Ok. >> If I'm going to have an unsupported OS, damnit, then I'm going to KNOW its >> unsupported and not pay for support! I don't mind doing my own qualification > > One thing I might suggest is hiring in some local talent who finds the > idea of hacking on free software cool, for god knows whatever reason, > and can provide you with at least one source of immediate recourse in > case of failure. It all depends on whether or not the numbers add up > for you, of course. > > Jordan I think its cool myself, and don't mind as long as I know what I'm getting into. Its when I get surprised and *don't* know how much fat is in the fryer that I get a little ticked off. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity Modem: [+1 312 248-0900] | T1 from $600 monthly; speeds to DS-3 available Voice: [+1 312 803-MCS1] | 21 Chicagoland POPs, ISDN, 28.8, much more Fax: [+1 312 248-9865] | Email to "info@mcs.net" WWW: http://www.mcs.net/ ISDN - Get it here TODAY! | Home of Chicago's only FULL Clarinet feed!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0tiOCz-000IDUC>