Specific to the software discussed here: Bit weird criticism of software that obviously is not intended to run on end-devices with MCUs, but on a more powerful gateway. (But yes, there is overall too much focus on that part compared to the bits that run closer to the hardware)
"It's all fairly arbitrary stuff, and in the end, the point is to present something cool running on the hardware and within the nominal restrictions, even if you get tricky to do so."
Another good, detailed perspective on it. Appreciate it. I'll especially agree with the part I quoted. :)
This is also, what this article is actually about. It's just from a more "hermeneutic" perspective, rather than a bottom-up approach based on an analysis of the hardware.
I think the lines between software and hardware-based are a little blurred these days with accelerator cards and whatnot. It's just a lot harder to come with the same level of guarantees when you're basically running a hypervisor on top of it.
Which is itself a commentary on the immaturity of the technology. I certainly wouldn't run it in production if I can't trust that all devices of a certain performance level can run it. Random performance issues on top-tier hardware is going to be a non-starter.
I agree... what I think they meant to say is something along the lines of software defaults are already optimized to maximize and take advantage of the hardware's abilities so work is completed faster. The 'with the software baked in' should be changed to reflect the value proposition that Oxide is alluding to.
You're right. I wanted to abstract away from specific hardware and express that in the requirements. I definitely failed at that. See other comments for specifics and details on the device.
By the end it’s not really clear to me that their choice isn’t potentially the worst choice.
The vagueness about this project doesn’t help.
The project / use case is what should matter / drive this, less so rando idea like “ we don’t want to add any extra KB that is not strictly necessary”. Maybe if we understood the project the decision might make more sense.
There is an upper limit of a piece of hardware, but if the software driving it's use is not exposing that or performing actions in a less efficient manner it can certainly have a negative impact.
No, it's because you're not considering properly the problem at hand. You're comparing apples and oranges by comparing consumer hardware capabilities and the capabilities able to be achieved for a hardened service environment solution.
It's the same reason why we don't just go and install a new quad core x86 on rockets for their guidance.
There are lots of differences between hardware and software, so I don't think it is hypocritical to complain about the hardware manufactures doing this.
I tweeted to him to research IBM's zTPF before writing this, I guess it conflicts with the narrative he's telling though. In general, I agree with his sentiments, but there are no absolutes, only trade offs here. You can, for instance, hook a debugger into the kernel or through the hypervisor. And debugging hardware looks a lot like debugging a unikernel in that sense.
Please make a little effort and expand on why this article is interesting instead.
For instance, people are using micro frameworks for a reason. They want less clutter and a more direct grab on what the machine is doing. With the proposed theoretical solution we get to remove one big complexity element in the setup, it is very interesting.
reply