> > When there are issues with a Linux install, it's usually transparent enough to debug.

> Bull. I've been using Linux for decades and it's always the same story. You have a problem with X, you do a search for your problem with X, you find a dozen solutions that don't apply to you because you're on a different distro or they're from 2013 when half the software stack was different.

Ok, so in some cases there can be complications. But once you've found (a/the) solution, it makes a sort of sense. In contrast, in the cases I've successfully found a solution to a problem on Windows, the reasons usually remain opaque. This, surely, is a side-effect of running a proprietary OS, and one I no longer have patience for.

For example, when I was dual-booting Windows 10 on two desktops a couple of years ago, I ran into major problems just getting Windows installed (taking far longer to ultimately install than it ever took me to install any Linux distro, from Ubuntu to Arch to Void to GuixSD).

I had downloaded the official Windows 10 image from Microsoft onto a usb thumbdrive and went to install. During the installing process, it failed with an obscure message about missing drivers. I try on the other differntly-configured desktop (different motherboard etc). It's the same thing. I think perhaps it's an chicken-and-egg issue with trying to install via a usb3 port (i.e. maybe it's missing usb3 drivers or something). Seems unlikely, but I try booting from a usb2 port. No luck. For good measure, even from different usb ports. But it doesn't matter, it's always the same error message during install. Seems like something which would be easy to debug, since there are in fact lots of Windows users, but I can't find anything similar described.

I finally find a post on some obscure forum which describes a similar problem. The suggested solution: wait until you get the 'drivers missing' error, and then unplug the installation usb thumb and plug it into a different usb port. (So it doesn't matter which usb port you start with, it will always 'miss' the drivers until you unplug it and plug it into another usb port.)

I thought: what a stupid solution, surely it won't work, but what the hell, let's try it for shits and giggles. Of course, that was the solution. That's completely opaque. The solution might as well have been sprinkling the machine with chicken blood while playing the Beatles' White Album.

I don't know how many hours were wasted trying to resolve that. After a year or so, I ended up wiping all of the Windows partitions. Too much headache.

It sounds like you have better experiences with Window. Perhaps you have the right magic touch that's needed.

^ I'm a confirmed Linux user these days, but this is accurate. Half the time when I break something in a serious way, the above situation obtains and I just scowl and do a clean reinstall.

Windows NT was designed by some DEC people with lessons learned from VMS, though certain microkernel-like aspects of it were influenced by Mach.

> They really ought to have, at minimum, aliased a lot more bash commands to Powershell 'cmdlets'.

First of all, I am of the opinion that PowerShell is significantly superior to bash+coreutils in many ways. If you took a step back from your familiarity with the UNIX stack and looked at it objectively, you might come to the same conclusion.

Anyway, I think aliasing bash commands to cmdlets at all was a mistake, because it creates the impression that they are compatible in some way, when they often function very very differently.

> It used to be so frustrating, having to look up all their weird, verbose commands.

They're verbose because they are descriptive. When you write scripts, this is an advantage. When you're not writing scripts, PowerShell has a lot of built-in short aliases you can use (gci => Get-ChildItem), and you're free to define your own at will. This is in addition to tab completion of cmdlets, variables, and argument names.

My understanding is the the Windows NT was influenced by the design of the Mach kernel, but it certainly wasn't itself the Mach kernel. I have a vague recollection of a discussion of some of the NT kernel designers being old Multics people (so that most of the extant OSes are in same way or other influenced by Multics). But I've never enjoyed using any of the versions of DOS/Windows. I surely would have gone into computer science if my experience in late high school/university hadn't been almost exclusively Windows (in contrast to my earlier experience with Atari computers).