From owner-freebsd-stable@FreeBSD.ORG Fri Apr 2 12:15:28 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 776C41065673 for ; Fri, 2 Apr 2010 12:15:28 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by mx1.freebsd.org (Postfix) with ESMTP id 5C8E58FC26 for ; Fri, 2 Apr 2010 12:15:28 +0000 (UTC) Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta07.emeryville.ca.mail.comcast.net with comcast id 0br71e0031bwxycA7cFVbr; Fri, 02 Apr 2010 12:15:29 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta18.emeryville.ca.mail.comcast.net with comcast id 0cKg1e0043S48mS8ecKgYw; Fri, 02 Apr 2010 12:19:41 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 6FF319B419; Fri, 2 Apr 2010 05:15:26 -0700 (PDT) Date: Fri, 2 Apr 2010 05:15:26 -0700 From: Jeremy Chadwick To: "Svein Skogen (Listmail Account)" Message-ID: <20100402121526.GA64746@icarus.home.lan> References: <20100402021715.669838e0.stas@FreeBSD.org> <11597.1270200291@critter.freebsd.dk> <20100402101454.GA62089@icarus.home.lan> <20100402.122836.41723967.sthaug@nethelp.no> <4BB5CAA7.5030108@stillbilde.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BB5CAA7.5030108@stillbilde.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: Results of BIND RFC X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 12:15:28 -0000 On Fri, Apr 02, 2010 at 12:44:55PM +0200, Svein Skogen (Listmail Account) wrote: > On 02.04.2010 12:28, sthaug@nethelp.no wrote: > >> [1]: FreeBSD really needs to move away from the "base system" as a > >> concept, as I've ranted about in the past. > > > > Strongly disagree. > > > >> Or if it cannot, the "base > >> system" needs to start using pkg_* (somehow) for use, and src.conf > >> WITHOUT_xxx (where xxx = some software) removed. Concept being: "I > >> don't need Kerberos; pkg_delete base-krb5. I also don't need lib32; > >> pkg_delete base-lib32". Beautiful concept, hard to implement due to > >> libraries being yanked out from underneathe binaries that are linked to > >> them. But you get the idea. > > > > This *might* be workable. However, in general - a large part of the > > reason why I use FreeBSD is that the FreeBSD base system gives me > > most of what I want, in *one* well defined chunk, *without* having > > to install a zillion extra packages, and without umpteen different > > versions of config files and locations for the important information. > > > > So please don't destroy this. > > With the risk of sounding like a me-too-ist: "me too!" Since I made a bikeshed reference I don't want to continue arguing my point -- I've said my piece, and that's that. But I'm just one man, with one opinion (that IS in fact shared by others), but I hold high respect for others' views despite being different from my own. However, I want to make some things perfectly clear, because there's some misconceptions (IMHO), addressed below. I won't respond to this thread past this point. > I can see the point some have in wanting to run a version from ports > over running the base system one. This is doable in the current setup. > However the bundled versions of bind (and the other base system > packages) are rock stable and there for a reason. 1) In most scenarios (historically speaking), what gets updated quicker: base or ports? Answer: ports. For **security issues only**, the base system gets updated quickly. Of course, in some cases (depending on the software), this requires an **entire world rebuild**. Why not just rebuild only what's dependent upon what got fixed? "OpenSSL security hole fixed, gotta rebuild.... uh, world?" Yes, there are sometimes exceptions to this rule, but depending upon what the software is, world is usually what you have to resort to. 2) What has proper infrastructure for dependencies and tracking of installed files as part of a software package? Answer: ports. The base system has src/ObsoluteFiles.inc which has been stated *by developers* as "being regularly neglected" and "is a hack, not fully effective". This is what "make delete-old" and "make delete-old-libs" uses, and where WITHOUT_xxx comes into play. Ponder this for a while. 3) How often do you see people posting problems with key pieces of FreeBSD infrastructure (device support/reliability or storage-related subsystems), followed by a response from a developer stating "this has been fixed in -STABLE" or "can you try the code from HEAD?" Answer: often. What all this means: change is happening much more rapidly than in the past. The days of "I installed FreeBSD on a box and didn't touch it for 60,000 years" are long gone -- assuming you care about true reliability and security. > Following the "I want this slimmed down and moved to the ports/packages > section", further, you could argue that ls, dd, and basically most of > /usr/bin could go the same way. Yes, and it should be, IMHO. Have you ever looked in src/contrib? A lot of FreeBSD's software these days -- the stuff you've come to rely upon -- is in src/contrib. Let me know if you don't use any of the software in there. :-) > Giving FreeBSD the same "distribution nightmare" that some of the ... > other unix-like os'es have. Is this really where the users of the OS > want it to go? We'll end up spending more time updating tidbits of the > system now moved to packages, than actually using it. Nothing *forces* you to update a package/port. If you want to run some old crusty version of some software (maybe there's legitimate reason for it, maybe the newer stuff is buggy), you can do this with ports. You could do this with the base system being package-ised or port-ised like I describe as well. But you cannot easily do this with the base -- the instant you csup to update base (for something else), you've now updated everything. And it's been stated many times by developers that your supfiles should use src-all and NOT select src-xxx pieces -- because world/kernel WILL break during build. To this day there are still "I tried to build world but it didn't work" "Show us your supfile" "" reports coming in. > But why stop > there? We could do the same to the src/sys/dev subdirectories as > well... That probably should happen too, *especially* for the networking and storage subsystems, which are being constantly updated to fix bugs. Not just improvements, but downright bugs. Do I really need to point you to all the mails about bce(4), bge(4), re(4), em(4), fxp(4), msk(4), ata(4), ahci(4), ZFS, blah blah blah... Again, see my point above, re: how often people report bugs with maintainers of these pieces telling folks to update things. Welcome to 2010. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |