Live data from Hacker News

Doom crash after 2.5 years of real-world runtime confirmed on real hardware

lenowo.org

181–190 of 221 posts

Re: Doom crash after 2.5 years of real-world runtime confirmed on real hardware

#181

Earlier quoted context omitted.

> Back in the real world, no race team would agree that their cars should disintegrate after one race. Wasn't F1 teams basically doing this by replacing their engines and transmissions until the rules introduced penalties for component swaps in 2014?

Yup, cigarette money enabled all kinds of shenanigans. Engine swaps for qualification, new engines every race, spare third cars, it goes on. 2004 was the first year that specified engines must last the entire race weekend and introduced penalties for swaps.

> cigarette money enabled all kinds of shenanigans.

It still does. New Zealand has a crop of tobacco funded politicians.

Re: Doom crash after 2.5 years of real-world runtime confirmed on real hardware

#182
post #13

Earlier quoted context omitted.

There's a weapon in Final Fantasy 9 which can only be obtained by reaching a lategame area in less than 12 hours of play time, or 10 hours on the PAL version due to an oversight. Alternatively you can just leave the game running for two years until the timer wraps around. Slow and steady wins the race. https://finalfantasy.fandom.com/wiki/Excalibur_II_(Final_Fan...

Am reminded by this quote from Ferdinand Porsche: "The perfect racing car crosses the finish line first and subsequently falls into its component parts." Games fit this philosophy, compared to many other pieces of software that are expected to be long-lived and receiving a lot of maintenance and changes and evolve.

There's a quote in the bible that says something similar:

"Verily, verily, I say unto you, Except a corn of wheat fall into the ground and die, it abideth alone: but if it die, it bringeth forth much fruit.”

(John 12:24)

Re: Doom crash after 2.5 years of real-world runtime confirmed on real hardware

#183

Earlier quoted context omitted.

Dividing by a difference that is suddenly zero is another possibility.

The error states that the window can't be created. It might be the problem with parameters to the window creation function (that should not depend on game state), or maybe the system is out of memory. Resources allocated in memory are never cleaned up because cleanup time overflows? Doom4CE (this port) was based on WinDoom, which only creates the program window once at startup, then switches the graphical mode, and p…

The VGA 320x200 mode, either 13h or "Mode Y", ran at 70.086 Hz, so that adding up to ~2.5 years is just coincidental.

It's a shame the source code for doom isn't available, and that the author couldn't just link directly to a specific line in a gitweb repository. /s

Re: Doom crash after 2.5 years of real-world runtime confirmed on real hardware

#184

Earlier quoted context omitted.

Yup, cigarette money enabled all kinds of shenanigans. Engine swaps for qualification, new engines every race, spare third cars, it goes on. 2004 was the first year that specified engines must last the entire race weekend and introduced penalties for swaps.

> cigarette money enabled all kinds of shenanigans. It still does. New Zealand has a crop of tobacco funded politicians.

>New Zealand has a crop of tobacco funded politicians.

when they leave politics do they just rapidly age and dissolve like that guy in the Indiana Jones film?

Re: Doom crash after 2.5 years of real-world runtime confirmed on real hardware

#185
post #116

Earlier quoted context omitted.

Are there not industrial ones meant to last longer? Maybe you can buy a used but good condition one of those.

There are, and if you really have the workload that you need to cook stuff 24/7 (what in gods name is OP cooking btw?) then you should definitely get one of those. Maybe not even secondhand but just a new one. The cheap consumer grade ones are meant for people who use them once or twice a year. This is a fine example of what I meant about people complaining when they use products beyond their design parameters.

If the manufacturers keep replacing the machines because they're within warranty isn't this cheaper for OP?

Re: Doom crash after 2.5 years of real-world runtime confirmed on real hardware

#186
post #89

Earlier quoted context omitted.

Signed overflow is undefined behavior in C, so pretty much anything could happen. Though this crash seems to be deterministic between platforms and compilers, so probably not about that. TFA says the variable is being compared to its previous value, and that comparison presumably assumes new < old cannot happen. And when it does, it could easily lead to eg. stack corruption. C after all happily goes to UB land if, fo…

Just because the language standard allows for anything to happen doesn't mean that actually anything can happen with real compilers. It's still a good question to think about how it could actually lead to a crash.

That’s what I said? It’s easy to come up with scenarios where signed overflow breaks a program in a crashy way if the optimizer, for example, optimizes out a check for said overflow because it’s allowed to assume that `++i = 0. That’s something that very real optimizers take advantage of in the very real world, not just on paper. For example, GCC needs -fwrapv to give you guaranteed wrapping behavior (there’s sctually -ftrapv which raises a SIGFPE on overflow – that’s likely the easiest way to cause this crash!)

But I specifically said that it doesn’t look like SOUB in this particular case, and proposed an alternative mechanism for crashing. What’s almost certain is that some type of UB is involved because "crashing" is not any behavior defined by the standard, except if it was something like an assertion failing, leading to an intentional `abort`.

Re: Doom crash after 2.5 years of real-world runtime confirmed on real hardware

#187

Earlier quoted context omitted.

Does this discussion strike you as one where I’m deliberating whether or not to chuck my smartphone and buy into a new ecosystem to avoid ads on fandom? These types of comments are always very unhelpful.

No, that's just a reminder that you had a choice, and chose empty talk about “ecosystems” over ability to control what you can see on “your” screen. You've stepped on a rake once, you got some experience, why repeat it over and over again?

Or another option: we could remember that the ultimate offender here is Fandom.

My choice of device is irrelevant when assessing their crappy site.

Re: Doom crash after 2.5 years of real-world runtime confirmed on real hardware

#188
post #77
post #51

Earlier quoted context omitted.

Isn't this common in the computer game scene? Shouldn't you asume your game will be disassembled, deconstructed, reverse engineered? Although for old games released before internet was widespread in the general population, it might have not been this obvious.

aslong as it doesnt lead to online cheats having such code is fine. if someone wants to reverse the game find an obscure almost untriggerable bug and then trigger it or play with it. 2.6 year game session is crazy if its not a server, and if its a server, thats still really crazy even for some open-world open-ended game... its a long time to keep a server up w/o restarts or anything (updates?). looking at the various…

> if its a server, thats still really crazy even for some open-world open-ended game... its a long time to keep a server up w/o restarts or anything (updates?).

Pretty much doable even without resorting to VM migrations or ksplice. My last one had uptime in 1700s (days). Basically I leased it, put a debian on it and that was that until I didn't need it anymore.

Re: Doom crash after 2.5 years of real-world runtime confirmed on real hardware

#189

Earlier quoted context omitted.

You are on iOS. There is only safari. Any other "web browser" is just a skin over safari

Yes I know everything is wrapped around safari. But I like having Firefox syncing across devices. Edit: ah forgot my vpn was off, usually clears all that up for me. Much better now

[deleted]

Re: Doom crash after 2.5 years of real-world runtime confirmed on real hardware

#190

Earlier quoted context omitted.

I run sous vide cookers 24*7, and they uniformly break within 90 days or less. But they don't like to admit their smaller duty cycle, so they don't, and keep sending me warranty replacements instead. I keep buying different brands looking for one with a longer life. I'll bet most people do that when their gadgets die, and purposely making products that die as soon as sold isn't often a successful business model.

Try a Breville PolyScience... https://www.breville.com/en-us/product/csv750 Or if you want something even beefier: https://sammic.com/en/smartvide-xl

It looks like the Breville is the most affordable at $600. Currently I'm paying optimistically $45/90 days or $0.50/day. For the Breville to match that it would need to survive for 3.29 years. Will it?
Post reply on HN