What about Android? The only thing Android shares with Linux is the kernel; the entire user mode environment is completely different, and this includes how 'users' and their data are handled. What about automotive stuff like VxWorks?
> I know plenty of engineers (myself included) which have no interest in trying to make things work in the Windows ecosystem.
Good for you; then why even bother releasing stuff for Windows? Because it checks the 'here's your Windows release, now bugger off' box? As a parent commenter says,
> it is because they thought 'with -target darwin I don't get any compilation errors. ship it!'
What happened to actually caring about users, their expectations, and user-friendliness, without worrying about platform dogmas?
As an aside, Windows has the objectively superior filesystem permissions model. It supports a massive variety of access modes, uses ACLs by default, and this is what allows straightforward fleet management with AD. It is easier to map down Windows ACLs to POSIX octal file permissions than to map up the reverse.
I don't 'bother releasing stuff for Windows', as I said - for me it's not worth the pain.
There's nothing 'hidden' about dotfiles on UNIX-likes, unlike on Windows where, as I mentioned, there is such a thing that is exposed by the OS filesystem API (it's a normal attribute and can be straightforwardly set/unset with right-click -> Properties; not an extended attribute which refers to a very specific thing).
That files and directories beginning with a full stop are hidden in `ls` was openly acknowledged as a bug[1] in the original implementation, that gave rise to 'a bad precedent'. Ergo all the repeated gnashing of teeth (see this very article) by UNIX-like consumers who end up noticing the dotfiles anyway, because a significant plurality of people use a variant of `ls -la` for the utility of its tabular output.
[1]: https://web.archive.org/web/20141205101508/https://plus.goog...
What you seem to be confusing it with is file system ACLs, something that *nix for quite some time. In fact it was available on consumer desktop environments in the early 2000s - roughly the same era as Windows (when Microsoft brought their NTFS filesystem to the desktop).
Anyway, don't feed the trolls and all that, you're welcome to enjoy your windows ecosystem - just don't expect all engineers to write their software specifically to cater for it.
Then again, you said 'don't expect all engineers to write their software specifically to cater for it', seemingly ignoring my and essentially every parent commenter's plea for developers targeting non-Linux platforms to be good citizens on that platform, and adopt platform conventions. If you're not writing software for Windows, then sure, no need to think about Windows. If you are, or you are going to, then this platform convention business needs to happen and needs to be done correctly, whatever your thoughts on Windows, or, in the thread's case, macOS, where application data should go in `~/Library/Application\ Support` and not dot-dirs in $HOME.
The conversation digressed into cherry-picking my explanation of 'hidden file'. I'm not sure the troll epithet is fair.
... But it's still much larger than everything else put together, no?
Personally (and most people I know) see windows as user stuff. Not developer stuff. So CLI tools etc are linux/mac-first. Lots of projects I find nowadays don't even have a windows build...
I'm not sure what a reliable way of counting for developer machines would be but I'd doubt it'd be anything like it was in the 90s and early 2000s - as a consultant it's pretty rare that I'd see a developer running windows these days, even big old enterprises like banks and insurance seem to be largely Mac for technical users it seems. I have no doubt that I'll have some folks jump on this comment and disagree stating they see the opposite and I'm in a bubble - but that is the honest truth (at least here in Australia anyway).