Is there any good gui application for mange these but also edit them in a user friendly way like getting a dropdown for a settings like: Yes/No, Country Sweden. Number size range etc. So include validation. Even nix os does not have that.
Tangentially related: I recently learned that there are tools for handling dotfiles such as chezmoi and yadm. I would suppose that after spending some time on backing up the dotfiles that matter one can purge the remainders without much issue. I also remember some tool that was made for the purpose of cleaning $HOME, but can not recall its name (if anyone knows please let me know).
…that’s assuming that apps actually respect that environment variable. The problem is that if the app is writing to ${HOME} then they’re already not following XDG spec.
You might wanna backup your dotfiles somewhere remote too. I literally lost dotfiles that I’d been building up for years because I couldn’t remember the password to my Linux machine after coming back from vacation. Funny enough though, a couple hours after nuking my OS I magically remember my password.
Unless you disk was encrypted, you could have booted up a live distro and back up the files you needed (or even overwrite the shadow file to get a new password)
In the late 90s I taught an intro course for folks who wanted to run *nix boxen (Solaris, IIRC). On the afternoon of the last day I had them swap places after lunch and gain root access to each others’ machines. It was partly for root passwd recovery and other maintenance tasks, but also to demonstrate that physical access to the box was a serious issue.
After two years of typing in the same boot pass on my same laptop at my same job I woke up one day and couldn’t remember it. Almost died trying. Right as I was reaching out to my admin it came to me.
Oof. Yeah, I once forgot my LastPass password literally less than 30 seconds after entering it on another device. Muscle memory versus active memory kind of thing.
I absolutely despise the following directories: Documents, Music, Pictures, Public, Templates, Videos. Why? Because applications randomly dump stuff into these directories and fill them with junk files. I don’t want any application putting anything into directories I actually use, unless I explicitly tell them to. It is not possible to keep your files organized if applications randomly dump trash files into them.
Most the default installation path is Program Files. That needs elevation to write to. Fine when you’re installing something, but not something you want to need just to run the game.
Writing to %APPDATA% or really anywhere in %USERHOME% is guaranteed to have the right permissions for this user.
Granted, a lot of home PCs and gaming PCs are single-user environments. The “personal” computer. In that case there’s no reason games and applications can’t be installed in %LOCALAPPADATA%, and in fact, I think windows has an environment variable or registry setting for that.
It’s no different in Linux. You don’t want users writing to /etc. And you may expect multiple users. So all of that stuff goes to dot files in $HOME.
Granted, a lot of home PCs and gaming PCs are single-user environments. The “personal” computer. In that case there’s no reason games and applications can’t be installed in %LOCALAPPADATA%, and in fact, I think windows has an environment variable or registry setting for that.
I tried setting up my main windows gaming machine with a separate admin and user accounts, and tried to set it up to be multi-user. It didn’t work well. Most games worked but some random games had all sorts of bizarre issues, from only being able to run as admin, to requiring messing with directory permissions to just plain strange behavior but working sometimes. Steam also really didn’t like if I tried to run games as a different user and got very confused at times by the multiple user accounts
See, that’s dumb. Just because games aren’t enterprise software, there’s no reason basic security practice like least-privilege shouldn’t apply in development.
My Documents > My Games is kinda the default, but then you have steam cloud syncing and tons of games that default to various Appdata folder seemingly at random.
C:UsersUsernameSaved Games is a thing. Not a lot of games use it though.
There’s also C:UsersUsernameDocumentsMy Games which seems more popular with some devs. Though some devs inexplicably use the base Documents folder, which is just obnoxious.
But yeah, a lot of devs still use AppData. I read a post from a dev once that explained the advantages and disadvantages to each Directory, though I can’t remember the specifics, there is at least logic to why saves get stored in so many odd locations.
hough some devs inexplicably use the base Documents folder
Shoutout to Anno 1404 which creates no less than 4 directories in the base Documents directory each for slightly different releases for the game that they later rolled into a single release so your user data is strewn across all of them if you bought the most complete release of the game
Why can’t the save game and config.ini just be in the main god damn game directory?
You’d lose all save games every time you uninstall the game. We already had that in DOS/Win9x days and I am very happy that we moved away from this. Static program data and generated data should be clearly separated.
In Linux we have the XDG Base Directory spec for that, that gives you directories for cache, config, state and data, so everything is nicely separated. The only problem is that not every app follows it, bug reports can help.
I find Android handles this by far the worst. They have the core right idea with permissions that makes it impossible for games to write outside of their assigned directories, but the way they handle it your savegames go into an area that will be deleted when you uninstall the app. So the risk of losing savegames is extremely high. The alternative is that games require SD card permissions and than just write wherever they want. It’s basically all just a dark pattern to force games into using the Google Play service for cloud saves. Games that lose state and restart when you switch apps are also great.
I mean, in Windows they literally have a “saved games” folder and almost no games use it. I too hate that most fucking games have to save their shit to the Documents directory. That’s the directory FOR MY FUCKING DOCUMENTS, NOT GAME SAVEDATA
I have my own directories on windows. I never use system provided directories for my own stuff, it always sucks. And if I want to move directories between drives or just change permissions, all hell breaks loose because everything depends on the default locations… So I just leave them be if I can.
These places are a cesspool of junk in every system, it’s incredible. MacOS has this kind of shit too, just like Windows, with apps dumping crap there without a care.
Those bugs and PRs would just get closed without comment. Nobody is going to move a dotfile as a breaking change in any established software. You either get it right the first time or probably never.
That could break some peoples’ dotfile management, e.g. symlinks or git repos. I’d say deprecation notice and reading from both, at least for a while, is better.
In the old days (I’m 50+) tumbleweed drifted through ~/ apart from my drivel and I’d have a folder for that so /home/gerdesj/docs was the root of my stuff. I also had ~/tmp/ for not important stuff. I don’t have too much imagination and ~/ was pretty clean. I was aware of dot files and there were a shit load of them but I didn’t see them unless I wanted to.
This really isn’t the most important issue ever but it would be nice if apps dumped their shit in a consistently logical way. XDG is the standard.
Nobody is going to move a dotfile as a breaking change in any established software
We have oodles of counterexamples to this. GIMP did it, Blender did it, DOSBox did it, Libreoffice did it, Skype did it, Wireshark did it, ad nauseum. It’s not really as big a deal as you make it to be (or a big deal at all). You have a transitional period where you look for config files in both locations, and mark the old location as obsolete.
It’s not really as big a deal as you make it to be (or a big deal at all).
It’s a big deal to developers who were inconsiderate enough to do it in the first place. To do it in a non-breaking, non-confusing way requires slightly more care than doing it correctly to begin with. Hence why your $HOME is still a giant mess.
I mean if the code is well written it shouldn’t be hard in the first place. You likely have a sinlge code var for the config path already so instead of hardcoding it to be in $HOME make it check if the file is in XDG_Config, if not check if it’s in $HOME. If the file is in neither of these it does not exist -> create a new one in XDG_Config. If it does exist in $HOME -> Move it to XDG_Config.
I know developers are busy, and I don’t mean to berate them for their choices or work. I only have a two year Computer Information Systems degree and haven’t programmed a lot for a while, but supporting the XDG specification and remaining backwards compatible doesn’t seem to be very difficult or would cause so much breakage (of course, the amount of work would depend on the software and how the hardcoded path is implemented). I look up git repository issues for the software and tend to find ubiquitous examples like vim to be resistant to such change: github.com/vim/vim/issues/2034
This is really frustrating and leads me to find alternative software, such as neovim/doom emacs instead of vim, nushell instead of bash, etc., just to be able to clear up my home directory. I don’t mind if I have to wait for XDG to be supported, but many important projects just label the issue as “won’t fix”. I totally understand where you are coming from.
If you install config files to the new location and prefer the new config file location over the old, you risk accidental misconfiguration when a system has both config files (e.g. in a build pipeline that installs the software and then copies the config to the old location). It is not impossible to solve, but there are questions that require some care if you have a large userbase and solidified codebase. More care than it takes to do it right the first time.
A (very well used) program I use places files in $HOME. Someone argued for changing to $XDG_CONFIG or at least add that as an option. The dev, being used to the old school way, gave the exact opposite reason: that .config was just an extra level of organization when dotfiles are what the home dir is for. So I’m not sure how successful you would be with that approach.
To be clear, I am clearly on the side of XDG, myself.
Add comment