Date: Tue, 10 Jul 2001 09:56:58 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Rasputin <rara.rasputin@virgin.net> Cc: Jamie Bowden <ragnar@sysabend.org>, hackers@FreeBSD.ORG Subject: Re: FreeBSD Mall now BSDCentral Message-ID: <3B4B33DA.242EFDDC@mindspring.com> References: <200107100731.f6A7VxR05700@panix1.panix.com> <Pine.BSF.4.10.10107100439380.67797-100000@moo.sysabend.org> <20010710125613.A51035@dogma.freebsd-uk.eu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Rasputin wrote: > > Where as I see the ability to incrementally upgrade only > > the parts of the OS that have changed from release to > > release as I can do right now in Irix. > > I may be low on caffeine, but I don't see how breaking up > the base system into packages makes it any easier to upgrade > than using cvsup? > > Id have thought it would require more work to upgrade > under some system similar to the ports tree (at least > that's my experience) We're talking packages, not ports. We're also talking about being able to maintain basic configuration control, without having to screw around without compiling the sources yourself. Consider binary upgrades for things like security alerts, which could happen automatically, based on whatever criteria you specify (including "root exploit" or "Never Do Anything Without My Permission"). In the worst case, you could need to compile a newer version of "sendmail" or "bind" than that which came with the system, to resolve an exploit. You would still want to end up with a "RELEASE plus known patch sets" when you were done, so that you could feel both comfortable about your ability to reproduce your production system, should you need to replace it or to scale to more customers. Running "some snapshot of STABLE" is not really the way to do this. And there is the commercial support issue: what constitutes a "supported configuration"? Certainly not a "checkout your source tree from your local repository copy using this date tag: XXX". Also, you should be aware that in commercial deployment, having a compiler on board the system is often considered a bad thing, as it permits entre to exploiters bringing their own programs onto the system. One of the things that TrustedBSD played around with is binary signatures, where it is not possible to run a binary that does not have a corresponding approved signature. In such a system, it's really imperitive that configuration management occur through a centralized binary blessed to install only blessed binaries. That _really_ precludes rebuilding from sources. > But like I said, I've probably misread this post. > > I thought the OP was referring to X in particular, and > since that's upgraded via ports anyway, it does seem a > good candidate to be installed by pkg_add (it's quite > confusing for newbies to "pkg_info | grep XFree " and > have it return nothing, especially when you're sat in > Enlightenment...) This really demonstrates the problem with having base system components (I include X11, bind, sendmail, etc. in this) that are not easily upgraded. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B4B33DA.242EFDDC>