5 ms·

This part seems fairly editorial: >Debian Policy still cites the FHS, even though the FHS has gone unmaintained for more than a decade. What ongoing maintenan

This part seems fairly editorial: >Debian Policy still cites the FHS, even though the FHS has gone unmaintained for more than a decade. What ongoing maintenance would a file system standard require? A successful standard of that type would have to remain static unless there was a serious issue to address. Regular changes are what the standard was intended to combat in the first place. >The specification was not so much finished as abandoned after FHS 3.0 was released... OK. >...though there is a slow-moving effort to revive and revise the standard as FHS 4.0, it has not yet produced any results. So it is not abandoned then. A slow moving process is exactly what you would want for the maintenance of a file system standard. >Meanwhile, in the absence of a current standard, systemd has spun off its file-hierarchy documentation to the Linux Userspace API (UAPI) Group as a specification. LWN covered that development in August, related to Fedora's search for an FHS successor. Ah. Systemd/Fedora want a standard that they can directly control without interference from others.

Hendrikto 1y ago
Counterpoint: Modern distro’s needs have evolved past the FHS in some cases, and everybody deviates from it slightly but incompatibly. A standard does no good if it does not reflect reality. I think it is a worthwhile effort to try to bring it back in line with actual real world usage.
- cwillu 1y ago
  An interesting take in the context of systemd's deviation from it being the source of bugs because of real world usage that conflicts with systemd's changes.
- sterlind 1y ago
  laughs in NixOS it's remarkable to me that NixOS manages to run so well despite breaking the FHS so thoroughly. and not just in superficial ways like not calling it /bin, I mean forsaking dynamic linking (hence /var/lib and /usr/lib), keeping man pages, resources and config bundled into the same derivation as the binary sometimes, and occasionally hacking up binary blobs to rewrite rpaths. on the other hand, there's a place for legacy distros too.
meltyness 1y ago
Well, it probably depends on which software's concern will be implementing a policy to prevent users from having permission to fill critical directories and prevent the system from operating normally, which is discussed in the article. Which is also a coordination problem because the most common user of disk is software itself, I think. FHS seems to specifically imbue the user with the responsibility and consequences of filling up the disk.
rascul 1y ago
The /usr merge is an example of something that a modern FHS might reflect.
- curt15 1y ago
  OS X doesn't have a merged /usr. On my Mac I see /bin as a separate directory, not a symlink into `/usr`. Does Linux have a compelling reason that OS X lacks?
  - mariusor 1y ago
    The reason for having a separate /usr has long slid into obsolescence. Our storage is no longer constrained to require us to mount a remote partition which holds most of the binaries and other sundry required to boot a distribution.
    - tremon 1y ago
      In other words, the strongest argument for usrmerge is that there is no compelling argument against it?
      - mariusor 1y ago
        I think the current strongest argument against it is that systemd complains when /usr is on a separate partition[1], and what its devs have weighed in on the matter[2]. [1] https://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/ https://freedesktop.org/wiki/Software/systemd/separate-usr-i... [2] https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ https://www.freedesktop.org/wiki/Software/systemd/TheCaseFor...
        amiga386 1y ago
        sysvinit had no problem being told to mount /usr as soon as network was available, and if you set up an init script to run before /usr was available, but the script needed /usr, that was your own fault. systemd relies on things in /usr being available, including to decide which scripts to run, and mounting /usr would be one of those scripts, so it has a chicken-and-egg problem. But ah, it doesn't! Instead the world needs to make sure /usr is mounted before systemd even gets started, so systemd doesn't have to fix its bug. Personally, I don't mind /usr/bin merging with /bin, the benefit I can see is no more squabbling over whether something should be in /bin or not (i.e. is this tool needed to boot the system, or not?)
blueflow 1y ago
I'm very happy that the "independent standard" facade of the UAPI group fell, and its actions are now directly attributed to systemd's interests.
jzb 1y ago
Author here: It was abandoned. I linked to one of the former maintainers who said as much. The current effort is by a few people who asked the LF to take out over, and have (so far) done little after an initial flurry of activity. That, too, is covered in the other article I wrote about the FHS recently. Prior to the group who started an update effort, it had not been touched in about a decade. That’s not slow-moving: that’s abandoned.
- upofadown 1y ago
  The FHS ultimately belongs to the users collectively, not those maintaining it. I am old enough to remember the horror that existed before the influence of the FHS. It exists in the fact that it is to some extent respected, not because there is a file somewhere that says it is the FHS standard. If you want changes, then sure, do the politics required to develop support for those changes. You can't just declare a new standard and then do whatever you want. Developers have this thing where they will think of a standard as a specification. Instead it is a statement of political will. Saying that a standard is "abandoned" due to lack of "maintenance" seems like an example of thinking of a standard as the instantation of a specification; an actual program.
  - dijit 1y ago
    I know it's not the same, but imagine thinking a law is not longer meant to be followed because it hasn't been updated in 10 years.
    - Arubis 1y ago
      I agree--given your contraints of law and 10 years. But what about a law that hasn't been updated for 150 years? There's plenty of those that we regularly ignore. What's the timeline for software?
      - dijit 1y ago
        There is no automatic, fixed timeframe after which a law simply stops being followed because it hasn't been updated or looked at; and remember, we're still applying the FHS, it's in active use even if it's not updated. Laws remain in force until they are formally: * Repealed (abolished) by the relevant legislative body (Parliament, Congress, etc.). * Struck down by a court as unconstitutional or otherwise invalid. A 150 year "delete" timer would genuinely undermine the foundation of the legal system. Lawyers, judges, and businesses rely on the continuity of core laws (e.g., contract, property, and tax law). If a 150-year-old property law suddenly lapsed, it could instantly void millions of land titles and commercial contracts...
palmotea 1y ago
>> Debian Policy still cites the FHS, even though the FHS has gone unmaintained for more than a decade. > What ongoing maintenance would a file system standard require? A successful standard of that type would have to remain static unless there was a serious issue to address. Regular changes are what the standard was intended to combat in the first place. It's 2025, anything that wants to be considered modern (and everything should want that), needs to be undergoing constant change and delivering regular "improvements." >>...though there is a slow-moving effort to revive and revise the standard as FHS 4.0, it has not yet produced any results. > So it is not abandoned then. A slow moving process is exactly what you would want for the maintenance of a file system standard. The FHS people to get off their butts. There's no excuse for that pace now that we have such well-developed AI assistants. They should be pushing quarterly updates at a minimum, and a breaking change at least every year or two. It's been obvious for decades that "etc" is in urgent need of renaming to "config", "home" to "user", and "usr" to "Program Files" to keep up with modern UX trends.
- cweagans 1y ago
  I genuinely can't tell if this is satire.
  - palmotea 1y ago
    I thought it would have been obvious by the "Program Files" at the end :). Anyway, Linux community as a whole has an antiquated development process, and needs to modernize and follow the best practices of an industry-leading trend-setter, like MS Teams.
    - hulitu 1y ago
      The X11 people are trying this hard. I'm really curious how Wayland will evolve but, the history of GTK and QT does not give me much hope.
    - prerok 1y ago
      Ok, so it's only half satire, or is this reply also a satire? I mean, MS Teams, really?
paulddraper 1y ago
A more neutral phrasing would be. > Debian Policy still cites the FHS, and FHS has remained static for over a decade.
dathinab 1y ago
> What ongoing maintenance would a file system standard require? adaption to _a lot_ of subtle changes to requirements - very different security related requirements today - very different performance related requirements/characteristics - very different need for various edge cases and lastly adapt based on what turned out to work well and what didn't so some examples not already mentioned in the article - /boot -- dead or at least differently used if you use efistub booting - /etc/X11 -- half dead on wayland - /etc/xml, /etc/sgml -- dead, should IMHO never have existed - also why was /etc/{X11,xml,sgml} every explicit part of the standard when the spec for `/etc` already implies them as long as e.g X11 is used ?? - `/media` -- dead/half dead depending on distro, replaced by `/run/media/{username}/{mount}` - `/sbin` -- "controversial"; frequent reoccurring discussions that it isn't needed anymore, didn't work out as intended etc. It was useful for very old style thin clients as `/sbin` was in storage but `/bin` was mounted. And there are still some edge cases where it can makes sense today but most fall under "workaround for a different kind of problem which is better fixed properly". - `/tmp` -- "controversial", long history of security issues, `/tmp` dir per program fixes the security issues (e.g. systemd service PrivateTmp option) but requires having a concept of "programs" instead of just "running processes" (e.g. by systemd services or flatpack programs). Also `tmpfiles.d` can help here. - `/usr/libexec` -- dead, nice idea but introduces unneeded complexity and can be very misleading in combination swith suid and similar - `/usr/sbin` see `/sbin` - `/usr/share/{color,dict,man,misc,ppd,sgml,xml}` -- should never have been in the standard they are implied by the definition of `/usr/share`; at least sqml,xml are dead. dict was for spell check/auto completion, except that neither works anymore like dict expects - `/var/account` -- to specific to some subset of partially dead programs, shouldn't be in the standard - `/var/crash` -- distro specific mess - `/var/games` -- basically dead/security mess, I mean 99% of games today are user per-user installed (e.g. Steam) and even for such which are packed any variable download data is per user, making it shared creates a permission/security mess - `/var/lock` -- as mentioned there are better technical solutions by now, e.g. using `flock` instead of "presence of file" and some other techniques. Tend to also avoid issues of crashed programs not cleaning up "lock files" leading to dead locks and needing manual intervention. - `/var/mail` assumes a quite outdated form of managing mail which is quite specific to the mailing program, as it's very program specific it IMHO shouldn't be in the standard - various legacy program specific, non "generic" file system requirements e.g. that `/usr/lib/sendmail` must exist and be a link to a sendmail compatible program and similar. also missing parts: - `/run/user/{uid}` - `/var/run/user/{uid}` - `/proc` - `/sys` - user side versions (e.g. from the XDG spec which is also somewhat in a zombie state from my personal experience with it , e.g. .config, .local/{bin,share}) - references to light weight sandboxing, e.g. per-program /temp etc. - factory reset stuff (`/usr/share/factory`) needed for having a uniform way for devices sold with Linux and device specific distro customization(e.g. steam deck) so yes, it's quite outdated

Hendrikto 1y ago

Counterpoint: Modern distro’s needs have evolved past the FHS in some cases, and everybody deviates from it slightly but incompatibly. A standard does no good if it does not reflect reality. I think it is a worthwhile effort to try to bring it back in line with actual real world usage.

cwillu 1y ago
An interesting take in the context of systemd's deviation from it being the source of bugs because of real world usage that conflicts with systemd's changes.
sterlind 1y ago
laughs in NixOS it's remarkable to me that NixOS manages to run so well despite breaking the FHS so thoroughly. and not just in superficial ways like not calling it /bin, I mean forsaking dynamic linking (hence /var/lib and /usr/lib), keeping man pages, resources and config bundled into the same derivation as the binary sometimes, and occasionally hacking up binary blobs to rewrite rpaths. on the other hand, there's a place for legacy distros too.

meltyness 1y ago

Well, it probably depends on which software's concern will be implementing a policy to prevent users from having permission to fill critical directories and prevent the system from operating normally, which is discussed in the article. Which is also a coordination problem because the most common user of disk is software itself, I think. FHS seems to specifically imbue the user with the responsibility and consequences of filling up the disk.

rascul 1y ago

The /usr merge is an example of something that a modern FHS might reflect.

curt15 1y ago
OS X doesn't have a merged /usr. On my Mac I see /bin as a separate directory, not a symlink into `/usr`. Does Linux have a compelling reason that OS X lacks?
- mariusor 1y ago
  The reason for having a separate /usr has long slid into obsolescence. Our storage is no longer constrained to require us to mount a remote partition which holds most of the binaries and other sundry required to boot a distribution.
  - tremon 1y ago
    In other words, the strongest argument for usrmerge is that there is no compelling argument against it?
    - mariusor 1y ago
      I think the current strongest argument against it is that systemd complains when /usr is on a separate partition[1], and what its devs have weighed in on the matter[2]. [1] https://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/ https://freedesktop.org/wiki/Software/systemd/separate-usr-i... [2] https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ https://www.freedesktop.org/wiki/Software/systemd/TheCaseFor...
      - amiga386 1y ago
        sysvinit had no problem being told to mount /usr as soon as network was available, and if you set up an init script to run before /usr was available, but the script needed /usr, that was your own fault. systemd relies on things in /usr being available, including to decide which scripts to run, and mounting /usr would be one of those scripts, so it has a chicken-and-egg problem. But ah, it doesn't! Instead the world needs to make sure /usr is mounted before systemd even gets started, so systemd doesn't have to fix its bug. Personally, I don't mind /usr/bin merging with /bin, the benefit I can see is no more squabbling over whether something should be in /bin or not (i.e. is this tool needed to boot the system, or not?)

blueflow 1y ago

I'm very happy that the "independent standard" facade of the UAPI group fell, and its actions are now directly attributed to systemd's interests.

jzb 1y ago

Author here: It was abandoned. I linked to one of the former maintainers who said as much. The current effort is by a few people who asked the LF to take out over, and have (so far) done little after an initial flurry of activity. That, too, is covered in the other article I wrote about the FHS recently. Prior to the group who started an update effort, it had not been touched in about a decade. That’s not slow-moving: that’s abandoned.

upofadown 1y ago
The FHS ultimately belongs to the users collectively, not those maintaining it. I am old enough to remember the horror that existed before the influence of the FHS. It exists in the fact that it is to some extent respected, not because there is a file somewhere that says it is the FHS standard. If you want changes, then sure, do the politics required to develop support for those changes. You can't just declare a new standard and then do whatever you want. Developers have this thing where they will think of a standard as a specification. Instead it is a statement of political will. Saying that a standard is "abandoned" due to lack of "maintenance" seems like an example of thinking of a standard as the instantation of a specification; an actual program.
- dijit 1y ago
  I know it's not the same, but imagine thinking a law is not longer meant to be followed because it hasn't been updated in 10 years.
  - Arubis 1y ago
    I agree--given your contraints of law and 10 years. But what about a law that hasn't been updated for 150 years? There's plenty of those that we regularly ignore. What's the timeline for software?
    - dijit 1y ago
      There is no automatic, fixed timeframe after which a law simply stops being followed because it hasn't been updated or looked at; and remember, we're still applying the FHS, it's in active use even if it's not updated. Laws remain in force until they are formally: * Repealed (abolished) by the relevant legislative body (Parliament, Congress, etc.). * Struck down by a court as unconstitutional or otherwise invalid. A 150 year "delete" timer would genuinely undermine the foundation of the legal system. Lawyers, judges, and businesses rely on the continuity of core laws (e.g., contract, property, and tax law). If a 150-year-old property law suddenly lapsed, it could instantly void millions of land titles and commercial contracts...

palmotea 1y ago

>> Debian Policy still cites the FHS, even though the FHS has gone unmaintained for more than a decade. > What ongoing maintenance would a file system standard require? A successful standard of that type would have to remain static unless there was a serious issue to address. Regular changes are what the standard was intended to combat in the first place. It's 2025, anything that wants to be considered modern (and everything should want that), needs to be undergoing constant change and delivering regular "improvements." >>...though there is a slow-moving effort to revive and revise the standard as FHS 4.0, it has not yet produced any results. > So it is not abandoned then. A slow moving process is exactly what you would want for the maintenance of a file system standard. The FHS people to get off their butts. There's no excuse for that pace now that we have such well-developed AI assistants. They should be pushing quarterly updates at a minimum, and a breaking change at least every year or two. It's been obvious for decades that "etc" is in urgent need of renaming to "config", "home" to "user", and "usr" to "Program Files" to keep up with modern UX trends.

cweagans 1y ago
I genuinely can't tell if this is satire.
- palmotea 1y ago
  I thought it would have been obvious by the "Program Files" at the end :). Anyway, Linux community as a whole has an antiquated development process, and needs to modernize and follow the best practices of an industry-leading trend-setter, like MS Teams.
  - hulitu 1y ago
    The X11 people are trying this hard. I'm really curious how Wayland will evolve but, the history of GTK and QT does not give me much hope.
  - prerok 1y ago
    Ok, so it's only half satire, or is this reply also a satire? I mean, MS Teams, really?

paulddraper 1y ago

A more neutral phrasing would be. > Debian Policy still cites the FHS, and FHS has remained static for over a decade.

dathinab 1y ago

> What ongoing maintenance would a file system standard require? adaption to _a lot_ of subtle changes to requirements - very different security related requirements today - very different performance related requirements/characteristics - very different need for various edge cases and lastly adapt based on what turned out to work well and what didn't so some examples not already mentioned in the article - /boot -- dead or at least differently used if you use efistub booting - /etc/X11 -- half dead on wayland - /etc/xml, /etc/sgml -- dead, should IMHO never have existed - also why was /etc/{X11,xml,sgml} every explicit part of the standard when the spec for `/etc` already implies them as long as e.g X11 is used ?? - `/media` -- dead/half dead depending on distro, replaced by `/run/media/{username}/{mount}` - `/sbin` -- "controversial"; frequent reoccurring discussions that it isn't needed anymore, didn't work out as intended etc. It was useful for very old style thin clients as `/sbin` was in storage but `/bin` was mounted. And there are still some edge cases where it can makes sense today but most fall under "workaround for a different kind of problem which is better fixed properly". - `/tmp` -- "controversial", long history of security issues, `/tmp` dir per program fixes the security issues (e.g. systemd service PrivateTmp option) but requires having a concept of "programs" instead of just "running processes" (e.g. by systemd services or flatpack programs). Also `tmpfiles.d` can help here. - `/usr/libexec` -- dead, nice idea but introduces unneeded complexity and can be very misleading in combination swith suid and similar - `/usr/sbin` see `/sbin` - `/usr/share/{color,dict,man,misc,ppd,sgml,xml}` -- should never have been in the standard they are implied by the definition of `/usr/share`; at least sqml,xml are dead. dict was for spell check/auto completion, except that neither works anymore like dict expects - `/var/account` -- to specific to some subset of partially dead programs, shouldn't be in the standard - `/var/crash` -- distro specific mess - `/var/games` -- basically dead/security mess, I mean 99% of games today are user per-user installed (e.g. Steam) and even for such which are packed any variable download data is per user, making it shared creates a permission/security mess - `/var/lock` -- as mentioned there are better technical solutions by now, e.g. using `flock` instead of "presence of file" and some other techniques. Tend to also avoid issues of crashed programs not cleaning up "lock files" leading to dead locks and needing manual intervention. - `/var/mail` assumes a quite outdated form of managing mail which is quite specific to the mailing program, as it's very program specific it IMHO shouldn't be in the standard - various legacy program specific, non "generic" file system requirements e.g. that `/usr/lib/sendmail` must exist and be a link to a sendmail compatible program and similar. also missing parts: - `/run/user/{uid}` - `/var/run/user/{uid}` - `/proc` - `/sys` - user side versions (e.g. from the XDG spec which is also somewhat in a zombie state from my personal experience with it , e.g. .config, .local/{bin,share}) - references to light weight sandboxing, e.g. per-program /temp etc. - factory reset stuff (`/usr/share/factory`) needed for having a uniform way for devices sold with Linux and device specific distro customization(e.g. steam deck) so yes, it's quite outdated