4 ms·

I doubt "junior Microsoft devs" reintroduce what you think is somehow related to Linux. And a "sane" operating system is independent of shells (whether *sh or

• jiggawatts 7y ago
  > And a "sane" operating system is independent of shells (whether sh or PowerShell or cmd) and is also independent of the GUI running on it. No, it is not. An operating system is not just a kernel. It's a collection of components, of which the kernel is just a tiny part. Windows is the combination of Win32, WMI, DCOM+, Active Directory, Registry, NTFS, GDI+, DirectX, and so on. Take away even a couple of those, and you no longer have Windows. Applications are programmed not against the bare kernel API, but shims like Win32. Similarly, applications are programmed against the standard operating system shells. A Linux install script that requires "sh" will not "Just Work" on Windows. A program that requires CMD.EXE batch files will not "Just Work" on Linux, even if it could otherwise, such as a Java app. That's just the APIs and shell languages. The GUIs are the same. That's the human interface to the OS. An Apple OSX app ported as-is to Windows (preserving the look & feel) would feel horribly out of place. Other than the GUI, the only other human interface is the text shell. It's important. It's a significant chunk of the experience for advanced users. Directly porting Linux-isms to Windows is just as out-of-place as directly porting a Mac app to Windows. > Button action is related to the GUI you're running, not Linux. Switchable GUIs are an X-Windows thing. Most other operating systems, such as OSX and Windows have consistent GUI toolkits. Linux doesn't. Its arbitrary button click behaviour is insane. When your learned habit is to depress buttons for a second while thinking twice about potentially harmful actions, knowing that you can cancel by moving the cursor off and releasing, the outlier Linux behaviour is shocking in its indifference to 99% of the installed GUI base that existed at the time. > Delete key actions are related to termcap which indeed is historical. I still can't use the del key like... 50% of the time I interact with non-Windows operating systems, particularly over SSH. How is this still a problem in 2020!? Please explain why this has been simply unsolvable for all of this time. The 101-key layout has been out for 30 years. That's three decades. THREE! > Cursor key support I was being sarcastic at this point. However, you will still find people arguing with a straight face that ijkl movement is "superior", which is just hilarious. > Multiple clipboards Windows has one primary clipboard. One. It now has clipboard history, but I'm willing to bet that 99% of its user base is unaware of this feature. The standard for 99.99% of its apps is to not overwrite the clipboard on select, yet I've seen apps ported from Linux introduce this behaviour to have that "Linux feel". This is just as wrong as porting the Mac OSX look and feel to Windows. > All output becomes text, is actually a misnomer. It is that all output (by default) comes out of stdout and is an octet stream. That's splitting hairs. Practically all Windows APIs are Object Oriented, especially the ones used for scripting, such a WMI. They're not text-based. The notion that what Windows is "really missing" is a bunch of text-oriented Linux shell tools is just nuts. It already has native shells that are better suited to it, such as PowerShell. Meanwhile I don't particularly recommend PowerShell to Linux people, because its string processing capabilities are not particularly good. > SSH didn't exist when there were 300 baud connections Technically true. However, telnet did exist, it was just less secure. > SSH vs WinRM. Neither were around when the Unix TTY/PTTY/line drivers etc were established. The point is that I keep hearing Linux admins clamoring for SSH support on Windows, with the argument that Windows is hard to administer because it doesn't have a secure remote shell. Even though it does. They just don't know about it, because they use bash on Windows instead of PowerShell. 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. Be honest: what fraction of the time do you verify that the public key fingerprint of your first-time SSH sessions really match the fingerprints of the boxes you think you're connecting to? I'm guessing never... > But hey, tell us what you think about systemd. Sure: It's about time Linux caught up to Windows NT 4.0 I can't wait to hear the wails of anguish when the Linux world is dragged kicking and screaming into the Windows 2000 world of Active Directory and its magic powers called Group Policy and ACLs with more than 3 entries. I had just recently wasted days trying to figure out why some Linux box was basically locking up on a customer network only to discover that pre-systemd the secondary DNS doesn't do what you think it does. It's not a backup DNS server for the primary server at all! 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. The secondary will never be treated as a primary, no matter what. Failures aren't cached. Successes aren't cached. Nothing at all is memorised. TTLs may as well not exist.[1] If you have a process that takes multiple DNS requests to succeed, you now have a guaranteed connection timeout.[2] Meanwhile OSX, IOS, Windows, or Linux with systemd will just instantly switch to the secondary DNS and keep trucking along like nothing happened. You know... for redundancy. I looked this up, researched the issue at length. There were endless posts on the systemd forums asking for the legacy behaviour back, arguing that the evil systemd people were destroying some sort of precious heritage by introducing heretical notions from other operating systems like automatic failover. No logical arguments were made. Nothing sane was said. Just an endless torrent of "but that's how it always was". This is what I think of systemd: I wish there was more of it, and less adherence to 1960s accidental history. [1] I found it amusing that only RedHat had a working DNS resolver pre-systemd. The others were either insecure due to being abandoned, or did not follow DNS standards such as adhering to TTLs properly. We needed strict TLL support because load-balancers on the network were using short TTLs for some entries. [2] Anything complex like Kerberos auth to Windows or SAML auth to anything behind a load-balancer. This typically involves 5-20 DNS lookups. At 30 seconds a pop, it's a guaranteed authentication timeout for any reasonable DNS timeout. Even if the DNS timeout is dropped to the minimum of 1 second, this is outrageously slow for a middlebox that does authentication as a part of a high-performance API workflow.
  • vetinari 7y ago
    > 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.