This is somewhat proving my point.
Windows has essentially only two GUI toolkits: Win32 GDI+ and WPF/UWP. Both follow the same very-high-level paradigms: Where the toolbar belongs, what the minimise/maximise/close buttons look like, how scrollbars work, keyboard shortcuts, clipboard behaviour, etc...
OSX similarly has only had a couple at any one time, such as Cocoa and Carbon.
These were not introduced concurrently, but simply represent the evolution of the operating systems over decades, with the explicit aim of standardising on the latest framework.
It is precisely the apps that fail to follow these consistent paradigms that feel jarringly alien.
Like you mentioned, Adobe applications are notable. They're ported from MacOS! They use a complex emulation layer to run on Win32, which is why they feel clunky and slightly weird even today.
Many CAD GUIs such as Autodesk products were developed in the DOS days, long before standardisation. Even Excel suffers from this, it's the odd one out in the MS Office suite because it was originally developed for Macintosh.
Sometimes this can be a good thing. Google Chrome introduced the tabs in the title bar UI paradigm, and it's now becoming standard.
> Since then, linux desktop blushes in envy, how inconsistent it could be.
Linux always had several competing GUI frameworks, many of which were introduced concurrently, and continue to coexist. There's Unity and GTK+ as notable examples, but there are many others.
> Has it occured to you, that this might be a problem at your end?
Explain to me what I'm doing wrong, such that on dozens of devices with many different terminal emulators the "del" key specifically doesn't work for me about half the time. What mistake am I making? Am I pressing it too hard? Not hard enough? Did I plug the keyboard in wrong?
Seriously though: I don't expect the Windows key to work on Linux, Solaris, or BSD. I do expect the Del key to work. Every time. Not just sometimes. Not just with some tools. Always. It shouldn't be a thing that can go wrong without special effort.
> You know that you can use SSH with Kerberos too, right?
The Kerberos support in Linux is a hilarious joke compared to Windows.
It's almost like... there's a parallel universe where 99.999% of Kerberos servers are not Active Directory. There are only University labs with a single IP address for the KDC because, meh, if authentication fails, what's the the worst thing that can happen? You just get to skip the CS lab class today!
Kerberos as seen in Windows doesn't need kerbtab files and hard-coded IP addresses. It supports site-to-site roaming efficiently, and can tolerate spectacular levels of infrastructure failure before authentication actually stops working.
I have an honest question for you: Do you have a reference to a good how-to for setting up robust Kerberos auth for Linux with vaguely comparable features to Active Directory? E.g.: Dual-redundant servers per-site, site-local auth by default, tolerance of arbitrary component failure, etc...
PS: I discovered how broken DNS is in Linux precisely because of Kerberos. Linux as-is simply cannot handle something as "complex" as DNS-based server discovery during auth, because it's not designed to have a reliable DNS client.[1] The only vaguely robust, caching, standards-compliant DNS resolver for Linux is the one in systemd.
> Nope, but it is configurable.
There is no timeout value that can be set that will make something as complex as Active Directory Kerberos auth work consistently on pre-systemd Linux. If you use 1 second, you'll get spurious timeouts when servers are busy, and 2 seconds is already too long because of the large number of DNS requests required.
> nscd
I tried it, but it ignores TTLs and its caching behaviour is simply broken. Some of these are known issues over a decade old marked with "WONTFIX". Here's a recent one, as an example: https://bugzilla.redhat.com/show_bug.cgi?id=1367565
RedHat's "sssd" works well enough, but it's the outlier. The system I was trying to fix was forced to use an older, pre-systemd SUSE distro.
As I said, I researched this for days. The issue was a show-stopper for the client, so significant effort was sunk into trying to fix it.
The outcome of the investigation was: "upgrade to a SUSE distro with systemd, all previous versions of Linux simply do not support DNS properly". That's just nuts, if you think about it for a minute. It's not like DNS is a new protocol!
> Systemd by itself won't do anything like that.
Well no, granted, but this is splitting hairs. Most systemd-based Linux distros however use "systemd-resolved", which is AFAIK the only working DNS client on Linux other than the RedHat-specific sssd.
The idea of systemd is to move away from resolv.config, which is an ancient and fundamentally broken way of configuring DNS.
Mind you, even systemd has issues! It cracks me up to read things like this:
https://unix.stackexchange.com/questions/466336/how-to-make-...
The stated problem: "If I run systemctl restart systemd-resolved then it will switch to another server and continue working, but it will randomly switch back to the offline server after a while and name resolution will again fail. How can I tell systemd-resolved to stop using an offline DNS server and quickly switch to one of the other ones it knows about?"
The insane response: "DNS professionals have known for long that if you want DNS service resiliency in any network, you do not leave that decision up to the client implementation. It is a too important decision to leave to the resolver implementations of clients to make."
That's just crazy. Literally crazy. This idiot is saying that you need either a hardware load-balancer appliance, anycast IP, or some other complex network configuration because the client "cannot be trusted"!!!
Meanwhile all other operating systems fail over to a working DNS sever perfectly fine within milliseconds, completely transparently to the end-user.
Check out this raw arrogance: "I implemented anycast DNS with iBGP and OSPF in two ISPs and one University in the past, with dramatic improvements in the uptime availability of the DNS service."
So what this Mr Bigshot Linux Admin is saying is that if you have a home network[2] that gets a primary & secondary DNS pushed down from your ISP it is YOUR FAULT for not configuring your ISP's iBGP or OSPF routing properly. Get good, scrub!
[1] This is a difference in philosophies, which is interesting by itself. Linux is highly modular, clearly separating client and server functionality. So the DNS client is just a client. It is not a "server" and does not perform "server functions" such as caching or failover. If you "want" server functions like caching, you have to run a local server on 127.0.0.53 and loopback to it. This then forces all DNS requests to traverse multiple processes and involve the network stack even if the data is in cache. Contrast this with OSX or Windows, where the DNS client has a simple in-memory cache and the DNS server has a full database that caches on disk as well.
[2] Or WiFi hotspots. Or 4G tethering. Or any cloud network. Or large corporate networks where you are not the network admin. Or any network using Windows Active Directory DNS. This insistence of having "one reliable IP" for DNS instead of "client-side failover between an alternate IP list" in Linux will never stop being a constant, endless source of hard to fix failures until it goes away and dies in a fire.