> 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.
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.
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.
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.
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.
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?
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.
Network transparency is mostly irrelevant on modern desktop systems, X11 remotes modern apps poorly at best, and if you really need remote desktop access you know where to find RDP and SPICE.
The Wayland switch will be a win because X11 is almost pure cruft. The good parts are what was kept in Wayland.
That depends on your perspective. Why are you accepting connections from malicious X clients?
> Network transparency is mostly irrelevant on modern desktop system
For you, maybe. That's an opinion that many of us do not share.
> X11 is almost pure cruft
It's only cruft if you limit your use cases to stuff like GTK+ that decided to only use X as a dumb framebuffer.
> The good parts are what was kept in Wayland.
Except for a long list of features, such network transparency, support for copying PRIMARY selections in addition to CLIPBOARD, or overriding input events of arbitrary programs. Until Wayland supports these, it isn't compatible with a lot of my tools.
Just because something is "old" or has features that you personally don't mean they are "bad" features that should be removed. There are more use cases than those in you definition of "desktop".