Announcement

Collapse
No announcement yet.

Glibc's Slow Turnaround For Y2038 Fixes Is Frustrating

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Glibc's Slow Turnaround For Y2038 Fixes Is Frustrating

    Phoronix: Glibc's Slow Turnaround For Y2038 Fixes Is Frustrating

    While there is another nineteen years to go until the Year 2038 problem manifests, the GNU C Library "glibc" is one of the key software components still needing some fixes for this issue where this problem where storing the Unix time as a 32-bit signed integer will wrap around and become a negative number...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    GNU development is slow in general.

    I wonder why people are so desperate right now with so much time left. Are they designing embedded devices with such a long lifetime?

    Comment


    • #3
      Embedded devices live a long time. This is indeed an issue. Why is it so hard to fix? Will a fix, say a 64bit value, break lots of apps?

      Comment


      • #4
        Originally posted by Spam View Post
        Why is it so hard to fix? Will a fix, say a 64bit value, break lots of apps?
        That's API and ABI breakage I guess, so yes, all of them.

        Comment


        • #5
          Originally posted by Spam View Post
          Embedded devices live a long time. This is indeed an issue. Why is it so hard to fix? Will a fix, say a 64bit value, break lots of apps?
          how long do you keep a TV for? Car? Digital sign deployed as a roadside billboard? Some embedded devices have long lives, and not all receive post deployment updates. So fixing the issue 15-20 years in advance might actually be cutting it close?

          Comment


          • #6
            Would switching to musl or uclibc help?

            Comment


            • #7
              I know that 32-bit glibc RISC-V support is waiting on Y2038 support (64-bit time_t) because they want the api/abi to not need to change right after stabilization.

              Comment


              • #8
                Originally posted by DoMiNeLa10 View Post
                I wonder why people are so desperate right now with so much time left. Are they designing embedded devices with such a long lifetime?
                Yes, embedded is the thing people are worried about. (Outside embedded, 32-bit is more or less dead anyway, and certainly so by 2038.)

                But imagine you start developing sw for some embedded stuff today:
                • You choose some kind of BSP (board support package) for the hardware you're targeting, including an embedded distro. Most likely this is not bleeding edge, but some kind of LTS thing. So lets say the software is a few years old.
                • Then you spend a couple of years developing your software on top of the above platform. That takes, say, a few years. So by the time you get something out in the market the oldest part of your software stack (including kernel and libc, most likely) is around 5 years old.
                • Then the company might want to sell said thingy (hw+sw) for, say, depending on industry, 5 years, before it's replaced by a newer model. By this time the oldest part of the stack is already 10 years old.
                • And then you have customers (hopefully). If the customer expects a usable life for the product of, say, 10 years and happens to buy it just before it's replaced by the next generation, then by the time the customer replaces the product the oldest part of the software will already be pushing 20 years.

                2019 + 20 = 2039. 2039 > 2038; Oops.

                Comment


                • #9
                  On why Denx patches are not accepted:
                  The arguments he gives are not on a technical level; instead he says that only a native English speaker who has a with deep understanding of glibc internals and the previous development process will be capable to provide such a patch in an acceptable way.
                  Now you have all that "outreachy" programs on one hand, and on the other hand you are screwed if you weren't born in England (or its colonies) and raised by a GNU approved household. If politics haven't pushed me over the edge, this did: Stop the damn simulation you mice, its gone horribly wrong.

                  Comment


                  • #10
                    Yeah, review times for glibc is too big. I sent a few simple warning fixes 3-4 months ago, and even pinged once — still no answer, patches just fell into void. And it's not a unique situation as I can see from reading the ML.

                    Comment

                    Working...
                    X