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.
But languages are easy, there is the whole field of PL theory to draw from. If you're randomly throwing things together like Lerdorf was, there's a missed opportunity.
But what is the universally regarded theory that k8s contradicts? I don't think there is one.
In fact, I'd say that k8s is unusually heavily stepped in high-brow theories from both engineering and AI space. Just not necessarily ones that enjoy hype right now.
The storage of apiserver essentially works as distributed Blackboard in a "Blackboard System", with every controller being an agent in such a system. Meanwhile the agents themselves approach their tasks from control theory areas - oft used comparison is with PID controllers.
I don't think this is right. The reason I say that is because for the most part, teams new to k8s aren't building and managing their own clusters, they are using a managed solution. In that case, an application deployment only need be a few dozen lines of yaml. Most teams aren't really going to be building deep into k8s, and it shouldn't be hard to deploy your containers to some other managed solution.
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.
Poor people are certainly exposed to bad policing more often, but I don't think they see the entire concept of law enforcement as unequal. Most people across all income groups don't commit or approve of crimes.
“[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".
tl;dr The signal from a DVI cable can be detected but at much more reduced ranges. See also; RAGEMASTER (Snowden leak) a range extending implant for video cables.
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.
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.
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.