BIND REPLACE_BASE option

[Royce Williams]

On Mon, Jan 12, 2015 at 8:24 AM, Chris H <bsd-lists at bsdforge.com> wrote:
> On Mon, 12 Jan 2015 07:55:45 -0900 Royce Williams <royce at tycho.org> wrote
>
>> On Mon, Jan 12, 2015 at 7:38 AM, Chris H <bsd-lists at bsdforge.com> wrote:
>>
>> > As to the "sysadmin gap" a look to
>> > the ports tree seems to indicate quite a volume of "sysadmin"
>> > related ports. Are some missing?
>>
>> To the contrary -- there are too many.
>>
>> A good project would be to survey which ones people actually use, and
>> why -- and then bring their best features into base.
> I agree something like thishas value. But obtaining access to the
> usage matrix is the key.

A fair point.  Instrumenting the OS now to make this usage possible
later would be a good idea.

IIRC, PC-BSD integrated BSDstats a while back.  If FreeBSD did the
same, and prompted at install for "Would you like to help the project
by reporting anonymous hardware and software inventory information?",
we could start to build that matrix.

>> This would be difficult to do as a independent skunkworks project, and
>> would be better suited as a high-level, Foundation-sponsored one.
> see above.
>>
>> (For example, in the Debian ecosystem, for most people, there is no
>> reason to use something other than apt-get, because it does what it
>> should and does it well. Every time I upgrade a port, I have to study
>> /usr/ports/UPDATING, read multiple mailing lists, and hold my breath.
>> I cannot remember the last time I worried about running apt-get.
>> Arguments about flexibility and diversity ecosystem don't hold up well
>> when the basics fail on a regular basis.)

> Here is where we will clash; I've been riding *BSD for over 20yrs.
> It's *biggest* asset has been in it's flexibility -- it wasn't another
> Linux "dist", that required me to essentially become a "clone" of
> every other Linux install. The Ports system, and /src allowed one to
> tailor my build/install to meet *my* needs. I wasn't required, in fact
> I was *encouraged*, to have a unique system. Frankly the new pkg(8)
> *requirement* was a complete 180 on this philosophy. It's implementation
> was also flawed in many respects (which speaks to your point). I have no
> objection to pkg(8), per se; But it *should* have been optional, it
> *should* have been better (longer) tested, *before* pushed into the
> ecosystem, and should *not* have been implemented with a backend with
> single-point-of-failue (sqlite3(1). Honestly; why did pkg(8) have to
> be *required*? Is FreeBSD simply hoping to become a new "distro"?
> But, given it's there, and how it's there. You have/bring up some valid,
> points; it *is* a bit of a game of roulette. I *too* get a knot in my
> stomach even at the *thought* of an upgrade. Sure there are plenty of
> choices in an upgrade path/implementation. But, as it sits now, I'm
> not sure I can say it's gotten any easier, or "trouble free", as a
> result of pkg(8).

I basically agree.  pkg(8)'s heart is in the right place, but it was
not baked long enough.

I like the idea of being flexible as a proving ground, and then
selecting best of breed as the baseline.

Royce