Which one?

You still have devices?

I’m over here chilling with my a

• Rental flat, where I can’t make any modifications or else I’ll be evicted.
• Free TV that serves me ads, on the condition I don’t tamper with it.
• Leased car with a heated seat subscription.
• Vendor-locked iPhone that came with my mobile plan.
• Netflix subscription that still shows me ads.

I’d say the only thing I own is the clothes on my back, but those were repossessed yesterday for nonpayment.

/s

I just leave all config in memory. If the user really cared, they would never reboot.

/dev/null

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.

Microsoft OWNS not just gaming companies, but one of the largest gaming hardware companies and many of the largest game developers.

You’d think by now we’d get a dedicated Saves folder to organize this shit after this long.

Actual reason is system permissions.

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.

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.

They’re probably trying to handle per user config. But nowadays, there’s mostly only one user using a machine.

deleted by creator

The apps dumping files into foldes like Documents usually don’t care about the XDG_user_directories spec, iirc.

That’s not the only folder go creates. There’s also ~/sdks/go1.xy

That’s just the default location for what it’s worth. You can move GOPATH wherever you want.

The software can read from both locations in a backwards compatible way. Many tools already do this.

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.

They will if enough people whine about it.

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.

I’ve made about 5 MRs changing dotfile locations, and not once has it ever been declined

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: https://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.

List of software with hardcoded paths at this time: https://wiki.archlinux.org/title/XDG_Base_Directory#Hardcoded

You can add the proper location to the list of possible dirs. Fhen you can movd your dotfile

Old things like that get a pass. New tools and frameworks should definitely obey the standards.

Why aren’t all of these just normal directories under either .local (for data files) or .config (for configuration)???

Actually, I think the XDG directories should be under a single XDG directory either dotted or not (a better name would be OK with me) ~/xdg/Documents, ~/xdg/Music, ~/xdg/Pictures etc.

Is it a problem to change this?

Yeah, I think I tried it and it didn’t do something I wanted and so used a homebrew script for the same thing, but it or a similar package or script is definitely what I’d recommend.

That should work with dotfiles in .config, in the home directory, any other config you want to be portable across machines, etc.

I’m using the Snap Flatpack of Steam, but I’m thinking of wrapping that in an AppImage because screw all of these idiot distribution walled gardens.

You can manage symlinks pretty easy with home-manager. I’d personally setup symlinks for these app configuration directories if I don’t want them storing files directly on the disk I use for $HOME. It’s also done in a delcarative way that can persist across multiple computers.

You can absolutely use nix and home-manager without NixOS, you can even use it on a Mac!

Most of the tutorials I find are tailored to NixOS

I think that’s less true than you think. There’s definitely a lot of tutorials from people who do use NixOS… But this mostly doesn’t matter, using nix is more or less the same regardless of operating system. There is some stuff specific to NixOS, but that’s mostly just using nix to configure system services.

Is there an easy way to learn this for just the package manager?

That said… There’s not a super easy gateway to learning nix, unfortunately. The easiest way to learn is probably to try to package one of your personal projects, or by learning home-manager and trying to fully declare your home environment. Packaging programs in certain languages can involve having to learn more about the nix ecosystem than others (e.g., python is a little more complicated than what you’d need to package a simple C program, because python has it’s own ecosystem that you have to integrate with).

Probably the best introduction is the nix pills if you want to learn how nix works (not necessarily how to use it, but it will give you a really solid foundation):

https://nixos.org/guides/nix-pills/

Though, it’s really common for people to bounce off of the nix pills because they start kind of slow. If you can follow through them, though, you’ll have a good understanding of the nix language and how it’s used to construct derivations for building packages.

The nix language is much maligned, but it’s actually not as bad as you think going in (error messages can be ATROCIOUS, however). It looks a bit weird, but I think if you go in with the understanding that it’s “Turing Complete JSON” you’ll have a better time. Almost everything you’re doing in nix is building up attribute sets (which are basically just JSON dictionaries) which specify the dependencies and build stages of a project… But it’s not a static representation like JSON, you can call functions to do arbitrary computations to build up fields (e.g., I have some functions to automatically set up wireguard configurations from a description of the network layout of my machines, so it’s useful to be able to do this stuff).

For what it’s worth, I don’t understand the nix language or all the package manager functions in their entirety. I generally use what I need and that’s it. Most information I’ve required that is nixpkgs-specific I was able to find in the manual. home-manager has one as well and it’s been the best reference for me.

Yes, that is the one. Thanks!