Comments URL: https://news.ycombinator.com/item?id=42657144

Points: 2

# Comments: 1

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.

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.

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

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

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.

'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 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 have not seen any further confirmed details in this or any other articles, how do you determine the necessity of boots on the ground?

In my experience, honeypots and tarpits are not the same sort of thing, and fufill different goals. Tarpits get you more utilitarian good, honeypots get you more representative threat intel.

You might have a point, and maybe i should try to turn these subjective feelings into harder metrics in terms of cost, but we have figured at this point it has a net good. If we slow the scanning down by a magnitude, in my opinion its a good thing!

One downside to running software like cowrie is that generally speaking crawlers like shodan will be able to figure out that you are running a honeypot, and will have you fingerprinted in a hurry.

A better strategy for increasing the cost of an attack is actually implementing something i read about on HN called a ssh tarpit, where one can "hang" an incoming ssh connection indefinitely. A lot of the attacks on honeypots are automated, so instead of having a 3 second attack, one can waste the attackers time for about 30s to 1m on average as these scripts have very generous timeouts (and sometimes no timeouts at all).

Here i am just referring to the ease of using iaas offerings like s3 buckets but through on prem hardware. Devs build against drop in blob storage apis as if we lived in aws, and my ops guys still manage the backing vms.