Announcement

Collapse
No announcement yet.

Linux 4.18 Continues Prepping For The Year 2038

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

  • torsionbar28
    replied
    Originally posted by L_A_G View Post
    Really, the whole thing just boiled down to the media wanting a huge story to report and greedy consultants all too eager to take advantage of the situation.
    ^ This is true for much of what's considered "news" these days.... Who cares about facts, we have a panel of experts here to weight in with their opinions! Stay tuned, so we can influence your opinion!

    Leave a comment:


  • makam
    replied
    Originally posted by wizout View Post

    I truly hope you never end up managing life-critical systems.
    I do hope so too as having so much responsibility would be dancing around my stress threshold.

    However i think you misunderstood what I was trying to say. I never meant to say that you should remove preventions to test it out.

    I was referring to how when things are working correctly nobody gets thanked, but when things break everyone blames you. Same when the year 2038 happens, few people will thank engineers and think about the many hours that went into fixing the problem, most will just say 'Oh those pesky engineers have overblown that problem, yet barely anything happened'.
    Last edited by makam; 06-07-2018, 04:05 AM.

    Leave a comment:


  • wizout
    replied
    Originally posted by makam View Post

    You can't be sure if your prevention is working until you try going without it.
    I truly hope you never end up managing life-critical systems.

    Leave a comment:


  • jpg44
    replied
    Its already a problem now because some software has to use dates that far into the future. Like financial and scientific software. One solution of course is to address it in a time API that uses explicitely 64 bit integer rather than a native integer on all platforms. This can involve using an 8 byte array, or the fixed width 64 bit integers, on 32 bit platform loading the lower and upper part of the array seperately and running seperate 32 bit operations to simulate 64 bit operations . time_t is often assumed to be a native int and some code exists that puts time_t values into a native int. This has been discussed for years, one possible solution to make time_t 64 bits on 32 bit platforms, is implement a new 64 bit ABI, have a stdlib/compiler switch that causes the toolchain to cause time()/time_t use that rather than the 32 bit one, have a tool in the compiler to raise warnings if int cast is found, and also a tool to automatically rewrite code so time_t always goes into explicitely 64 bit data types.

    An argument can be made for always using fixed width integers for data and saving native ints for pointers. The size of data fields is driven by the needs of the application rather than CPU register size. Some might argue that fixed width might consume more cycles on CPUs with smaller registers. But the determining factor on the correct size is the application , so you can make an argument that the correct size would not be different on different CPUs.

    Leave a comment:


  • L_A_G
    replied
    Originally posted by rtfazeberdee View Post
    well, they did spend millions on making sure it didn't. Thats the problem with "scare stories" when they don't happen, people overlook the obvious facts that other people did the work and found solutions to make sure said "scare story" didn't happen.
    You do realize that's exactly what all of the overpriced consultants who did all of the "Y2K Compliance" checks would have said even if there were no problems.

    Really, the whole thing just boiled down to the media wanting a huge story to report and greedy consultants all too eager to take advantage of the situation. All that really happened was some stupid things like 103-year-olds being sent kindergarten invitations and perishable food items being thrown out by mistake.

    Leave a comment:


  • makam
    replied
    Originally posted by rtfazeberdee View Post

    well, they did spend millions on making sure it didn't. Thats the problem with "scare stories" when they don't happen, people overlook the obvious facts that other people did the work and found solutions to make sure said "scare story" didn't happen.
    You can't be sure if your prevention is working until you try going without it.

    Leave a comment:


  • rtfazeberdee
    replied
    Originally posted by eydee View Post
    They predicted the end of the world because of the year 2k issue. It didn't happen. It's a safe bet that it won't happen in 2038 either.
    well, they did spend millions on making sure it didn't. Thats the problem with "scare stories" when they don't happen, people overlook the obvious facts that other people did the work and found solutions to make sure said "scare story" didn't happen.

    Leave a comment:


  • Termy
    replied
    Originally posted by eydee View Post
    They predicted the end of the world because of the year 2k issue. It didn't happen. It's a safe bet that it won't happen in 2038 either.
    But it's still better to adress it now than to have a collective panic as it was in 99

    Leave a comment:


  • eydee
    replied
    They predicted the end of the world because of the year 2k issue. It didn't happen. It's a safe bet that it won't happen in 2038 either.

    Leave a comment:


  • GunpowaderGuy
    replied
    makam systems dealing with future dates will be affected earlier

    Leave a comment:

Working...
X