You’d also know that dumping the database in MAME is very straightforward. The compelling counter argument to the perceived “separation of responsibilities” - is there is one source of truth.
First, to be petulant for a bit: Why would I? There's no arcade game I have ever had the desire to play (didn't grow up in the right era to have nostalgia for them); and so, despite tinkering with emulators / contributing to emulator development in general, I've never had any reason to use MAME.
The only interest I have in MAME is technological; and in that respect, I was trusting the explanation of the GP poster (whose authoritative phrasing implied them to be a contributor to the MAME project.) So when they said:
> Locking it down to specific "best we know of as of this moment" prevents people from easily using materials we know to be incorrect
— which strongly suggests not "allowing you to proceed anyway" — well, why wouldn't I believe that that's what happens?
But now, to actually rebut the spirit of this argument: how would you imagine I would learn this from MAME in only "a few minutes", without having a bad dump on hand to provide MAME with? As, presumably, you'd never see this dialog if you don't specifically trigger it by handing the emulator a bad dump as a ROM-chip asset for a game and then telling it to try running it.
Should I be downloading good dumps and then POKEing them in a hex editor to find out what happens? That doesn't sound like "a few minutes." Sounds more like something you'd only know if you're very involved indeed in MAME emulation, either deeply, on the game-archiving side; or for a long time — at least a decade or more — since back when sites archiving ROM dumps didn't care about the verified-ness of said dumps.
Going off the StackExchange thread linked in a sibling reply here, there seems to be no actual click-through in the UI version of MAME; rather, the way you are enabled to "run the game anyway" is by running the game from the command line — not something you'd be doing in your first few minutes spent tinkering around with MAME. (Thus, presumably, the GP's phrasing: "prevents people from easily using [...]".) Meaning that this is (much) less discoverable than you're implying; and, in fact, that my original suggestion — that this should be made to work more like a click-through browser security warning on the UI side, rather than being a full-stop blocker — is entirely a plausible and warranted change.
> You’d also know that dumping the database in MAME is very straightforward.
Would I? Again, sounds like something you'd only know if you're intimately involved in the MAME ecosystem.
Given that I spend my day professionally figuring out how to make production deployments out of undocumented alpha-quality software, I am able to educated-guess my way through Google, and then the MAME wiki, to finding this CLI subcommand — https://docs.mamedev.org/commandline/commandline-all.html#ma... — but that's not something I ever would have run into by just poking around.
> The compelling counter argument to the perceived “separation of responsibilities” - is there is one source of truth.
When the database is independent of the emulator, but there is only one such database that everyone agrees to use, that is also "a single source of truth." The database is effectively upstream of the emulator, like a library. The single source of truth is the canonical version at some URL pointed at by some RSS feed; the emulator's local copy is a mere cache, and one that would be invalidated by any change to the upstream database.
More importantly, though, is the practicality of the two setups.
A standalone database — or even a database living as a data file inside a release of a project — is just data, and therefore able to be extracted + transformed by anyone with the right file-encoding library to work with that data.
A database that's burned into the code of a project, where you must run the program itself with some flags to get the DB out, means that for any downstream project that wants to track the database for its own releases, this downstream project must acquire a copy of, and then run the upstream project, within its own build infrastructure. Which, for projects that would otherwise be simple CLI utilities, can massively bloat the build dependencies required of the project. (Some romset-verifier tool might just need libc to build; but for the fact that it needs to run MAME to extract its DB, and so now requires every library MAME requires to run, to build.)
You really should learn more about a product before you complain about it.
> Locking it down to specific "best we know of as of this moment" prevents people from easily using materials we know to be incorrect, which in turn also prevents people from sending invalid bug reports.
Which, whether it actually pertains in fact to MAME or not — not my concern here — would be a bad idea on its face, and one that I would want to discourage other emulator developers (who may well be reading this thread) from getting the idea is "a thing that is okay to do because MAME does it."
One big downside I would see is that it somewhat inhibits the creation/growth of an arcade-machine romhacking scene. (Unless there's some explicit provision in MAME for loading arbitrary patches on top of the known-good game versions.)
> which in turn also prevents people from sending invalid bug reports
Something to consider: some other emulators do this not by burning hashes into the code, but rather by downloading at runtime (tracking via RSS or the like) an independently-maintained known-good-dumps-hashes DB.
(Compare/contrast, the way that the http://www.accuraterip.com/ database is used in audio CD ripping.)
This approach enables a separation of responsibilities between "building good emulator software" vs "archiving and conserving specific games" — with one of the touted advantages usually being that that the database of good dump hashes can then be used for things other than just powering one specific emulator. It can be shared by many emulators, and other ecosystem tools; and it can even be used by anthropologists to study the "family trees" of game releases.
Also, when emulators besides MAME that use such techniques, detect that a game has a known-bad hash, they don't prevent you from playing it. They just tell you really loudly that you're about to play a bad dump (implicitly, disclaiming all liability for your doing so.) Like a modern web browser's "insecure" warning when retrieving a page over a non-HTTPS connection.