[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Re: Debian BSD.. cool idea



I recall waay back on Feb 12 when Dan Papasian wrote:

> It all comes down to this.  Use FreeBSD first, make suggestions next.
> 
> If suggestions are rejected, continue work on Debian/FreeBSD.

There's no reason to believe that my suggestions (all of them) would be
accepted, since they are personal preferences that apparently conflict
with the ideals of a greater part of the BSD community (see: FHS).

> The FHS is a load of crap.  There are plently of standards existing
> beforehand for the layout of the UNIX filesystem.. Linux, aiming to act
> exactly like a UNIX, should follow these, not set their own standards.

It is really kind of irrelevant what anyone else thinks of FHS, Linux is
_not_ Unix and is no longer even really aiming to be Unix. It is trying
to be enough of a clone of Unix that it can be used basically like one.
That said:

- It's totally opinion and preference how you'd like your system
organized, so I don't see how bashing the other way will help anything.

- The goal of the list is still Debian BSD (or opposition therein,
apparently), which given what people have said, would be Debian with a BSD
kernel. This implies Debian layout, which is not even Linux FHS; it's
Debian FHS. Debian FHS dictates that config files go in /etc, "vendor
provided" binaries and data go in /usr, and "admin provided" binaries and
data (and generally config) go in /usr/local. The /usr/local/var thing is
still a problem there of course since you wouldn't want stuff installed in
/usr/local to dump things into /var but I don't know how that's resolved.

> /usr/local/var is rarely occupied.. some ircds and whatnot use it.
> But, when there are non-essential logs/spools placed by a program that
> was installed by the user, they are free to use it.

I still think this is another case where /opt would make more sense.
/opt/var seems less contradictory.

On the other hand, I generally consider /usr/local and /usr to be totally
seperate spaces.

> I've never had problems updating my ports and packages.
> I've had to shuffle with apt-get a few times to get things to work sometimes.

I've had some troubles with both so I won't say that either is
particularly superior as far as updating and conflict handling. BSD's
system just doesn't tell you when something goes wrong, which I'd rather
hear about and be able to override if neccessary.

Ports are pretty cool though, I had the opportunity to use that system the
other day. Fortunately (for me currently =) in Debian there isn't much of
a need for ports since it's all been compiled for you anyway. Notable
exceptions are things like pine which have goofy license restrictions, and
of course new platforms.

> There are only a handful of the 3,071 ports/packages that out and out
> conflict with another.  And it is documented in the readme..

Which is ok unless you're working from the GUI.. =) But you've already
noted that suggestion.

> Less than ideal, yes, but it is being addressed in designing the 2nd-gen
> package system.  Debian can feel free to step in and relicense code/donate
> time to help make our package system better.  Everyone would be happier :)

Why? It wouldn't have anything to do with Debian then. If individual
people wanted to help that's cool but it still wouldn't make it Debian
even just to port apt / dpkg.

-- 
Once it hits the fan, the only rational choice is to sweep it up, package it,
and sell it as fertilizer.


Reply to: