- cross-posted to:
- [email protected]
- [email protected]
- [email protected]
- cross-posted to:
- [email protected]
- [email protected]
- [email protected]
You must log in or register to comment.
Here’s the closest thing we have to a solution: xdg-ninja
It looks in your home for known files and folders outside of the proper xdg locations and tells you if and how you can move them to their proper place
I wish everything was put into ~/.config or whatever the proper place was. Oh you’re used to your ssh config being ~/.ssh as it has for years? So make a symlink! Everyone wins.
Monocultures are great every 20 years, but Spock would say ‘IDIC’.
Systemd, networkManager, ‘consistent’ naming; were it not for bleeding edge vs enterprise, and the packaging differences they bring, you’d only have the logos to discern SuSE from Kubuntu.
I have recentlly created a data directory in my home dir, and moved almost everything I need to it. Even configs and program data are in it somewhere I find ok, and symlinked to the xdg dirs (I know i can make my new location the xdg dir for config and data, but this way I selectively add stuff to my now main config, so it remains more pristine)
fraid I generated a tl;dr for this rather verbose article:
“Home directories are a mess because too many apps ignore XDG spec and dump dotfiles everywhere. The problem isn’t just legacy software—new apps do it too, often out of ignorance or laziness. Windows has similar issues with profile folders. Fixing it requires devs to actually follow standards, but many resist due to inertia or ‘my way is better’ thinking. Users should push back and demand proper XDG compliance to keep $HOME clean.”
my favorite bit is how hostile some are after all this time about xdg beyond a simple WONTFIX https://wiki.archlinux.org/title/XDG_Base_Directory#Hardcoded
auto main() -> intWhat programming language is this even?!
Why would anyone bother writing it like that? That just seems like
int main()with extra steps. Like does auto enable some compiler optimisation of the return type that I’m not aware of?Defining the return type that way can be used when dealing with template sorcery - there’s no use for it here though, not even for readability in any way.
Looks like C++.
TIL that you can declare return types this way in C++.
I never understood why they added that
They’re useful for templates because the trailing version is resolved later
because explicitly declaring types can be redundant, if the compiler knows a lot of the times you should also know
also because some types are extremely cursed: see std views/ranges
Among other things it lets you define the return type in terms of the arguments to the function.
yes please. its a big peeve for me and thats not even exclusive to linux.
its dumb to be so contrarian about something like where the directory will go. be predictable for us and just respect the fucking standard, it will make everyones lives that little bit easier in the long run. mobile oses simply just force them to write in a specific directory, maybe its necessary here too.
I hate all the cruft in my home directory, but I also hate when stuff suddently stop working after an update, or when all the documentation online talks about something that doesn’t work on my system or is not there anymore. Developers are the ones that will have to deal with people with these issues, so I can see why they are reluctant to implement the naive solutions that some ask for.
We could do this already with flatpak apps
Not a ringing endorsement. Of anything.
Yeah, flatpaks that just write into $HOME/.var are a prime example of how not to do it.
its a step in the right direction. that way all flatpak app data is going to be there, no fuss. well, some fuss but much less so.
My home directory has its own nearly full 300gb partition, so it could be better…
While I enthusiastically agree with the whole thing, I can somewhat get behind RenderDoc’s “making it configurable would take some work”.
However, Flatpak’s “fucking cry about it” attitude is why I’ll avoid using Flatpak for as long as possible.
