Including this in the standard library speaks to how much a citizen JSON has become, where a language simply can't afford to not consider it.
I find it interesting to note that nowhere in this JEP is the word "serialization", which is what most people might associate with JSON libs. Or rather, they are studiously ignoring that feature and just improving the ergonomics of interacting with JSON.
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
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.
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.
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 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.
Indices are composed of one or more primary shards. Each primary shard can have one replica. Three nodes, each with one primary shard as a part of that sjngle index, no replicas in play at all.
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).
I find it interesting to note that nowhere in this JEP is the word "serialization", which is what most people might associate with JSON libs. Or rather, they are studiously ignoring that feature and just improving the ergonomics of interacting with JSON.