3 ms·

> Most other operating systems, such as OSX and Windows have consistent GUI toolkits. Has been not true for more than a decade. Between win32 user/comctl32/she

> Most other operating systems, such as OSX and Windows have consistent GUI toolkits. Has been not true for more than a decade. Between win32 user/comctl32/shell32 widgets, office widgets, xaml and uwp, saying nothing of the mirriad of third-party widget libraries used by applications by Adobe, Autodesk and other third parties, which one is supposed to be consistent and canonical? Somewhat consistent widgets in windows applications were last seen at the end of 90-ties. Since then, linux desktop blushes in envy, how inconsistent it could be. > I still can't use the del key like... 50% of the time I interact with non-Windows operating systems, particularly over SSH. Has it occured to you, that this might be a problem at your end? > The irony is that securely distributing SSH public keys is essentially an unsolved problem (unless I'm missing a recent development), whereas WinRM uses Kerberos to automatically negotiate a temporary key. You know that you can use SSH with Kerberos too, right? > If the primary fails, then DNS has failed, period. The primary will be tried 100% of the time with a 30s timeout before the secondary is tried. Nope, but it is configurable. Did you happen to have a misconfigured system? Default timeout is 5s; and your config option will be just capped to 30s max. > Failures aren't cached. Successes aren't cached. Nothing at all is memorised. TTLs may as well not exist. I guess you didn't notice nscd, part of the glibc since '98, either. > Linux with systemd will just instantly switch to the secondary DNS Systemd by itself won't do anything like that. You can use systemd-resolved, which is an optional part of systemd (afaik only Ubuntu uses it by default); but otherwise, systemd won't touch your resolver config. NetworkManager (default in RHEL7 and 8) will, though.

jiggawatts 7y ago
> Has been not true for more than a decade. Between win32 user/comctl32/shell32 widgets, office widgets, xaml and uwp, saying nothing of the myriad of third-party widget libraries used by applications by Adobe, Autodesk and other third parties 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 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-systemd-resolved-stop-trying-to-use-offline-dns-servers/466340#466340 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.
- vetinari 7y ago
  > This is somewhat proving my point. 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.

jiggawatts 7y ago

> Has been not true for more than a decade. Between win32 user/comctl32/shell32 widgets, office widgets, xaml and uwp, saying nothing of the myriad of third-party widget libraries used by applications by Adobe, Autodesk and other third parties 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 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-systemd-resolved-stop-trying-to-use-offline-dns-servers/466340#466340 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.

vetinari 7y ago
> This is somewhat proving my point. 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.