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