On Mon, Sep 30, 2013 at 10:15 AM, Daniel Campbell <li...@sporkbox.us> wrote: > On 09/29/2013 09:05 PM, Mark David Dumlao wrote: >> On Mon, Sep 30, 2013 at 9:50 AM, Daniel Campbell <li...@sporkbox.us> wrote: >>> Anyway, I'm not in favor of FHS _per se_, but it sounds pretty >>> reasonable to have some semblance of order among where different parts >>> of a system go. Shoving everything into /usr and symlinking everything >>> else seems like a stop-gap or good-enough solution that came about due >>> to ignoring the existing standard (FHS) and refusing to try to change >>> it. I could be wrong, though. My point is I'm not dogmatic about it; I >>> just think that if the FOSS community were willing, a better solution >>> could be crafted. >> >> It's true that it's nice to have a semblance of order where different parts >> go. >> But "all libraries and binaries in /usr" is also a semblance of order. You >> don't >> separate stuff for the sake of separating stuff. You separate them because >> you >> have a good reason to separate them. It turns out that there isn't a good >> reason >> to separate them, and that there's no way to predictably separate them. >> >> Mushing them together isn't just a stop-gap or good-enough solution. The >> idea of keeping system-critical separate from non-critical was not >> maintainable >> in the long run to begin with. >> > If separating them was unmaintainable, why bother with /bin and /sbin at > all, then? If /usr is essentially replacing what / was originally, it's > hard to take any filesystem standard seriously and we return to chaos.
The people that write software and systems and standards, etc are human. Give them a break. They did the best they could. > What was /usr's original purpose? /usr was originally the home directory. Programs were moved there because Unix didn't fit into a single disk. http://lists.busybox.net/pipermail/busybox/2010-December/074114.html > If the change to > /usr was brought about because the FHS has holes in it, why not draft a > new FHS completely from the ground up? At the end of the day, a standard is just a doc that people don't read. Part of the reason why FHS was "successful" was because it was more than just a prescriptive standard. Most of the rules in it had rationales written based on existing practices. In other words, writing a new FHS isn't going to do a damned thing to fix the problems people have had so far, and there's the likelihood that people won't follow it anyways. Heck, just look at /usr/portage. Portage, or at least the distfiles, in no way, shape, or form, belongs in /usr. It's just there because that's how it was done before. THE way to rewrite FHS is to change existing practice. And if the big distros agree on it, the existing practice gets codified into a standard. -- This email is: [ ] actionable [x] fyi [ ] social Response needed: [ ] yes [ ] up to you [x] no Time-sensitive: [ ] immediate [ ] soon [x] none
