24 ms·

It wasn't intended to be sarcastic. I suspect there will be a lot of businesses (especially finance) interested in verifying that the "ancient" Linux system th

It wasn't intended to be sarcastic. I suspect there will be a lot of businesses (especially finance) interested in verifying that the "ancient" Linux system they setup to replace their mainframe 25 years "ago" is safe. I lived through the Year 2000, and watched the same thing happen there. With suitable groundwork, there will be a willing and wealthy market looking for people to assuage their fears - a service I see myself as happy to provide. Much as it was in the "Millennium bug" area, a lot of the effort in getting the business is PR spadework, but I've got 15-20 years of prep time to position myself suitably. I also hope to provide a slightly more useful service than many Millennium consultancies did at the time.

tyingq 10y ago
Databases too. MySQL has a 2038 bug in their UNIX_TIMESTAMP function. select unix_timestamp('2038-01-19') returns 2147472000 select unix_timestamp('2038-01-20') returns 0
- pbhjpbhj 10y ago
  Surely these sorts of errors in major systems are already being/have already been addressed - for healthcare for example a search for which members of a GP's practice are going to be pensioners in 2040 is going to error badly? Strikes me that the time to address them was shortly after the millennium bug.
  - tyingq 10y ago
    That's not been my experience. A lot of companies don't address needs that are farther in the future, because there are nearer term needs and a fixed budget. Also, legacy systems that haven't been patched or updated in decades aren't that uncommon. And, even if they happen to be safe, they do tend to pay well just for an audit to confirm that.
  - ams6110 10y ago
    Financial systems that deal with bonds already have to deal with maturity dates on 30-year bonds that are past 2038.
    - PeterisP 10y ago
      Those type of systems use various date representations instead of datetime/timestamp fields, they should be mostly immune. Well, until 2038 arrives and some of these dates start being compared with the current datetime.
  - __jal 10y ago
    If you were around for the millennium bug, then surely you remember how many people waited until about October, '99 to start looking for problems. If you think those people went looking for another problem 38 years away to fix... If this class of business is not seeing a problem this minute, it isn't a bug. And it won't be a serious-enough bug to spend money on until whatever workarounds they can think of start having negative effects on income. Sources: experience with Y2K remediation, experience with small business consulting & software development, experience with humans.
    - tormeh 10y ago
      >experience with humans So true. That said, thinking 38 years into the future is usually not sensible for most businesses, because it's very possible that they're bankrupt before then. Thinking 21 years into the future also offers poor ROI for the same reason.
      - pbhjpbhj 10y ago
        I was thinking large companies, banks etc.. I'm not in IT/programming but remember (despite being young) that 2 other calendar related 'bugs' were mentioned at the time. IIRC we've had one and the epoch bug is the second. Strikes me that big businesses would have thought "will we need to do this again in a few years" and acted appropriately and that there should be a trickle down effect as large corps demand future proofing in IT products. Yes negligence, ignorance, lack of foresight, corner cutting, and other human traits feed in to that.
        tyingq 10y ago
        Generally, the bigger and older the company is, the more unmaintained cruft you have. Banks would be one of the worst I imagine.
  - gcb0 10y ago
    > Surely these sorts of errors in major systems are already being/have already been addressed [...] search for which members of a GP's practice are going to be pensioners in 2040 If you know anything about programmers, you know they found that error at some point during development, thought about how other people dealt with that, remembered that windows used to treat >30 as 1900s and <30 as 2000s and did the same. So probably the people in this thread planning their retirement solving this will have to figure out which random unix timestamp number is treated as pre 2038 and which one is after. And then they will have to undo all the last-minute spaghetti code tying it up on the original program.
drzaiusapelord 10y ago
>verifying that the "ancient" Linux system they setup to replace their mainframe 25 years "ago" is safe. The problem with mainframes is that they can't be trivially upgraded or migrated to 64-bit like modern OS's on x86 hardware can be. Vendor lock-in, retirement of OS, bare to the metal coding, etc caused this. If these mainframes were running a modern OS, it would have been trivial to upgrade them to a 64-bit version and make whatever small changes are needed to date storing in the old 32-bit apps. You won't need a wizened COBOL guy for this. A first year CS student would be able to look at C or C++ code and figure this out. Modern languages are far more verbose and OO programming makes this stuff far easier to work with. Comparing mainframes to unix systems really doesn't make sense. Its two entirely different designs. Not to mention, the idea of running a 32-bit OS today is odd, let alone 20+ years from now, especially with everything being cloudified. You'd be hard pressed to even find a 32-bit linux system in 20+ years, let alone be asked to work on one. That's like being asked to setup 1000 Windows 98 workstations today.
- Spooky23 10y ago
  Be careful about your definition of absurd. Somewhere, right now, some poor bastard is building an NT 3.51 workstation for some stupid reason. I'll bet you $0.05 that some future poor bastard will be building NT4 or 2000 devices in 2038. :)
  - ygra 10y ago
    Well, at least NT has no problem with 2038 ;-)
  - jackvalentine 10y ago
    I built an NT3.5 VM in 2012 to run some ancient book binding publishing junk that relied on an ancient version of access... might still be in production, no idea.
- deleted 10y ago
  [deleted]
- deleted 10y ago
  [deleted]
M_Grey 10y ago
Aren't you worried that by then someone will develop and train a DNN to do that?
hinkley 10y ago
Woah, you were alive in the year 2000? Tell us what that was like, grandpa!
- astrodust 10y ago
  Our phones sucked and we had to watch television with commercials you couldn't skip.
  - lokedhs 10y ago
    I don't know what phone you had in 2000, but I had a Nokia 2100 in 1996 and it was the best phone ever made. Now that I think about it, I probably had an Ericsson T28 in 2000 and it did kinda suck.

tyingq 10y ago

Databases too. MySQL has a 2038 bug in their UNIX_TIMESTAMP function. select unix_timestamp('2038-01-19') returns 2147472000 select unix_timestamp('2038-01-20') returns 0

pbhjpbhj 10y ago
Surely these sorts of errors in major systems are already being/have already been addressed - for healthcare for example a search for which members of a GP's practice are going to be pensioners in 2040 is going to error badly? Strikes me that the time to address them was shortly after the millennium bug.
- tyingq 10y ago
  That's not been my experience. A lot of companies don't address needs that are farther in the future, because there are nearer term needs and a fixed budget. Also, legacy systems that haven't been patched or updated in decades aren't that uncommon. And, even if they happen to be safe, they do tend to pay well just for an audit to confirm that.
- ams6110 10y ago
  Financial systems that deal with bonds already have to deal with maturity dates on 30-year bonds that are past 2038.
  - PeterisP 10y ago
    Those type of systems use various date representations instead of datetime/timestamp fields, they should be mostly immune. Well, until 2038 arrives and some of these dates start being compared with the current datetime.
- __jal 10y ago
  If you were around for the millennium bug, then surely you remember how many people waited until about October, '99 to start looking for problems. If you think those people went looking for another problem 38 years away to fix... If this class of business is not seeing a problem this minute, it isn't a bug. And it won't be a serious-enough bug to spend money on until whatever workarounds they can think of start having negative effects on income. Sources: experience with Y2K remediation, experience with small business consulting & software development, experience with humans.
  - tormeh 10y ago
    >experience with humans So true. That said, thinking 38 years into the future is usually not sensible for most businesses, because it's very possible that they're bankrupt before then. Thinking 21 years into the future also offers poor ROI for the same reason.
    - pbhjpbhj 10y ago
      I was thinking large companies, banks etc.. I'm not in IT/programming but remember (despite being young) that 2 other calendar related 'bugs' were mentioned at the time. IIRC we've had one and the epoch bug is the second. Strikes me that big businesses would have thought "will we need to do this again in a few years" and acted appropriately and that there should be a trickle down effect as large corps demand future proofing in IT products. Yes negligence, ignorance, lack of foresight, corner cutting, and other human traits feed in to that.
      - tyingq 10y ago
        Generally, the bigger and older the company is, the more unmaintained cruft you have. Banks would be one of the worst I imagine.
- gcb0 10y ago
  > Surely these sorts of errors in major systems are already being/have already been addressed [...] search for which members of a GP's practice are going to be pensioners in 2040 If you know anything about programmers, you know they found that error at some point during development, thought about how other people dealt with that, remembered that windows used to treat >30 as 1900s and <30 as 2000s and did the same. So probably the people in this thread planning their retirement solving this will have to figure out which random unix timestamp number is treated as pre 2038 and which one is after. And then they will have to undo all the last-minute spaghetti code tying it up on the original program.

drzaiusapelord 10y ago

>verifying that the "ancient" Linux system they setup to replace their mainframe 25 years "ago" is safe. The problem with mainframes is that they can't be trivially upgraded or migrated to 64-bit like modern OS's on x86 hardware can be. Vendor lock-in, retirement of OS, bare to the metal coding, etc caused this. If these mainframes were running a modern OS, it would have been trivial to upgrade them to a 64-bit version and make whatever small changes are needed to date storing in the old 32-bit apps. You won't need a wizened COBOL guy for this. A first year CS student would be able to look at C or C++ code and figure this out. Modern languages are far more verbose and OO programming makes this stuff far easier to work with. Comparing mainframes to unix systems really doesn't make sense. Its two entirely different designs. Not to mention, the idea of running a 32-bit OS today is odd, let alone 20+ years from now, especially with everything being cloudified. You'd be hard pressed to even find a 32-bit linux system in 20+ years, let alone be asked to work on one. That's like being asked to setup 1000 Windows 98 workstations today.

Spooky23 10y ago
Be careful about your definition of absurd. Somewhere, right now, some poor bastard is building an NT 3.51 workstation for some stupid reason. I'll bet you $0.05 that some future poor bastard will be building NT4 or 2000 devices in 2038. :)
- ygra 10y ago
  Well, at least NT has no problem with 2038 ;-)
- jackvalentine 10y ago
  I built an NT3.5 VM in 2012 to run some ancient book binding publishing junk that relied on an ancient version of access... might still be in production, no idea.
deleted 10y ago
[deleted]
deleted 10y ago
[deleted]

M_Grey 10y ago

Aren't you worried that by then someone will develop and train a DNN to do that?

hinkley 10y ago

Woah, you were alive in the year 2000? Tell us what that was like, grandpa!

astrodust 10y ago
Our phones sucked and we had to watch television with commercials you couldn't skip.
- lokedhs 10y ago
  I don't know what phone you had in 2000, but I had a Nokia 2100 in 1996 and it was the best phone ever made. Now that I think about it, I probably had an Ericsson T28 in 2000 and it did kinda suck.