@Dwight A. Spencer XDG actually does exist on most relevant posix systems that are not OSX, most of the ones you mentioned (amiga, plan9, hurd, minix) have essentialy been dead for quite some time, whenever "linux" tries doing something right there's always some stubborn BSD dev to cry about "muh unix"
@@dispatch-indirect9206It's also large and widespread enough that they could just do it anyway and everyone would just be forced to deal with it somehow, so it can go either way really
Mozilla complains about config vs data being confusing, meanwhile Windows exists... with it's appdata Roaming, Local and LocalLow which I can't wrap my head around to this day.
@@dimguru That is how it's roughly intended to work, but roaming stores cache files for firefox while profiles live in local. However, many applications have this backkwards or mixed with files in my documents and etc shenanigans.
Fairy simple. Roaming is for stuff that is portable, that can be synced with other computers. Local is for files specific to the machine, while LocalLow is for files that are less important or have lower priority or integrity needs
The worst apps are those that "support" the standard - with "support" meaning they dump ALL files into .config and not just configuration; for example electron apps and chromium. Which renders the whole "just backup your .config folder" point kind of moot, since i again have to filter through my .config content for these kinds of folders to omit.
The sound of silence at the end actually cracked me up. I knew it'd happen one day (maybe already has, I often stop video at "and") cos random BS that maybe, kinda sorta has something to do with the subject gets tricky. Today apparently was one of those days.
Not just legacy unfortunately... I legit just saw the Primeagen's review of the V language which is relatively modern and what do you know, it still puts its modules file right in your home directory at least by default
@@mega_gamer93 yes but that shoves everything in one place, instead of e.g. cached crates going to $XDG_CACHE_HOME, and config.toml going to $XDG_CONFIG_HOME. Still better than nothing (XDG_DATA_HOME can technically contain everything, really), but definitely not optimal.
I have thrown in the towel, I sat down one day and thought, ok so like, in my home there is some random bs and clutter from others I live with, however, within my home I also have my bedroom where everything is 100% mine and I don't have to be bothered by this mess the others made.... so now I have a directory ~/Bedroom which is essentially my new home folder, and I treat my applications as my messy housemates now
This is what people do on Windows. Because most config stuff gets dumped inside My Documents people have started creating My Real Documents or something like that heh
The standard says that programs should place config files in "$XDG_CONFIG_HOME" or "$HOME/.confg/" if "$XDG_CONFIG_HOME" isn't defined or is invalid (isn't an absolute path). Some apps, even now, don't actually follow the standard: they just place files at "~/.config" without looking at the environment variable first. The same applies to the XDG_DATA_HOME, XDG_CACHE_HOME, etc. These applications aren't using actual implementations. There are libraries that implement it properly and simply in many programming languages, but many people don't know or care to use them. For Rust, there's the `dirs` and `directories` crates (which are actually cross-platform, but use XDG for Linux/Redox).
Wait, i didn't understand, the standard is $HOME/.config when $XDG_CONFIG_HOME is declared but when it isn't defined it is "~/.config/". Isn't them the same thing so the standard is being applied? Both will be... Let's say "/home/user/.config/" right???
@@AtomicFeasT yes, you are able to change the $XDG_CONFIG_HOME variable to point anywhere you want, that's the point of its existence, so that the user can change the directory if they don't like the default. otherwise, every program would just put configs in $HOME/.config and not even check the variable (which some programs actually do, erroneously), if hypothetically we're assuming that no one would ever want to change that directory's location. for example i have my $XDG_CONFIG_HOME directory set to point somewhere else, but a couple programs are hardcoded to not even check the variable first like they should, so they put their crap in $HOME/.config, thus i have 2 config directories now instead of just the 1 that i want
@@shallex5744 Damn, thanks for all the insight, everyday learning something new. Although i don't really have any formed opinions about it, having the option to change the directory could be very handy if most programs would make that check, it's unfortunate that that's just not the case, tho i don't see any real use case, i use the $HOME/.config and never had any problems with it. Could you share why it would be useful (In your case) to have a second config directory to save some configurations?
What's great about Linux is the power of symlinks. Since very recently I maintain a dotfiles directory inside my home folder in which I have put several important files from both my direct home directory as well as from the dot config and dot local directories. I made a Git repo inside that directory and sync it between the several Arch systems that I have using that way. I even wrote a script to automatically create symlinks for those files and got that working pretty smoothly. So for me it does not really matter anymore that applications use different locations, I just have to look in 1 directory now for all the actual files. Very simple.
i honestly find this specification getting partially ignored MUCH less annoying than others, for example manufacturer ignoring the usb spec, cables with missing pins/ weird power delivery stuff/ devices that use a usb port for something COMPLETELY DIFFERENT. but thats just how it is ignoring specifications has ZERO consequences for the person doing it.
This is legitimately why I use Conty. The sandboxing is really simple for doing custom home and selective binding of external directories. It's annoying that I have to do this for stuff like adb, mozilla, and itch which litters my home, but it works well enough and that's good enough at this point. Also, Nix config can help too, some doesn't work well outside of NixOS context but it worked pretty well for most of the zsh configs.
here's my take: it is indeed a lost cause (sorta). so maybe the notion of making our home folder root some new folder could be overall just a bit easier and sidestep all that. for example if we could point our xdg root could become /home/username/something_else/ then within that we could put our documents, desktop, music and other subfolders. and then make a symlink back to our actual historical ~/ folder. i know maybe that approach could introduce some new new issues all of its own. however in spite of that it just might overall be less work or bother than trying to hunt down every single last legacy .dotfolders. which is total lost cause at this point. i know because i have already tried doin exactly just such a thing. and it was indeed a total abject failure upon all epic proportions. as i am sure this video will no doubt confirm is still the case in the year 2023.
so hey! this got me thinking... well can i actually create a directory within my home called ~ then? just tried ---> it turns out i can. and this brand new directory is then ~/~ hmm... so what if i could make some sort of shell autocompletion alias to redirect that? without having to type the / slash. for example a double tilde nomenclature or something? if the shell could understand ~~ to substitute for ~/~ then we might actually be able to get a teeny bit further here. of course maybe not since so many existing programs are historically all been hard coded simply to just understand the single tilde ~ as $HOME. ah well. but still, it feels like maybe i could finally be onto 'something'. whatever that something is. might just be a dead end, but otoh could be worth exploring just a little bit further
The funny thing about this is that hidden files were originally an accident, so just imagine how much worse the clutter could be. Also, people, please containerize your web browser. Your web browser is often on the front lines of your system’s security, so putting it in a container is a really good idea.
Talk about breaking things. They broke support for USB floppy drives! It's now constantly attempting to read the floppy even when there is no floppy disk in the drive.
As for the dotfiles being less accessible/visible, it would not have been a problem if every program embraced the standard so that everyone knew what goes where. The benefits of cleaner home directory and all configs being in one place greatly outweigh the drawbacks of having to open only one more folder.
You are expressing my pain very well. The dot files are a real mess. They clog my home dir even if I started the app only once and uninstalled already.
@@MOOBBreezy given some of the responses to the projects featured in this video, the developer's of the projects seem hostile to the idea of even supporting the old way ($HOME) and the newer way ($XDG}. It seems reasonable to support both due to legacy since it literally only requires an if-statement and could be encapsulated within a function to simplify matters.
Yes, its what I intended to do for a while, but laziness, you know. For a time I was hoping maintainers would do that instead and save the end users of the chore.
the thing is.. if the devs are against this and you go ahead and fork the project just to add this one change, you'll have your wish but your fork will probably be dead after this. forking isn't that magical solution to everything
I very much appreciate the XDG standard. 👍🏻 It has made finding the information on my system I’m looking for much easier. If everybody adopted it, we could even build GUI tools to easily allow new users to configure “.desktop” files, for example.
@@laughingvampire7555 Because when you've got 100+ items in your home directory, even finding the ~/.foo directory can be a pain unless you know its exact name. The real beauty of XDG is that it's a *standard*. I don't care what we all ultimately agree on as long as we do--and as long as you keep your config files out of my home directory.
Migration and rewriting all the documentation and countless websites with how-tos and FAQs is a big big problem for any linux project. Making all the community knowledge incorrect doesn't seem wise. This problem probably wont see much progress while the mess that is AppData continues to be a thing in Windows. Evey program for Windows does its own thing in AppData. Cross platform projects like firefox can just do things the same way for every platform as is. Changing only for linux is a hard ask.
It costs nothing to have a function that looks for the old config and moves(convert->rm) it, even forever if it takes that long for everyone to migrate.
and could do a symlink from the old location in case it did the move and otherwise not create it at all. Transition without breaking old installations that may rely on the old locations, but don't mess on new installs.
I've created a folder called Temporal which is cleaned every time I suspend my laptop. I use it as my download directory and screenshots directory. Only if I want to preserve a file I move it elsewhere.
The one that always puzzles me are the developers who "fix" the issue by adding an environment variable. You have a hard-coded directory path, unless some environment variable is set, in which case you derive a path from the environment variable and put files there. Isn't that what XDG does? Why did it have to be $GOPATH? Or $RUSTUP_HOME? We have a set of well defined variables for that! Why not use that? The code challenges are exactly the same. e.g. how do you transition users and handle potential duplicate files. But now users have to worry about their environment variables, which are also an absolute mess under Linux. You have some rc-files that only apply to their respective shell, or a ~/.profile. Does that get loaded? What about login-shells? Desktop environments? Oh, that depends on the display manager? What about if you SSH into a system? And now I have to maintain that and make sure it works correctly for multiple apps, instead of them just using the XDG standard. *sigh* Yes, flatpak is awesome for that encapsulation. I personally think it should have gone in ~/.local/opt instead of ~/.var but that's not really an issue.
I'm not sure why environment variables are really an issue. Yeah, they don't all use the XDG_* ones, but as long as it's documented it shouldn't be difficult to deal with. I don't have GOPATH or RUSTUP_HOME set and I was still able to determine where to install them both, Rust in ~/.rust and Go in ~/go .
@@anon_y_mousse I'm not sure what you're trying to say here. The video and my comment are about wanting applications to follow XDG base directory specification. Not about whether or not it's difficult to figure out what path they will use. It's usually the other way around, we see the path they use and want to change it to something else. Guess what my $GOPATH is set to? Did you guess that it's $XDG_DATA_HOME/go? Then you guessed correctly. So the question is, why do hundreds or thousands of users have to do that in their environment profiles? That was my argument: telling users they can change the path with an environment variable when there already is such a variable (XDG_*) is not a very user friendly "solution" at all.
@@frustbox So basically your complaint is that a cross platform programming language doesn't use a Linux specific environment variable and instead requires the user to add their language specific environment variable, and that's just not user friendly? And don't you dare tell me it's an "open standard" when only Linux-based OS's implement that standard, and even then, not all of them.
Some time ago I wanted to create my own Linux distribution. I even wrote my own package manager for that and build packages based on LFS docs. And I had idea of patching Every Single Application to move their configs from home directory to at least ~/.config and fixing few other paths along with that :D
For the config files, I just have a big folder full of symlinks. can't be bothered to change config locations every time for every app. For cache and such I just live with the pain.
Well, in distrobox - unless you specify a different home directory for a container - it will litter your actual home directory and use configurations that are already there.
I've pretty much given up at this point. I've always **tried** to get things in XDG, but it just stopped being worth it when there are so many apps that you can't mess with.
Am I the only one who thinks it should be possible to use unionfs/overlayfs to create launch configs for apps so that they can place whatever they want in a fake home dir, and it would only be visible there for that app while it's running?
I think firefox shares the problem with those containerized platforms though, since you are saving multiple profiles for the browser which are basically independent to each other, there is only the profiles.ini that is clearly a configuration file. It does not make much sense to distribute them over the different directories again. I personally think when in doubt just put everything in XDG_DATA_HOME, though for the ease of using it XDG_CONFIG_HOME might be a better option, it is probably the first place people look for when they want to change stuff
"... a clean home directory...". Yea... I had that dream back in 1994. Hasn't gotten better. Though \.config did improve things a bit, except for the bloat in it. Would be nice if the virtualbox dot files would play nice in to .config too. Some of the venerable TUI tools could be moded to use \.config too (e.g. alpine, procmail, fetchmail, etc).
@@thingsiplay steam is one of these offending programs, which dumps not just one, but 3 files/directories in your home directory, one of them being a broken symlink that doesn't actually point anywhere
@@shallex5744 Interesting about the symlink. I was not aware of it. It points to ".steam/sdk32/steam" file. The folder is there, but it's missing the "steam" file. If it is broken, why not just delete it?
flatpak flatpak flatpak now you dont have to give flatpak apps full host access, when an app tries to open a "open file/folder" dialog, flatpak shows files on the host in the dialog and when you select file(s)/folder(s) in the dialog flatpak gives temporary access to the app for that file(s)/folder(s) same applies for if you try to open a file/folder with a flatpak app, and also drag and drop i always remove host access from the flatpak apps now, if they have it by default
what if we don't use the home directory for storing personal files ? mount a separate partition or subvolune and simlink it to home directory. This partition should comtain your downloads documents and all the files you create and leave the home directory alone for apps to use ?
The usual way I see this get supported is for people to add support for the new XDG location and if you have that, don't bother using the old location at all. A bigger issue for me is that a lot of stuff DOES NOT just live in one dir even in ~/.config … if I want to revert to defaults for a DE for some reason (I'll need to do this when I move to wayland, for example), what do I remove from .config? Honestly, what I will end up doing is moving .config out of the way, putting some stuff I know I want back, deleting the cache directory, and run with that. That's suboptimal.
Just making the xdg method the default and supporting the traditional behavior when it's detected or explicitly specified would easily transition users from one standard to another where they don't care and let people clutter their home directory if they want. I know it isn't as simple as it sounds but it's a method that works for a lot of people and if the directoy locations aren't hardcoded into every place they are needed it's a simple change to pick a standard at startup and use those values for the rest of the runtime. Choosing what goes where is probably the bigger problem by far.
When is it gonna be normalized to not trust third-party apps and sandbox everything, so if stuff try to create files outside their own box they just get tricked into remaining inside and outside stuff is only accessible when the user permits (or based on system rules that people can install for convenience for known needed exceptions and stuff like that) ?
~/.local/state is another cool dir Also, I have a ~/.shame, that all the 'partial' apps go to. Then I use symlinks to slice and move them into correct directories
Where does .bash_history go in the XDG standard? .local/share? .cache? .config? I can make a case for any of them, though the biggest stretch seems to be .config. I know about the XDG standard, and if I were to write a new command line thing, I would use it. I do think though, that there are a bunch of cases like .bash_history that aren't so clear.
.bash_history you could argue data or cache, config definitely not. The seperation between the 2 is cache shouldn't damage the core function of the project if missing it should only slow it down.
Why into hidden directories? Why not put everything into hidden directories so that ls gives you an empty listing? When I can, I turn on options to list hidden directories. I'm not big on hiding things from myself, either in computes or in real life. Oh crap? I hit the dresser again! Its invisible!
So your dresser is made out of transparent material then? I guess that analogy makes sense for your home folder, and I suppose you always use `ls` with the -a and -R options? I would suggest -A, but that would hide '.' and '..' from you.
If a project ends up supporting it, wouldn't all they have to do is just make it an environment variable? They don't have to change any of the defaults. Something like "MINETEST_CONFIG" and change that to your config folder. That's a simple way to make everyone happy.
but they would need to check 2 different directory or have check each time they want to call upon the configs which in some applications can be a small performance hit
TBH bash doesn't surprise me because it seems like a lot of the people who are particular about using bash over zsh or fish or other modern shells are extremely conservative people who resent things like systemd for changing the way they administered their systems 30 years ago. This problem isn't exclusive to Linux either, there are a lot of Windows programs that still use the old standard of "dump things in the program install directory" and since C:\Program Files is locked down in modern Windows versions, this can make dealing with config files an annoying ordeal involving digging through the VirtualStore directory, or the program simply won't run properly unless you either install it outside of C:\Program Files or run it as root. The idea of a clean, consistent, elegant computer system will always only be a fantasy because human beings are and have always been messy, petty, recalcitrant little bitches who will fuck up all your attempts to make your system consistent and beautiful and high-speed-low-drag, and many of them have been doing things a certain way for decades and won't change. In a hundred years, assuming industrial civilization hasn't crumbled into dust, people will still be building layer upon layer of new stuff on top of Unix ideas from the 1970s because "we've always done it that way".
I try to obey the standard. My main issue with it is that I HATE that they chose fucking dotfolders for some of that shit: make it be ~/config, not ~/.config, and so on. I want to change XDG_CONFIG_HOME to ~/config, XDG_DATA_HOME to ~/share, and so on, and then delete their original locations, but that's going to mess up those programs that have hardcoded ~/.local/share, etc. ughhh Also kinda annoying that there can be a ton of overlap between possible directories for a given file, but whatever, just ruling XDG_DATA_HOME by default should be fine. And to solve the program of split files / stuff hard to browse, symlinking ~{config,share,state,cache}/${app}/* to ~/app/${app}/ or something of the sort with new files by default being symlinked INTO XDG_DATA_HOME should fix that issue and give you the best of all worlds, ..right? My only other real issue is not so much with the standard as with the X Desktop Group itself: they are unfortunately now extremely, horribly, [forcibly redacted by youtube], and I want nothing to do with anything like that. But I can put aside my extremely justified abhorrence of effective promotion of violation of people's rights and lack of critical thinking and other objectively bad and quite literally [forcibly redacted by youtube] stuff for stuff that's itself superior. I just won't interact with them at all and pretend they don't exist while I use their good products.
hell even with stuff like windows where AppData exists (essentially the config and local file and cache directory for applications) you still see applications not caring, ooh here's a new bullshit folder in your documents directory, oh and here I'm dumping this bs in your User directory and ooh I'm just putting everything in my installation directory (Looking at you steam)
Ok I can understand why some developers are not keen to support the XDG specs. Having all of your program files under one directory is easier than having them split between the various XDG_XXX paths. Perhaps instead of trying to get them to comply with XDG, we just tidy things up a bit. Like Snap and Flatpak, why not have a single folder ~/.legacy where apps not wishing to adhere to XDG can put their hidden folders. It is going to be much easier to change the software to do this,rather than implement the XDG spec.
It would literally be the same thing. Figuring out where to put config files with XDG is as simple as reading the shell variables. Just pick one, and if it's set use that path, otherwise use ~/.whatever .
In this case, windows is actually better than linux, it has functions that allow apps to easily place config/data files in folders (namely %APPDATA%) that won't bother the user. The XDG standard is not too easy to implement and not all developers will go through the truble. If this was all handled by the OS there would be a clear right way of doing it, but the problem is that linux is just a kernel and the OS layer above varies from distro to distro. PS: I think that the reason why Minetest doesn't follow the XDG standard is bullshit. Minecraft puts his files in the appdata folder on windows and it requires traversing 3 subfolders to access the Minecraft data folder, but still even young kids are able to access it.
don't they just have to run a getenv() function in their code to check for the existence of the XDG variables, and then if the variable exists, place the config/data there, and if not, place it elsewhere? i've seen that in a few codebases, it seems easy enough to me with only a few lines of code required
Umm, I don't see any difference between using %APPDATA% (%LOCALAPPDATA%) and $XDG_CONFIG_HOME ($XDG_DATA_HOME). Both are simply environment variables and in both cases decision to respect/disregard them is up to the app developer.
Yet again I find myself wondering why this is an issue. I personally prefer each app to have their own .[app] folder in my home directory so that I can find their configuration files easily. If they obey the XDG standards then that's cool too, as long as they keep things in their own folder I'm fine with it. If I had a ~/config folder and everything went into individual [app]/ folders in there, I'd be fine with that too, just so long as they're either in one visible folder or a bunch of invisible ones I don't see why it would matter to anyone. I've got three lines of files and folders that are listed in my home directory and nearly all were created by me. I don't need to ls -A my home directory, but if I was looking for something, ls -d .[apps_first_letter]* works fine.
I think the distinction between config files and data files is a little silly. Cache files are much easier to define, but for config/data I think there should be a single folder for both and that the app developers should partition this folder as they see fit.
I'd argue that config files would be savegames, ini files and etc while data is stuff like assets. But that's a simplified way to look at things because as soon as "dlc", "mods", "plugins", "extensions" or etc is introduced, it doesn't quite work
@@TheExileFox I would argue that savegames are not config files since they do not configure the behavior of the program. Are they data? Are they config? It's a bit blurry for sure - blurry enough that a dev might want to just put it in either place without thinking about it too much. The standard is useful for most unix command line tools, but it gets weird with a lot of GUI apps and video games and such
@@snail8720 I would argue that save states are configuration files since they configure the game to continue where you left off. However, I would also argue that it's a pointless distinction since they should be separated into their own category of folder in the folder for the individual application in question.
Clearly this is a source of pointless confusion due to the unnecessary distinction between data and config. I also lend myself to the view that the individual application should have a single config/data folder and that they should simply create subdirectories for further customization.
Год назад
I would like to counter the "It's annoying that things aren't in the same directory" with: We've literally had it like this for system applications since the inception of FHS with /etc and /var. It hasn't bothered me yet, and I am a Linux sysadmin.
yeah, .config is literally analogous to /etc, .local/share to /usr/share, .cache to /var/cache, and so on. it's just following the basic unix-like directory structure but for the user's personal data
I'm pretty indifferent on this issue. Hidden files are hidden for a reason. It can be a little annoying when different applications keep their files in different places, but I really don't mind provided it's clear in the documentation (that's what it's for!) I do think there probably just isn't enough awareness around the XDG standard, especially among cross platform developers like you said.
Remember they’re not really that “hidden”. On a multiuser system, the existence of a file with a particular name in your home directory betrays the fact that you have used a particular app. That’s a potential invasion of privacy.
@@lawrencedoliveiro9104 Sure, but I will only ever see hidden files if I explicitly ask for them. I can see your point about privacy on multi-user systems though.
Lost cause rant - pushing a standard on Linux is like trying to squeeze out the last bits of toothpaste (or, if you prefer, pushing non too-viscose excrement through thin, badly angled plumbing…) - you either enforce it for all and without exceptions - resulting in pissing people of that don’t want to change or a few zillion drop in replacement forks that dilute your traction and support and simply replace you - or you leave it open choice so it will be a free for all turkeyshoot for whoever wants and is willing… given developers are in general not a willing crowd for work and changes you can surely guess the result… In short: you will be unlikely to fix tech debt and you need to live with until forever. :)
@@BrodieRobertson yes, thank -insert your preferred deity here - for that. It’s just very difficult to change historical debt and convince everyone of a benefit so adding a new standard and having it succeed is rather touch and go due to the open nature of it all. For a standard to get widely adopted and accepted it needs to be really, really good to prevent some new standard being invented to replace said new, unadapted standard or you need to enforce it, hard. I assume the famous cartoon is known?
I don't like the standard, to me it doesn't make things "cleaner" to me it makes them dirtier with nonsense fixed organization mixing all the software packages, to me what is clean is to have a clear distinction per package, per application.
why should anyone use ~ for one's files on a pc totally escapes me ~ is for config, thumbs, cash, & general crud /DATA is for a data partition, includes /DATA/MAIL did so since Win98FE, multibooting with everything incl Linux and Chtulu
Those files are usually user-local configs, in the context of a multi-user system (which is still common, especially on servers), sharing file configs would clobber each others configs. For the purpose of data and cache they can technically be shared. But then it becomes a security issue. It's easier to just have a user home. I usually use /local for non-private data and use XDG home for configs and private data
@@SkyFly19853 maybe until it gets widely adopted. Linux was made in 1992 then gained widespread desktop use...... I don't even know how to measure that. I'm not a dev or a CS graduate or anything, this is new territory for me. Anyway I like to overextend on promises and projects, give myself a lot of leeway. Look if Redox comes earlier than that I'd be really happy. As for Zircon, I'm technically excited for it but can't help feeling we're in a 2008 android Google is the hero of the people situation.
Nope because if you push some DOT directories under other locations it will make things more confusing, and if you backup unsafely then you will get secrets moved incorrectly. Like .ssh should be separate and make sure they are correct. If you have two places which works is there a primary and secondary can people be confused or used by malicious actors by using a different location.
I am sorry but I am gonna comment this on every video I hear this word on every RU-vidr I follow from now on (Out of love...mostly) haha Reason? It is driving me nuts because every American RU-vidr does it It is pronounced "et cetera" and not "ek cetera" Please spread this message so it will hopefully become a standard for all Americans and hopefully in the future ease my asperger brain (Yes I am in the spectrum) from going bananas! Keep up the good work though, I love your content
Nothing to do with the app. The OS simply needs to control where stuff is installed. a app should not have the capability of putting anything in my home dir without my consent.
I honestly don't understand why it is a big deal to you and many others that these programs shouldn't save their configs into the $HOME directory. Other than having a consistent setup for backups, I don't see any benefit in moving all $HOME files into config, cache and so on. I only speak for myself and say that I don't care. To me the $HOME folder is the folder where configs go into too. So from my perspective, the programs do not need to support it. But I wish they would for those who care, like you.
i don't like having files and directories there that i didn't put there. to me. at the very least, the root directory of my home should be something i have control over and can make it look a specific way how i want it to, just like how i would find it offputting if the root directory of the system, /, was subject to random new directories being added to it. it just doesn't seem right to me.
Remember they’re not really that “hidden”. On a multiuser system, the existence of a file with a particular name in your home directory betrays the fact that you have used a particular app. That’s a potential invasion of privacy.
@@lawrencedoliveiro9104 If you think the existence of a file in home directory is a privacy issue, then why is it better if the program can lookup XDG or .config directory to violate your privacy? I don't get this argument. Edit: Also on a multiuser system people don't have access to your home. And if they do, then they have access to the other config files too. I understand that others want to control the home directory. I am just saying that I don't care personally about programs putting config files in root home. Maybe it's the way how I organize my stuff. But I agree that every program should at least support the standards and be configurable at least for those who care.
