It's about the dominant unholistic approach to modern operating system design, which is reflected in the vast number of independent, proprietary, under-documented RTOSes running in tandem, and eventually leading to uninspiring and lackluster OS research.
https://www.osfc.io/2022/talks/i-have-come-to-bury-the-bios-...
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.
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…!
To summarize:
> ITS (of PDP-10 hacker fame) - processes could debug and introspect their child processes. The debugger was always available, basically. The operating system provided support for breakpoints, single-stepping, examining process memory, etc.
> KeyKOS (developed by Tymshare for their commercial computing services in the 1970s) - A capability operating system. If everything in UNIX was a file, then everything in KeyKOS was a memory page, and capabilities (keys) to access those pages.
In every operating system, the basic unit of abstraction will be a process -- which necessitates a scheduler, some form of memory protection, some way for the process to interact with the kernel, and the notions of "kernel space" and "user space". There is a lot of room for innovation there (see ITS), but I suspect most of the room for innovation is in how an OS abstracts/refers to various parts of the system.
The Unix ‘everything is a file’ has done well because it works pretty well.
It also isn’t generally a security issue, because it allows application of the nature things we use for files (ACLs, permissions, etc), without having to come up with some new bespoke idea.
Five species of salamanders have similar enucleated red blood cells, but I can’t find out how long they last in comparison. https://pubmed.ncbi.nlm.nih.gov/18328681/
One theory is it’s an adaption to having unusually large genomes which would otherwise be an issue, but biology is odd so who knows.
DNA is the worst spaghetti code imaginable.
The design is such a hack, that it's easier to let the unit die and just create new ones every few years.
the human body can scale from 1 cell to several trillion without going down for maintenance even once all while differentiating to different functions
it can take a high level of damage and heal without needing a shutdown as well, most software crashes completely at the first exception
cells give you that highly scalable and fault tolerant system that we all want
doesn't it go down for maintenance approximately once a day?
Cattle, not pets
[0] https://www.computer-dictionary-online.org/definitions-c/cyc...
Back in the day I owned machines that did it both ways, but not a C64. My Atari computer also had a smart disk drive. Worked over something Atari called SIO, which is an early ancestor of modern USB. Back then, the Atari machine was device independent and that turned out to be great engineering!
Today we have Fuji Net devices that basically put Atari and other computers on the Internet, even to the point of being able to write BASIC programs that do meaningful things online.
The C64 approach was not much different, working via RS-232. But for a bug, it would have performed nicely.
Now, my other machine was an Apple ][, and that disk was all software. And it was fast! And being all software meant people did all sorts of crazy stuff on those disk drives ranging from more capacity to crazy copy protection.
But... That machine could do nothing else during disk access.
The Atari and C64 machines could do stuff and access their disks.
Today, that Fuji Net device works via the SIO on the Atari, with the Internet being the N: device! On the Apple, it works via the SmartPort, which worked with disk drives that contained? Wait for it!!
A CPU :)
Seriously, your point is valid. But, it's not really valid in the sense you intended.
In any case, I maintain the engineering wasn't at fault, having a CPU etc. Fastloaders showed it to be just poor software, and that's a point I did not make clear enough.
All to sell more outdated garbage chips made by MOS instead of using proper FDC controller on CPU bus with cheap standard floppy.
Basically commodore was gonna use an ieee-488 bus for the drive and then decided it was too expensive late in the design and switched to this hacks serial bus that bottlenecked everything.
Epyx games used the Vorpal format which gave 15x load speedup.
The point is, the speed issues weren’t really the 1541’s fault although GCR coding could have benefited from a HW decoder.
https://www.linusakesson.net/programming/gcr-decoding/index....
The fact they are running entire OSes themselves isn’t that big of a deal. I just hate having no control.
… I miss my NeXTs..
- C64 shipped with 6526, a fixed version of 6522
- C64 is incompatible with 1540 anyway
They crippled C64 for no reason other than to sell more Commodore manufactured chips inside a pointless box. C128 was similar trick of stuffing C64 with garbage leftover from failed projects and selling computer with 2 CPUs and 2 graphic chips at twice the price. Before slow serial devices they were perfectly capable of making fast and cheaper to manufacture floppies for PET/CBM systems.
For example, Intel's ME could be a really useful feature if we could do what we want with it. Instead they lock it down so it's just built-in spyware.
And remote management isn't bad if it's entirely under my control. It's the closed nature that makes me distrust it.
It's to remotely recover when Windows corrupts itself. (Which is far less common than it used to be.)
(Especially because wall clock time is not the only kind of performance that matters.)