Not at all.
Microsoft Office always used custom widgets; the Office division wanted their new toys for their package, but they didn't want to wait for or to be limited to future Windows versions, so they shipped their own, much to the chagrin of the Windows division. After Office shipped, some of them were incorporated into system, but they were re-implementations, not the versions used in Office, so they always were slightly different. Some of them were not (remember the auto-hiding menus in Office 2003?)
On the Adobe side, even relatively new and modern apps, cross-platform from day 1, like Lightroom, used custom widgets. For the "old" apps, they are using their own thing; they are not native on Mac either. It doesn't matter, that they were ported from MacOS, they grew their own thing. Photoshop was originally written in Pascal, and that doesn't matter either.
CADs that were written in pre-Windows days had their UI completely rewritten since then. Several times. Today, acad uses ribbon, and yet, the widgets are non-native. They sometimes need to do things, that are difficult with native widgets. And of course, they want to own their look and feels. Exactly like the Office team.
And then there was the theming craze. Later, everyone wanted their own branding. And then Electron happened.
> There's Unity and GTK+ as notable examples, but there are many others.
Unity is not a GUI framework. It is a shell (something like explorer.exe in windows, that draws the desktop). While nothing prevents applications to draw their own widgets (like Blender does, on all platforms, including Windows), there are about 3 modern, usable widget libraries: GTK+, Qt and Electron. Qt and Electron are used cross-platforms, they are not Linux exclusive. It is not simple to use GTK+ outside Linux, and it is not an objective anyway, so few people try.
Yes, historically there was Athena, Motif, and a bunch of others; there were cross-platform toolkits like Tk, there were cross-platform wrappers like wxWidgets. But most of them applied to Windows too.
> 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
I don't know, what specifically you are doing. Maybe your terminal emulator configuration is broken. It might ask for a terminfo entry that it doesn't support properly, or whatever. Contact the vendor of your terminal emulator and try to work it out with them. I don't have any problem with del key, neither on native linux desktop (gnome-terminal), nor with pc keyboards attached to a mac (macs do not have del key on their native keyboards).
> The Kerberos support in Linux is a hilarious joke compared to Windows.
The Kerbeos support in Windows is hilariously broken. It can kinit only in single realm (I'm routinely using several, at once) and it has to be AD. Neither Linux nor Macs have a problem with this (Macs are using the Heimdal Kerberos implementation, that some Linux distributions and Samba are using too).
> 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?
So for a broken Kerberos implementation, Linux is at fault?
To make things simple, just use sssd. Despite it being a Redhat sponsored project, it is available in other distributions too, including Debian.
> Kerberos as seen in Windows doesn't need kerbtab files
Oh yes, it does. Keytabs are Kerberos secrets; that's how Kerberos works. Windows just doesn't show them to _you_. They are secrets, after all ;). But otherwise, try "ktpass /h" in your favorite windows terminal.
If you mean that applications that use SSPI do not have to be bothered with them - that's something different. For something similar on the Linux side, see gssproxy (it is by default on on RHEL).
> hard-coded IP addresses
Neither does any other system. But I suspect it has something to do with your broken DNS. Or someone trying to workaround the broken DNS.
> It supports site-to-site roaming efficiently
Just not multiple realms, right?
> 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...
Check out www.freeipa.org. It is a nice, packaged set of apps, that include Kerberos, LDAP, PKI and more. It is vaguely comparable to AD; it has few things that AD doesn't have (HBA!) and vice versa (don't expect GPO). You can have multiple replicas, not just two, you can replicate among sites, etc.
There's just one problem, though: it won't work with Windows clients (easily). It works perfectly with Linux and Mac clients. For Windows, I've thrown in the gauntlet, created trust with AD domain and pointed windows towards AD (the superior Windows Kerberos support, yay!). But I hear there are people who managed to make it work with Windows clients in some limited ways (Kerberos only. FreeIPA LDAP has different schema than AD LDAP, that will not work with Windows clients, unless Microsoft starts play nice).
> Linux as-is simply cannot handle something as "complex" as DNS-based server discovery during auth
Querying srv and ptr records is not complex.
> The only vaguely robust, caching, standards-compliant DNS resolver for Linux is the one in systemd.
Systemd is not resolver. Systemd-resolved is. You are making exactly the same mistake are most systemd detractors, conflating multiple applications into one... Also, I guess that the makers of dnsmasq or kresd would take such claim personally. Especially dnsmasq, which is a resolver that has been used long before systemd-resolved existed.
> 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.
Again, it is nothing complex, you just have something broken and project from there.
> 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.
If you redefine "most" as "only Ubuntu", then yes. Otherwise, no. Other distributions are not using systemd-resolved.
SSSD is not DNS resolver either. It is identity/auth service. It won't make your gethostbyname() work, but it is capable of verifying your credentials. It is not Redhat-specific either, just developed by Redhat. It works perfectly with Debian too; it happens to be the easiest way to join kerberos-based realm.
> The idea of systemd is to move away from resolv.config, which is an ancient and fundamentally broken way of configuring DNS.
Not really true. Yes, resolv.conf is something that everyone would like to move away, but there are still applications, that expect they will read it and figure out DNS settings out of it.
For the same reason, OSX keeps resolv.conf too; but reading it could radically differ from what `scutil --dns` would show you.
> This then forces all DNS requests to traverse multiple processes and involve the network stack even if the data is in cache.
Since we mention systemd-resolved here so often, it should be noted, that it comes with nss plugin (nss-resolve). So it doesn't work as dns-proxy for most apps, like you describe, only for these do their DNS resolving by themselves.
> Contrast this with OSX or Windows, where the DNS client has a simple in-memory cache
Except it is not, in OSX and Windows it works similarly. See dnscache ("DNS Client") service in Windows, or mDNSResponder in OSX (yes, it is not only bonjour responder, it caches DNS too. In older OSX versions, it was done by Directory Service).
> 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.
Linux doesn't insist on this. Some people, which might be using Linux, do. I've seen many incorrect claims or configurations across all systems, Linux doesn't hold monopoly there.