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 ku...@gentoo.org 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
