And furthermore, OS research is not only about building Linux alternatives. There are a lot of operating systems that have a much narrower focus than full-blown multi-tenant GPOS. So building holistic systems with a narrower focus is a much more achievable goal.
> As for the components, at least their interfaces are standardized
That's not true once you step into SoC land. Components are running walled-garden firmware and binary blobs that are undocumented. There's just no incentive to provide a developer platform if no one gives a shit about holistic OSes in the first place.
What is this in response to? GP never mentioned file interfaces.
How so? I can see the limited access control in Linux is an issue, and for this reason augmented security MAC (Mandatory Access Control) controls exist like SELinux and AppArmor.
But I don't see how the nature of everything being a file is a vulnerability in itself.
I'd be happy to learn how though.
In traditional unix-like systems, file descriptors are very close to capabilities. But the global filesystem namespace is a source of ambient authority.
There are a couple of ways to fix this issue: fine-grained per-process namespaces like Plan 9, so that the filesystem’s authority can be attenuated as necessary, so it becomes more like a capability. Or eliminate absolute pathnames from the API, so you have to use functions like openat() to get an fd relative to an existing fd.
I hear some of them are used to manage embedded components in GPOS systems. Oh, wait…!
As for the components, at least their interfaces are standardized. You can remove memory sticks by manufacturer A and replace them with memory sticks from manufacturer B without problem. Same goes for SATA SSDs or mice or keyboards.
Note that I'm all in favour of creating OSS firmware for devices, that's amazing. But one should not destroy the fundamental boundary between the OS and the firmware that runs the hardware.