1. 66
  1.  

  2. 18

    oh wow, 2038 is going to be a lot of fun.

    1. 3

      I have run old (i.e. more than 15 years) 32-bit binaries and it’s already a pain.

    2. 5

      I have to admit, I would not have guessed that y2038 could have caused such obscure behavior. (We really need to finish migrating away from 32-bit software over the next decade.)

      1. 10

        There are many proprietary software in the state of abandonware; games are a good example of that, and I believe Steam is going to become some sort of mad games archive (if it isn’t already). Original developers might not have access to the code anymore, it might even be lost forever, or maybe they wouldn’t be allowed to modify it, couldn’t care about it, etc.

        I believe old video games (and actually all proprietary software for that matter) are kind of in the same position as old video files: when spread in the wild, we have to support them forever. That’s why the amount of hacks to support old broken encoded files that you can find in projects like FFmpeg is likely never going to shrink, ever. You need to be able to playback an old .avi or .wmv files from your hard drive from 20 years ago, even if the dumb encoder that produced them doesn’t exist anymore, and even if it was generated a half broken files violating whatever standard at that time. It’s terrible and depressing, but that’s the way it is.

        Instead I’m expecting to see some sort of virtualization/container mechanism that put these games in some sort of time loop by isolating a fake clock and hooks all stat FS accesses such that never reaches y2038.

        1. 2

          But even with virtualization, etc, how do you pick the time it is? What if the software uses functions depending on time, day of week, etc.? Especially video games tend to have Easter eggs.

          You’d have to decide if you want to to be close (so January 2038), if you need the right week days, how long the application runs so it doesn’t have to go over 2038, software might even do worse if time goes backwards, especially in bigger steps.

          Side note: Containers as they are mostly used today I don’t think are varying in time, because they share the OS which keeps the time.

          I’d think that today’s software will likely run in an emulator. Does anyone know how emulators for very old systems deal with Y2K and other time related issues, for example in games that use something like Release Year + X or something to shave off some bits?

          1. 3

            But even with virtualization, etc, how do you pick the time it is? What if the software uses functions depending on time, day of week, etc.? Especially video games tend to have Easter eggs.

            An arbitrary user offset from the current clock?

            Side note: Containers as they are mostly used today I don’t think are varying in time, because they share the OS which keeps the time.

            On the technical side, a naive implementation would use LD_PRELOAD to hook gettimeofday, stat, etc

            1. 2

              An arbitrary user offset from the current clock?

              Yes, that’s what I mean. Not trivial to choose. Might even be hard to decide on what’s the “best offset” on a per-software basis. And you might very much not be aware about all the things it does, so I am expecting a lot of interesting investigations and “archeological” findings in that area in the time after 2038.

              On the technical side, a naive implementation would use LD_PRELOAD to hook gettimeofday, stat, etc

              Again, that’s what I mean. Not really a container. But then that term is loosely defined and only nitpicking. ;-)

              1. 1

                Might even be hard to decide on what’s the “best offset” on a per-software basis.

                What’s wrong with “release date plus one year”? I’m not seeing what you think will be hard about picking which time to emulate. (As opposed to emulating the desired time, which is a technical challenge.)

              2. 2

                On the technical side, a naive implementation would use LD_PRELOAD to hook gettimeofday, stat, etc

                There is already the rather sophisticated libfaketime: https://github.com/wolfcw/libfaketime

              3. 2

                There’s a time namespace since around Linux 5.6 but it only lets you mess with the boot time and monotonic clocks, not the real time clock. https://man7.org/linux/man-pages/man7/time_namespaces.7.html

                The sensible way to fake the date for just one process is to run it in a virtual machine of course. :)

          2. 0

            This article perfectly summarises the sheer hatred I have for the software industry and software in general. Horrible shit, it’s going to kill us all eventually, and in the most ridiculous and stupid way you could possibly imagine.