> How about defending these?
> 1. Unnecessary and confusing directory structure. `/etc`? Why not `/config`?
> `/usr` instead of `/system`, `/var` instead of ... well who knows. The maximum
> directory name length is no longer 3 characters.
I know yrro already explained the ludicrously inconsistent nature of the OS you're apparently defending, but I'll add in:
Why do I need to edit c:\Windows\System32\Drivers\etc\hosts (in what way is hosts related to bit-length or a driver?)
Why .htm rather than .html?
Why programiwanttorun.exe rather than programiwanttorun
/system is as overloaded a word as any in IT. /config doesn't accurately reflect what /etc is about (but in any case, the latter is not a great barrier to entry)
If you're complaining about limits on directory entries .. you're skating around on very thin ice if you're on the NTFS lake (compared to any of xfs, btrfs, reiserfs, ext2/3/4fs, etc)
> 2. Programs are mushed together and scattered through the filesystem rather
> than stored in separate locations. This basically means applications are
> install-only. Yeah, package managers try to keep track of everything, but
> that is just hacking around the problem, and most developers don't want to
> spend hours creating 5 different distro packages.
14,000 registry entries for
one suite of software ... how is that not 'mushed together and scattered'.
Applications are not install-only. Because package managers (or, rather, distributions) managed to solve this problem elegantly more than a decade ago, I don't know how you can credibly make this claim.
Is 'mushed together and scattered' a contradiction?
Building packages for a variety of distros is a solved problem (again, it has been for a decade or more).
> 3. Not strictly Unix, but the mess of glibc with respect to ABI compatibility,
> static linking, etc. is ridiculous. Musl fixes most of this fortunately.
It's hard to not sarcastically comment with the observation that the phrase DLL Hell did not originate within the nix world.
More pragmatically, I rarely (in twenty years) have had glibc issues. I think perhaps 3 times. All easily solved.
> 4. Emphasis on text-based configuration files. This is often ok, but it does
> make it hard to integrate with GUI tools, hence the lack of them.
The biggest complain with Win95 was the move away from .ini files (text-based).
GUI tools do not intrinsically have an issue dealing with text-based configuration files.
I posit the problem you're describing is the fact that text-based configuration files often contain useful human-readable components (which non-text-file config systems, such as 'the registry' lack) which is slightly harder to maintain using automated tools. But only slightly. As noted elsewhere, these are typically only a library call away.
> 5. Emphasis on shell scripts. Fortunately this is starting to change, but
> doing everything with shell scripts is terribly bug-prone and fragile.
Doing anything badly is fragile. Shell scripts aren't intrinsically bad - as evinced by the success of shell scripts.
I don't know many people who have significant experience with apt|rpm && sccm (for example) ... but I know a couple, and the fragility of shell scripts leads to fewer expletives than the alternative.
> 6. X11. 'nuff said about that. When is Wayland going to be ready again?
Are you suggesting that a system that completely disavows any network-awareness is preferable to one, designed >20 years ago, that does it fairly well?
What problems have you had with X11 that aren't dwarfed by citrix / rdp / single-user consoles / etc?
> 7. General bugginess. I know stuff works 90% of the time, but that 10% is
> infuriating. Windows is a lot more reliable than Linux at having things
> "just work" these days.
Sounds like hyperbole. If things in the GNU/Linux world broke 10% of the time there'd be a lot fewer people using it - and if Microsoft Windows was more reliable than GNU/Linux, there'd be a lot more people moving towards it rather than away from it.