Re: [gentoo-dev] FHS or not (WAS: [gentoo-project] Call for agenda items - Council meeting 2014-03-11)

[Joshua Kinard]

On 02/28/2014 7:47 PM, William Hubbs wrote:
> On Sat, Mar 01, 2014 at 12:24:02AM +0000, David Leverton wrote:
>> William Hubbs wrote:
>>> And I would argue that the maintenance cost of having separate /usr in a
>>> general sense is much higher than the benefit it provides.
>>
>> That's a legitimate point (not that I necessarily agree or disagree as
>> I'm not the one who's tried to make it work) - perhaps I should have
>> acknowledged that it's still a trade-off.  I'm just trying to get rid of
>> the meme that whatever benefits do exist somehow don't count because
>> they weren't planned in the original Unix design.
>
> Actually we are digressing heavily (I'm guilty too), the original point
> of this thread was about the fhs and how tightly we are supposed to
> follow it.
>
> Patrick thinks that all configuration files belong in /etc, and what has
> happened is, some packages are placing default configuration
> files in /lib or /usr/lib and allowing them to be overridden by files
> with the exact same names and paths in /etc. His argument is that only
> libraries belong in /lib or /usr/lib.
>
> I disagree with this based on understanding how the config system in
> these packages works. Also, I don't think a distro should do this type of
> patching if the patches are not accepted upstream.

Digressing a little myself, but trying to remain on point, the _only_ reason
I went with a split-/usr setup many years ago is because, back in the early
2000's, BOTH Debian's Security Handbook AND Gentoo's Security Handbook
recommended it as an option to enhance system security should all your other
defenses get compromised and an attacker gets onto the filesystem.  Does it
completely and utterly stop all lateral movement?  Nope.  Probably takes a
seasoned attacker all of 2-3mins to get around it.

That setup has run great for years.  I rarely re-install entire OSes, too,
preferring to maintain and upgrade them.  I.e., one of my Windows installs
is over five years old, having started w/ Vista SP1 and now it's on Win7
SP1.  Most people reinstall Windows twice a year because it can become
cluttered up so quickly.

So when that Freedesktop.org page came out a few years ago and suddenly
declared that split-/usr was broken, I just felt snubbed by it.  I had
7-year old installs that booted just fine.  Who were these freedesktop.org
people that were dictating that my particular setup was suddenly broken?
Call it a case of having my "geek pride" insulted.  Like hell I was going to
change.

But, you know, in reality, they had a point.  Original System V UNIX did a
lot of weird things that probably made sense decades ago, but don't now.
You find this virtually endemic across a lot of OSes, too:

  - Windows is happy to let you dribble non-OS related files all over C:
(which makes backups and OS re-installs a lot of fun) -- this was fine in
Win95/Win98, but became more of an issue in XP and up.  Nowadays, people
usually install the OS to C: and put games/programs on a separate drive
entirely.

  - NetWare seems to roll dice when installing things into the SYS: volume.
 Some configs are in SYS:\SYSTEM\ETC, Apache lives in SYS:\APACHE2\, and a
lot of other bits are encoded into eDirectory attributes (DNS/DHCP configs).

  - The *BSDs make heavy use of /usr/local for things that can confuse
non-BSD users (at first).  Even the install locations of Ports varies across
the BSDs (FBSD has /usr/ports, DF/BSD has /usr/dports, NBSD has pkgsrc, etc).



Anyways, back on point, FHS is more-or-less deprecated.  It was reasonable
when Linux had a small ecosystem.  Now, Linux has a *huge* ecosystem that it
operates in.  Everything from small, embedded devices to multi-node
supercomputing clusters, to servers and desktops.  FHS does doesn't scale
well to all of those configurations.  Android pretty much ignores FHS, from
what I can tell.

Options really are boiled down to these three:

1. Continue to support FHS as much as possible, including patching upstream
packages when they violate FHS.

2. Ignore FHS entirely and let upstream packages do what they want, within
reason (i.e., some patching may be needed depending on if one was running
Gentoo/Linux or Gentoo/FreeBSD).

3. Develop our own, Gentoo-specific variant of FHS that we use and which
suits the particulars of our distribution in a way that we feel is sensible
(my choice).  Packages are patched as appropriate, after discussion/debate.
 For all we know, the way an upstream package does something by default
might be worth integrating into our FHS design.

Further on point #3, we'd have to probably develop a high-level,
kernel-agnostic layout that can be modified by kernel-specific differences.
 I.e., Gentoo/Linux is going to do things one way while Gentoo/FreeBSD is
going to do it a different way.  Ditto for Hardened or Embedded stuff.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@g.o
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic