You're right. I was thinking of it from the point of lowering it from a hypothetical hardware device to the manual process instead of raising it from the current system.
No, I'm arguing against a universality of such a claim. There is a performance/complexity threshold above which hardware or hybrid solution is a way easier than a purely software one.
It is not just silly, it's the most stupid suggestion of the year.
If you are happy to use half-working, half-baked products, feel free. I will choose those, where software is finely tuned to the hardware and this combination makes pleasurable experience.
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.
No, it's just complicated - easier to implement it on a reasonably general purpose core with firmware than to bet on getting it right first time in dedicated hardware.
I don’t think the author was meaning to cut out hardware all together, more that he is becoming hardware agnostic. Upgrading his hardware means nothing since he has virtualized everything and is probably pretty quick.
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.
What you describe sounds like a "throw a lot of hardware at it" approach. What often matters in the real world is how you integrate and use the hardware, not how powerful the hardware is.
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.
So here's how I summarise the whole essay: "Hardware is cheap. Instead of making your software perform well, why not just throw more hardware at the problem."
reply