Hacker News new | comments | show | ask | jobs | submit login

  > 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.

X11 is inherently insecure. With Wayland, the compositor itself is privileged but all clients get access to only their frame buffers and event streams.

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.

> X11 is inherently insecure.

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".

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact