Reminds me of a funny story - the first day at Google (2018) I got a chat from an SVP, I forgot who, saying "Hi!". At first I was blown, wow, what a company! SVPs greeting new engineers! A minute later they were like "oops, my bad, wrong person".
They intended to message someone else with my first name, so my guess is they used to type that name and hit tab to start the chat, and that person was no longer the first option in the auto-complete since I joined.
(side note - the most bad-ass response to this would have been to just send back "go/no-hello" ;) )
* When RSS was a thing but in my country a lot of news/content websites hadn't adopted yet, I wrote a service to quickly define scrapers that turn those sites into RSS feeds.
* In one of my former workplaces I wrote (alongside another person) a gamified shared playlist app that allowed everyone to participate in being a DJ for our company hackathon (people getting more upvotes getting more playtime, songs getting many downvoted being skipped in the middle, etc). That was a lot of fun and surprisingly a very emotionally engaging experience for everyone.
Pretty sure the first monitor on my first PC (~1988) was amber, later replaced by black and white that did not "smear" as much so was better for games, and later replaced by a color one (that might have been on a newer PC).
One thing that makes SO an easy target for this is that they let you download all their data and you don't even need to crawl and scrape the content from the website. Just download a dump, put it in an database, slap an HTML template on top of it, splash a few ads, and boom.
I don't disagree, I'm just saying that time drift between nodes is not an issue with this algorithm. Also, using monotonic clock as antirez says he intends to in the post, will take care of most of these scenarios besides VM migration pauses.
yes, that goes back to the first issue in Martin's article, and he mentioned the tokens thing for this. But time drift between the machines is not an issue, is my point.
but the expiration time is relative to the redis server's time, and the time measurement on the client side is done relative to the client's time. Other clients don't care about your clock and you don't care about redis' clock AFAIK. From TFM:
> The client computes how much time elapsed in order to acquire the lock, by subtracting from the current time the timestamp obtained in step 1. If and only if the client was able to acquire the lock in the majority of the instances (at least 3), and the total time elapsed to acquire the lock is less than lock validity time, the lock is considered to be acquired.
They intended to message someone else with my first name, so my guess is they used to type that name and hit tab to start the chat, and that person was no longer the first option in the auto-complete since I joined.
(side note - the most bad-ass response to this would have been to just send back "go/no-hello" ;) )