Hacker News Reader

Comment by delta_p_delta_x | Hacker News Reader

What I personally find more egregious are dotfiles and dot-dirs on Windows, created by half-baked ports of Unix-first software (such as `ssh`).

Windows has `%APPDATA%` and `%LOCALAPPDATA%` that are accessible with `ShGetKnownFolderPath`[0], using the appropriate `KNOWNFOLDERID`[1]; all programs should put their configuration and cache data in these paths.

Windows also doesn't know what the dot at the beginning of a file/folder means. Instead, it and NTFS have something that's arguably better: a hidden file attribute `FILE_ATTRIBUTE_HIDDEN`[2], that's again settable/gettable when a file/directory is created or polled, rather than regex-ing for a full-stop.

The worst irony is Microsoft software creating dot-files and dot-dirs on Windows[3][4][5].

[0]: https://learn.microsoft.com/en-us/windows/win32/api/shlobj_c...

[1]: https://learn.microsoft.com/en-us/windows/win32/shell/knownf...

[2]: https://learn.microsoft.com/en-gb/windows/win32/api/fileapi/...

[3]: https://github.com/dotnet/sdk/issues/8678

[4]: https://github.com/OmniSharp/omnisharp-roslyn/issues/953

[5]: https://github.com/microsoft/vscode/issues/3884

View on HN

I think "hidden" files are a bad idea. What's the point of hiding some of the files in a directory from user? It only makes things more confusing.

For example the folder might look empty but in fact it could contain thousands of hidden files. You want to delete it as it is empty but accidentally delete important system files.

Even worse, imagine if all files on an USB drive are marked as hidden. You see that the drive is empty but when you attempt to copy something to it see a message that there is no free space.

One more example. Imagine if you have a project and want to edit an .env file. But as dotfiles are hidden in Linux you don't see this file and cannot open it. It turns out that Windows Explorer which doesn't hide dotfiles is much better for developing projects with Docker!

There should be no hidden files. We cannot do anything with Windows and their MS-DOS legacy but Linux could stop hiding dotfiles in GUI and CLI commands.

i just always list dotfiles for years now.. and my IDEs too. mostly a non issue.

And I have to enable showing them on every system I work with (and add -a to every ls command, and google which option enables incldues them in pattern expansion). That is annoying.

Well.. ya. I set up my aliases and then forget about it again. Globbing is mildly annoying but i think there's a dotglob option or something you can set

Hidden files on MacOS were used sparingly—the main instance of a hidden file is the file which stores an icon for a folder, if the folder has a custom icon. Hidden files are only hidden from the UI, they appear normally in the command line.

The standard Unix folders (usr, var, etc) are also hidden—to be honest, this is a compromise because the Unix filesystem hierarchy sucks, but we are saddled with it for backwards compatibility reasons.

I did appreciate the relative clarity of old macOS systems—everything in the OS was in “System Folder”, the rest of the filesystem was yours, and you could freely move applications without breaking anything, uninstall them by putting them in the trash, etc.

Hiding thumbnails cache is bad because a user might believe that the USB drive is empty and doesn't have any confidential data but the thumbnails cache might still have them.

There is no need to hide such files. Just display them as system files in Explorer.

> The standard Unix folders (usr, var, etc) are also hidden

Again there is no need to do it. Just move them to a directory named "System files".

You can’t move “var” to a “System files” folder. This would break programs which expect /var to be, well, at /var. Long ago on macOS, everything was in “System Folder”, and it worked fine, but macOS has since inherited a massive Unix legacy.

Thumbnail caches are not stored on USB drives, they’re stored somewhere else, away from your files.

For people out there on macOS, you can press Cmd-Shift-dot in Finder to toggle displaying any hidden files (including the standard UNIX hierarchy at /).

By the way, I'm pondering setting my XDG_*_HOME vars on Linux/BSD to use the macOS paths like ~/Library, just to see if the standard is actually being followed.

I did a similar thing. I set XDG_CONFIG_DIR=~/ (normally ~/.config/). It works surprisingly well, though I encountered some edge cases that eventually made me give up. Also some programs don't know about XDG_CONFIG_DIR and just hardcode ~/.config/, but you can symlink ~/.config/ -> ~/.

>What's the point of hiding some of the files in a directory from user? It only makes things more confusing.

If a user doesn't know what .ssh/ or .bash_history are, and it can hurt them to accidentally delete or modify them, why show them by default? It's like training wheels on a bike.

>For example the folder might look empty but in fact it could contain thousands of hidden files. You want to delete it as it is empty but accidentally delete important system files.

If it is possible for a regular user to accidentally brick a system like this, it was doomed to begin with. If a user doesn't know what a dotfile is they shouldn't have administrative privileges, and if they do get them there is no safeguard to stop them destroying the system. It's not a dotfile issue.

>Imagine if you have a project and want to edit an .env file. But as dotfiles are hidden in Linux you don't see this file and cannot open it. It turns out that Windows Explorer which doesn't hide dotfiles is much better for developing projects with Docker!

In what reality is someone developing software and building Docker containers who doesn't understand the concept of hidden files? Seems awfully contrived.

> If a user doesn't know what .ssh/ or .bash_history are, and it can hurt them to accidentally delete or modify them, why show them by default? It's like training wheels on a bike.

This is really the problem with the home directory. It’s supposed to be the place where the user puts their files, but it’s also a place where applications put their files, usually without asking the user.

The battle is lost - the home directory territory should be ceded to applications and the user should have a separate space in which to manage their files.

This can sort of be achieved with the $XDG_CONFIG_HOME environment variable, but not all software respects it, so in practical terms it’s a lot easier just to leave $HOME to be the application config dumping ground.

It kind of goes around to the same point: developers are sloppy and assume that ~ or %USERPROFILE% has full read-write permissions, and treat the corresponding home directories as a free-for-all dumping ground.

Yes! I did that long ago, putting my stuff in /home/kept/. I'm surprised at everyone who still puts their files in ~. What a mess.

> If a user doesn't know what .ssh/ or .bash_history are, and it can hurt them to accidentally delete or modify them, why show them by default?

Because they are there. To prevent accidental deletion you can show an icon with a skull and crossbones or name a directory "configuration files" so that it is obvious what's in there.

> if they do get them there is no safeguard to stop them destroying the system

If the folder are named or labeled as "operating system" then the user will probably understand that it is better not to mess with it.

> In what reality is someone developing software and building Docker containers who doesn't understand the concept of hidden files?

Hiding hidden files is annoying because you have to add -a to ls command, have to add an option in Bash to include then when matching against a star pattern and to configure Explorer so that it shows them. It would be easier without them.

> To prevent accidental deletion you can show an icon with a skull and crossbones

This will make users more likely to delete it thinking it's a virus.

> If the folder are named or labeled as "operating system" then the user will probably understand that it is better not to mess with it.

Big assumption that most people know what an operating system is.

> Hiding hidden files is annoying because you have to add -a to ls command

Have you ever heard of aliases?

You are suggesting a workaround instead of solving the original problem.

The workaround is trivial and painless, whereas “solving the original problem” would require fundamental changes to decades-old systems conventions. I was responding to the “annoying” part, which is effectively solved using an alias.

> If a user doesn't know what .ssh/ or .bash_history are, and it can hurt them to accidentally delete or modify them, why show them by default? It's like training wheels on a bike.

You have permissions to prevent from accidental deletions.

Personally, I think hidden files are OK, but we have lousy defaults, regardless of OS.

By default, Explorer hides hidden files (and goes one step further and doesn't display file extensions: why???), so do Finder, Dolphin, Nautilus, and even `ls` by default.

Well yeah.. because they are hidden files. They wouldn't be hidden files if the default wasn't to hide them...

hidden file extensions by default are to "save" users from renaming files and borking the extension. Later windows UX improved the renaming to help avoid selecting the extension.

file extensions are the mistake here really not them being hidden.

Executability based on extension combined with hidden extensions is imho one of Windows biggest mistakes. Make an exe, give it the icon of a word document - no way for a layperson to know it’s a trick.

"Show hidden files" and "show extensions for known file types" are two folder options I enable on any Windows system I touch / within a few minutes of installation. I'll take a bit of extra visual clutter if it means I can actually see what all is in a folder, vs. just assuming I know.

When I run ls I don't want to see all the configuration files. Just my files. I think that's the point of hidden files.

> One more example. Imagine if you have a project and want to edit an .env file. But as dotfiles are hidden in Linux you don't see this file and cannot open it.

How likely is it that someone is going to want to edit a .env file and not know how to view hidden files?

> When I run ls I don't want to see all the configuration files. Just my files.

Well then configuration files can simply not be in the same directory as your files. Easy fix.

Your user doesn't have permissions to write to any directory that isn't yours. It doesn't mean configs have to be in your "documents" directory, but they do have to be in with your files!

The comment I was responding to was talking about the utility of files being hidden.

But they don't need to be hidden by being special, they can just be "hidden" by living in a subdirectory that you don't look inside.

Re accidental deletion, ntfs also has a "system" flag. Windows prompts if you delete one of those.

I don't find it egregious at all. Nobody should go out of their way to integrate with Windows APIs when files work just fine everywhere.

It’s basically the same as looking up $XDG_CONFIG_HOME on GNU/Linux.

That's just an environment variable while this ShGetKnownFolderPath thing is a Win32 API function. People should avoid directly depending on that stuff as much as possible.

People aren't obligated to "comply" with the XDG specification either. It's not a bug to just use $HOME.

You're directly depending on platform-specific stuff the moment you look up the user directory, because it's not $HOME on Windows either.

There is a difference between being cross-platform, and being Linux but mangling it so it technically works on other platforms.

It's just a different variable: USERPROFILE.

https://stackoverflow.com/a/42700844/512904

> being Linux but mangling it so it technically works on other platforms

Sounds like the easiest way to solve this problem. I don't blame or shame developers for choosing it.

This is simple and works everywhere:

  char * home = getenv("USERPROFILE");
  if (home) {
      // Use home directory
  }

The answer demonstrating the Windows API way has the following code to accomplish the same thing:

  WCHAR profilePath[MAX_PATH];
  HRESULT result = SHGetFolderPathW(NULL, CSIDL_PROFILE, NULL, 0, profilePath);
  if (SUCCEEDED(result)) {
      // Use home directory
  }

Yeah, I seriously doubt open source developers want to deal with this Windows bullshit. I sure don't. Maybe if you're getting paid.

'This Windows bullshit' is merely the Windows equivalent of a veritable zoo[0] of Unix/POSIX/Linux headers and functions including unistd.h, sys/types.h, sys/socket.h, fcntl.h, sys/ipc.h, semaphore.h, stdarg.h, signal.h, pthread.h, and so on.

Just because you aren't used to it doesn't mean it's 'bullshit'. Might I provide a counterexample to the 'simplicity' of Linux? Developing video games natively on Linux is such a pain point that the industry has standardised around simply translating Windows syscalls and Direct3D shaders to their Linux equivalents, because the latter is so heavily fragmented to develop natively for. Also known as Proton.

[0]: https://en.wikipedia.org/wiki/C_POSIX_library

Whenever dotfiles are mentioned, it's safe to assume we're talking about terminal applications and that the target audience is software developers. This stuff only really matters to us, people who actually care enough about the system itself to not only use a terminal but also to bikeshed configuration formats and file system trees. That's exactly what the article this thread is about and the comment I replied to were talking about: stuff like developer tools and ssh.

Honestly I don't even disagree with you. I think POSIX sucks. I think even the libc sucks. However there is no way you can look at the Windows API mess above and think it's somehow better than the portable and clean getenv function call. Maybe you can "get used" to that cruft but I can't. If I had to deal with code like that the first thing I'd do is abstract it away so I don't have to deal with it anymore. That's exactly how Windows is and should be treated by everyone.

Video games, your counter example, are probably the most platform-specific software imaginable. There's a reason pretty much everybody uses an engine these days. There is no way you can compare that stuff to getting a user's home directory and writing files in there.

Also, for video games it ultimately doesn't matter how sucky the APIs are since it's all about market share anyway and people will use whatever they need to get it done. First parties don't put in effort into porting games to Linux because they don't see the money. Valve puts in effort because it gives them their own platform that they control and therefore leverage over Microsoft and its app store. Emulation and compatibility layers are a proven solution when first parties aren't playing ball. If they don't want to make it work on Linux, people will make it work whether they want it or not.

The former does not in fact work everywhere, it only works on Windows. Once you have your #ifdef, there is absolutely no point in having the wrong Windows-specific code instead of the right Windows-specific code. Also, look at what you're describing as weird bullshit: a function call with an enum, instead of a function call with a string. The only difference is that you haven't bothered to familiarize yourself with the world outside of Linux, so it feels unfamiliar.

Also, you're comparing something it makes zero sense to compare. People are not saying 'you need to fetch $USERPROFILE without calling getenv'. People are saying 'you need to not store random garbage in $USERPROFILE'. Calling getenv("APPDATA") is a perfectly fine way of fetching FOLDERID_RoamingAppData, the same way you weren't going to bother calling getpwuid if $HOME was undefined.

> The former does not in fact work everywhere, it only works on Windows.

It's just some example code. Real code will probably try a number of variables.

> Calling getenv("APPDATA") is a perfectly fine way of fetching FOLDERID_RoamingAppData

Okay then. Top level post said you needed a Win32 function for this. If you can do that without those functions, I suppose it's easy enough to support.

> calling getpwuid if $HOME was undefined

$HOME is set by login and ssh to whatever is in the passwd database. Can it ever be undefined? Seems like something is seriously wrong if it is.

> Nobody should go out of their way to integrate with Windows APIs

  int writeConfigFile(ConfigFile file) {
  #if defined(_WIN32)
      // Windows-specific function
  #elif defined(__linux__)
      // Linux-specific function
  #elif defined(__APPLE__)
      // macOS-specific function

With modern C++, there's probably a way to do this in a nicer manner, and achieve runtime polymorphism with virtual functions or a lambda (function pointer) table.

As another sibling commenter wrote, .NET already has a platform-agnostic function to write to a `user program data` folder that nicely maps to the platform-specific directories. Other GC languages (Java, Go, etc) likely have similar abstractions.

As for scripting... A cross-platform project with scripts that also targets Windows should (in my opinion) have PowerShell `.ps1` scripts accompanying any `.sh` scripts. Better still, scripting should be done in a language that's truly platform-agnostic, like Python.

> With modern C++, there's probably a way to do this in a nicer manner, and achieve runtime polymorphism with virtual functions or a lambda (function pointer) table.

You proved my point. Creating an #ifdef mess with polymorphism, virtual methods and indirection is the very definition of going out of one's way to support something that really doesn't need any support.

If a developer writing in C/C++ is targeting Windows, then bringing in `<windows.h>` (and associated headers) is almost guaranteed, especially if said developer wants to work with native APIs (unless said program will rely on MinGW/Cygwin/Msys2, which are arguably worse, since they drag in an entire Linux directory tree per application).

This is just part of the cost of developing cross-platform, and I'm sorry, but to me, dismissing this as 'going out of one's way' is just being sloppy.

Are the developers of "Unix-first software (such as `ssh`)" targeting Windows though? I don't think so. They don't deserve to be shamed for this stuff. They aren't "sloppy", Windows is lucky to get ports at all.

> #elif defined(__linux__)

I felt a great disturbance in the source, as if hundreds of BSD users suddenly cried out in terror and were suddenly silenced.

No need for runtime polymorphism for this. The same binary won't be used in different operating systems. This is a classic example of misuse of C++ features just because they exist and a reason why I personally prefer programming in C. What I would do in a case like this is to have three source files each implementing the function for UNIX/Windows/Mac and the build system should take care of compiling the right one into the program depending on the OS.

This is a much better idea, actually. You're right that what I mentioned is a bad misuse of C++ features.

I initially did think of simply letting the build system handle it (CMake can do this excellently, as can Meson, probably) by simply choosing different source files for different target OSs, but when typing out the parent comment, I forgot about it in my train of thought.

Come to think of it, this is far more elegant.

The reason app developers think it's fine to dump them in $HOME is because Linux hides them. Those app developers do not bother hiding them on Windows. The specific functionality being used does not 'work just fine everywhere'. It is not the case that Linux functionality is How Computing Works with every deviation being 'out of the way', not even in a hypothetical world where Linux isn't the drastic minority of machines by an order of magnitude.

> Linux hides them

Linux doesn't hide anything. It's POSIX and GNU programs that choose not show anything that starts with a dot by default. As far as Linux is concerned they're just normal files on the file system.

It doesn't have to be that way. Personally I have my system configured so that all "hidden" files are shown because I hate the concept of hidden anything. I used to do this in Windows too.

> The specific functionality being used does not 'work just fine everywhere'.

It kind of does. "Program reads configuration from a file" seems like a really basic thing that every operating system supports. There really is no need to directly depend on any Windows API stuff. Even worse would be suggesting the use of the registry.

> It is not the case that Linux functionality is How Computing Works with every deviation being 'out of the way', not even in a hypothetical world where Linux isn't the drastic minority of machines by an order of magnitude.

And yet Windows is the system getting "half-baked ports of Unix-first software" here. Why should the developers be shamed for not going of their way to support Windows conventions for Unix software?

People develop software on and for the systems they actually care about. Windows is the legacy proprietary system people only support because it gets them paid. At least I hope someone got paid to port ssh to Windows because I sure wouldn't want to do it otherwise.

> Even worse would be suggesting the use of the registry.

I would actually argue otherwise: the registry is the perfect place to put configuration data, provided Microsoft's guidelines[0] on registry key creation/deletion and hive use are followed. I would argue every OS should have its own 'registry' for a universal location to set configuration for programs.

On the other hand, if every application has its own configuration file, then every application shall have its own configuration file parsing/serialising/deserialising routine. It's also what has led to this explosion of 'config file formats': .json, .yaml, .ini, .conf, .cfg, .toml, .xml.

I guess this is why people dislike systemd so much: it reminds them too much of Windows.

[0]: https://learn.microsoft.com/en-us/windows/win32/sysinfo/regi...

You appear to have an attitude of UNIX/Linux > Windows, which is unfortunate. The two OS families are different, but I personally believe neither is superior to the other. Both OSs suck in their own ways, both OSs are better in their own ways (this conclusion after using Windows and Linux both on a 70:30 time ratio).

Windows is in every way as modern an OS as Linux is, but just like Linux, has inherited strange baggage from its 40-year-old past, like 'a file cannot have COM in its name'.

> the registry is the perfect place to put configuration data, provided Microsoft's guidelines[0] on registry key creation/deletion and hive use are followed

Few people follow that stuff. I wouldn't be surprised if Microsoft's own people didn't follow that stuff. The result is of course a mess that users have to clean up with software like CCleaner or whatever people use these days.

It sucks even if those guidelines are followed. Configuration is data and belongs to the users. I know people who really like portable applications that they can keep on a USB drive and use anywhere and this registry bullshit breaks that.

> I would argue every OS should have its own 'registry' for a universal location to set configuration for programs.

And I would argue otherwise. The Windows registry is essentially a poor excuse for a proper file system. I think at least one Linux desktop environment tried to reinvent this crap and it sucked just as hard.

> every application shall have its own configuration file parsing/serialising/deserialising routine

The Windows registry values are essentially memory dumps of C types. It's perfectly possible to simply dump raw bytes into binary files on Linux too if you don't care about stuff like endianness. The result would be strictly superior to the Windows registry because the files are being stored in a real file system.

> I guess this is why people dislike systemd so much: it reminds them too much of Windows.

I like systemd.

> Windows is the legacy proprietary system people only support because it gets them paid.

Windows is the system everyone actually uses - even developers!. I write software because I care about people using it.

> Why should the developers be shamed for not going of their way to support Windows conventions for Unix software?

Because it's wrong on Unix, and even wrong on Linux, and once you are doing the right thing on Linux it is no longer out of your way.

Regular windows users do not visit $HOME often either. They work mostly in Desktop, Documents and Downloads. They can’t even “go up” from these anymore for more than a decade. None of the non-tech users I know would even understand me if I told them to look at their homedir. So yeah, it’s fine regardless.

Btw, many native, no-linux windows apps, including Microsoft ones love to create their bs folders like “My Games”, “Microsoft Visual Studio (c)(tm) <yearname> Pile of Whatever” or “Android Projects” right in ~/Documents. This “way” is unenforceable even in OS’es own company.

When using .Net 6 I use

  Environment.GetFolderPath( SpecialFolder.LocalApplicationData)

in Windows this maps to

  ~/AppData/Local

An in Linux to

  ~/.local/share

so it is configured well

I'm not sure I'd call that configured well. On Linux, share is supposed to contain static data used by the app, not the changing configuration that normally goes into appdata on Windows. For config the equivalent should be ~/.config/appname

He's getting the wrong folder on Windows too because that's what he's requesting when passing in SpecialFolder.LocalApplicationData. SpecialFolder.ApplicationData returns %USERPROFILE%\AppData\Roaming on Windows and ~/.config on Linux.

I prefer the app placing the config in the same place on every system. It makes it easier for me to find the file regardless of OS (to modify or back up with a script) and it's simpler for the app dev to write the code for as well.

I recognize this is probably because I first learned about config files on a Unixy system, it's not the "native way" for Windows, and other people have stronger cases for their preference, but this is my preference and I'm stickin to it :)

Your argument breaks down even between 'Unixy' systems. Linux programs that follow the XDG base directory specification write to those, whereas macOS programs tend to write to ~/Library/Preferences or ~/Library/Application Support, neither of which exist on Linux, or even BSDs.

When in Rome, do as the Romans do.

I’m a Roman and have no clue what these AppData/Romaning are for. Dotfiles that I’m aware of are my files and I expect them to reside in my ~ atrium.

> When in Rome, do as the Romans do.

Yeah, but then again, when you visit Rome for a short vacation as a tourist, the English versions of menus and such help, no?

Just saying, some degree of consideration for non-natives is a good thing, as it will help the tourism business generate more revenue. Same for OSes: give me at least an option of staying with my old habits until I get used to the new ones, then there's a higher chance I'll switch.

> I prefer the app placing the config in the same place on every system.

That is impossible because in Linux there is no drive letters and you cannot have the same path to a file as in Windows.

Windows is a lost cause anyway. Even Microsoft products (at a glance: IISExpress, Visual Studio, RDP, Powershell) happily dump their cruft in the Documents folder. I don't know where they imagine users should actually save the files they control.

Is “..” the official way to get a parent directory on Windows? Or do they have some other API and the “..” is just a nod to UNIX compatibility?

".." works fine in Windows environments.

> on Windows

There are many ways to access the filesystem on Windows. CMD.exe and PowerShell respect `..` to go to the parent directory, as does MSVC C++17 with `std::filesystem`, and .NET, with `System.IO.Path.Combine(String, String)`.

In PowerShell and .NET, there's also the `System.IO.DirectoryInfo.Parent` property, and of course, the equivalent `std::filesystem::path::parent_path` in MSVC C++.

There's an important consideration 'ChrisSD mentions here[0], i.e. whether resolving ".." is done lexically or by querying the filesystem. You may get different answers in each case if e.g. you try to resolve /foo/bar/../baz, when /foo/bar is a symlink to a different directory.

At least in case of std::filesystem, everything in std::filesystem::path is purely lexical. So, to get actual parent of some path, you'll need to go through std::filesystem::directory_entry and std::filesystem::read_symlink().

[0] - https://news.ycombinator.com/item?id=33312712

The difference between Windows ".." and unixy ".." is that the former is done lexically whereas the latter is a link to the canonical parent.

E.g. on Windows: "path\to\..\file" is always the equivalent of "path\file". Whereas on unixy systems "path/to/../file" may take you to a completely different parent directory.

That said, Unix shells can muddy the waters a bit. They may choose to act lexically with some commands.

> E.g. on Windows: "path\to\..\file" is always the equivalent of "path\file". Whereas on unixy systems "path/to/../file" may take you to a completely different parent directory.

Worth noting here that Plan 9 is using lexical names[1], and the Go standard library offers the function path.Clean[2] to achieve similar results. If your language/library/OS doesn't offer this behavior by default, it's likely a good idea to add/reimplement this function, unless you need bug-for-bug compatibility.

[1]: https://web.archive.org/web/20220824070659/https://9p.io/sys...

[2]: https://golang.bg/pkg/path/#Clean

It seems the only official native API for getting the parent directory from a known (full) path is PathCchRemoveFileSpec. But certainly C# and other similar platforms have functions doing similar things, and usually don't require a system API call anyway, it's just string manipulation - unless of course the path is relative to the current directory.

Hold your giggles until you learn that windows MAX_PATH is only 260 characters. Not just filename, the entire path.

Unless an app uses \\?\ prefixes and special API for navigation, which is rare, ime.

On Windows anyway, the root of the user profile is already filled with garbage directories, and so a few more dot-dirs and files feel par for the course. The advantage is that accessing your root dir is easier than typing out %appdata% in File Explorer.

One could say the same for ~ on Linux. 'It's already bad' isn't an excuse for sloppy programming.

Software should ideally adhere to OS norms. Better still, software shouldn't be opaque about where global/user-specific cache/config data is stored, and should prompt users to choose (or set sane defaults, again adhering to OS norms).

IMO the video game industry is a big offender of home-folder pollution, with saves and configs being splattered all over %USERPROFILE%\Documents, %USERPROFILE%\My Documents\ (which is a legacy holdover from Windows XP), %USERPROFILE%\Saved Games (which does have a corresponding KNOWNFOLDERID), etc etc.

If it's any consolation, games from Steam on Linux leak files all over the place on that OS too.

Right now the offenders in my $HOME not following $XDG are games, LibreWolf via Mozilla, Xmonad, GnuPG, and anything related to npm (with their maintainers closing any issued opened about support $XDG).

SteamApps/userdata, %APPDATA%/Publisher, %APPDATA/Developer, %LOCALAPPDATA%, the list goes on...

When making games, I have them store their config in %APPDATA% on Windows, although I do see the downside if there's a bug and I want to direct a customer to send me a log file that was saved there or just generally delete or move files around in there. It's not as familiar and safe-feeling for a nontechnical user to navigate to %APPDATA% is it is to just look in their Documents.

Reply on news.ycombinator.com