From owner-freebsd-stable Wed May 26 10:46:22 1999 Delivered-To: freebsd-stable@freebsd.org Received: from rio.i-plus.net (rio.i-plus.net [209.100.20.25]) by hub.freebsd.org (Postfix) with ESMTP id 07647156B7 for ; Wed, 26 May 1999 10:46:12 -0700 (PDT) (envelope-from st@i-Plus.net) Received: from localhost (st@localhost) by rio.i-plus.net (8.9.3/8.9.3) with ESMTP id NAA08394 for ; Wed, 26 May 1999 13:46:11 -0400 (EDT) Date: Wed, 26 May 1999 13:46:10 -0400 (EDT) From: Troy Settle To: freebsd-stable@FreeBSD.ORG Subject: Re: [Q] How stable is FreeBSD 3.X ? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 26 May 1999, Mike Meyer wrote: > On Wed, 26 May 1999, Daniel C. Sobral wrote: > > We also do that, through cvsup. Of course, the process of installing > > said fixes involves a make world, which could as well be a black > > box. Can you tell the difference between that and applying a service > > pack? > > I'm not familiar with service packs. However, I can certainly tell the > difference between doing a "make world" and installing a patch from > Sun. The patch doesn't change every system binary. This means it's a > lot faster to install, and you don't necessarily have to reboot the > system as part of the process. I've only been doing the *n*x thing for about 4.5 years now. Starting with Linux, then moving on to FreeBSD. If Sun does a "patch this, patch that, patch the next thing" sort of game, I'm glad I've never had to admin one. Sounds as bad as linux: Patch this, but only after you've upgraded that. Before that, however, you need to reinstall foo, and of course bar which foo depends on. etc. etc. etc. With FreeBSD: cd /usr/src cvsup supfile make buildworld && make installworld && reboot cd /usr/src/sys/i386/conf config KERNEL cd ../../compile/KERNEL make depend && make && make install && rebot And, I shit you not. I've even thought about automating this process, so that once a week (or whatever), cron would start the first part of the process, then upon first reboot, a script would check to see if the kernel was out of date. If so, build and install a new one, then reboot again. > I'd expect installing a service pack to be a lot more painfull than > installing a patch, much as installing an application on Windows 9x is > a lot more painfull than doing so on a Unix box (Does WNT require a > system reboot on every application install like Windows 9x?). Windows is braindamaged beyond repair. You don't *need* to reboot after sneezing, but it is reccomended. > I realized recently that a lot of the problems people have with the > FreeBSD support structure and terminology is because, unlike > commercial software, FreeBSD does things from the developers > viewpoint. For commercial customers, the release is the first version > of a software branch available. Everything that follows that is > patches and improvements to that. For a developer, cutting the release > disk means you're done with that branch (after that, it belongs to > maintenance :-). Guess which one FreeBSD does? It is my understanding that FreeBSD is under constant development, with several branches going at once. When a bug fix was needed, it gets applied accross the board. When a new feature has proved itself in -CURRENT, it might get pulled into -STABLE. When -STABLE has made signifigant progress over latest -RELEASE, a new -RELEASE was cut. IMO, there have been a few problems with this scheme, but nothing I can remember that didn't affect only those persons who should have been running -STABLE, but weren't. All in all, it's a pretty nice development structure compared to what I know of other vendors. > Do any of the commercial FreeBSD support organizations run a seperate > branch and bundle patches up for their customers? Like what Red Hat does for Linux? No Thank You. I would be hard pressed to leave FreeBSD, and it would seriously sadden my heart if I ever found myself in a position where I couldn't use it. -- Troy Settle iPlus Internet Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message