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.