The authoritarians are the ones owning the platforms - X is owned by somebody who's openly calling for the abolishment of our democratic structures, is supporting far-right extremists in our countries and has done a Sieg Heil on the world stage.
Getting their toxic propaganda out of our continent is the minimum we need to preserve our democracies. The paradox of tolerance applies.
Even if that'd be true, two wrongs don't make a right. If a government centrally determines whether something is propaganda and censors it, then it's authoritarian. A free society is built on free information and free debate. If you don't have that, then you don't have a democracy to protect. There's no wiggle room or grey area there.
Your government would be no better than Putin starting a "special military operation", and censoring all "foreign propaganda" calling it an invasion. Russia also holds elections, and yet Putin keeps winning.
Again, I would recommend you familiarize yourself with the Paradox of Tolerance, written up by an Austrian philosopher after the horrors of WW2. Honestly, the entire book - The Open Society and its Enemies - might be a good read.
We've been here before. We learned our lesson. We can't wait for Americans to catch up.
People were able to make very realistic fakes of anything 10-20 years ago, using basic tools. Just ask the UFO nuts or the NSFW media enthusiasts. And like what you mentioned, staged scenes have become somewhat common as well, including before the internet.
We can expect more of the same. Random unverified photo and video should not be trusted, not in 2005, not in 2015, and not today.
I believe that this "everything was fine but it's going to get really bad" narrative is just yet another attempt at regulatory capture, to outlaw open-source AI. This entire fake bridge collapse might very well be a false flag to scare senile regulators.
What I'm missing here is a test environment. Gradual or not; why are they deploying straight to prod? At Cloudflare's scale, there should be a dedicated room in Cloudflare HQ with a full isolated model-scale deployment of their entire system. All changes should go there first, with tests run for every possible scenario.
Only after that do you use gradual deployment, with a big red oopsie button which immediately rolls the changes back. Languages with strong type systems won't save you, good procedure will.
This is kinda what I'm thinking. We're absolutely not at the scale Cloudflare is at.
But we run software and configuration changes through three tiers - first stage for the dev-team only, second stage with internal customers and other teams depending on it for integration and internal usage -- and finally production. Some teams have also split production into different rings depending on the criticality of the customers and the number of customers.
This has lead to a bunch of discussions early on, because teams with simpler software and very good testing usually push through dev and testing with no or little problem. And that's fine. If you have a track record of good changes, there is little reason to artificially prolong deployment in dev and test just because. If you want to, just go through it in minutes.
But after a few spicy production incidents, even the better and faster teams understood and accepted that once technical velocity exists, actual velocity is a choice, or a throttle if you want an analogy.
If you do good, by all means, promote from test to prod within minutes. If you fuck up production several times in a row and start threatening SLAs, slow down, spend more resources on manual testing and improving automated testing, give changes time to simmer in the internally productive environment, spend more time between promotions from production ring to production ring.
And this is on top of considerations of e.g. change risk. Some frontend-only application can move much faster than the PostgreSQL team, because one rollback is a container restart, and the other could be a multi-hour recovery from backups.
They have millions of “free” subscribers; said subscribers should be the test pigs for rollouts; paying (read: big) subscribers can get the breaking changes later.
This feels like such a valid solution and is how past $dayjobs released things: send to the free users, rollout to Paying Users once that's proven to not blow up.
If your target is security, then _assuming your patch is actually valid_ you're giving better security coverage for free customers than to your paying ones.
Cloudflare is both, and their tradeoffs seem to be set on maximizing security at cost of availability. And it makes sense. A fully unavailable system is perfectly secure.
I am sure they have this. What tends to happen is that the gradual rollout system becomes too slow for some rare, low latency rollout requirements, so a config system is introduced that fulfills the requirements. For example, let’s say you have a gradual rollout for binaries (slow) and configuration (fast). Over time, the fast rollout of the configuration system will cause outages, so it’s slowed down. Then a requirement pops up for which the config system is too slow and someone identifies a global system with no gradual rollout (e.g. a database) to be used as the solution. That solution will be compliant with all the processes that have been introduced to the letter, because so far nobody has thought of using a single database row for global configuration yet. Add new processes whenever this happens and at some point everything will be too slow and taking on more risk becomes necessary to stay competitive. So processes are adjusted. Repeat forever.
I don't think I did. The implication is that using languages with strong types (as discussed in the article) is not a solution. That's rubbish. It's at least part of the solution.
When is Reddit going to get fined? There's no transparency or reason in content moderation, no consistently enforced ToS, no appeal mechanism, and they're very aggressive in stopping public access to public data. Seems a bit more relevant than blue checkmarks.
0.7m observed about 40 minutes ago.
reply