Date: Thu, 18 Apr 2002 20:49:24 -0500 (CDT) From: hawkeyd@visi.com (D J Hawkey Jr) To: brett@lariat.org, freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-02:21.tcpip Message-ID: <200204190149.g3J1nOb01496@sheol.localdomain> In-Reply-To: <4.3.2.7.2.20020418141843.021d1540_nospam.lariat.org@ns.sol.net> References: <20020418182218.GA35672_peitho.fxp.org@ns.sol.net> <4.3.2.7.2.20020418141843.021d1540_nospam.lariat.org@ns.sol.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <4.3.2.7.2.20020418141843.021d1540_nospam.lariat.org@ns.sol.net>, brett@lariat.org writes: > At 12:22 PM 4/18/2002, Chris Faulhaber wrote: > >>ftp://snapshots.jp.freebsd.org/pub/FreeBSD/releases/i386/4.5-RELEASE-p3/ > > I've looked at this. It looks like the right idea. But: > > 1) It's halfway around the world, in Japan. Downloads can be quite > slow. Why isn't it on the main FreeBSD FTP server and mirrors? > > 2) It's not documented anywhere -- not even on the Web page at > http://snapshots.jp.freebsd.org/. > > 3) Is it really a "p3" build? Or is it a snapshot of -STABLE? It looks > as if at least part of it (maybe all of it) is rebuilt every day. OK, I believe it was mentioned already, but was rather glossed over: For any one "snapshot", be it a major.minor-RELEASE, or -RELEASE-pN, have you - or anyone - any idea just how many snapshots would be required? Some systems are IDE/ATAPI, others are SCSI, some are both, and some are RAID. You want a snapshot kernel supporting all that, if yours is just an internet gateway? What're the possible permutations of supported DASD? What are the possible permutations of NICs? What of optimizations for particular CPUs? So, how many kernels should be "snaphot"d? And who's to make that call? My point is, if it isn't already obvious, is that this path will garner nothing but disappointment to some group of people somewhere. There's no way FreeBSD - or any OS that runs on "ubiquitous" or "off the shelf" hardware - can make everyone happy. I daresay it'd actually satisfy but a small number of users, of which you may or may not be included. Even "snapshot"d GENERIC kernels wouldn't cut it, methinks (it wouldn't for me, anyway). --- I've tried to use Red Hat's RPMs for updates/upgrades, and it was more hassle to keep that straight than to simply replace the OS altogether (and I have to wonder if a majority of Linux sysadmins haven't came to the same conclusion and practice?). Those were on "generic" systems, too; I shudder to think what would break were they custom (in the FreeBSD sense). RPMs are not the panacea they're purported to be, many's the time they've broken more than they've fixed. --- I have used NFS as a method of distributing builds from a "master" box, and it is a viable solution, indeed. Clean, too, from the standpoint of support. And the price of the "master" box? What, $600 or $700? For the record: I cvsup'd from -RELEASE-p2 to -p3, rebuild the world, and kernel, while doing all my day-to-day business, with only occasional and brief hesitations in response times. It took about 2-1/2 hours. The system was off-line for all of about ten minutes for the installation. This on a 700Mhz Celeron. The overhead on other servers NFS-connected to it would be that last ten minutes or so. As to your "what if" about customer's systems? The build process is a great time for an extended lunch to mull over others issues with that client. Someone can page you on the off-chance it breaks, though that's never happened to me. --- And to a comment of yours that stuck in my mind: You can cvsup every night if you want, but that doesn't necessarily mean a build every night. > --Brett Brett, FreeBSD's methodologies may not be the most convenient for you or others that agree with you, but you've got to admit, it is comprehensive, and pretty much bullet-proof, if not idiot-proof. Just my more-than-two-cents' worth, Dave -- Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200204190149.g3J1nOb01496>