By "patch" I am talking about the public commit. Updated binaries were made available when the CVE was published.
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?
The author of this post is incorrect about the timeline. Our Atlas clusters were upgraded days before the CVE was announced.
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…
We received communication that all Atlas clusters were upgraded with the fix before the vulnerability was announced.
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…
You can look at this particular bill and observe that more than 50% of the cost was going to AWS.
There's definitely MongoDB markup, but a full 33% of their bill was AWS networking costs that have nothing to do with Atlas.
Most of the cost in their bill wasn't from MongoDB, it was cost passed on from AWS
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…
I'm not planning to because there is no documented protocol. If there were, I might! As a result, I can't use FoundationDB.
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…
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.
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…
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…
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…
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,…
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…
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…
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…
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),…
I don't like Taylor Swift's music, but I do hope this author experiences joy in something, sometime.
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 there are…
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 message.
You're correct, but in my experience the vast majority of code written is not downstream of a usable de-duplication mechanism.
By "patch" I am talking about the public commit. Updated binaries were made available when the CVE was published.
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?
The author of this post is incorrect about the timeline. Our Atlas clusters were upgraded days before the CVE was announced.
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…
We received communication that all Atlas clusters were upgraded with the fix before the vulnerability was announced.
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…
You can look at this particular bill and observe that more than 50% of the cost was going to AWS.
There's definitely MongoDB markup, but a full 33% of their bill was AWS networking costs that have nothing to do with Atlas.
Most of the cost in their bill wasn't from MongoDB, it was cost passed on from AWS
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…
I'm not planning to because there is no documented protocol. If there were, I might! As a result, I can't use FoundationDB.
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…
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.
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…
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…
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…
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,…
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…
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…
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…
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),…
I don't like Taylor Swift's music, but I do hope this author experiences joy in something, sometime.
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 there are…
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 message.
You're correct, but in my experience the vast majority of code written is not downstream of a usable de-duplication mechanism.