Results of BIND RFC

Jeremy Chadwick freebsd at jdc.parodius.com
Fri Apr 2 12:15:28 UTC 2010


On Fri, Apr 02, 2010 at 12:44:55PM +0200, Svein Skogen (Listmail Account) wrote:
> On 02.04.2010 12:28, sthaug at 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"  "<random src-xxx stuff
removed which the user felt they didn't need>"  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 at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |



More information about the freebsd-stable mailing list