I think the GP used the word "tuned" incorrectly / to make the wrong point here.

A general-purpose OS is one to which you can build a stack on top of it for any use-case you can think of, and it will cope with whatever stack you lay on it about equally well, because it hasn't been forced into a particular shape where it's much better at some things but much worse at other things. A "jack of all trades, master of none" OS.

Microsoft would call all consumer and server editions of Windows "general-purpose OSes." But Windows Datacenter Edition and Windows IoT Core would be non-general-purpose OSes — the former only exists to run hypervisors/SANs, and it doesn't support "stripping off" that layer, so if you used it for anything else, that layer would always be there, bloating things up; and the latter only exists to run on embedded devices, and it doesn't support "adding back" the extra frameworks and services regular Windows has, that would be required to use it for "more" than embedded use-cases.

An OS being "tuned" for a particular substrate (what the OS is goot at running on), meanwhile, has nothing to do with the OS's use-case (what can be run well on the OS.)

An analogy: each mobile OEM's spin of Android only works on that OEM's own phones, because that OEM's phones have the required hardware wired to the right SoC pins, and the Android spin ships with a BSP that defines a device tree that matches that expected wiring. Thus, those OEM Android spins are "tuned for" those phones.

But in the end, they're all just Android phones, and they can all do the same things. All of these Android spins are "general-purpose OSes." They're all made to enable you to put any Android software you like on top of them, and run it just fine. (Contrast Android spins made by industrial vendors specifically for automotive or kiosk use-cases, where a given car company or kiosk manufacturer then produces a hardware-customized-and-tuned spin of that already-appliance-purposed spin. You wouldn't use a car-infotainment Android upstream for other use-cases; you'd have to undo all the car-infotainment stuff.)

Azure Linux is exactly like those phone-OEM Android spins; or like, say, the vendor-specific Linux distros that ship as (usually binary-only) images for various Single-Board Computers. In all three cases, the OS fork is still intended to run anything a user might want to run on the platform the fork is forked from. In all three cases, the fork accomplishes that by relying on device-specific knowledge and capabilities that have been burned into their fork rather than upstreamed.

> The fundamental issue is that a GUI is a static abstraction over a CLI that allows for millions of potential combinations. You can only expose so many options in a menu before the interface becomes completely unusable.

But is that an issue? Macs have had this solved for almost half a century: You expose things in the GUI that normal people need, not everything. For hackers, they can still go to the command line to hack.

One thing that's been really useful for many years is the Help menu in MacOS. You click it and start typing the command you are looking for, and MacOS conveniently opens the menu and any submenus and shows you the command with a big blue arrow. Wouldn't this be easy to pair with a simple AI, so that people can more freely type what they want to do? Maybe even make it Spotlight accessible.

I like the visual and thus get along much better with drag-and-drop than any text based interface. So for me (and maybe your mom) the best solution would be that Sally was a window you could open and drag things to. Surprised that Apple and nobody else ever did this on desktop. At least on iOS, your friends are pictures that appear whenever you press share, but it's not perfect.