Martin Kleppmann has some interesting thoughts on Redlock:
> I think the Redlock algorithm is a poor choice because it is “neither fish nor fowl”: it is unnecessarily heavyweight and expensive for efficiency-optimization locks, but it is not sufficiently safe for situations in which correctness depends on the lock.
Salvatore Sanfilippo (author of Redis and Redlock) wrote a response to Martin Kleppmann's analysis that is worth a read (though it is a bit dense and hard to follow at times): http://antirez.com/news/101
I think I agree with Kleppmann's analysis, though.
> The algorithm's goal was to move away people that were using a single Redis instance, or a master-slave setup with failover, in order to implement distributed locks, to something much more reliable and safe, but having a very low complexity and good performance.
I think this is good perspective. More reliable + more safe + good performance - Fine, its not perfect, but I bet if you are currently using a single node redis lock and keep running into problems when it goes down, these improvements sound nice.
Some of antirez's comments surprise me a bit though
> A distributed lock without an auto release mechanism, where the lock owner will hold it indefinitely, is basically useless.
I have found durable locks very practical and useful
Durable locks have a partitioning problem. If the lock holder gets hit by a tornado or catches on fire then there is no recovery method short of manual intervention.
I took a formal class on distributed systems back when dinosaurs roamed the earth and the implementation of Ethernet was still considered interesting. And even back then we talked about leases for locks.
We have things we call "durable locks" (but it sounds like thats a loaded term that I don't know the meaning of) that work by recording lock holders in persistent storage + use a corresponding volatile lock when the lock holders need to assert ownership (e.g. to perform a write).
in our system, the only programs that are allowed to take "durable locks" are ones that are guaranteed to complete (ie, their existence is also recorded in persistent storage, and they are retried until completion). The "durable" part means that even if they restart or die, other writers cant jump in and screw things up. The "volatile" part guarantees that only one of them will be writing at the same time.
I wonder what Martin would have to say about our weird little locks
The thing about most modern web backends is that virtually nothing is guaranteed to complete.
The processes that use locks are often short-lived. They live in short-lived containers with no state, or maybe they're just lambdas executing under a strict resource limit. Either way, there's nobody to clean up after them or restart them once they're killed. When they begin a database transaction and then disappear for any reason, the best practice is to roll back and pretend they never did anything.
In this brave new world of YOLO lock holders, antirez's position makes a lot of sense. There's definitely still room for old-fashioned durable locks, but these are different use cases.
Autoscaling might mean there isn’t even a machine that corresponds to that dead server for days, weeks, or months.
What GP said sounds like it has leases of a fashion. Maybe not the jargon I’d choose to describe them but the industry is full of misleading names for things.
time have changed though. there are better implementations of these, and many companies have built successful startups based around these ideas. look around, it’s the age of distributed locking!
I think this is a good read, but not so much a rebuttal. He never really addresses the following scenario:
1. Get the current time.
2. … All the steps needed to acquire the lock …
3. Get the current time, again.
4. Check if we are already out of time, or if we acquired the lock fast enough.
4.5. client pauses for whatever reason (the example Kleppmann gives is a GC pause), long enough for the lock to expire
4.75. another client acquires the lock
5. Two clients simultaneously hold the lock
Which is the core of Kleppmann's argument against Redlock's correctness. I think the conclusion Sanfilippo can arrive at is that the algorithm is safer than the single node locking algorithm.
I've personally used Redis locks in my personal projects. The real motivation isn't because it's good or correct but because: Redis is already there in my env.
Maybe. But I sympathize with people who recoil at the idea of "Extremely cheap life saving medication sold at unaffordable price".
Must it be sold to the world at a price that is only reasonable for the richest countries to pay?
Is there no possible regulatory system that could avoid 20 years of HIV spread and death in poor countries, while still getting the rich countries to pay their fair share?
> Must it be sold to the world at a price that is only reasonable for the richest countries to pay? Is there no possible regulatory system that could avoid 20 years of HIV spread and death in poor countries, while still getting the rich countries to pay their fair share?
Gilead literally did that! They sold Sovaldi (a treatment for Hepatitis C) for $1000/pill in the USA and $5/pill in India. And people hated them for it.
Only because Americans insist on their self-harm health insurance system. Americans are both collectively wealthy and have a very small number HIV infections per capita
It appeals to me. I don't write fronted code, but sometimes I want a frontend, even if it's really dinky. This seems way more approachable to me than learning JS/all the shit you have to deal with to write a non-toy ui
Let's say you want a frontend for your server and have never written HTML before.
Where so you start? If you have decided on using Python for the UI you have a handful of libraries each with their own documentation. To get started you need to choose one and then read the guides.
If you decide to use HTML you have a whole lot more resources. I'd argue you'll be able to make a frontend faster using this approach.
I understand the hesitation because of the complexity associated with JS. Maybe you're thinking about bundlers and minifiers when you think about writing a frontend with JS.
But you don't need that. You can create amazing user experiences with a plain HTML, CSS and a JS file.
I'm not trying to make an argument for "Python for the UI" in general. I just looked at their demo page, and thought "huh I could probably turn my debug script in to an okay looking UI in an hour with this". Maybe you are right that I could make something okay looking with plain HTML/CSS/JS in less time (including the time to figure out HTML/CSS/JS?)
I agree on making a demo for an existing Python project. I have used Gradio and I think it's amazing!
I disagree on the using something like this to start making a UI. When you know that your project requires a complex frontend, you're better of starting with HTML.
While you may be able to create amazing experiences in JavaScript, JavaScript still has multiple problems:
1. It is inconsistent [1]
2. It does not have many features that programmers love and other languages have.
3. It has a community that holds different values from what other programmers value themselves.
If people want to continue development in JavaScript, they can. But since JavaScript has a monopoly on the (fairly large) 'frontend development for the web' market, there will always be attempts to find an alternative.
Yes, writing a complete SQL DB engine like MySQL is a huge amount of work, but that is not what this article is talking about.
They are wrapping another database that solves these hard problems for them. This is a fine program to write. They will be able to hire other people to maintain it. Its not rocket science
I don’t think it’s secret if you give it to Facebook. Furthermore, something doesn’t need to provide social value to be ethical.
I think that the vast majority of people don’t really care about privacy, and aren’t divulging anything remotely “secret” by providing all of their browsing history to ad companies.
The tools for not doing so are a two second websearch away for everyone, and most people don’t bother.
Is it a secret how long I subconsciously linger on a single post as I scroll through my Instagram feed? I’d argue that it’s even more private than a secret, it’s something I may not be aware of and have little control over.
Bikes, (non humiliating) public transport, and more compact city design all have to work together.
I think cars in small towns are pretty sweet - but they suck for everyone in big cities. They take up huge amounts of space during rush hour, and move very few people compared to any form of transit you like
