An interesting question about Stop Killing Games is if this should apply to software more broadly. If a company shuts down should they open source their product so people can continue using it? There isn't as strong an argument for this since most software is structured like a SaaS rather than a one time purchase. But it's considerate when companies do this, e.g. Facebook open sourcing Parse Server was better than outright discontinuing it.
Maybe not open source it. But at least allow it to operate in offline manner where for one time purchases you do not have any license checks that stop it from operating. I do not expect things like cloud sync to continue. But at least I should be able to run it on my local machine.
> If a company shuts down should they open source their product so people can continue using it?
The question is who is now responsible for the software? Who can the government compel to open source it? There is no more legal entity behind the software. Maybe the last employee just takes the source code home on their laptop and that's it.
How is a government forcing a private entity (especially a defunkt one) to release their source code?
When a company shuts down, somebody becomes the new owner of their stuff, including their intellectual property. Most of the time it's whoever the company was in debt to. Now that company can choose to either host the software, or release it.
This just feels like one of those things that can be completely loopholed. There's plenty of reasons why a company might find a specific software not profitable but also not want to open source it, so under this rule they will just host it on the most basic server possible (only concurrently supports like 50 users) and never update it again. Effectively still dead.
No, they do not want to force publishers to keep a game online. The initiative just wants developers to provide a way for users to keep using a game after it has gone EOL by allowing users to run their own servers or by no longer requiring internet access.
See the FAQ[1]:
> Aren't you asking companies to support games forever? Isn't that unrealistic?
> A: No, we are not asking that at all. We are in favor of publishers ending support for a game whenever they choose. What we are asking for is that they implement an end-of-life plan to modify or patch the game so that it can run on customer systems with no further support from the company being necessary. We agree that it is unrealistic to expect companies to support games indefinitely and do not advocate for that in any way. Additionally, there are already real-world examples of publishers ending support for online-only games in a responsible way, such as:
> 'Gran Turismo Sport' published by Sony
> 'Knockout City' published by Velan Studios
> 'Mega Man X DiVE' published by Capcom
> 'Scrolls / Caller's Bane' published by Mojang AB
> 'Duelyst' published by Bandai Namco Entertainment
I'm not sure what the question "What does it have to do with democracy?" is referring to. Some people find that no longer having access to video games they paid for isn't fair so are petitioning their governments for consumer protection against that.
Desktop Commander is new to me so I'll check it out. I'm excited for these kinds of coworking tools that have a lot of leeway to act on systems more broadly. I have been using Claude to create spreadsheets and documents for various tasks and it has been quite helpful. Claude has an "add to Google Drive" button for files so I was hoping I could have Claude edit files in my Drive too but it looks like that isn't possible unfortunately.
I'm particularly excited for when the models are capable (and safe) enough to be more autonomous and persistent. A lot of these tools still have a human in the loop. It seems like we've gotten a taste of that with OpenClaw but there's so much more potential.
Hey Manish! Congratulations to you and your team on the round! It's a phenomenal achievement.
You mentioned transactions... I work for MongoDB so I just wanted to add that MongoDB does have ACID transactions since version 4.0. Distributed transactions will be included in the upcoming 4.2 release. There's more info on distributed transactions in the 4.2 release here if you're interested: https://docs.mongodb.com/master/core/transactions/
By the way, it's awesome to see you're using Go. I just got into it recently and it's such a nice language to work with.
Thank you! As an aside, is there a reason you're not using a write concern of "majority"? If you have w:3 in a three node cluster then if one node goes down, writes are going to start throwing wtimeout errors (assuming you have wtimeout set) even though the data may safely be written to a majority of nodes. We generally recommend setting w:"majority" for this reason.
It was recommended by our vendor. I asked why, he was just paranoid. But, most of the data was entered on a semi connected mobile device, stored on the handheld and synced when they had service. If it wasn’t immediately writable to the server, it wasn’t a show stopper.
Plenty of people are successfully using MongoDB for real, customer supporting data at a large scale. There's a selection of users on the website for a start: https://www.mongodb.com/who-uses-mongodb
The Jepsen tests [1] have been run against MongoDB - while older versions presented edge-case opportunities for data loss, that's no longer the case with recent versions. The Jepsen tests also specifically test sharded clusters. From Aphyr's report:
These tests are now integrated into MongoDB's regular test suite. Maybe MongoDB wasn't the right choice for you at the time you were evaluating it, but I just want to point out that MongoDB has matured and improved a great deal.
Wasn't it only has of version 3.4 that Jepsen stopped finding single-node data loss bugs in MongoDB? So it's been 3 years that MongoDB has been suitable for single-node data storage, and apparently 5 months that it's been reasonable to use in a sharded deployment.
Perhaps in another decade, MongoDB can shed its well-earned reputation for eating data.
I think it's fair to say that it might take some time to regain trust. Just want people to know that the software is being improved and large strides have been made in this area.
The thing is, it's too late. When MongoDB was in its heyday, it got known as something that loses records. Not much you can do now when for every post affirming its consistency, there are two about how someone tested it and it failed consistency checks.
I'm not disagreeing with anybody else's test results. Just want to say that MongoDB has matured a lot and people should test out the newer versions to see how they fare.
Kind of in line with the article, I think that people should methodically check what works for them... particularly for something as serious as a database. It would be a shame if somebody decided against using something because they heard about an issue that has been fixed and/or improved in more recent versions.
FWIW, the data loss I was referring to happened on a single node. There may have been issues in a distributed environment as well but we never got there.
Great article - it's definitely vital to fully understand the tradeoffs of any technology you choose, and not just going with the latest fad.
I work at MongoDB, so I do want to mention that MongoDB has changed a lot over the past few years. MongoDB now has multi-document ACID transactions. Also, schema validation means you can enforce a strict data structure if you want. On top of that there have been improvements in data durability and consistency (the Jepsen tests are now integrated into the MongoDB test suite).
As mentioned in the article MongoDB has matured a great deal. It's far more mature and fully-featured in 2019 than it was in 2012.
MongoDB will reuse free space when documents or collections are deleted (even though the storageSize stat will remain the same). You can compact the database to release free space to the OS. You can read more about how MongoDB's WiredTiger storage engine reclaims space here: https://docs.mongodb.com/manual/faq/storage/#how-do-i-reclai...
I work for MongoDB so if you have any questions about storage, feel free to reach out.