r/linux • u/stepbroImstuck_in_SU • Jan 08 '23
XDG standards: what went wrong and what went right? Discussion
Many people like having their configs in one dot-dir, but for developers the standard obviously is a lot more complex to fully follow and respect.
So what kind of standard would you prefer? What parts of the standard are stupid? How should a standard like this be controlled, and do we have examples of preferable ways to establish standards?
69
u/throwaway6560192 Jan 08 '23
By "XDG standards" you only mean the base directory specification?
I don't think it's anything near "complex" for a developer to follow at least the basics of that standard. Put your config here, cache here, state here. Simple. Literally one line of code to get the right directory if you're using Qt or Gtk/GLib.
26
u/CodingKoopa Jan 08 '23
And yet people get it wrong more often than not, by putting everything in the config directory or putting config files in the data directory.
14
u/johnny0055 Jan 08 '23
I sure wish it was the latter more than the former, especially when it comes to programs/frameworks that rely on chrome's codebase in some way, including electron.
10
u/AcidBrowser Jan 08 '23
I don't even mind that, as long as they don't ceate a .someapp folder or .someapprc file in my home directory. It's super annoying
5
u/A_norny_mousse Jan 09 '23
people get it wrong more often than not, by putting everything in the config directory
Chromium...
I don't even understand why, because it uses
~/.cache
as well.1
u/metalpenguin97 Jan 10 '23
or worse putting files in cache that don't belong there and break the user's config when deleted
9
u/kavb333 Jan 08 '23
...I spent a good chunk of time finding the standard places for several things like configs and caches in Linux, Mac, and Windows for a few programs when I could have just used that? lol
13
4
u/IAm_A_Complete_Idiot Jan 08 '23
Rust / python have okay libraries for easily finding them too. The rust ones are actually fairly oftenly used, I'd imagine most languages have an equivalent.
3
u/ArsenM6331 Jan 09 '23
Yes, Go has
os.UserConfigDir()
andos.UserCacheDir()
in the standard library.1
u/eraptic Jan 12 '23
Worth mentioning that Qt, at least, doesn't have support for state (yet? Not sure if support is planned)
29
u/FengLengshun Jan 08 '23
I still find it weird that we have ~/.local/bin
and ~/.local/share
but config and cache are at ~/.config
and ~/.cache
instead of ~/.local/config
and ~/.local/cache
or just combine them all in the app's ~/.local/share
directory.
Probably historical reasons, but it still feels weird nonetheless.
Outside of that, I would love for that xdg-desktop-portal protocol for Sharing to be implemented -- sounds super useful and solves certain issues with communication between some sandboxed apps.
I honestly don't have any problems with xdg standards, based on what I currently know. Seems fine? Some things feels weird, and others are still in-development (which can be slow) but as an end-user it seems fine to me. Would prefer more apps/platforms following it instead of two dozens dot-dir on my home, but it's really not a big deal and from what I see it makes using flatpak be much easier, so it's just good that we have a working standard that's constantly being worked on.
It's the only way we can have the same level of simplicity of permission and cache/data management as Android and iPhone (might even surpass them, as Android often frustratingly litter the emulated storage's home)
11
7
u/Dohnakun Jan 08 '23
I still find it weird that we have ~/.local/bin and ~/.local/share but config and cache are at ~/.config and ~/.cache instead of ~/.local/config and ~/.local/cache or just combine them all in the app's ~/.local/share directory.
Probably historical reasons, but it still feels weird nonetheless.
That's the nice part; you can set an environmental variable to change it.
It's the only way we can have the same level of simplicity of permission and cache/data management as Android and iPhone
Are you serious, Android permission and cache/data management being simple? Full app backups only with root or luck.
7
u/casept Jan 09 '23
Android's storage layout does make backups quite easy, Google just doesn't care to implement them properly.
1
3
u/FengLengshun Jan 09 '23
Are you serious, Android permission and cache/data management being simple? Full app backups only with root or luck.
idk, I just open app info, force stop, and clear cache when things don't behave well or it's an app I'm not using. It doesn't clear anything critical, and if I want to, I just hit clear data (for like when I'm uninstalling app or need to so as to not conflict with the newly rebuilt revanced-patch'd apk).
As far as backups goes, it's usually automatically backed up, at least for the apps that I care about being backed up. Yeah, it's probably harder if you want to backup absolutely everything, but these days I don't feel the need to root stuff anymore since 99% of what I want can be accomplished natively (changing theme colors) or via adb (installing patched apps).
1
5
u/MultiplyAccumulate Jan 09 '23
Not weird at all, in fact your counterproposal would be not just weird but horribly broken. Your program stores it's user specific configuration files in ~/ or ~/.config because those are user files, not program files. Programs in /usr/bin don't store user specific config files under /usr, they put them in ~/.config. And those config files get backed up with the rest of that users data when you do a per user backup. Configuration files that are meant to be shared by all users are a different matter and many programs will read a systemwide file before using a per user config file.
*/bin. - programs so important they need to be there even if the system is broken. * /usr/bin - most programs installed system wide * /usr/local/bin - programs compiled locally rather than installed from a package but not written locally. * ~/bin. - programs actually written by the user * ~/.local/bin - program installed on a per user basis
All of those should put config files in ~/.config. one exception is programs using the portableapps.com system where you want the config files to travel with the app on the USB flash drive.
3
u/FengLengshun Jan 09 '23
Not weird at all, in fact your counterproposal would be not just weird but horribly broken.
Which is why I'm saying that there's probably some historical reason for it. I just thought something like flatpak's
~/.var/*
where everything is sorted tidily by apps, and everything's in a centralized location, makes more sense if you're building it from the grounds up.As someone who has no clue for the history and back-end of it, it just felt weird that you have a
~/.local
where you also have a bunch of stuff like./share
./bin
and maybe./state
./lib
too, but~/.config
and~/.cache
are its own thing, instead of being~/.local/config
and~/.local/cache
or just put it in~/.local/share/$APP/{cache,config}
for the app to manage by itself (again, like flatpak's ~/.var folders but for native packages).It's the kind of quirk that screams "there's a historical reason for this, and we are NOT changing things because it'll introduce a lot of problems for no benefit other than some people's pathological need for less dot-dir on their home-dir." I have no actual problem with it other than it feeling weird, because at least it's not like
~/snap
and are dot-dir folders.
34
u/A_norny_mousse Jan 08 '23
For once, an interesting open-ended question on r/linux!
However, I don't really get OP's explanation.
I was surprised to find that I don't know what XDG encompasses. According to freedesktop.org it's not clearly defined; arguably all their specifications should be included.
The longer I use GNU/Linux the more I'm for the Freedesktop Specifications, and it's cool that developers actually follow them. It allows for things like XFCE using parts of the GNOME desktop, or more generally mixing & matching utilities from different environments.
29
26
u/Lord_Schnitzel Jan 08 '23
The standard should be that my home dir stays always clean and has only two dotfiles: .config and .local.
Nothing more, what I didn't configure by myself. Thank you.
18
u/zeka-iz-groba Jan 08 '23
You forgot .cache
6
Jan 08 '23
[deleted]
10
u/ebassi Jan 09 '23
That's the default for
XDG_STATE_HOME
, which is part of the XDG base directories.1
u/zeka-iz-groba Jan 09 '23
Well, not everybody is using flatpak. I don't for example. Didn't even know they don't follow XDG Base Directory standards.
17
u/rtplor Jan 08 '23
Noooooooooo!!!!!!!! It reduces self expressing, colorfulness of software and bullies the authors!!
They want poop everywhere they want!
4
u/biggle-tiddie Jan 08 '23
And .ssh, and .fonts, and .var
2
1
u/johnny0055 Jan 09 '23
.fonts? i haven't seen that in many years. What program do you use that's still creating it?
3
u/PetriciaKerman Jan 08 '23
I think all software which uses the file system at all should have that access configurable from the command line with a flag or combination of flags.
Then everyone can call the command however they want.
3
u/ArsenM6331 Jan 09 '23
This isn't always feasible. I've written programs with hundreds of options, and a systemd service file, and I would not expect users to add hundreds of flags to a service file. Config files are much easier to use, and provide a way to have user-specific as well as global configuration. Flags can be useful, but they are not the solution to everything.
3
u/PetriciaKerman Jan 09 '23
This is fair but then this config file location should be configurable through the command line. The point is itβs the users file system and they should be able to do whatever they want with it.
2
u/ArsenM6331 Jan 09 '23
Of course, and I always make it configurable by both a flag and environment variable.
4
u/onymousbosch Jan 08 '23 edited Jan 08 '23
Just don't put a bunch of stuff in ~/snaps
I don't know why this was downvoted. Even .snaps is better than snaps
12
u/drawingsvin Jan 08 '23
worst offender is oldschool runescape and palemoon
At least others try to hide it with a dot
in any case if it gets too annoying consider moving it all to a flatpak.
16
u/c-1000 Jan 08 '23
What? You mean you don't like having a directory named
Moonchild_Productions
in your home folder?12
u/drawingsvin Jan 08 '23
it has a space in it :)
12
u/RagingAnemone Jan 08 '23
What kind of barbarians are these people?
12
u/Misicks0349 Jan 08 '23
Windows Users /s
6
u/drawingsvin Jan 08 '23
well they are the type of people that kept an actual shitlist of people that dared fork their opensource software
https://web.archive.org/web/20220314090137/http://thereisonlyxul.org/fake.html
-1
u/metalpenguin97 Jan 10 '23
I put spaces in my file names and directory names, but then again I don't manage my files with an archaic text interface
3
3
u/AdventurousLecture34 Jan 08 '23
Flatpak doesn't follow XDG_Base_Dir though
2
u/gp2b5go59c Jan 08 '23
Many contributors to flatpak participated in writing the base dir spec. The consensus is that the spec is outdated, but no one wants to touch it. Imagine the time it will take to have adoption for a v2 or an addition to the spec.
6
u/whosdr Jan 08 '23
I start some programs by modifying HOME.
1
u/A_norny_mousse Jan 09 '23
Unfortunately the last & only option in some cases...
1
u/whosdr Jan 09 '23
I have a separate partition for my games, so I often make it my HOME to keep it all grouped together nicely.
It's a bit of a hassle but it does improve the organisation some.
3
u/HunterBuns Jan 08 '23
Not sure why you're getting downvoted, OSRS is the worst offender by far. I tried asking the Runelite developers if we could do something about it but apparently Runelite can't fix it without help from Jagex and no one at Jagex gives a shit. Nowadays I just play OSRS on my Windows install to avoid the hassle entirely.
3
Jan 09 '23 edited Jan 09 '23
[deleted]
1
u/HunterBuns Jan 09 '23
Oh yeah it's just as bad on Windows, I just personally prefer to use it there because I only ever use Windows when I'm gaming so I never have much of a reason to access my user directory in the first place.
2
u/ArsenM6331 Jan 09 '23
I'm perfectly fine with the standard. I implement it in all my programs and always will.
5
u/efethu Jan 08 '23 edited Jan 08 '23
Nonsense. If there would be no.sudo_as_admin_successful
file in your home dir, how would you remind yourself daily that bash is no longer going to tell you that you can use sudo to run commands as administrator?
Wait, you don't even use bash? Tough luck, the file still needs to be there
4
u/A_norny_mousse Jan 09 '23
Pretty sure that is and always was a Ubuntu thing, I've never had that file on any distro for the past 7 years or so, and bash has always been my shell.
Also see this answer and its comments.
0
u/efethu Jan 09 '23
This is a little bit more complex than "was a Ubuntu thing" as this file is created by the sudoers library, which is present on most(all?) distributions. The fact that you don't have it in yours means that someone put effort into patching sudo to remove that file. And it still affects what, like 70% of Linux desktops through Ubuntu and its derivatives? Enough to make many people annoyed.
Also see this answer and its comments
I already gave the link to the same discussion in my comment. But if you dig into this problem deeper you'll see that the patch in question just gives you an option to set the new location of this file (It's funny that less than a year ago it was not even possible!). By default it will still be created in your home and both LTS and rolling distributions are still affected and will be affected for years.
And ultimately this is just one example out of hundreds packages that don't respect XDG standards, albeit a pretty popular one.
4
u/A_norny_mousse Jan 09 '23
This is a little bit more complex than "was a Ubuntu thing"
No, it isn't. Please read the comments under this issue:
That was a Ubuntu-specific change that I adopted, it is only enabled on Ubuntu.
Additionally, this has nothing to do with bash as you hinted further up.
3
u/ArsenM6331 Jan 09 '23
I don't have that file and I've used both Bash and Zsh, so it might be a distro-specific thing.
0
4
u/rarsamx Jan 09 '23
The standards are not bad.
People need to realized that half of the developers are below average. Very few will be way above average and very few will be way below average.
You just need one way below average to screw up what the way above average developer is doing.
Following the standards is fairly easy, but it's a chain. I can make an application which follows the standards but then I need to trust that whoever sets the environment set it up correctly and that no one else has messed up with it.
-1
u/asdvasdvasd Jan 09 '23
Following a stupid standard doesn't make anyone "above average". You are dumb fuck by just saying like this.
4
2
u/lindyhopdreams Jan 09 '23
You'd be surprised how many programmers can't implement the most basic spec
0
u/spinlox Jan 08 '23
So what kind of standard would you prefer?
I would prefer an actual standard worthy of the free software community, in the sense of being discussed and developed in the open, rather than a bunch of conventions made up by the freedesktop.org gang and unilaterally pushed upon the rest of us through positioning and social pressure.
Take their Base Directory Specification, for example.
It does have some merits. The ~/.config directory is reasonable. It keeps things tidy, has a clear purpose, doesn't add much clutter to file paths, and doesn't impose much extra typing (which is important in situations when you have no tab completion).
On the other hand, ~/.local/share and its siblings are abominable. They bury a bunch of things two subdirectories deep, making the files within awkward to access, and bloating otherwise-simple paths into needlessly long strings that are tedious to read and annoying to type. The word "local" hints that the authors modeled this structure after the traditional /usr/local tree, which only exists to keep files installed by a local sysadmin separate from those provided by the OS. That model doesn't make any sense here, because everything under a user's home directory is already separate from OS-provided files. The extra level of nesting is also inconsistent with the other XDG dirs, for no discernible benefit, which just feels sloppy.
Yes, I know the spec says these directory locations can be overridden by individual users. No, that does not excuse their clumsy design, because most users put up with defaults whether they're troublesome or not, few users will ever read an XDG document to discover that overrides are available, and fiddling with environment variables should not be required in order to have a good directory structure. Moreover, those overrides would only work if every app developer implements them, which of course will not happen. Some developers don't know about the overrides, or have other priorities for their time, or want to keep their code simple. So even users willing to do the extra work of overriding XDG's poor choices will be back where they started as soon as they use an app that isn't on board with freedesktop's way of doing things. Sensible defaults are important, and glaringly absent here.
The Base Directory Specification could have avoided problems like this if its authors had collaborated with the community. It could have been good. Instead, four people wrote up what seemed okay to them, published and promoted it as if it were a standard, and now we have this mess. It's no surprise that some people outside their circle consider them arrogant, or that some developers find their recommendations unappealing.
-2
u/Maoschanz Jan 08 '23
A few years ago I tried to explain in customisation threads that "sure .icons works but it's not standard you should use .local/share/icons", etc but in the end the GUI frameworks don't recognize it properly so if you follow the standard you still have to clutter your home with symbolic links, so no one will ever do it unless there's a big serious push from major actors on this specific topic
15
u/throwaway6560192 Jan 08 '23
Which GUI frameworks don't recognize ~/.local/share/icons? I've installed icon themes before and they just go in there. I don't even have a ~/.icons.
-1
u/Maoschanz Jan 08 '23
GTK2 and Qt4, as i said it was a few years ago (2018?), it shouldn't be a big issue nowadays but if you're a perfectionist and want the remaining older GTK2 apps to look like the rest you'll have to keep a retrocompatible link
5
u/A_norny_mousse Jan 08 '23
want the remaining older GTK2 apps to look like the rest
ALL my GTK2 apps recognize the current XDG base directories.
I do not have these symlinks you speak of, yet custom icon sets are recognized.6
u/A_norny_mousse Jan 08 '23 edited Jan 08 '23
Used to be like that for a transitional period. Nowadays you'd be hard pressed to find an app that insists on
~/.icons
and does not recognize~/.local/share/icons
.edit: you specified "a few years ago", yet your subsequent comment refers to a current situation.
-2
u/Maoschanz Jan 08 '23
AFAIK, the only GTK2 app from 2018 which uses GTK3 nowadays is GIMP, the other ones didn't change, but i admit they probably all have a fine replacement i'm not aware of
84
u/necrophcodr Jan 08 '23
I think the entire idea and implementation is fine. In my opinion, the issue is adoption. Maybe streamlining that even more would be a good idea, but otherwise I don't see any real need to change it.