5 ms·
Side note, but someone linked a great talk by OS researcher Timothy Roscoe the other day about a) the increasing heterogeneity of our computing devices, b) Linu
by wzdd 4y ago
Side note, but someone linked a great talk by OS researcher Timothy Roscoe the other day about a) the increasing heterogeneity of our computing devices, b) Linux's inability to really support same, and consequently c) Linux being used on the device, because the device has to "run Linux", but in increasingly smaller and more walled-off spaces, leaving board management which you'd normally think of as an "OS task" to device drivers or onboard firmware. The non-Linux-running processors on the board run an RTOS or whatever.
This would seem to be what's happened here with Linux running on, and really only in charge of, a small portion of the SOC. https://www.usenix.org/conference/osdi21/presentation/fri-keynote https://www.usenix.org/conference/osdi21/presentation/fri-ke...
To paraphrase what he says at the end of the talk, it would be a great idea to think about the kind of OS which could take these three cores properly into account.
- JoeAltmaier 4y agoYet Windows ran 16-bit, 32-bit and 64-bit code on the same core for years. Huh. Really folks. It doesn't take new research or exotic OS design ideas, to do something that has been common practice for a decade. Let's quit pretending linux is driving any innovation. It's followed behind in OS design, often by years.
- tomsmeding 4y agoLinux is, too. The thing being discussed here is supporting multiple pieces of _hardware_ in the same machine that have different instruction sets. I don't think Windows supports that either.
- alexklarjr 4y agothey do, using drivers, that is too novel idea for linux.
- monocasa 4y agoLinux has just as much native support for such things as Windows does, if not more.
- jazzyjackson 4y agoI mean maybe you're right at this point but it's not like the reputation is undeserved
- monocasa 4y agoI mean, we're going on close to 30 years or so that Linux has had parity with Windows for the kind of driver we're talking about: loadable kernel driver for a weird accelerator core that takes firmware but doesn't really fit into a driver model otherwise. On Linux this is a module that exposes a character device with one off ioctls. On Windows this a kernel mode driver that exposes a Device object with one off DeviceIoControls. I really don't think the reputation is deserved in this case, both kernels added equivalent support for this workflow back in the 90s.