HN user

IanGabes

60 karma
Posts1
Comments21
View on HN

this is so far from the truth its baffling.

in a year where the world cup is taking place, counter-examples are readily available in numbers. I doubt FIFA will be releasing environmental impact datasets...

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

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.

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 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.

I havent seen anything terribly relevant, most of the thesis projects i have seen are more interested in creating realistic and believable honeypots for specific protocols, eg RDP.

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.

Depends on your goals! If you are defending a network, increasing the cost of attack is something we actively try to optimize for. It costs me next to nothing to hold a socket open and send a keep alive every 15 seconds or so, in addition to the extra threat intel from the initial connection.

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!

My team and i run some different honeypot solutions, and we base a lot of them off of cowrie. As pointed out by previous comments, most interactions are not so interesting, except for the fact that many cowrie based honeypots imitating IoT devices have their attackers running a simple script that pulls down a number of second stage binaries, for a variety of cpu architectures.

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).

My team and i tried leveraging different pivotal products as part of a test deployment of our current esxi managed vm deployment imagined through the pivotal kubernetes deploy.

We found that Pivotal's kubernetes makes it easy to run kubernetes on top of existing vmware infrastructure, so our ops team could continue to manage their normal vmware stack, with an admin interface to manage kubernetes clusters that live within esxi. They could provision us devs with a cluster for a specific use, and hand us the keys to do the rest.

It was pretty cool, except for the fact that we discovered kernel incompatibility with the underlying esxi version/os that brought down the entire deployment repeatedly a few days before the event where we intended to stress test the product.

The use case is definitely there for larger orgs who want to share hardware, but you also get the "on prem cloud" quick wins. Our experiment obviously failed in a low risk way, but i think the idea is sound.