tech-userlevel archive

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

Re: Filesystem Hierarchy Standard (FHS) and NetBSD



Hi,

> > I don't see how a layout standard can cover both the BSD and Linux
> > worlds at the same time, unless it has variants.  (And then there's
> > Solaris and others.)
> 
> We have an "annex" system, which supposedly splits out things that are 
> specific to a particular OS.  There's only one annex, though (Linux), 
> and it seems that a lot of Linux-isms found their way into the main 
> document.
> 
> It looks like the idea of describing all UNIXes was a goal more than a 
> fact.  Given how easy it's been to find them with quick looks on the BSD 
> lists, it seems that no one took the bait.
as I said, not only from the perspective of a BSD-user but even for the sake
of the FHS, I think, one should make a Linux-specific FHS and declare is at
such (as Thor Lancelot Simon pointed out). Finding the least common would end
up in a very small base standard, even without many of the standard-paths
used (e.g /usr/local).
You would have many annexes for specific operating systems, making the
standard large with many references and unreadable.
What I like about the current FHS is: You can just read it, without looking
at references or having to remember much.
On the other hand, everything but Linux is more closed and tends to change
things faster than Linux does. They would evolve faster than this standard.

I don't see any good point in making a generic standard, documenting
differences could be a nice hobby, but a plaintext file is imho not suitable
for showing dependencies.
As was pointed out, other OSes do not really care for the FHS as they have a
more direct and conservative development which is on the one hand slower, on
the other hand faster than it. Linux should have its own standard, making
itself in its world more compatible across distributions instead of having a
standard nobody likes (and uses?) because it is too large und unspecific.

> > What would be really useful is a documented notion that all upstream
> > packaegs should be configurable (at ./configure or equivalent time) to
> > put various bits in various places, hopefully using standard directives,
> > so that they can easily be configured to follow FHS on Linux or hier or
> > hier_pkgsrc on BSDs.  As a packager, the biggest problem related to this
> > I run into is programs with hardcoded Linux assumptions (although many
> > programs that use autoconf are easy to configure).
> 
> I actually strongly agree with this.  Even if you limit yourself to 
> Linux, there are changes and features that exist on one distribution but 
> not another.
> 
> Do you maintain any documentation of "common Linux-isms" that hinder 
> porting to NetBSD?  I suspect that the list would be good developer 
> documentation for more reasons than just porting.
In my opinion, this is neither undocumented nor unknown. Good practices for
programming are easy to find, even the single coding guidelines for NetBSD
aim at portability.

A problem I discovered lately is that Linux-(desktop-)developers
intentionally break portage. Gnome, systemd, xfce, more and more projects are
coding explicitly only for Linux. Whether they say it's easier, better, or
that they don't have the manpower to make portable code - the result stays the
same, it's simply ignorance of portability. I'm specially referring here to a
talk I heard about the Gnome 3.0-release with the conclusion "We won't code
for anything else but Linux because it is the future and the best one."
Or:
http://lwn.net/Articles/429597/
http://lwn.net/Articles/432914/

Anyway, this is clearly off-topic, but you have to consider this for
understanding how the BSD-community looks at Linux.


Regards, Julian

Attachment: signature.asc
Description: PGP signature



Home | Main Index | Thread Index | Old Index