the twitter migrants complaining about the way tumblr functions are so funny because they will say things like "you mean i have to FOLLOW people? i dont get posts spoon fed to me by an algorithm???" like yeah these are positives on an unrelated note is your attention span doing alright
Cackling.
In case the original goes away:
Text version:
Washington State Department of Natural resources tweets:
(Falling to my knees, begging, pleading)
Please.
Folks, seriously.
PLEASE.
Do not - and I can’t emphasize this enough - set the state on fire this weekend.
Fire danger is abnormally high this holiday weekend.
URGING you to consider firework alternatives:
- screaming “bang! boom!” at the sky
- dropping a stack of large books on the floor
- wrapping a toga around a candle
- play America the Beautiful while combining Coke and Mentos
I cannot stress enough to Tumblr staff that they do not need to change the site. Do not try to be like Twitter. Do not try to be like Reddit. Do not alter how this site works.
Tumblr will be the most popular social media site if they continue letting all these other sites implode
funnypoeple asked:
Unsure if you are aware of this update, but apparently someone got into the Twit api and believes that the "rate limiting" is actually a cover up by Elon bc they accidenlty pushed an update DDOSing their own site, which is why he says its "temporary" in his tweet. Not sure if Elon is actually trying to cover-up, or if the DDOS is an unintended side effect of the change
prokopetz answered:
(With reference to this post here.)
As far as I can tell, the folks advancing that theory have it perfectly backwards. The rate limit isn’t an effort to address the self-DDoS situation: the rate limit is causing the self-DDoS situation.
In a nutshell, when you load up Twitter in your browser, two things are happening:
- In response to your initial request, Twitter’s server sends your browser the information it needs to construct the website’s user interface (UI).
- Once the UI has been constructed within your browser, it instructs your browser to dispatch a separate request, via the Twitter API, requesting content (i.e., tweets and ads) to fill itself with.
(It’s actually a little more complex than that, because the response to the initial request may come pre-filled with a portion of the required content in order to speed things up the first time you visit your dashboard, but that’s the gist of it, anyway.)
So, what happens now that the rate limit is in place?
Well, the rate limit doesn’t affect the first request – it’s not using the API, so your browser is able to construct the Twitter UI just fine. The moment you try to scroll your Twitter dashboard, however, that triggers the Twitter UI that’s been constructed within your browser to ask the Twitter API for more content so you can keep scrolling – and that request is subject to the rate limit.
If you happen already to have exceeded your rate limit, that request is going to receive a response along the lines of “Error 429 – Rate Limit Exceeded”. Here’s the trick: while Twitter did update the UI to reflect the addition of a rate limit (i.e., they’re not complete idiots), it turns out they did an incomplete job, and certain dashboard widgets don’t know what to do with an error 429.
Now, the fun part: apparently, what the affected Twitter dashboard widgets are coded to do when they receive a response they don’t recognise is simply to ignore it and try again. Further, nobody thought to impose a delay between attempts, so they retry immediately upon receiving the unrecognised error 429. For users with snappy Internet service, this can result in their browser making multiple attempts per second to retrieve content for the affected Twitter dashboard widgets, receiving (and ignoring) the same error code each time.
And that’s how Twitter ended up accidentally ordering its own users to DDoS its API.







