1. 14

  2. 11

    If I’m reading this article correctly, glibc is compliant by default when compiling for 64 bit architectures, it is only when building for 32 bit platforms that it does not use the new flag. The article makes it sound like most GNU/Linux systems are going to explode, but given that many distros (including my stomping grounds of Arch) aren’t even building for 32 bit platforms any more this might not turn out to be that big a deal.

    1. 16

      A better title would’ve been “glibc in 32 bit user space is still not Y2038 compliant by default” as suggested by someone on HN, which would be less clickbait.

      1. 4

        Based on previous posts submitted here, the author of the blog seems mainly interested in making posts that highlight specific deficiencies in glibc vs musl and using that to imply that you should never use glibc for any reason ever.

        1. 1

          I have made the same observation, with Alpine the obviously superior distributions, why aren’t all people using Alpine?

        2. 4

          A more accurate headline would be ‘being Y2038 compliant on 32-bit platforms is an ABI break and glibc requires you to opt into ABI-breaking changes’. Any distro that wants to do an ABI break is free to toggle the default (though doing so within a release series is probably a bad idea). Given that none of the LTS Linux distros has a support window that will last until 2038, it isn’t yet urgent for anyone.

          1. 3

            “glibc in embedded/I(di)oT will bite you in 2038”

          2. 7

            Some embedded boards on x86 / 32bit ARM deployed right now will still be working into 2038. This is about them.

            1. 12

              Sure. But that brings up two things the article should have addressed:

              1. State the scope of the problem rather than generalizing to all GNU/Linux except Alpine.

              2. Note that fixing the compiler may or may not fix boards that are already deployed anyway, the stuff that is likely to still be running in 17 years is also the stuff that never ever gets firmware updates. The real issue here is “what has been deployed before compilers started fixing this” and/or “what is currently being deployed to a never-updated long term deployment without proper compiler options turned on”.

              1. 3

                Fortunately the share of embedded Linux systems still using glibc is tiny.

                1. 4

                  Quite so! And of those that do, the number of them that are 32 bit and don’t get upgraded ever is also tiny. Maybe a single system in a non critical role, like a greenhouse watering system watchdog, actually falls under this criteria.

                2. 2

                  Fortunately there’s more awareness about things like that in embedded development. It’s not perfect of course, but you tend to deal with custom glibc and similar issues more often, so a lot of people deploying things that depend on real dates today will know to compile the right way.