I see the argument as saying that all those layers are not really necessary. Take HTTP for example: it's a large complex protocol that requires plenty of code to handle correctly (e.g. the size of a request, and the various pieces inside it, are not specified and the parser has to read through the whole request sequentially to figure this out), and the majority of applications using it never need the full functionality. What if it was a simpler, easier-to-parse format that was as extensible?

One of the points I get from his argument is that encapsulation has encouraged us to build massively overcomplicated systems by piling layers upon layers with little understanding of how everything fits together, when we could instead be building much simpler and more efficient systems that could still be using abstraction but in a far more cautious manner.

Then it would become HTTP. It would take time but it would be inevitable.

HTTP didn't just happen. Using Fred Brooks' terminology, the real world is essentially complicated. We may pile accidental complexity on top of it at times, but the real world is essentially complicated.

While I agree that there is room for accidental complexity to occasionally be swept away and a new clean slate presented, I do not believe that a new protocol for HTTP could solve all the problems HTTP solves without being at least nearly as complex as HTTP. The set of problems that HTTP solves is a great deal larger than "request page -> get page". There's caching, proxies, security, encryption, policy enforcement, needs that schools have, needs that Facebook has... and that's still just the high-level table of contents of the table of contents of the world of HTTP. And if you think you can just ignore those cases and simplify... try it and you'll see how wrong you are.

Note I do think there is room for improvement in HTTP, and it probably isn't the direction of 2.0. But it's not like there's some sort of brilliantly simple protocol in there struggling to get out, buried under layers of cruft. It's a thorny hard problem and the result will be a thorny hard protocol. It often fails to work not because the protocol itself is broken but because people doing work in HTTP have truly failed to account for a fundamental use case properly, like caching or the use of proxies.

Also note that there's no guarantee that "simple protocol + time" will yield something any simpler than HTTP. Under HTTP is a fairly powerful idea, and there's a reason why so many Internet protocols look very similar to it. It would be easy to start with something "simpler" that turns out to grow much, much worse.

By example, Moore Law has allowed us to pack incredibly large amounts to transistors in reasonably affordable machines, and what we do is... virtualization, a.k.a. write software that (presumably) simulates being a (much slower and limited) hardware system so a third party can run other programs on top of it, for a fee.

That kind of makes economic sense (because customers have a big appetite for computing power... just as long as they do not have to keep those pesky sysadmins on the payroll), but from a purely technological point of view is craziness. Every component you add into your stack is a potential source of error, and you do not gain any extra features because you are simulating real hardware... so, why to do it in the first place?

I think the answer is: because nobody would buy all those transistors if we didn't do so.

...which is part of the reason why you're seeing people in Linuxland rediscover things (LXC) the BSD community (Jails) have known for ages.

Why does everybody ignore the obvious explanation, that you'd get from the mouth of any participant, for a convoluted one that only fits the criterium of political correctness?

Having said that, please excuse my ignorance on system administration but, how does running a virtual machine that pretends to be a Linux/x64 box... on top of a real Linux/x64 box saves anybody at least some time? As a software developer who drank the Java kool-aid back in the 90, at least the "write once, run everywhere" mantra did make some kind of sense in those terms, but this other example is genuinely beyond me.

To me it has more to do with a tech company being able to put together an A-class team to serve a large number of customers that would not stand to pay the salary of a single full-time B-level IT guy if their business model depended on it.

To borrow someone else's words: https://blog.engineyard.com/2014/pets-vs-cattle

Or, in summary, it's a heck of a lot easier to instantiate a new instance of a machine from a snapshot than instantiate a new machine from a set of directions and some auto-config scripts.

I see some value in having a running system right now, instead of waiting for a long latency while the image is downloaded to real hardware... at least in some situations. However, is taking a permanent performance degradation of an order of magnitude worth that advantage?

Sure, you can create a simple transfer protocol that meets 80% of the use cases. Now add on the other 20% of the use cases, and you will end up with equatable complexity. And then, congratulations, you now have two competing standards.