For what it's worth, a holistic system only allows the user to bring their own code only above some layer. For Unix systems of ye olden days, that would be your C source code that you compile. For Chrome OS, that's gonna be websites and extensions. For Oxide, it seems like that is going to be VM images.
But it's important to note that these days, there will always be somebody who wants to bring their code in at a lower level. And the immediate reaction of all vendors is "But why would you want to do that?". Why would you want to bring your own Unix flavor to our hardware? Why would you want to run Linux executables on Chrome OS? Why would you want to run a different hypervisor on Oxide racks?
Those people will exist. And layers like BIOS and UEFI allow system vendors to say "Eh, sure, we don't think that what you're doing is wise, but whatever, here's a standard way we'll allow you to use". Holistic systems don't have these standards. They are only usable as their creators intended. And not everyone will agree with their creators intentions. But the work required to refit them to fit another purpose, which the hardware is very fit to do, but the software fights against, is usually too high, and you'll be better off using something that is worse, but left you an avenue to customize it for your purpose easily.
My main takeaway from this talk, is that we need some standards for phase-based booting, as there is some very cool improvements that could be done with it. But I see no need for holistic systems as described in that talk, I just see a need for better, more transparent systems. And a system doesn't have to be holistic to be transparent, or good.
>But I see no need for holistic systems as described in that talk, I just see a need for better, more transparent systems. And a system doesn't have to be holistic to be transparent, or good.
my takeaway is that it's not the holistic systems themselves that are needed -- it's that when holistic systems aren't enforced that vendors will go mad with power.
IBM Z systems are arguably the most holistic systems currently available, everything down to the silicon is designed in a coherent way. And yet, it is all incredibly proprietary.
Holistic systems don't prevent vendors from going mad with power. Competition and pressure to document their products does.
But it's terrible power for them because now they have to maintain that firmware, and that's very expensive, so they don't do a good job of it at all, and we can pretend it's OK right up until it's not.
Legal liability for broken, unmaintained firmware would very quickly bring about the world that BMC wants.
Legal liability for the madness of alarming confusing systems in the flight control room when the airplane goes down with more than 200 lives lost in the sea is about half the yearly income of an exec's $400K.
This was my feeling as well. PC BIOS and UEFI are far from ideal, but does it really make sense that, for every single ARM (or whatever) board, every single OS vendor has to write their own bringup code? Certainly some of it will be reusable across OSes, but it's still a huge amount of work. This would also disadvantage a hobbyist OS developer who wants to build a new OS, whether as a toy or for eventual educational or production use. Suddenly they have to read through pages and pages of low-level documentation for the board they have, and then once they get it working, it still won't work on any other board.
I just don't think it's realistic to expect every vendor to provide deep-enough documentation to make this work. Even the cooperative ones (of which I assume there are currently very few) would probably have trouble with it.
And even if you do have a bunch of cooperative vendors who are great at releasing hardware documentation, that still doesn't save every OS developer from the tedious, error-prone process of converting that documentation into low-level bringup code.
Isn't it so much better that a Linux developer, when confronted with a new board, need only craft a device tree description (or use one provided by the vendor), and then -- aside from any exotic peripherals that may not have drivers written yet -- the board will mostly work? It's at least likely to boot, even if it comes up in a not-fully-functional state.
Cantrill talks about an experience he had at Joyent, where he diagnosed that memory was failing on systems, but the errors were suppressed by the firmware. Having adequate documentation of the firmware doesn't help you in this kind of sutuation. Holistic systems would not lie about what the system is doing in this way.
Good firmware tells no lies. But it doesn't have to be built with a specific OS in mind to be good - on the contrary, I believe that building firmware with specific OS in mind is what got us into this whole bad firmware mess.
And yet, holistic systems can lie. They can lie horribly about their state, and you'd be none the wiser. Being "holistic", created with the intention of the whole, does not mean that the system cannot lie. If the whole is created with the intention of lying to you, than it will.
We don't need holistic systems. We need good systems. A system doesn't need to be holistic to be good, and a system doesn't need to be good to be holistic.
So what would you want to have happening in the case Cantrill was talking about? The aim is to have good systems and there have been plenty of bad holistic systems in the history of computing. But by good, non-holistic systems, do you mean that we have a motherboard with well-documented firmware that the buyer of the hardware can't see into except according to the interfaces the vendor has provided? This seems to be potentially hiding the kind of information about a malfunctioning system that gets Cantrill so worked up about.
I do think that one of the prerequisites of (firm/soft)ware being good is being open source. For hardware to be good, I do believe it has to be well documented.
If we go by those two requirements, we can see how it works. We can fix things ourselves. And most importantly, anyone can create their own good firmware, without the need for the system to be designed in a holistic way.
But it's important to note that these days, there will always be somebody who wants to bring their code in at a lower level. And the immediate reaction of all vendors is "But why would you want to do that?". Why would you want to bring your own Unix flavor to our hardware? Why would you want to run Linux executables on Chrome OS? Why would you want to run a different hypervisor on Oxide racks?
Those people will exist. And layers like BIOS and UEFI allow system vendors to say "Eh, sure, we don't think that what you're doing is wise, but whatever, here's a standard way we'll allow you to use". Holistic systems don't have these standards. They are only usable as their creators intended. And not everyone will agree with their creators intentions. But the work required to refit them to fit another purpose, which the hardware is very fit to do, but the software fights against, is usually too high, and you'll be better off using something that is worse, but left you an avenue to customize it for your purpose easily.
My main takeaway from this talk, is that we need some standards for phase-based booting, as there is some very cool improvements that could be done with it. But I see no need for holistic systems as described in that talk, I just see a need for better, more transparent systems. And a system doesn't have to be holistic to be transparent, or good.