But also, as long as the game works on the specific hardware it was designed for then that's all that mattered, which was my point. If it reads uninitialized memory or depends on exact cycle counts or some undocumented hardware behavior then that's _fine_ if it still works on the real hardware, plenty of that was even intentionally done to achieve things otherwise impossible on that hardware.

At the same time it makes it almost impossible to verify even trivial changes to a function. Once you start accounting for all the potential state differences the answer to "does this function work the same?" will basically always be 'no' unless the code is identical. The only way to eliminate various kinds of state from being a concern is to analyze where the function is _used_, rather than just the function itself, and that's an entirely different and much harder kind of challenge.

Emulators constantly run into games that don't run because of specific hardware nuances that may or may not have been intentionally used (Ex. relying on exact cycle counts, reading uninitialized memory, changing values while they're used, etc.).

I think the more important part is to define what "rare" actually means and save/digitize set copies of those books that are actually at risk of being lost completely (rather than letting them rot away somewhere or get bought up to be privately destroyed). I suspect many of them are just not at all interesting enough to justify the expensive though.

No they're not, the systems that exist today often don't even work and there's no alternative of "just mail a letter to Microsoft and they'll sort it out for you".

"Faster" is also a frankly a silly point - it's not like your parents were waiting at the mailbox until the letter came in the mail, the important question is the amount of time actively spent dealing with these things.

> I think this means any solution which involves active parent participation is going to get shunned by a vocal subset.

I don't think that's a fair assessment personally, rather you've missed a key detail that things are significantly more complicated than they used to be, it's not just an 'effort' issue. There is no universal "user is age X" setting that applies to everything everywhere, rather everything has a different system and pretty much all of them are terrible in various different ways.

I'm very tech savvy and I still struggled just to set up a Microsoft/XBox account for my daughter so that we could play some computer games together. Access to all the different age rating settings is spread across something like three different apps and websites and in my experience they don't even all work consistently. That experience is also not dissimilar from the experience with other types of accounts. For people I know who are less tech savvy it honestly doesn't matter how much time they put into it, eventually they give up and turn off age ratings because something isn't work and even if there's a solution it would take them hours to figure out.

Point being, if the existing tools were much better I don't think we would be having this kind of conversation.

The fact that 'unsafe' also enables all unsafe operations in the function body just makes it even messier, since you definitely _don't_ want that unless the entire body is really nothing but unsafe operations. Thus the "mark a safe function as unsafe" has a clear downside since it allows all the unsafe operations you didn't want to use.

That's entirely dependent on how you write your Rust code. If you're derefing an invalid pointer then the bug is usually in how you calculated that pointer value, but the only part that actually requires 'unsafe' is the deref, not the bugged pointer calculation.

Now in properly written Rust code you should be marking all of that code as 'unsafe' in that case and documenting what invariants need to be maintained, but that's entirely on you to do. The only part the compiler actually enforces is that you mark the specific spots where you make use of the operations that 'unsafe' allows.

1. Too many people think that having lots of text makes something impressive, really it's just inconsiderate and nobody is reading it all.

2. Helping people often feels pointless because I can tell I'm just getting a cut/paste AI response back.

Something to consider: The use of timezones in mostly 1-hour increments over inconsistently placed areas means that the vast majority of people are already living many minutes off from the "actual" time at their precise location, in some cases even more than an hour. "Giving-up" implies that this is something important worth maintaining, where-as for the vast majority of people they gain nothing from leap seconds or even leap minutes. The most important thing for people is simply that everybody agrees on what time it is, which is easier when leap-Xs aren't done.

That said it's also probably true that a leap-hour would never actually happen, but that's not some big issue. By the time we got to the point that a leap-hour would make sense people would have already adjusted their habits and it probably wouldn't be worth it.

A cheap $300 mini-PC is a lot weaker but it can still play plenty of indie and other games just fine, ultimately that's what matters. For me, I would have considered buying one of these if they had one at a $300 to $400 price point even though it would have been significantly weaker, but at $1k it's just impossible for me to justify.

Ex. if I license my artwork, music, characters, code library, etc. to a game developer and they don't create a legally releasable version of their server, then the government will forcibly break our licensing agreement and I just get screwed?

It's a question of when, not if - you're not going to pay to keep the servers online forever. What are the legal consequences of not releasing a functioning server if for some reason you can't? If they're bad enough then plenty of people will not be interested in taking that risk by making such games.

It's not, that's clear from this kind of bug popping up. Functionally this bug exists because `PathString` was converted into a "safe" Rust API but still works the same internally as the original Zig code did (via using `unsafe`), that introduces UB that wasn't there in the Zig code.

If it was attempting to be a 1:1 with no behavior changes (like c2Rust attempts to do) then this would not have been turned into a "safe" Rust API like this.

Why do they need to buy eBay to do that?

If you're saying sellers could come into a GameStop to have their individual items packed and shipped out, I suppose, but:

1. They don't really have the space for much shipping volume at any of their stores.

2. You can walk into any USPS, UPS, FedEx, etc. store and do that already, you don't need an 'EBay' store. GameStop would presumably get the packages picked up by one of those carriers so it's not saving any shipping time or expense.

For buyers, in many cases there's already alternative drop-off locations similar to GameStop Ex. For UPS deliveries I can get them shipped to a bunch of different convenience stores near me. GameStop stores might be a nice addition to that list but it's not enabling something you couldn't do before, and I would think for most people they already have a closer location than a GameStop.