Alternative proposals for FHS

Posted by MontyCLT@reddit | linux | View on Reddit | 32 comments

I don't like FHS. I won't go into a critique. I think most people here already know the historical baggage and inconsistencies it has.

I want to run a thought experiment: what would a filesystem hierarchy look like if we designed it today from scratch?

Proposal

This is not a serious proposal to replace FHS. I'm fully aware how unrealistic that would be due to compatibility and the ecosystem.

It's just a thought experiment about what a more semantically consistent hierarchy might look like. Maybe we could build a proposal together and try in an experimental distro.

This is my proposal:

/
├── system/
│   ├── boot/
│   ├── kernel/
│   ├── bin/
│   ├── lib/
│   ├── state/
│   ├── temp/
│   ├── runtime/
│   │   ├── dev/
│   │   ├── proc/
│   │   ├── sockets/
│   │   └── sys/
│   └── platform/
│       ├── arch/
│       └── manjaro/
├── apps/
├── config/
├── data/
├── volumes/
└── users/
    └── <user>/
        ├── .config/
        └── .data/

Design ideas

1. Reduce root complexity

The root directory should contain as few top-level directories as possible, each with a clear and distinct purpose.

2. Make the structure obvious at a glance

The goal is to make the structure easy to understand just by looking at it, avoiding historical clutter and overlapping responsibilities.

Directory structure

1. Top-level directories

/system → system artifacts
/config → global configuration (replacement of /etc)
/apps → installed software, usually from the administrator (replacement of /opt)
/data → data used by services (e.g. what would be /var/www or /var/mail)
/users → users' personal data
/volumes → mounted external storage (USB, disks, etc.)

2. System directories

boot/ → boot artifacts (e.g. ESP contents)
kernel/ → kernel, drivers and modules
bin/ → fundamental executables, such as GNU command-line tools; other executable programs provided by the distro or a package should be in /system/platform or /apps
lib/ → shared libraries and runtime dependencies
state/ → persistent mutable system state (logs, internal DBs, caches…)
temp/ → temporary files (can be deleted freely)
runtime/ → ephemeral runtime interfaces and data (sockets, pid files, /dev, /proc, /sys)

Here, I have a doubt: should /system/kernel exists or the kernel should be in /system/boot? I'm not sure.

3. /system/state vs /data

The difference is who owns the data:

/system/state → internal system state (implementation detail)
/data → application/service data (real data with meaning outside the system)

A simple rule:

If deleting it breaks the system → /system/state
If deleting it loses business data → /data

For example, an SQL database used by the package system should be in /system/state while a SQL database with my customers should be in /data.

4. Distro-specific space

/system/platform/<name>/

Reserved for implementation details of the distro. A system may contain multiple distro directory for tools added by a derived distro.

For example:

/system/platform/arch/ → pacman, sync dbs, hooks…
/system/platform/manjaro/ → tools added by a derived distro

This allows layering instead of forcing everything into a single "distro identity".

5. Minimal rules for user directories

users/<user>
├── .config/
└── .data/

Only two conventions are enforced:

.config/ → per-user configuration
.data/ → per-user application data (replaces current /home/<user>/.local/)

Everything else is up to the user.

I'm curious how others would approach this:

What feels wrong here?
What would you change?
What would your "from scratch" layout look like?

[-]

Morphized@reddit

Personally I would prefer it if the structure were user (and pseudo-user) focused, where each user gets a directory in root (or if it's a service, its parent user's home). That would make it much easier to create, deploy, and integrate containers/isolation/modules, because you could just overlay the base system onto your home directory and chroot in.

[-]

mina86ng@reddit

The root directory should contain as few top-level directories as possible

Why? I think it should have exactly 70 directories for each ASCII letter, digit and +, ,, -, ., =, @, ^, ~ characters. All directories should start with a unique character and most-commonly used ones should start with a lower-case letter.

I’d rather write >/dev/null than >/system/runtime/dev/null whenever I want to discard output of a command.

config, apps, data and volumes are just renames of etc, opt, srv and media so I don’t really care though if I had to choose, I prefer the shorter names.

In what way is temp a system artifact?

state/ → persistent mutable system state (logs, internal DBs, caches…)

I don’t understand what internal DBs are and don’t think logs represent state. Logs represent history, not state.

Distro-specific space

What exactly is a system and what is a distro?

What would your "from scratch" layout look like?

Don’t really want to think through it too much, but I’d start with categorising data based on its characteristics: * Lifetime: ephemeral (deleted on each reboot), rebuildable (can be deleted and software is capable of recreating it, think caches) and permanent (must stay). * Mutability: read-only (never changes outside of system update) or mutable. * Arch-dependence: i.e. platform-independent files vs. files specific to given architecture. * Type of data: binaries, libraries, assets. * Ownership: system (whatever comes with the distribution), administrator (whatever administrator installs system-wide on top of software from the distribution) and user.

Each should have its own directory with additional entries for things which don’t fit so neatly (e.g. /media and /mnt) and maybe also often-used directories (e.g. /dev)

[-]

MontyCLT@reddit (OP)

Why (The root directory should contain as few top-level directories as possible)?

Due to mental exhaustion when lsing the root directory. I want to see a few directories and understand their meaning at a glance.

I think it should have exactly 70 directories for each ASCII letter, digit and +, ,, -, ., =, @, ^(,) \~ characters. All directories should start with a unique character and most-commonly used ones should start with a lower-case letter.

Is it a joke?

I'd rather write /dev/null than /system/runtime/dev/null whenever I want to discard output of a command.

I agree. Writing a long path is tedious. I'm not sure how to solve it. It could be a symlink from /system/runtime/dev/null to /dev/null (or even to /null) and hide it with GoboHide.

config, apps, data and volumes are just renames of etc, opt, srv and media so I don't really care though if I had to choose, I prefer the shorter names.

Yes, but it is not only renaming, but also merging some directories, like media and mnt into volumes. I prefer obvious names over shorter names. I do not want to Google "opt meaning linux" to understand that it stores apps installed by the admin. The only thing I like more about FHS over my proposal is media (I was thinking of /mnt when I wrote it).

In what way is temp a system artifact?

It isn't. I put it inside system for the same reason I put runtime inside it: to reduce the number of directories in the root. As other commented about immutability, I agree with extracting /runtime at the root.

What exactly is a system and what is a distro?

System artifacts are common artifacts to any Linux system. GNU tools are a good example.

About distro, when I proposed the platform directory, I was thinking about distro-preinstalled software and artifacts, for example, apt in Debian, snap in Ubuntu, or pacman in Arch. Not only the package managers, but any distro-specific stuff.

I would use my own project as an example: OpinionatedArch is not really a distro, but an opinionated Arch installer that leaves the final system with extra executable scripts in the Arch installation and other artifacts. While pacman should stay in /system/platform/arch, those scripts should be in the /system/platform/opinionated-arch directory.

Don't really want to think through it too much, but I'd start with categorising data based on its characteristics

About your list of characteristing, it is interesing. I could agree with that list. That is exactly the feedback I wanted.

[-]

mina86ng@reddit

Due to mental exhaustion when lsing the root directory. I want to see a few directories and understand their meaning at a glance.

It’s a root directory and all systems have practically the same contents so what exactly is there to understand or list? You’re introducing unnecessary constraint which introduces problems later on.

Is it a joke?

Only partially. It doesn’t have to be 70 directories but a) I don’t see minimising the number of directories as a goal (so I’d rather see flatter hierarchy with more directories per level) and b) I see having each directory with unique first character as an advantage (so you can tab-complete after typing just one letter¹).

It could be a symlink from /system/runtime/dev/null to /dev/null (or even to /null).

Just leave /dev alone. Notice that you’re creating a problem; just don’t change it and the problem doesn’t appear. As for /null, what about zero? urandom? What random devices are you going to symlink?

and hide it with GoboHide.

No. Do not hide things user doesn’t expect to be hidden. For better or worse, the convention in Unix is that files are hidden iff their name starts with a dot. Nothing else should be hidden for numerous reasons including the fact that different tools will show different directory contents.

also merging some directories, like media and mnt into volumes

Technically your description (‘mounted external storage (USB, disks, etc.)’) is what /media is. /mnt is for temporary mounts when doing administrative tasks.

System artifacts are common artifacts to any Linux system.

That’s an empty set then. Not all Linux systems have GNU tools for example. Distribution is the system.

OpinionatedArch is not really a distro, but an opinionated Arch installer that leaves the final system with extra executable scripts in the Arch installation and other artifacts. While pacman should stay in /system/platform/arch, those scripts should be in the /system/platform/opinionated-arch directory.

You’re making things overly complex for no reason. If you don’t treat OpinionatedArch as a distribution, it should install things to /usr/local.

¹ It annoys me to no end that something keeps creating ~/Documents directory in my home directory because I now need to type three characters to differentiate it from ~/Downloads.

[-]

MysteriousLion01@reddit

Il faut des points de montage racines comme system:/ ou data:/ comme ça quand quelqu'un lance un rm -rf /* il ne touchera pas à tous les lecteurs (et lecteurs réseau inclus)

[-]

DFS_0019287@reddit

Or, you could just not do that?

[-]

MysteriousLion01@reddit

Non, c'est naze 😄

[-]

natermer@reddit

Most of the problems with "FHS" have been solved by going with unified /usr. This has improved ease of finding various files significantly.

The other problems are starting to get solved by modern desktop and mobile applications ignoring the concept of file managers completely. Instead they hide everything behind search and recently used, among other things.

Which means that a lot of young people don't really even understand the concepts of files or directories in the first place.

[-]

MontyCLT@reddit (OP)

usr-merge was a nice improvement that solves a lot of issues (not all issues), but my post isn't about that specific issues but imagining a better hirearchy.

About the idea of hide the concept of a file: I noticed that a lot of apps are going to this way, but I really hate the idea. Each app stores it data internally and it difficult to export it to another app.

[-]

Sharp-Debate-523@reddit

Windows has /users like this

[-]

MontyCLT@reddit (OP)

Yes, the directory structure of Windows is more obvious than FHS.

Windows directory contains all the system.
Users directory contains the user data.
Program Files directory contains the applications.

It's simple and obvious at a glance. It's one think I like more from Windows than Unix.

[-]

Sharp-Debate-523@reddit

I agree its pretty clear. Except Why "Program Files". Why not "Windows Files" and "User Files". The "Files" is silly.

[-]

SwizzleTizzle@reddit

Raymond Chen wrote an answer to the "why program files" question:

https://devblogs.microsoft.com/oldnewthing/20131119-00/?p=2623

and

https://learn.microsoft.com/en-us/previous-versions/technet-magazine/cc160958(v=msdn.10)?redirectedfrom=MSDN

I think it's an interesting view point.

[-]

Sharp-Debate-523@reddit

I always the real reasons was .... they were showing off that they could handle spaces is folder names. And forcing application programmers to make sure they did too.

[-]

MontyCLT@reddit (OP)

Interesting. In the structure I proposed above, I included an apps/ directory, which goes against Raymond's point of view.

macOS solves this with ".app runnable directories." If you go to the /Applications directory, you see what appears to be a list of .app files. When you double-click them, the application opens.

I dislike the macOS solution because it "lies" to the user by presenting a directory as a file. In that sense, I would prefer applications to be packaged in a tar container with a .app extension.

[-]

thomas-rousseau@reddit

It may be obvious for you, but it was never obvious for me. I spent 25 years on Windows and was constantly grasping around to figure out where I needed to be in the directory structure. It took me 2 months on Linux to learn the FHS

[-]

DFS_0019287@reddit

I had no idea AI LLMs could paint bike sheds.

[-]

stef_eda@reddit

There are 13245 file system standards. This is insane, so I propose my universal File System Standard.

Result:

There are now 13246 file system standards.

[-]

stiggg@reddit

You may want to have a look at GoboLinux, a distribution that is around for a very long time. It’s main feature is an alternative directory hierarchy which iirc goes into the direction what you are proposing.

[-]

MontyCLT@reddit (OP)

I didn't know GoboLinux. I'm reading the At a Glance article and I like it they tried it in a real distro.

I will read about the GoboHide extension to do a compatibility with FHS. It's interesting to me.

[-]

Alduish@reddit

I'm not that much a hater of FHS cause even if some parts aren't perfect at least it's a standard everyone agrees on in the linux world and apps.

For your layout I think it's a bit clearer but I'm confused about maybe two parts :

As you said /system/kernel maybe shouldn't exist because of UKI or even EFISTUB which make the kernel an efi executable and it should be on the ESP in these cases, and in other cases maybe you still have an external bootloader like grub and you main partition and encrypted and should be decrypted by the initramfs because grub still doesn't support LUKS2 decryption completely so in these cases again the kernel and initramfs shouldn't be on an encrypted partition so grub can boot them, and the perfect place is again the ESP.
for users//.data it's not a full replacement of .local in this state, .local can also have .local/bin for user installed binaries only accessible to this specific user, which is outside of simply application data if you ask me.

[-]

MontyCLT@reddit (OP)

/system/boot is intended to be the mount point of the ESP partition in EFI firmware, so this partition should stay unencrypted while the rest of the system may still encrypted. I don't see any issue with that.
True. Could be just .local/data and .local/bin like the actual structure. I agree.

[-]

Pitiful-Welcome-399@reddit

NixOS is non fhs compliant, gnu/hurd is non fhs compliant, gnu/guix is non fhs compliant

[-]

NeedleworkerLarge357@reddit

I think this is not as unrealistic as it first sounds. Things like this can be done with an intermediate state where for example both, /etc and /config exist and point to the exact same contents. And it is a quite interesting thought experiment, especially to see different opinions and maybe even understand some things in the end, why are things as they are. What can actually be improved?

This would however only happen if you have very good reasons to put in the huge effort necessary, which is what I don't really see (apart from some special cases). Yes, some paths are a bit clunky, but most are already somehow sane. Some changes that you propose to the current layout seem logical to me, but some also are really strange/not what I like:

/system/bin + /apps? Just no. No need for another round of pulling appart /bin or /usr/bin and /sbin or /usr/sbin and later merging it back together and creating symlinks from /bin to /usr/bin as everything was a mess and implemented differently everywhere. Putting new names onto this mess won't change the fundamental issues that exist since /bin and /sbin exist.

/system/runtime/dev? Such a complicated long path for the hardware? I'd stay with /dev, much better.

The whole runtime folder feels like it should be on top-level, not hidden in the third level. But maybe I am just too used to the current state already...

Your goal nr 1 "reduce root complexity" is not met. You could put everything into a single folder that resides in the root directory, like "system". And everything could be below that. Or maybe have system and data there, everything else inside those. To be honest, I think the nr 1 rule is not desireable as you have put it. Maybe put it like "no more than 8 (sub) items in every directory by default", as otherwise you just shift complexity somewhere else.

[-]

aioeu@reddit

One of the features of the existing layout is that it is possible to build a system where /usr is immutable, without any need to carve out mutable subtrees within it. This doesn't look so easy to do with your scheme.

[-]

Important-Yak-8844@reddit

That's good point. In this scheme you'd need to make `/system/bin` and `/system/lib` immutable while keeping `/system/state` writable, which is more complex than current FHS where you can just mount whole `/usr` as read-only.

Maybe could solve this by moving all mutable system stuff under single tree like `/system/mutable/` so rest of `/system` can be mounted immutable? Though that starts to feel bit like reinventing `/var` again.

[-]

aioeu@reddit

I think tackling the mess in /var would be a good first step in cleaning up the FHS — mostly by moving or removing all the historic crap.

The UAPI Group's File System Hierarchy spec only has /var/{cache,lib,log,opt,tmp}.

[-]

MontyCLT@reddit (OP)

What about building /system inmutable? Maybe we should extract /system/boot and /system/platform outside system.

[-]

aioeu@reddit

/system/{state,temp,runtime} all appear to be mutable.

[-]

MontyCLT@reddit (OP)

True. I think a good improvement is split /system into two top-level directories: /runtime, and /system.

state and temp should be moved into /runtime.

Thanks for the feedback!

[-]

monolalia@reddit

Regarding user’s personal directories, I’d like there to be a “local” directory reflecting the greater system layout and work as an installation prefix for locally installed software (or just so you can drag stuff in there to make it locally installed as long as it uses relative paths):

/home/<user>
└── local/
   ├──bin/
   ├──etc/
   ├──include/
   ├──lib/
   ├──mnt/
   ├──opt/
   ├──src/
   ├──srv/
   └──var/
       ├──cache/
       ├──state/
       ├──tmp/
       └──…

Something like that, anyway. It’s how I do it “at home”, but it’s not completely 1:1 with the system-wide filesystem hierarchy (and the whole var thing (for files you won’t cry for if you lose them) is a lot more loosey-goosey).

Also I’d like the XDG environment variables to be pre-populated with their defaults if not overridden by the user. Not sure why that isn’t the case already… I guess there’s some reason for that.

[-]

alex-weej@reddit

Yo data is related by a graph not a tree. Bin the H in FHS