Announcement

Collapse
No announcement yet.

With Approaching Another Year Closer To Year 2038, Linux 5.5 Brings More Y2038 Fixes

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

  • pal666
    replied
    all devices in the wild have to support kernel updates, otherwise they will be running obsolete broken kernels very soon

    Leave a comment:


  • zxy_thf
    replied
    Originally posted by DoMiNeLa10 View Post
    Are there any plans to deprecate i686 support? I'd love to see x86 getting dropped entirely.
    It's unlikely to drop IA32 support anytime soon since Intel is still pumping out new IA32-only processors (Atom, Quark) for IoTs.

    Leave a comment:


  • discordian
    replied
    Originally posted by CommunityMember View Post
    Perhaps because things happened before Jan 1st, 1970 (the zero epoch), and you wanted a way to be able to represent them?
    Funny, that a negative time is an error in *nix (and most other OSes), you don't need to represent any system time that the system cant support. For everything else you will pick an solution that works (stay away from system time unless you need it in other words).

    a signed integer could have the advantage of detecting calculation errors, but I am not sure if there were much thoughts spent.

    IMHO, the core OS should refrain from using absolute timestamps, just use some unsigned ring arithmetic
    Code:
    isexpired = (targettime - time) < (maxtime / 2)
    . No need to care for wraps, timestamps only need to be
    Code:
    < (maxtime / 2)
    in the future. the rest are specific issues and solutions that can be better solved with specific solutions. You won't use filesystem timestamps for astronomic calculations after all.

    Leave a comment:


  • franglais125
    replied
    Originally posted by Britoid View Post

    We'll be dead long before 403207347832.
    Speak for yourself! I'm an optimist. Wait, either that or delusional, can't remember which.

    Leave a comment:


  • CommunityMember
    replied
    Originally posted by Raka555 View Post
    The question is why would you want time_t that can go negative? You can make that mistake in any language.
    Perhaps because things happened before Jan 1st, 1970 (the zero epoch), and you wanted a way to be able to represent them?

    Leave a comment:


  • Raka555
    replied
    Originally posted by CommunityMember View Post
    I suppose one could boycott Unix (and its derivatives) and the C programming language (and their other contributions), on the principal the creators did not imagine that what they started as a research project would still be in use 60+ years later. That will show them!
    The question is why would you want time_t that can go negative? You can make that mistake in any language.

    Leave a comment:


  • CommunityMember
    replied
    Originally posted by Raka555 View Post
    Who thought it was a good idea to store time as a signed integer
    Well, that would likely be either Dennis Ritchie and/or Ken Thompson back in the late 1960's, when they started working on their experimental OS because Multics was not sufficiently flexible.

    I suppose one could boycott Unix (and its derivatives) and the C programming language (and their other contributions), on the principal the creators did not imagine that what they started as a research project would still be in use 60+ years later. That will show them!

    Leave a comment:


  • Raka555
    replied
    People seem to forget that even an 8-bit system can handle a uint64_t just fine. It's just a bit slower to handle.
    You don't need to drop an entire architecture just because time_t was defined 32 bit and not 64 bit.

    Leave a comment:


  • GI_Jack
    replied
    Originally posted by DoMiNeLa10 View Post
    Are there any plans to deprecate i686 support? I'd love to see x86 getting dropped entirely.
    This isn't about 32 bit intel. Its about ARM, and other low power embedded architectures.

    And yes, I still expect to see 32-bit being in use in the future. Even RISC-V has a 32 bit implementation, and for the base low end processors that often consume milliwatts and cost under $1 to the manufacturer, there is little reason for anything else. Expect many of these devices to be installed, and run in production for years or decades without any updates. It is really hard to tell sometimes what larger system might end up relying on them, or how far past its expected end of service life they might run.

    Mitigating the 2038 bug completely, as soon as possible, is a wise decision.

    In case anyone is wondering about the Y2K bug? It was dead serious and real. It almost actually did cause the financial industry to crash. The only reason it didn't is a herculean effort by companies and developers to patch old systems. Anyone with any COBOL experience ate really well in the 90s, with stories of devs getting paid upwards of $300k/year, in 1990s dollars(about $500k in today's dollars) to fix the issue.

    Leave a comment:


  • Raka555
    replied
    Who thought it was a good idea to store time as a signed integer ...
    We should be having a 2106 problem and not a 2038 one ...

    Leave a comment:

Working...
X