Beyond the Desktop Metaphor: My “Intent-Based” Filesystem Layout

Tips and Tricks
1

I’ve been refining a way to structure my folders and system drives that moves away from the legacy “filing cabinet” model (Documents, Downloads, Desktop) toward what I call an Intent-Based Filesystem.

Most modern workflows are action-oriented, but our folders are still organized by file type. I’ve consolidated my entire environment into three “mental zones” that dictate how I interact with data.

~/canvas

  • Replaces: ~/Desktop and ~/Downloads
  • Philosophy: Active Workspace.
  • The Logic: “Desktop” is an outdated metaphor, and “Downloads” is a graveyard. By merging them into ~/canvas, everything that enters my system lands in a single, high-stakes “Inbox.”
  • The Benefit: It forces digital hygiene. If a file is in ~/canvas, I’m either working on it right now or I need to move it. It creates visual/mental pressure to either process or discard data.

~/archive

  • Contains: documents, music, pictures, videos, etc.
  • Philosophy: Cold Storage.
  • The Logic: I tucked the standard XDG directories away. I don’t need to see them every time I ls. They are for reference, not for work.
  • The Benefit: Reduces cognitive load and unnecessary clutter in $HOME. Everything that isn’t for configuration now lives in one of two semantically named folders.

/trunk

  • Purpose: Mount point for primary high-capacity data drive.
  • Philosophy: Infrastructure.
  • The Logic: It’s a double metaphor. In a tree, the “trunk” is the main branch off the root (/). In a home, a “trunk” is a place for storing things.
  • The Benefit: It’s a memorable, top-level path for games, VM images, and backups. cd /trunk/SteamLibrary is much more intuitive than hunting through /mnt or /run/media.

The “Why”:

Standard XDG layouts treat the computer like a fling cabinet in an office; my setup treats it like an art studio or workshop.

  1. Reduced Decision Fatigue: I never wonder where a file goes. Is it active? ~/canvas. Is it a finished asset? ~/archive. Is it a 100GB game? /trunk.
  2. Semantic Clarity: The names reflect the state of my work, not just the extension of the file.

Curious if anyone else has moved away from the standard ~/Documents / ~/Downloads sprawl in favor of something more “pragmatic”?

8 Likes
2

:open_hands: is there deliberately no ~ for trunk?

3

Yes :slightly_smiling_face:

SteamLibrary and system backups go there, so naturally it is system-wide.

4

guessed as much.

I’m old. I know why there are groups named tape, operator, and wheel. I also have seen the development of the FHS. It was made for a different time and a different kind of computer and computing. Trunk makes absolute sense it even rhymes—at least semantically—with root. I like your Desktop/Downloads convolution, have a bit of trouble with archive. On my NAS I have a simlar thing with archive vs backup. Yes I know they are different but frequently find it hard to decide what goes where.

On a broader remark we should archive FHS and find something more modern. like what Apple did—partly—with macOS and GOboLinux NixOS.

2 Likes
5

Thank you for the insightful perspective!

Being under 30, I wasn’t around for the foundational days of these systems, though I am actively working to fill those knowledge gaps. While the origins of legacy groups like tape, operator, and wheel predate my time, I am well-acquainted with the historical hardware constraints that birthed our current directory structures—like /etc, /usr, /bin, and /usr/bin.

I completely agree with your broader point regarding the FHS. It is genuinely surprising that we are still strictly adhering to cryptic conventions established over half a century ago—conventions based on hardware limitations that no longer exist. It is certainly time we discuss moving toward something more modern and intent-based.

In fact, this exact line of thinking inspired me to start a personal project I’ve dubbed the “Semantic Filesystem Hierarchy Standard.” The goal is to replace historical acronyms with plain, functional English. For example, instead of a cryptic /tmp or /var/cache, my standard uses a /buffer directory with clear subdirectories like /buffer/cache, /buffer/queue, and /buffer/trash. Rather than splitting binaries and libraries across /bin, /sbin, and /usr, everything is organized semantically under /programs, separated cleanly into native and installed (and further into binaries, daemons, drivers, etc.). I’ve even completely re-imagined the /home as /users, and significantly reorganized/relabeled pretty much everything.

I consider myself a power user rather than a system architect at this stage; I am currently pursuing an associate degree in network administration, with plans to obtain my RHCSA afterward. Because of this, I recognize that I lack the historical perspective of the engineers who built the original standard. My project is still largely conceptual and would need significantly more architectural development before a functioning operating system could be built on top of it.

However, I believe exploring these semantic, intent-based layouts is a necessary step forward for modern computing. I’d love to hear your thoughts on this approach and what you think a truly modernized hierarchy should look like!

1 Like
6

@theking2

├── buffer
│   ├── cache
│   ├── dump
│   ├── pagefile.md
│   ├── queue
│   └── trash
├── devices
├── documentation
├── programs
│   ├── installed
│   │   ├── applications
│   │   ├── binaries
│   │   ├── daemons
│   │   ├── desktops
│   │   ├── drivers
│   │   └── libraries
│   └── native
│       ├── bootstrap
│       ├── daemons
│       ├── drivers
│       ├── firmware
│       ├── headers
│       ├── libraries
│       └── utilities
├── records
│   ├── journal
│   └── logs
├── recovery
├── runtime
│   ├── conduits
│   ├── etcetera
│   ├── latches
│   ├── network
│   ├── processes
│   ├── sessions
│   └── vitals
└── users
    └── admin
        ├── buffer
        │   ├── cache
        │   ├── queue
        │   └── trash
        ├── profile
        │   ├── credentials
        │   ├── essence
        │   │   ├── preferences
        │   │   │   └── daemons
        │   │   └── wardrobe
        │   ├── narrative
        │   └── studio
        │       ├── archive
        │       ├── canvas
        │       └── reception
        └── programs
1 Like
7

i kind have already been doing this since windows days.

my desktop is where most everything flows thru and i have folders on the desktop to help me process things and keep them sorted.

you can definitely direct your “downloads” to dump right out onto your desktop as well if you want to deal with that.

having a physical HDD as my “cold storage” goes along way toward keeping archive things away from actively working on things, and i’ve always kept my games and recovery data on separate partitions from the main directories where i work.

2 Likes
8

Just recently I was thinking of making Desktop my default downloads folder: it makes so much sense to use my empty desktop to display files I just downloaded (not “archived“) because I need them. This would also make it easier to keep things clean: cluttering the desktop would remind me that I need to either delete or archive files.

I also notice that I rarely use the default Documents, Pictures etc. folders. I keep my files synchronized with Nextcloud and that has its own folder in Home, and I don’t want to try synchronizing it inside Documents to avoid local programs to pollute my cloud.

Therefore I somewhat agree. The issue is that maybe there’s no need to rename things: the default directories are there but I’m free to use them as I see fit. Renaming things for everyone would force a workflow to others; maybe a change like this can happen organically in some way?

9

I can and will support your efforts wholeheartedly and find it fascinating that both standards don’t die easily and some people do care enough to find something new.

You might want to review Gobolinux File Hierarchy. Not to dissimilar from what you work on.

Btw in 2026:
$ getent group | grep -e "tape" -e "wheel" -e "operator"
wheel:x:10:j
tape:x:33:
operator died, but wheel? tape?

10

I too use Nextcloud and my Desktop, Documents and Pictures are symlinked in the Nextcloud folder. This way no matter where I work I have my files with me. Stuff that should stay local is somewhere in a ~ subfolder.

For the same reason I am reluctant of combining desktop and downloads. Semantically logic, technically problematic as I might download an ISO image or other larger stuff that than gets synced before I can move it to its final destination. (although NC can save you from that)

Currently we (did Microsoft started that?) enforce a structure on the user anyway. And if we do not, we end up with a difficult to maintain and troubleshoot structure (.local, .config, .mozilla, .var, .etc, .ssh, .gnupg, .thunderbird, if I list all the hidden configuration folders in my home alone that I did not create myself).

11

The fact that you sync Desktop too is interesting: you are somewhat using OP’s suggestion by keeping the current active project in plain sight.

12

Your preferences are definitely not mine. If I had my druthers, I wouldn’t live within ~/Documents, ~/Pictures, ~/Downloads et al. - more or less forced on me by various tools - but I’ve learnt how to cope with them.

If I were God, and could control the behaviour of apps, snap et al, I’d start by requiring the lot of them to refrain from creating their own individual directories in $HOME.

There’d be one place for everything that pertains to the normal operation of installed software, including its cache files. I’d be able to conveniently exclude the lot from user space backups, and see only one directory when I looked at the contents of $HOME. They could have their own sub-directories within that common subdirectory.

They’d also refrain from putting any user-generated content in their normal operation directory, and ask me where I want it to go. (Wine is probably the biggest offender for burying things I want to access directly miles deep in a structure full of things that came with the wine installation. But it’s not the only one.)

Since that’s not possible, I use ~/real to contain files owned and controlled by me, with subdirectories based on purpose or topic.

Likewise, if I were God, there’d be no more dot files and directories in $HOME like .emacs.d and .gitconfig; they’d all live within ~/.config

In some cases, apps are much happier with having all user-content associated with that app in a single common directory. Without putting e.g. all LibreOffice files in the same directory, it’s a PITA to open some random LibreOffice document from within the LibreOffice Apps. Some systems support “open ~/foo/bar/baz.ext” from a terminal window - many don’t. So ~/Documents is better than the available alternatives.

It’s also far too large. I’m tempted to break it into subdirectories, based on which app handles the file in question.

I have no use for ~/Desktop. I don’t put icons on my desktop, where they’d be inconvenient to access beneath my collection of open windows.

I don’t consider ~/Downloads/ to contain current files. Much of the time, it’s a cache of once-used online material I don’t want to retain, sometimes dating back to the day I first installed the OS. (I do prune it manually from time to time.)

One key directory you don’t mention is ~/bin, where I keep executables I’ve created - usually scripts.

I also have ~/src/ which includes both source files I’ve created and source files I’ve downloaded, organized by project. Logically it, and even ~/bin should be in ~/real, but I’m not consistent.

Installed software, including games, belongs in /usr/local if it’s system-wide, and (sadly) $HOME if not. No need for /trunk in my world. (I say /usr/local, but the specifics change from time to time and distro to distro.)

So that’s my two cents, or perhaps 3 dollars given inflation.

13

Haha @ArlieS, I think we are actually in violent agreement about the problems with the defaults!

You mentioned having no use for ~/Desktop and treating ~/Downloads as a temporary cache of files you don’t want to retain. That is exactly the friction that drove me to merge them into ~/canvas! It serves as that single, temporary workspace so I don’t have to manage two separate holding pens for transient files.

Where we diverge completely is your temptation to organize by the app that handles the file. That is precisely the workflow my ‘intent-based’ layout is trying to escape. If I’m working on a specific project, I don’t want the scripts in ~/Documents, the assets in ~/Pictures, and the executable somewhere else. I want them all grouped together in one project folder because my ‘intent’ is to finish that specific project, regardless of whether I need LibreOffice, GIMP, or a text editor to do it.

Also, just to clarify on /trunk—that isn’t meant to be a new philosophical standard directory for Linux; it’s literally just a memorable mount point for a secondary, high-capacity physical hard drive because my massive VM images and games simply won’t fit on my main system drive!

It is always interesting to see how different minds tackle the exact same filesystem constraints, though. Thanks for sharing your 3 dollars!

14

You might want to try Tiago Forte’s PARA Method. I use it for my home directory, I’ve created links in places for the projects, areas and resources folder, and it works quite well for me. I left Downloads as is, I’m simply moving things from Downloads to the relevant folder after downloading and checking the content.

15

If the wretched tools would let me without additional pain, I’d have everything associated with a project stored with that project. Sadly, that only works conveniently with things I access from the command line.

So given that, why do I have ~/src/, which is pretty much only accessed from the command line? Mostly because I have a dubious habit of ‘git clone’ing all kinds of source trees I just want to look at, and it’s helpful to have them all in one place. There’s a less than 50% chance that code I’m personally developing will start its life in ~/src - but it might move there when finished, or when I abandon the project.

OTOH, I have been experimenting with sticking random .txt files in ~/Documents even though I generally access them with emacs, less, cat and similar, directly from the directory they live in. Here it’s been a matter of forgetting where I put them, and hoping a common spot for the non-obviously categorized will help. Currently they are pretty much all working notes from seeking solutions to specific problems with my new linux system, named based on the problem in question.

I suppose those particular files could have gone in ~/real/sysadmin - but I’ve traditionally used that just as a record of actions actually taken.

I also didn’t mention /backup - which is pretty much what you think - the mount point for an external drive used to backup $HOME, minus as much of the app caches and similar as I can find patterns to exclude.

16

Interesting. My use of “project” conflates their “project” and “area of responsibility”, but seems to work for me. I know “bookkeeping” and “sysadmin” never end, and the program I’m writing will hopefully one day be finished, and maybe one day be no longer useful . But mixing the two categories doesn’t seem to confuse me.

I don’t seem to spawn whole directories for short projects like “find a linux backup system that does what I need” - just notes files, resources (relevant bookmarks in this case), and a temporary virtual workspace on my computer (with perhaps too many open windows). (To give an idea of scale, that project took around two weeks, and resulted in me evaluating several, installing at least one, and eventually rolling my own using rsync.) Perhaps this is PARA’s idea of a typical project, not a 6 month coding spree?

17

I use projects for anything that has a clear “finished state”. Your “find a linux backup system that does what I need” would be a project in my case. Areas for anything that I might need for the foreseeable future. A program I intend to develop for years to come would be an area. I have areas for things like “my home” with bills and floor plans, “my car” with manuals, documents and spreadsheets tracking things about my cars, or a folder with documents for my business. “Resources” is basically a public library, knowledge in areas that interest me I can safely share on the Internet.

There are of course other methods of categorizing, you’ll probably find dozens of articles of videos about how PARA didn’t work for someone, so you can check the alternatives. I like it’s simplicity and it shouldn’t be hard to move to something else if I decide it’s not enough.

18

I am so glad that this discussion is open now! I have been getting very frustrated over the years with the organisational scheme imposed by ancient Windows systems now perpetuated by XDG.

  • Where do audio books go? Are they documents or music?
  • What about podcasts, or non-Movie video.
  • What exactly is a Document? Is this area meant to be for static content, as Music is for audio files? or is this where my works-in-progress go? It seems to me that those are entirely different things.
  • Where do multi-file projects like source trees go? Are they Documents?

Lately I have also been working on a couple of my own solutions that I would like to share. I have different variations on these 2 styles in use depending on which user@host I am using.

  1. Extended XDG-style
    • ~/Media or ~/Library (all static content, such as manuals, references, Movies & TV, etc)
    • ~/Media/Audio/{Podcasts,Music,Sounds,…} (all audio-only content)
    • ~/Media/Video/{Serials,Movies,Documentaries,…} (all video-only content)
    • ~/Media/Documents/{References,Recipes
    • ~/Media/Images/{Icons,Photos,…}
    • ~/Media/{DiskImages,ROMs,…} (other static and mostly single-file content)
    • ~/Archive (like ~/Media, but mostly contains personal documents, bills, receipts, etc)
    • ~/Projects or ~/Studio (works-in progress go here and are mostly git-controlled so I can just delete them at will when I want to clean up the space)
    • ~/Mountpoints (self-evident, with symlinks to auto-mounted trees eg /mnt/nethome/dkermin → ~dkermin/Mountpoints/nethome)
    • ~/Public (user shares root, eg link to ~/Media/Audio/Music)
    • ~/Programs/ (installation root for games and such that are not system-wide, executables linked into ~/.local/bin)
  2. repurposed FHS
    • ~/mnt (equivalent ~/Mountpoints above)
    • ~/mnt/{gmail/xxx,pcloud/{xxx,yyy},…}
    • ~/mnt/nethome →/mnt/nethome/xxx
    • ~/share (similar to ~/Library above but somewhat flattened)
    • ~/share/{icons,sounds,music,diskimages,roms,doc/{references,recipes,tutorials},…}
    • ~/incoming (equivalent to ~/Downloads)
    • ~/pub (equivalent to ~/Public above)
    • ~/src (similar to ~/Projects above, but only for projects of my own making)
    • ~/local (installation root for source projects and other FHS-compliant applications)
    • ~/local/src (downloaded source trees, not of my own making)
    • ~/local/opt (equivalent to ~/Programs above)
    • ~/attic or ~/archive (equivalent to ~/Archive above)

I am a bit conflicted though about using ~/local in FHS-style since I also have redirected all $XDG_*_HOME to ~/.local/{share,etc,cache,var}.

1 Like
19

It is interesting that the dm developers moved away from the desktop metaphor (as well). But the approach to current work (canvas!) in clear sight is far better option. An I actually glimpsed someone on my last flight with a desktop much like:

image
image480×270 64.3 KB

He looked a bit stressed…

Anyway. The complete user structure @nathaniel.krebs show (profile/studio/[archive,canvas,reception]) might again be a bit over the top IMHO and requires a bit of explanation.

2 Likes
20

Completely agree with you that it would most likely require a ton of refinement before it represented any meaningful, functional improvement that an implementation could be built from. Having said that, I’m happy to clarify decisions I made for names and locations, if you had any specific curiosities. :slightly_smiling_face: It’s definitely just a brain game I’ve been playing around with more than anything, but I believe the discussion is important and overdue.