It happened to me once. It was a cheap no-name hub so I don't really blame type c for it. I also haven't heard it happen to anyone else and most of my friends and family have an android.
Yes, that's when it was included to Trac 1.0 as a built-in plugin. Before that, it was a 3rd party plugin you have to install yourself. I remember using it before 2010 and I'm pretty sure the plugin pre-dates github.
Would you rather we don't have these numbers help us with decision making? Do you have a better system in mind? Should we just never discuss or think about risk/reward trade-offs as soon as it involves a single life at risk?
I also don't get where the Wikipedia snark is coming from. I know that Wikipedia pages are not perfect but It's still a pretty good reference for a lot of things. I often trust Wikipedia articles for any given subject as long as it is well-sourced and not political just like this one.
That's 1 of the reasons kids are usually valued more with these calculations. I'm not advocating for gun rights here. I'm not from the US and I prefer that civilians don't carry guns at all. Maybe I should have said that outright first so I don't just get down-voted and dismissed. I'm talking about freedom in a more general sense. Gun rights is not even the freedom being taken away by this type of surveillance.
I know it's really hard to wrap our head around the idea of objective worth of human lives but we already have calculations for the statistical value of life[1]. We only need to do a similar calculation for our freedom and then we can objectively determine when it's worth it to trade lives vs freedom. At some point (if not there already) a few lives is going to be statistically worth less than the freedom of the entire population.
I believe the criticism was fair here. The author specifically used "339 bytes" on the headline which implies a certain level of precision. Being orders of magnitude away from the claimed file size is not excusable. It just feels like click bait. Not counting imported CSS is simply wrong here. I can have a full-featured responsive CSS framework in <50 bytes if I @import bootstrap.css
Social media like factories are usually targeting websites that are not hosted by Cloudflare (Facebook, Twitter, Amazon, Youtube etc.)
If the like factories are using 3rd world IP's they are probably real human ( https://www.rt.com/viral/388169-smartphones-factory-generate... ) because bots can be run cheaper on a 1st world server because bandwidth, IP, and power usually cost less there. Captcha is an anti-bot measure and is not (or at least shouldn't be but I'm finding it hard to pass CF's captcha as human) very effective against actual humans.
I don't even think CF considers(or even aware of) the existence of a like factory on the same network for displaying the captcha and I am pretty sure they don't justify their captcha blocking with it. It's more likely that they just see a bunch of connections coming from the same IP and naively concludes that it must be a bot.
I'm sure it's easy to make "excuses"(vs justification) but given the real harm it does to actual human users and questionable effectiveness against the doubtful ill-effects of the existence of like factories against CF-hosted websites; I'd like to hear that "justification."
I didn't downvote but I don't believe the claim was 100% factual. Cloudflare has always been horrible with dealing with shared IP's even if the users are all legitmate non-malicious. I once worked in an office with a single shared IP for ~200 people and we got constantly captcha-blocked by Cloudflared websites. It was also a problem with google but it was less prevalent and their captcha system was less annoying than Cloudlfare's.
When I was a sysadmin for a few admittedly-not-highly-popular websites, there were definitely more unwelcome bot traffic from US and EU IP's than there were from any 3rd world countries.
I also don't agree that social media "like-factories" should be a concern for Cloudflare at all. Even if they are truly a concern; social media "like-factories" are probably human-operated on third-world countries or bots that are likely running from developed world servers with access to cheaper bandwidth and IP's.
Do you have a source for that claim? How does sharing IP's with 'like factories' and thousands of other legitimate users justifies getting captcha-blocked by Cloudflare without explicit instructions from the website owners?
Not really. The hardest part is getting the activation bytes and even that is actually quite simple and you only have to do it once. For the actual converting I have a bash script that can convert all the aax files in a directory and convert them to a m4b format with all the metada intact. Using your approach you would have to manually set the chapters and the cover art. I have thousands of hours worth of audiobooks but even if you only have a single 10 hour book I think this approach is still the easier of the 2.
As far as I know you can't do that on iOS. There's also nothing stopping the devs from selling IAP themselves on their own website. So no, Steam is much much more open than Apple's App store. Not to mention the fact that Steam is completely optional and the App store is not.
I know it sounds implied but he didn't say customer service had access to plain text password, just that he verified it over the phone. You can surely do that with hashed password but it's still not a good practice.