Right, and then everybody would be in the comments complaining about how "everybody is using a new term for planet and it's ridiculous, just call them planets". It's not a battle that can be won.
Who said games were well written? Older games are often very sloppy and buggy, and abuse the specific hardware they're designed for to get extra performance, unique graphical effects, etc.
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 wouldn't characterize that as sloppy or buggy in any way (though certainly that is also true for some games). Exploiting hardware in new and novel ways was an essential part of developing for older consoles.
This is something someone only familiar with writing code for general purpose devices or higher level languages can't imagine. But when you're building for one very specific hardware platform you can tailor your code to that platform in ways that simply aren't possible when building for portability.
Why would you assume that? That's not even true of regular software :D
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.
That seems a bit silly considering how many of the most famous paintings and artworks are/were commissions. Do you disqualify anything that was made for monetary reasons?
On its own that seems like a pretty weak justification, at that point we would need to preserve every copy of every book forever because you never know what what useful physical material it has on it even beyond its text. That extends to non-book items as well, and while I understand the idea it's just not realistic in any sense.
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.
My comments on this subject aren't some sort of justification for any particular course of action; they're more a disapproval of the course of action being made by people people who have more dollars than sense.
As a general rule preserving historical artifacts for continued future analysis and appreciation by people who have yet to be born is a noble cause that's considered worthy in and of itself without the need to justify it. We're talking about the richest group of people who have ever existed with the means to preserve them but decline to do so and instead act like the Taliban blowing up statues of Buddha.
I think this is intuitive to most people. If a prerequisite for the birth of AGI was that a humanoid robot had to sit down in the Louvre and eat every single painting there with a knife and fork while occasionally stopping to wipe away historical detritus with the Mona Lisa that it's wearing as a bib people would by and large express a visceral and justifiable outrage.
The people who are doing this know how this looks so they're trying to do it all behind closed doors, through cut-outs and intermediaries.
> I might be being overly cynical here, but I think part of the problem is parents expect to give their kids the internet so they don't have to spend so much time/attention with them.
> 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.
I don't mean to be confrontational, but the key detail you thought I missed, about it being complicated, was a fairly crucial part of my point that you've overlooked:
My parents when I was young ended up having to figure out how to use digital cameras, scanners, printers, fax machines and then print, sign and sometimes even post off a letter for me to access one website which I wanted, which could take hours of their time in a process that took literally weeks. This was in the early 2000s, when scanners and digital cameras weren't exactly user friendly. They had to do this sometimes multiple times a month. Every website was different, there was no universal permission slip. But they did it. Eventually, they too got bored and gave up, or maybe I just grew out of it.
Point being, the tools have always existed, and always felt inappropriate or convoluted, but my parents at least were happy to do it for their kids 20+ years ago. From what you're telling me, they're now a lot faster and easier to access and use.
Even if the tools were made to take only a few minutes to setup, there would still be a vocal set of parents unintentionally arguing that everyone should suffer with overbearing ID tools so they can spend less time supervising their kids internet usage.
> Point being, the tools have always existed, and always felt inappropriate or convoluted, but my parents at least were happy to do it for their kids 20+ years ago. From what you're telling me, they're now a lot faster and easier to access and use.
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.
It's far quicker/easier/more convenient to sit in front of a screen and try find some buttons. Your issue seems to be that those buttons have got harder to find and understand - that's a fair point.
My point is that - overall - clicking some buttons and waiting a few hours is far more accessible, faster, easier and less disruptive than what my parents had to do 20 years ago:
It required far, far more effort and thinking and action to find some physical, expensive, modern hardware, digitise signatures, and the post things off.
"Faster" is very relevant in a discussion about convenience and effort. The important point is how convenient it is for the child and the adult. Now, a child has to sit for an hour watching you fumble around on a screen. I had to wait for days and days whilst my parents fumbled around with cables and when to the post box and other stuff.
> the amount of time actively spent dealing with these things.
My parents used to have to spend more time actively dealing with me and my things whilst I was waiting for the post.
We're not going to agree here. You're a parent, complaining about how much time you have to spend supervising your kids. I sympathise for you, the modern world has a whole lot more expectations of your time which my parents didn't have. This is one of the many reasons me and my partner chose not to have kids, sorry.
Everything you describe is an argument for not trying to bake age verification in at a lower level - because all of those issues will become everyone’s problem, whether or not they’re parents, except they won’t be able to “turn off age ratings” any more, instead people will be fighting with systems that don’t recognize their ID document upload or whatever.
That, in the end, will hopefully kill these idiotic attempts at dystopia enhancement, because when people discover that “think of the children” makes their day to day life more difficult, it’ll lose support.
> But the bug is still almost always in an unsafe block.
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.
> The only part the compiler actually enforces is that you mark the specific spots where you make use of the operations that 'unsafe' allows.
Yes, I wish there was a way to mark code as unsafe without also allowing unsafe operations. Its quite common I have some "safe" code that generates values which are eventually used in an unsafe block. If the "safe" code is wrong, my unsafe code will fail in memory-unsafe ways. But there's currently no way to annotate this sort of "safe" code. Rust provides the unsafe keyword - but that keyword is generally reserved for code which needs to actually make unsafe operations (like derefing pointers or calling other unsafe functions).
Yeah I agree with that as well, the unsafe keyword takes on a double-duty which makes it unclear how it's actually intended to be used. The idea that you might mark a function that's only made of safe code as 'unsafe' is not that obvious and not always agreed upon, I've seen plenty of debating about it.
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.
> The fact that 'unsafe' also enables all unsafe operations in the function body just makes it even messier
This changed in the 2024 edition to now fire a warning lint, asking you to wrap your unsafe operations in an unsafe block, even inside an unsafe function.
I think this point gets missed too often in the face of technical things the Rust compiler does.
There was a world where everyone just used the unsafe keyword everywhere, and Rust code crashed & had memory issues all the time.
The big thing Rust did wasn't invent borrow checking or memory safety; it's the ease of use, the defaults, and the social aspect of "if unsafe is used, a memory bug is in the unsafe part".
> A leap-hour, meanwhile: That kicks the can so far down the road that we'll probably lose track of it completely. 600 years is a very long time; society will be a very thing by then. Leap-hours seem to me to be moral equivalent to the "fuck it, let's just give up" option.
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.
An extreme example is Xinjiang, where solar time can be more than three hours off from civil time (due to the PRC policy of having only one time zone for all of China).
Indeed. On a long-enough timeline, people will adjust to whatever it is that the sun is doing regardless of what the clock on the wall says. That's the way it has always been.
So when we're talking about one second every once in awhile, I'm not sure that [effectively] giving up by adopting leap hours instead of leap seconds isn't the right option -- as long as we agree to do it uniformly.
For me the problem is that the target performance is in a weird spot - low enough that it's not amazing, but high enough to still be very expensive if you don't plan to play games that actually require that performance.
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.
