computerfan494

7 ms·

1.
by computerfan494 9mo ago
By "patch" I am talking about the public commit. Updated binaries were made available when the CVE was published.
2.
by computerfan494 9mo ago
That's a good question. I suppose that posting the commit makes it incredibly obvious how to exploit the issue, so maybe they wanted to wait a little bit longer for their on-prem users who were slow to patch?
3.
by computerfan494 9mo ago
The author of this post is incorrect about the timeline. Our Atlas clusters were upgraded days before the CVE was announced.
4.
by computerfan494 9mo ago
If this is a result of that vulnerability, Ubisoft only have themselves to blame. Our support contacts ensured that we knew about the vulnerability as early as possible and gave us a clear guide to remediation for our self-hosted clusters.
5.
by computerfan494 9mo ago
We received communication that all Atlas clusters were upgraded with the fix before the vulnerability was announced.
6.
by computerfan494 9mo ago
Postgres violated serializability on a single node for a considerable amount of time [1] and used fsync incorrectly for 20 years [2]. I personally witnessed lost data on Postgres because of the fsync issue. Database engineering is very hard
7.
by computerfan494 10mo ago
Yes, and my point is that this customer switching to running their own MongoDB instances on EC2 like Atlas does would reduce the bill by less than 50% because the rates that they are charging mean that their cut is less than what AWS is get
8.
by computerfan494 10mo ago
You can look at this particular bill and observe that more than 50% of the cost was going to AWS.
9.
by computerfan494 10mo ago
There's definitely MongoDB markup, but a full 33% of their bill was AWS networking costs that have nothing to do with Atlas.
10.
by computerfan494 10mo ago
Most of the cost in their bill wasn't from MongoDB, it was cost passed on from AWS
11.
by computerfan494 1y ago
I can assure you that Stripe does not regret the decision.
12.
by computerfan494 1y ago
Maybe it's only me, but I just don't write that much code. I try to change less than 100ish lines per day. I try to keep codebases small. I don't want to run a codebase with hundreds of thousands of lines of code in a product
13.
by computerfan494 1y ago
I'm not planning to because there is no documented protocol. If there were, I might! As a result, I can't use FoundationDB.
14.
by computerfan494 1y ago
The hard part is that there is no client spec you can follow as a third-party. Everything is implementation-defined. If you're out-of-tree, your code can break at any time. If the FoundationDB project committed to a protocol, client au
15.
by computerfan494 1y ago
FoundationDB is very cool, but I wish it didn't require linking in their C library to talk to it. The client story is not good.
16.
by computerfan494 1y ago
MongoDB is a very good database, and these days at scale I am significantly more confident in its correctness guarantees than any of the half-baked Postgres horizontal scaling solutions. I have run both databases at seven figure a month spe
17.
by computerfan494 1y ago
The reason to change is scale. If your Postgres spend is in the six digits a month range, JSONB is probably very painful for you. It does not perform very well. Additionally, you've probably spent a good amount of engineering time pain
18.
by computerfan494 2y ago
I will copy and paste a comment I wrote here previously: "MongoDB ships with horizontal sharding out-of-the-box, has idiomatic and well-maintained drivers for pretty much every language you could want (no C library re-use), is reasonab
19.
by computerfan494 2y ago
I have been using it in production for more than a year. There were some early hiccups associated with my use-case that were resolved on upgrade and with a bit of tuning. Otherwise it has been very stable. I'll say that I wish the offi
20.
by computerfan494 2y ago
MongoDB ships with horizontal sharding out-of-the-box, has idiomatic and well-maintained drivers for pretty much every language you could want (no C library re-use), is reasonably vendor-neutral and can be run locally, and the data modeling
21.
by computerfan494 2y ago
My understanding of what the OP was discussing is an optimistic locking system where the nodes only accept commits if the last issued token matches the token included in the commit. While agreeing on the last token requested requires coordi
22.
by computerfan494 2y ago
I feel like you're dancing around admitting the core issue that Martin points out - RedLock is not suitable for systems where correctness is paramount. It can get close, but it is not robust in all cases. If you want to say "Red
23.
by computerfan494 2y ago
Locking without a timeout is indeed in the majority of use-cases a non-starter, we are agreed there. The critical point that users must understand is that it is impossible to guarantee that the RedLock client never holds its lease longer
24.
by computerfan494 2y ago
In the above description of optimistic locking, it is assumed that it is impossible to issue the same token to multiple clients. Nodes can agree that a given token has also never been issued before just like a monotonically increasing value
25.
by computerfan494 2y ago
To be honest I've long been puzzled by your response blog post. Maybe the following question can help achieve common ground: Would you use RedLock in a situation where the timeout is fairly short (1-2 seconds maybe), the work done usua
26.
by computerfan494 2y ago
I don't like Taylor Swift's music, but I do hope this author experiences joy in something, sometime.
27.
by computerfan494 2y ago
I'm not sure how to convince you to get over your hangup around how other people feel about the word "delivery", but this is exactly why others distinguish between "delivery" and "processing". If you think
28.
by computerfan494 2y ago
It explains why most people seem to disagree with you on what "delivery" and "you" mean in this context. For the majority of contexts, "delivery" means that a system responsible for de-duplication receives the
29.
by computerfan494 2y ago
You're correct, but in my experience the vast majority of code written is not downstream of a usable de-duplication mechanism.
30.
by computerfan494 2y ago
At the end of the day the author and those they are arguing with mostly agree, they simply disagree on what the word "delivery" means. Given the author's background, I wonder if the issue is that they're focused mainly o

More ›