This makes sense, but the the vast majority of tooling including ORMs, autocomplete SQL IDEs, and even suspect application code relies on table descriptions and listings provided by the information schema

I think that its easier to compare the shutter to airplane windows.

The windows are there just to make the humans inside more comfortable, similar to how many people would be more comfortable without a camera pointed at them.

Flashing firmware is a big hill to climb for bad guys in most peoples worlds.

They do! Its called Chronobreak. They have used it many times in professional matches successfully, but it doesn't work in 100% of scenarios.

You might be interested in CRIU: https://github.com/checkpoint-restore/criu

Huh. This is interesting, I can empathize with both sides of the argument. Are C text editors not able to take care of syntax highlighting the differences between a typedef'd scalar and a typedef'd struct? Colouring the type one way or another I figure would be sufficient.

Most frequently used in my experience by malware: https://en.wikipedia.org/wiki/MHTML

Creating a custom system to suit your situations needs sounds great and the thought process was fun to read, but some of the claims lobbed here are pretty questionable.

Specifically, the claim that Dota's matchmaking system is "probably wrong" because the model chosen doesn't match your own findings feels like a reach. Sibling commenters have pointed out how skill variance is important to allow the ELO system to function in games like chess. Additionally, someone else pointed out that the sigmoid function is similar to a linear funciton close to zero.

It seems at least as likely that Acolytefight doesn't have a high enough level of skill expression present in the game to see top players "curve out" weaker players, rather than exponential functions mapping player skill to be useless or wrong.

Does elo suck? Maybe, but this hasn't convinced me.

I'm not an expert in this field, but I did come across the carrier-grade NAT range on a very odd project:

https://en.wikipedia.org/wiki/Carrier-grade_NAT

I believe this was written in reply to someone that agrees with your article's general premise.

Q: What do you call a startup that raises Series C, then immediately kills itself? A: Fraudulent?

I think the legalese should be taken seriously!

For instance, we can draw a comparison to recent controversy with social media platforms. Do you think that social media platforms should be able to remove any content on their platform, regardless of legality? I believe that they can! Otherwise objectionable is hopefully that catch all.

I view the OP as a bit of a misguided test. The blog post, in all likelihood, will remain up. The control the authour speaks of will still remain in the cloud provider's hands.

In my personal opinion, there are three database types.

'Small' Databases are the first, and are easy to dump into kubernetes. Anything DB with a total storage requirement 100GB or less (if I lick my finger and try to measure the wind), really, can be easily containerized, dumped into kubernetes and you will be a happy camper because it makes prod / dev testing easy, and you don't really need to think too much here.

'Large' database are too big to seriously put into a container. You will run into storage and networking limits for cloud providers. Good luck transferring all that data off bare metal! Your tables will more than likely need to be sharded to even start thinking about gaining any benefit from kubernetes. From my own rubric, my team runs a "large" Mysql database with large sets of archived data that uses more storage that managed cloud SQL solutions can provide. It would take us months to re-design to take advantage of the Mysql Clustering mechanisms, along with following the learning curve that comes with it.

'Massive' databases need to be planned and designed from "the ground up" to live in multiple regions, and leverage respective clustering technologies. Your tables are sharded, replicated and backed up, and you are running in different DCs attempting to serve edge traffic. Kubernetes wins here as well, but, as the OP suggests, not without high effort. K8S give you the scaling and operational interface to manage hundreds of database nodes.

It seems weird to me that the Vitess and OP belabour their Monitoring, Pooling, and Backup story, when I think the #1 reason you reach for an orchestrator in these problem spaces is scaling.

All that being said, my main point here is that orchestration technologies are tools, and picking the right one is hard , but can be important :) Databases can go into k8s! Make it easy on yourself and choose the right databases to put there

I am in the middle of a k8s project, and tried out this tool briefly. I mostly love the UI! I guess I am newer to k8s, and am getting sick of typing all the same commands looking for pod descriptions, logs, and shell access. This tool is fantastic for debugging. I love being able to access pod shells instantly. I love seeing most of the k8s objects I have one click away! I have not yet tried out k9s, nor do I have prometheus installed in my cluster.

I have one feature request, and two gripes :)

Feature Request: Why is there not a big ol' search bar across the top so I can filter resources by label, or by resource name? I might hazard that caching resource names/labels across all object types, and letting users filter those would be a pretty fun feature.

Gripe One: I am on a flaky VPN connection into my cluster, and Lens wholesale drops the UI if the cluster is unresponsive for a second or two until I reconnect.

Gripe Two: Is it weird to call this an "ide" without giving me a YAML editor and file management? I could do everything in the terminal, which is alright I guess, but I figure editing/applying/inspecting all of that in the same app would be pretty chill! I currently use Pycharm to manage my yaml files, bash scripts, and some python code, but it clearly lacks all the k8s goodies Lens has.

I like the tool!

I am not sure that getting commodity style malware onto a internet connected workstation is truly considered sophisticated, but i am on board with caution before attribution.

I have not seen any further confirmed details in this or any other articles, how do you determine the necessity of boots on the ground?

Oh, yes, sorry i see your perspective now. You will get data loss in this example. My understanding of the example was that it is showing how one node can end up with all the write operations, i wasnt under the impression that it was a "real" cluster.