15 ms·
This is (serious) a part of my retirement planning. I'll be mid-50s when this hits, and have enough low level system knowledge to be dangerous. In about 15 year
by archgrove 10y ago
This is (serious) a part of my retirement planning. I'll be mid-50s when this hits, and have enough low level system knowledge to be dangerous. In about 15 years, I'll start spinning up my epochalypse consultancy, and I'm expecting a reasonable return on investment in verifying systems as 2038 compliant.
- Aloha 10y agoThere is a certain amount of snark embedded in this post, but its not a bad idea at all - I'll be in much the same boat at that time - perhaps I can borrow the same idea...
- archgrove 10y agoIt 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 agoDatabases 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 agoSurely 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 agoThat'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 agoFinancial systems that deal with bonds already have to deal with maturity dates on 30-year bonds that are past 2038.
- PeterisP 10y agoThose 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 agoIf 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.
- 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 agoBe 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 agoWell, at least NT has no problem with 2038 ;-)
- jackvalentine 10y agoI 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 agoAren't you worried that by then someone will develop and train a DNN to do that?
- hinkley 10y agoWoah, you were alive in the year 2000? Tell us what that was like, grandpa!
- astrodust 10y agoOur phones sucked and we had to watch television with commercials you couldn't skip.
- lokedhs 10y agoI 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.
- chiph 10y agoThere were fortunes made in 1999 doing similar work.
- axlee 10y agoIt was a good time to be a COBOL developer.
- bshimmin 10y agoThere's always someone on HackerNews who has done something pertinent to almost any discussion (it's one of the best things about being here, in fact) - are there any COBOL guys or gals who made a fortune fixing Y2K bugs who'd like to share their story?
- joshuaduffy 10y agoI wasn't around then, but I've worked with many programmers who said: £1000 per day (at least) as a consultant (solo or sub)
- janwillemb 10y agoI never quite understood why the transition from 1999-2000 should be a big deal for a computer system, until I learned about how COBOL works: it stores numbers as its string-representation unless told otherwise, and trying to store 100 in a field of two bytes will happily be stored as "00". Of course we had other bugs, with the same cause, well after the y2k-period.
- gbrown_ 10y agoI'm really curious about the kind of software things like pacemakers run and potential implications from 32-bit time expiring.
- scandox 10y agoResearch material for you: http://www.softwarefreedom.org/resources/2010/transparent-medical-devices.html http://www.softwarefreedom.org/resources/2010/transparent-me...
- abfan1127 10y agopacemakers I worked on ran on 8 bit MCUs.
- OnACoffeeBreak 10y agoI would guess pacemakers don't run Linux. I would be surprised if they run an OS at all. I work on devices that have to survive 20 years on one non-rechargeable and non-serviceable battery, and there's at most a simple scheduler in place to control tasks. We use 32 bits for epoch time, but our epoch starts Jan 1, 2000, so we have 30 years on Linux before this becomes a problem.
- pinaceae 10y agoyou might be underestimating modern med devices which even have wireless access (beats a port or invasive surgery to read a log). example for the issues in this area: https://spqr.eecs.umich.edu/papers/49SS2-3_burleson.pdf https://spqr.eecs.umich.edu/papers/49SS2-3_burleson.pdf
- OnACoffeeBreak 10y agoI see "wireless", but not "WiFi" or "802.11*" in the PDF. For what it's worth, devices I work on have a few wireless interfaces while guaranteeing 20-year life time: one interface is long-range (on the order of 10km), two are short range (on the order of a few mm). There is no way we can get to 20-year life time with doing WiFi (maintaining current battery size/capacity) for long'ish range and maybe not even BT for shorter range.
- jbattle 10y agoAnother idea that'd be way cheaper - start writing books on how to survive the epochalypse. You can crib a lot of material out of the books written in 99.
- dramamuch88 10y agoDon't be too obvious to early; you'll give your competitors time to catch up. Need to wait until late 2020s or early 2030s. Publish the epochalypse manifesto. Start slow building a low-level urgency in powerful people. Then around 2034, blow it wide open: "Epochalypse: The hidden danger they don't want you to know about." That's how you get them to rain money on you.
- alexc05 10y agoI hope you've trademarked the term "epochalypse" because it is really catchy! I love it.
- TheGRS 10y agoMaybe he can title himself an epochalist.
- frandroid 10y agoThe epochstle.
- ebbv 10y agoHe didn't invent it. It's been around about as long as people have seen this problem coming.
- nsxwolf 10y agoI will be just 5 years away from retirement, so I will use this as an opportunity to shore up my 401k. Of course, the singularity will be here by then and fix it for us just before turning us all into paper clips, yada yada. I will advertise with the slogan "Epochalypse... NOW."
- rzzzt 10y ago2038: Odyssey 2.5
- bnj 10y agoMake sure your 401k is the first thing you certify as 2038 compliant
- gcb0 10y ago> I will advertise with the slogan "Epochalypse... NOW." or you can do the same as the y2k people did: Y2K... TOMORROW!
- taneq 10y ago> turning us all into paper clips A paperclipocalypse?
- scandox 10y agoStart right now. You'll have the SEO and the thought-leadership circuit all stitched up well in advance.
- Lockyy 10y agoStart too early and you'll sound like an end of the world preacher. You need to time it so that you look cutting edge rather than paranoid.
- james_pm 10y agoSome good domain options available. .consulting, .guru, .pro, .expert. https://www.hover.com/domains/results?utf8=&q=epochalypse https://www.hover.com/domains/results?utf8=&q=epochalypse
- maxmcd 10y agoepochalypse.now (not avilable just yet)
- strangecasts 10y agoepochalypse.no is an option if you are/know a Norwegian
- Sean1708 10y agoCan you not get a .no regardless of where you live?
- web007 10y agoThis is part of my plan as well, thus https://2038consulting.com/ https://2038consulting.com/ registered 6 years ago.
- gcb0 10y agoGenius. Are you accepting A rounds?
- drzaiusapelord 10y agoNo one is deploying 32-bit linux now, outside of tiny edge cases and mobile. Mobile devices that go in the trash every 2 years. What do you reasonably expect to be around in 2038 in 32-bit form? Once 64-bit processors became mainstream, the 2038 problem pretty much solved itself. There's only disincentives to building a 32-bit system today let alone in 20+ years. Unlike with Y2k where there was nothing but incentives to keep using Windows and DOS systems where the 2000 cut-over was problematic. The non-compliant stuff was being sold months before Jan 1, 2000. The 32-bit linux systems have been old hat for years now, let alone 20+ years from now. Not to mention that those old COBOL programs were nightmares of undocumented messes and spaghetti code no one fully understood, even the guys maintaining them at the time. Modern C or C++ or Java or .NET apps certainly can be ugly, but even a second year CS student can find the date variables and make the appropriate changes. They won't be calling in $500/hr guys for this. Modern systems are simply just easier to work with than proprietary mainframes running assembly or COBOL applications that have built up decades of technical debt.
- tyingq 10y agoIt won't be the same magnitude of issues. However, I'm sure there will be plenty of apps on said 64 bit Linux that have issues. I commented about a mysql problem here that exists on 64 bit MySQL, on 64 bit Linux. It's not much of a stretch that some internal apps at a company would have similar issues. Edit: Ntp has something of a protocol issue to be addressed as well.
- drzaiusapelord 10y agoYeah but that's a protocol issue. Single graybeard devs aren't going to be paid to fix that. The people who run ntp are going to push out a new protocol way before 2038. Even if there are issues, more than likely they'll be able to handle it internally. OO programming isn't going anywhere and modern languages and concepts are easier to work with than piles of undocumented COBOL from Y2K. They won't be calling you with help to change date fields. That's trivial stuff.
- 10y ago
- thearn4 10y agoSame, I'll be 55. My son will be 23. Either our generation fixes it, or his generation will have to fix it in their first jobs out of college (sorry kids!)
- astrodust 10y agoIt's an issue now, and it will be even more urgent as the deadline approaches. Once we hit the ten year out mark then you're going to see things like expiry dates for services roll over the magic number. The shit will hit the fan by degrees.
- DannyB2 10y agoMy retirement planning is to work on the Y10K problem. When the year 9997 comes along, everyone is going to start worrying about the rollover to five digit years. In about the year 9995 I will start seriously brushing up on my COBOL.
- narrator 10y agoYes, I know some of us will never retire. 8000 years in the future career planning is an interesting thing to think of though. 8000 years ago the only thing that was going on was some neolithic agriculture. Domestication of the Jungle Fowl (modern day chicken) in India and the beginning of irrigated agriculture in Sumeria were probably the biggest news items of that millennium. I guess someone from 8000 years ago could have said he'd be raising chickens or doing irrigated agriculture in 8000 years and wouldn't have been wrong had he lived that long. Makes me think of F.H King's book "Farmers of Forty Centuries" about how Chinese agriculture has been farming the same fields without artificial fertilizer for 4000 years.
- jessaustin 10y agoYes, technology is subject to the Lindy Effect. [0] It's a good reason to learn both Unix and farming. [0] https://en.wikipedia.org/wiki/Lindy_effect https://en.wikipedia.org/wiki/Lindy_effect
- contingencies 10y agoThere was almost certainly some forms of relatively advanced seafaring 8000 years ago possibly including skin boats, sails and paddles, ropes, sealants and astronomy. Also, fairly sophisticated metallurgy was widespread with at least silver/iron/gold, possibly bronze. Writing was known to some cultures. Horses, camels and water buffalo were likely all domesticated. Use of drying/smoking for preservation and curing of meat. Yogurt may have been known in some areas. Advanced pottery. Probably nontrivial herbalist / medicinal / architectural / construction knowledge. Plus of course trapping, fishing, textiles, stonework, etc.
- 10y ago
- nickpsecurity 10y agoThat is a great term. Start investing time in static analysis tools in FOSS that find it for you or your customers. Then extend refactoring tools ("source-to-source translators") to automate the job. Apply for YC for growth. Get acquired by IBM who saw all kinds of adaptations for the tool in their mainframe offerings.
- fritzw 10y agoI hate to be to buzzkill but more than the computer systems is the food supply... climate change is going to reek havoc on our "retirement" we will likely die young starving and thirsty
- xelxebar 10y agoJust a heads up, reek v. To give off a foul odor wreak v. To inflict or execute
- andrepd 10y agohttps://xkcd.com/607/ https://xkcd.com/607/
- emcrazyone 10y agonot a bad plan. I did something similar in 1998-1999 as a Y2K consultant. Companies at the time wanted to be certified Y2K compliant - some good years. I certified a lot of companies using medical equipment from Perkin Elmer and Khronos time clocks.