JackRabbitSlim

Give me 10 years and hind-sight and I'll have your answer.

Fair point, but then plenty of people were using hosted solutions for their naive PHP apps too. Managed solutions don't prevent poor/improper configuration in either case.

The managed hosts and/or their tools probably helped negate damage/resolve issues quicker. However I think that the idea that "all you need is a couple of dozen lines of yaml and a managed provider" is exactly why it's headed down a similar path.

For a real world examples just look at every improperly configured S3 bucket leaking data. Every private key accidentally posted to github from a careless 'git add -a'. Every API that doesn't properly check auth. None of these are within the purview of a managed hosts responsibility.

I'm not even against K8 in any of this. Just making the observation that - like PHP - it is empowering entire groups of people to do things they otherwise wouldn't be able to do.

I get the feeling K8 is the modern PHP. Software that's easy to pick up and use without complete understanding and get something usable. Even if its not efficient and results in lots of technical debt.

And like PHP, it will be criticised with the power of hind sight but will continue to be used and power vast swaths of the internet.

So inversely, it is the right solution for police to permit lots of crime in well-off areas.

“The law, in its majestic equality, forbids rich and poor alike to sleep under bridges, to beg in the streets, and to steal their bread.”

“[t]he more an owner, for his advantage, opens up his property for use by the public in general, the more do his rights become circumscribed by the statutory and constitutional rights of those who use it.” -- Justice Hugo Black, majority opinion in Marsh Vs Alabama.

Youtube et al certainly encourage the free and public flow of traffic. Their business model depends on it. So their responsibility to the public would seem to obviously overshadow the perceived protections as a "private company".

I was also a child of the 80's

On the subject of email verification; Why not split the difference. Verify but give a 24 or 48 hours grace?

I noticed you said "meaningful" impact and not "no impact". If your optimizing this seems like the best of both worlds in the slight increase of conversion and the security of verified email?

Increasing user productivity and usability by any % doesn't directly translate to revenue. Steering users to premium features or ad click-throughs does directly translate to revenue.

Revenue driven design will win every time.

I know. Lets move it all that annoying complexity to yaml/json/XML config files!

Now look at this app I can write in 30 lines of code with this framework! Oh and 500 lines of yaml across 2 dozen files but look the "code" is so sleek and sexy.

Joking aside I think he could have at least mentioned the difference between required complexity and unneeded complexity. Ironically it seems to spawn from attempts to reduce the first type of required complexity in a lot of cases.

“But it was alright, everything was alright, the struggle was finished. He had won the victory over himself. He loved Big Brother.” -- George Orwell, 1984

This is pretty much it. Let's frame the proposition differently to get people to consider it from a new perspective.

I can verify the OS install media with trusted publishes using signing keys and PKI. I can't do a god damn thing about the cheap, back-doored PCI controller from China.

What protection does secure boot really offer the end user at that point? The PCI controller is in place to just pass the right signatures to secure boot or just wait until after the secure boot checks so it's not helping with bad hardware. I already verified the OS media at install, so its not super useful there either. Did my boot code change? How would I know? Did the bad PCI controller fake it? Do I have any additional trust in my system? I can't go probing the system to try to find out.

A black box with zero control told you you were safe and there is no way to look at or modify the system now so you can trust it. Your hardware was never on a TAO workbench. Who doesn't feel safer?

Not exactly. That's why those same vendors work so hard at disabling root access for exactly the reasons outlined by the article; root can wreck it or maybe read out keys, or a million other little things because ALL of it is predicated on no one being able to just arbitrarily read/write to everything on the system like root/uid 1 can do.

Not "Best Practice" according to whom? Cloud vendors selling lock-in services? From an architectural perspective how is a bare VM at a remote data center worse than indeterminate/unknown intermedate layers of a proper "cloud" provider that is still in the same remote data center with the same hops and latency?

That "very small set of primitives" is enough to build the cloud vendors themselves so how exactly is that a limiting factor?

If I seem overtly hostile I don't mean it that way. I am just genuinely curious for an extended explanation. In it's current form it sounds down right marketing tautology to my ears.

From what I remember, each disk was roughly a single "island". I think they tried to keep it semi-logical but I doubt it was as effective as they would have liked.