Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 26 May 1999 13:46:10 -0400 (EDT)
From:      Troy Settle <st@i-Plus.net>
To:        freebsd-stable@FreeBSD.ORG
Subject:   Re: [Q] How stable is FreeBSD 3.X ?
Message-ID:  <Pine.BSF.4.10.9905261327150.15724-100000@rio.i-plus.net>
In-Reply-To: <Pine.BSF.4.05.9905260831130.80146-100000@guru.phone.net>

next in thread | previous in thread | raw e-mail | index | archive | help

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 <st@i-Plus.net>
  iPlus Internet Services



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9905261327150.15724-100000>