There are probably a couple more typos in this ("momenet" being another one). It's very refreshing to see blog posts not being written by LLMs for once.
HN user
fusl
[ my public key: https://keybase.io/fusl; my proof: https://keybase.io/fusl/sigs/OLcLBLFSMyj5Dc6J7_Tqnat8dak_QGjerp9r3o-tI2o ]
Sounds like you're using Bluetooth headphones and the game is attaching to the microphone which will automatically switch the audio codec from audio mode into headset mode. I'd suggest trying to completely disable the microphone of the headset so the game won't even try to attach to it.
Unfortunately Anubis doesn't help where my pipe to the internet isn't fat enough to just eat up all the bandwidth that the attacker has available. Renting tens of terabits of capacity isn't cheap and DDoS attacks nowadays are in the scale of that. BunnyCDN's DDoS protection is unfortunately too basic to filter out anything that's ever so slightly more sophisticated. Cloudflare's flexibility in terms of custom rulesets and their global pre-trained rulesets (based on attacks they've seen in the past) is imo just unbeatable at this time.
Been using Cachet for quite a while before inevitably migrating to Atlassian's Statuspage.io. I'm a huge fan of self-hosting and self-managing every single thing in existence but Cachet was just such a PITA to maintain and there was just no other good alternative to Cachet that was also open source.
Happy to hear anyone's suggestions about where else to go or what else to do in regards to protecting from large-scale volumetric DDoS attacks. Pretty much every CDN provider nowadays has stacked up enough capacity to tank these kind of attacks, good luck trying to combat these yourself these days?
I think you misunderstand the flow of traffic here. The data flow, initiated by requests coming from AWS us-east-1, was Cloudflare towards AWS, not the other way around. Cloudflare can easily control where and how their egress traffic gets to the destination (as long as there are multiple paths towards the target) as well as rate limit that traffic to sane levels.
Looks like it was returning some SERVFAILs on 8.8.8.8 and .4.4
Their email makes sense, except it doesn't. As someone who considers themselves a low traffic usage customer, running hundreds of Hetzner Cloud servers - each averaging less than 10GB of data transfer, with only a few servers reaching the previously included 50-60TB/month - I’m now facing an overall increase in costs.
Not only are the per-server prices higher, but the drastic cut in included bandwidth (without a corresponding option for bandwidth pooling) means I'll be paying significantly more despite my usage being well within "low traffic" by their standards. It’s frustrating that Hetzner never introduced a bandwidth pooling option for customers where it would make sense, especially in scenarios like mine where usage is highly imbalanced across servers.
At this point, Vultr and Linode are starting to make a lot more sense, even with their more expensive traffic pricing, since both providers offer traffic pooling. This feature would have significantly softened the blow of Hetzner's pricing changes, but instead, they’re pushing costs onto loyal customers who don’t fit neatly into their new model.
In the EU under GDPR, users must be given a genuine choice, meaning they should be able to refuse consent without facing negative consequences such as being redirected or denied access to the service. Creating the illusion of choice by asking for consent and then redirecting users to another site if they decline is a violation of the principles of transparency, fairness, and freely given consent outlined in the GDPR.
This has been happening very frequently since end of 2020, see https://news.ycombinator.com/item?id=26357047
This has been an ongoing issue in the last few weeks to the point where we had to move production systems away from .ws to another TLD to keep thingns running. See: https://twitter.com/OhNoItsFusl/status/1350119705189748742?s...
Internet Archive link: https://web.archive.org/http://rent-a-pilot.nl/archives/190
For the downvoters, please just link here the proof if you disagree.
As far as my understanding goes, RFC3021 is unsupported on some router devices widely used as it doesn't have a broadcast and network address and is therefore invalid (/s), so some ISPs default to /30 instead for peering and don't filter out their peering networks in BGP.
As far as everything on the internet tells me, GDPR was made for exactly this reason, to prevent this kind of data collecting without the users consent. But what is happening instead is that small companies, starrups, etc. are getting fucked over by the sheer amount of "rules" they have to follow and implement while large companies can get away with collecting everything and anything, leaking personal user data all over the place, etc.
Conclusion: GDPR was made to help monopolies grow even larger and prevent smaller companies/start-ups from ever growing more than just a little bit. Change my mind?
This post is wrong on soooo many levels, mentioning all of them would explode this comment, but just to proof one of them: JSON does NOT "requires curly braces around the entire documen". In fact, you can enclose a document with [ and ] as well, which is why you need curly brackets to write configuration files. This has nothing to do with a JSON "require"ment.
I guess "This installer may include bundled offers." as a warning is not clear enough because it's not written in 72px red-colored bold text? Don't get me wrong, but, in my honest opinion, they make it clear on their own website that it includes bundled offers. I know many other open source projects that offer builds of their software for free, including "bundled offers", without any hint.
This has always been the case. Filezilla offers two versions for Windows and macOS on their website: Bundled and non-bunbled. You get the bundled version when you click "Download FileZilla Client" and then the big green "Download FileZilla Client" button (assuming you're visiting the website from a Windows or macOS client): "This installer may include bundled offers." makes this also very clear. In order to get the clean version, you have to click "Show additional download options" and then pick the version you want. For anyone saying that Filezilla can't be trusted anymore due to doing this, it's still open source and you can check out and build the code yourself: https://filezilla-project.org/sourcecode.php
I don't see where Amazon would be at fault here. Remember back in the old days of T9 keyboard phones, remember that one time where you forgot to lock your keyboard when you put it into your pocket and it called a random person from your contact list? You didn't immediately call the press to say it was Nokias, Ericssons, Siemens' (or whatever your phone manufacturer is) fault you left your phone unlocked and it called a random person because of the hardware keys being pressed within your pocket.
Your benchmarks:
Google's new Cloud Memorystore, 1.0 GB:
redis-cli -h 10.0.0.3 --intrinsic-latency 100
677411416 total runs in 100 seconds
avg latency: 0.1476 microseconds / 147.62 nanoseconds per run
Open-source Redis on a Google Cloud Platform micro instance, 0.6 GB: redis-cli -h localhost --intrinsic-latency 100
353427208 total runs in 100 seconds
avg latency: 0.2829 microseconds / 282.94 nanoseconds per run
Open-source Redis on an AWS EC2 micro instance, 1.0 GB: redis-cli -h localhost --intrinsic-latency 100
21681751 total runs in 100 seconds
avg latency: 4.6122 microseconds / 4612.17 nanoseconds per run
My benchmark:Open-source Redis on a Hetzner Cloud VPS, CX11 (92% cheaper than Google's Cloud Memorystore):
redisbench-client:~# redis-cli -h 88.99.124.195 --intrinsic-latency 100
Max latency so far: 1 microseconds.
Max latency so far: 77 microseconds.
Max latency so far: 113 microseconds.
Max latency so far: 130 microseconds.
Max latency so far: 2562 microseconds.
Max latency so far: 2835 microseconds.
Max latency so far: 4165 microseconds.
Max latency so far: 5497 microseconds.
757281326 total runs (avg latency: 0.1321 microseconds / 132.05 nanoseconds per run).
Worst run took 41628x longer than the average latency.