The End Of Linux Is Only 13 Years Away

[@BrodieRobertson]

Let me clarify a few things that were mentioned in the video but a few people didn't feel like watching before commenting. 1. Yes you're running a 64 bit kernel, and yes the kernel side was patched years ago, there is literally software that you can and test yourself right now that is built with 32 bit assumptions. 2. Y2K was a very little known problem amongst the general populace before the 90's, however the one to first identify the problem was Bob Bemer back in 1958 from his work on genealogical software whilst at IBM, he spent the next 20 years trying to get the word out about this issue.

[@cwill6491]

This doesn't bode well for climate change tbh, need to wait to the last minute when shit is hitting the fan

[@miriamkapeller6754]

@@cwill6491 It's worse with climate change, because the change is gradual, so people can always say "I see no difference between the weather now and 10 years ago". People will only start to get nervous when major oil wells are drying up, but not because of the climate.

[@interando420]

IBM has a funny history with that kind of software

[@fizipcfx]

thats your fault tho, you titled your video "the end of linux is only 13 year away". which is a lie just to make people watch your video. i know everyone does it and thats ok. but these comments shouldnt surprise you

[@rautamiekka]

Let's put Y2K this way: was real and happened, just not on the scale expected. Shit did happen.

[@finkelmana]

The Y2K bug was the largest worldwide computer problem ever. While I dont remember personally doing any Y2K related work. I remember the insane amount of work that everyone was doing at the time. Programmers pouring over obsolete code, pc techs updating software and BIOSs, endless testing, etc etc. To say nothing happened is both insulting and rewarding. Insulting as the amount of time and effort was tremendous. Rewarding, as no planes fell out of the sky.

[@danielbaker1248]

Good work getting the job done!(:

[@rtcmedic]

I was one of the sysadmins that put in a ton of leg work getting ready for Y2k. I touched hundreds of computers across 6 locations and 3 states in person by traveling to each location. I updated bios, made sure Windows and application patches were applied. I worked with software vendors to make sure our dispatch software was ready. I worked for a multi state private ambulance company and handled all IT issues solo and reported to the HR director. I was watching Armageddon with my wife on New Years. I called the dispatch center at 12:05 AM with no issues reported by any staff. Twas a good day.

[@AK-vx4dy]

I rember, i updated Novell Netware 3.X servers. This problem forced or rushed move to replace billions worth of software/hardware to newer versions/models in years just before 2000. Problem was taken seriously, big companies have designagted C-suite man to verify and eliminate potential problems, i meet one from BOC Gases. We may not know if something happend, most of problematic dates were stored in wast databases, it not necessarily would blow up just on 2000, could later give some wrong estimates (financial) but nobody wanted to admit it. I could bet that many developers hours were spend to implement "49-cut off" at least in legacy software (changing field type/size in wast DB was impractical in many cases.

[@VioFax]

And all the equipment is in the trash now. None of it matters tech just goes to the landfill.

[@farsyte]

We had some explicit prior warning: any system that dealt with dates in the future, hit its Y2K issues earlier; for example, if you were computing financial plans out five years, you had to have your Y2K ducks in order in 1995 (possibly with a period at the start where the dates in 2000 got printed as 1900). So some work was already done, and methods were known. The hardest part of Y2K, from my perspective, was convincing management that time (and thus money) was well spent assuring things kept working. The *SILLIEST* part was the stupid "Y2K Compliant" stickers. OK, drop them on various things that had to be fixed, but when management mandates that all our Monitors and Chairs and Cabinets get certified ... the silly season was absolutely upon us. The neat thing is, everyone did their jobs so well, we did not have huge problems -- and if the cost were silly over-the-top propaganda bits about all our electronics failing and all the airplanes falling out of the sky, so be it. I spent most of December 1999 and January 2000 on vacation, on the other side of the world from anyone who knew I touched computers for a living. New years eve was in a hotel on an island in the south pacific. If the world was going to end, it could do so without further help from me ;)

[@iAmTaki]

Don't worry, december of 2037 we will just work overtime and fix it ;)

[@DeronJ]

That's pretty much how the company I worked for handled Y2K.

[@benkato_]

and we will get compensated for it by receiving a large amount of Kronii coins instead of cash🌚

[@VioFax]

@@benkato_ They don't "need lowly techs like us. AI will fix everything"

[@zoeherriot]

I worked for a solid 6 months of overtime to make sure our business didn’t shit the bed during Y2K.

[@idkturtle]

damn, a kronii profile picture spot in the wild

[@R.Daneel]

What you say, I can confirm: Y2K didn't happen because we worked so hard on fixing it. It wouldn't have been a disaster but definitely a minor nightmare. I fixed dozens of date issue personally, and saw hundreds of other fixed. The panic gave us budget.

[@nxtvim2521]

yep, but nowadays, Y2K38 is that its not catchy, not mainstream, and will affect way more people and computers like the solar flares in the 1800s

[@BrodieRobertson]

My understanding is it did end up knocking out a few small stores and some lazy business software temporarily but it certainly wasn't the end of the world

[@ギコ]

​@@nxtvim2521Y2K38 * will * be mainstream if it gets close enough. Linux is very important commercially.

[@zoeherriot]

Yup - I worked for months fixing date related issue. It was a pain in the butt.

[@pallas_wept]

It absolutely would have been a disaster, we would have all died. Source: I worked on systems that provided food, and kept our financial systems working. I know others who saved our water supply, and military installations. We definitely all would have died, several times over, badly. Definitely disaster++

[@VictorSouza02]

2038 is the year of linux

[@l4ppland]

desktop

[@cedricksusername]

All will praise Supreme Planetary Emperor Torvald

[@FagnerLuan]

Too late 😭😭😭😭😭

[@MrAlanCristhian]

the year of systemd

[@akeem2983]

2038 is the end of linux desktop

[@nathanaelculver5308]

As a COBOL programmer in the ‘90s working at the Credit Union National Association I can assure you it was two years of hell on earth. I personally reviewed and updated nearly a half million lines of 30-year-old spaghetti code in the three-year run-up to Y2K.

[@myopiniongoodyouropinionbad]

Talk about standing on the shoulders of Giants. I was only a child at the time, but I do remember the fear mongering. I do also remember being a little kid and playing with our family’s PC. I was pretty much the only one who used it because my parents weren’t really tech literate. I remember changing the date on the computer from 2003 to 2086 thinking it just looked cool and futuristic. But I remember that actually caused a lot of problems with a few things. 😂😂😂

[@nathanaelculver5308]

Let me add a bit more color: COBOL (Common Business-Oriented Language) was developed in the 1960s with a focus on application to business needs. This was in the early days of programmable computers when C was still called B. Over the years, what started out as small, easily maintained COBOL programs slowly metastasized into behemoths of nearly incomprehensible spaghetti. At first, it was easier/faster/cheaper to update current code with new functions or fixes, and over the years many hands massaged and transmogrified code bases that no one fully understood any more. Every programmer has his own style; most programmers hate documenting their code (and there were not a few who delighted in demonstrating their skills by writing deliberately opaque code); and in the ‘60s there were no programming standards at all. The result was that by the late 1980s there was more utterly inscrutable COBOL code out in the wild than perhaps every other programming language combined. By the time it began dawning on anyone that the whole mess should be rewritten from scratch in a more modern language (meaning C) it was far, far too late. There wasn’t a COBOL programmer left alive who make sense of millions of lines of (often deliberately) obfuscatory code, let alone tell you why the whole thing hadn’t fallen down decades ago. That was the environment I had to work with in the late ‘90s.

[@Finkelfunk]

Jokes on you Brody, my code already doesn't compile in the year 2025.

[@terrydaktyllus1320]

Maybe your code doesn't compile because of spelling errors like "jokes" when it should have been "joke's"? I never understand how so many people claiming to be coders make such silly grammatical errors in comments they write.

[@Kirschi__]

@@terrydaktyllus1320 "claiming to be coders" seems unnecessarily attacking. Also: Regular human language isn't code. Also: When coding there's something called syntax highlighting, also the code won't run or compile and also exactly tell you why. Dunno why you woke up today and chose to punch down, but you won't make any friends being like that.

[@terrydaktyllus1320]

@@Kirschi__ " "claiming to be coders" seems unnecessarily attacking." "Seems" indicates the application of your subjectivity and emotions to my statement. I have no control over either of those, therefore the point is unnecessary. I am not here to check you're fine with anything I post before I post it. "Also: Regular human language isn't code." Yes, but you still need to be able to spell words correctly and write logical statements correctly. I would expect a coder to be able to create that logical connection themselves, given I myself do a bit of coding myself also. "Also: When coding there's something called syntax highlighting, also the code won't run or compile and also exactly tell you why." Entirely unnecessary to make as a statement as, as stated above, I do a bit of coding myself. "Dunno why you woke up today and chose to punch down, but you won't make any friends being like that." This isn't a discussion about me and "me" is a topic you know nothing about anyway. In subsequent replies, I would like you to try harder to keep up and stay on topic. We were talking about language and coding so, in your own time...

[@stefanalecu9532]

​​@@terrydaktyllus1320 no, *you* are the only one bringing language and coding into this discussion. OP very clearly wrote "jokes" in the message, and it isn't edited as that would show up. You have been really condescending towards OP for no apparent reason with extremely flawed logic to back it up. Riddle me Terry, why is it that language... and coding are connected? Why is it relevant to coding how you're spelling words? Are we writing Shakespeare when debugging embedded code? Sure, it is important in real life to spell correctly, at least in official documents (as nobody besides sad people like you and English teachers care on the Internet), but I could be writing using Spanish identifiers in my code (so clearly *not* writing English) and the compiler would still happily accept my code, the IDE would still accept it (and if I made a typo, it would also show it), everything still works. Computers don't give a shit about human language. P.S. Even if OP did make grammatical mistakes or more likely typos, unless it is something that completely alters the meaning or makes the phrase unintelligible, you can still understand what's being said. Unlike normal people, you decided to wake up and first understand what's being said and THEN point out in a smug fashion "🤓👆 ackchually you're*". Asking the other person "hey, what did you mean by ?", and they can explain it again if they worded it in a weird way because they're not a native speaker. Empathy for you is a wild concept. GTFO back to Reddit. Or Phoronix, for all I care.

[@terrydaktyllus1320]

@ ""You have been really condescending towards OP for no apparent reason with extremely flawed logic to back it up." Thank you for saving me some time here, and allowing me to waste some of your time. I read up to this point and stopped reading your comment. This isn't a discussion about me, it's a topic you know nothing about anyway. Run along. Discussion closed.

[@MechMK1]

"If the computers work, what are we paying IT for? If the computers don't work, what are we paying IT for?"

[@alexandergutfeldt1144]

All pay should be redirected towards the managers that make the difficult decisions and take the risks! ( sarcasm detected, argument halted)

[@sin_x1155]

A few months back, I was trying to install some fonts on my newly setup Fedora system. However, I could not get `fc-cache` to work - it would simply crash without yielding a useful error. After some digging, I noticed that `fc-cache-64` was still working, and only the 32bit build was affected (I don't know why they ship both versions). I suspected that this was somehow related to some integer overflow - I took another look at the fonts I had added; lo and behold: Their file timestamps had all been set to some date in 2040, due to some system time mishap during setup, hence causing an overflow in fc-cache ... talk about bleeding edge, experiencing bugs 15 years before official release 😎

[@GrzesiekJedenastka]

I got basically this but with the original Half-Life! lol

[@XH13]

Late Generation X software engineers started they career with y2k, will end it with y2k38 and still have the ipv6 transition mess

[@edstar83]

Gen X represent! Gen X doesn't get enough credit. Gen X created social media, firstly Sixdegrees in the late 90s, then friendster, MySpace, KZbin in the early 2000's. Gen X created Bittorrent, Napster, Limewire. IRC - internet relay chat. All the cool bands from the 90s and 2000's were Gen X.

[@stewie3128]

Yup, we'll still be transitioning to ipv6 in 2038

[@el_fucko]

@@edstar83 You want _credit_ for creating social media? What planet are you from?

[@lerager]

Well, fxck me😂

[@siddharths4676]

I need to wait till I'm into my 30s for ipv6 adoption ? 😖 Suffering from IPV4 & double NAT at ISP level , not able to host gaming servers to friends 😭

[@frankhuurman3955]

marked as "won't fix"

[@AntranigVartanian]

Lennart Poettering is that you?

[@7rich79]

What is often forgotten is that the problem will actually happen much sooner than 2038. Why? Many industries, but particularly finance, will do forecasting. That could be a bank calculating profit on a 15 year mortgage, an insurance broker calculating premiums for a life insurance and life expectancy etc. This could also be an issue in scientific fields, e.g climate change modelling, trajectories for satellites and other stellar objects etc

[@thatgotofinal]

Not really as big issue for banks etc, this usually does not depend on any old 32 bit machines, and half of it is written in Java or just any other tech with own calendars and clocks already operating on 64bit values. More surprising that during Y2k there wasn't a bigger push to ensure stuff wont break just 40 years later anyways.

[@nobodyimportant7804]

@@thatgotofinal Not too surprising as businesses won't spend money on a problem that isn't an immediate issue. The lack of foresight causes all manner of problems every year but the mindset of MBAs is broken.

[@randomgeocacher]

DailyWTF CodeSOD reported on a 2038 bug back in 2008. A 30 year sleep() in a script failed immediately causing a restart loop. So it has already been causing problems for decades. Rare oddities sure, but it is here and real.

[@CptJistuce]

​@@thatgotofinalMany Y2K fixes were implemented with "windowing", which is to say they special-cased it so 00 through 20 were treated as 2000-2020 instead of 1900-1920. It was an easy fix, and none of this code was still going to be in use in twenty years, and even if it was we've got twenty years to develop a proper fix. ... Yeah, there was a lot of scrambling to fix code and software that randomly broke in 2021.

[@pallas_wept]

​@@thatgotofinalYour intuition is sensible but experience will show you that the opposite is true. There's strong incentive to not risk billions per hour of downtime to replace old gear when it's making money and nothing wrong with it. You'd be shocked by the sheer number of 486 machines in cupboards (usually covered in dust with a sign that says DO NOT TOUCH) and literal mainframes from the 80s that underpin our banking infrastructure. OP is right. Personally I've seen y2k38 bug twice in the wild so far. I share them with my ex-y2k-bug buddies, it's interesting to watch the reboot of the show when we aren't starring in it.

[@VauxhaIIOpel]

I like how most of these git issues are filed by the same guy He's _REALLY_ worried about Y2K38

[@itskdog]

Probably the OP of the Reddit post, who is from OpenSUSE, who have an interest in making sure the packages they ship won't be broken.

[@Lucas-yh5zz]

Clearly a time traveler

[@BrodieRobertson]

He's made it a personal mission to track down many of these problems

[@r3ddr4gon80]

To be fair, a bug in git would be really annoying when one has to hotfix their own software in 2038. ;)

[@lennysmileyface]

I am from the year 2167 and we just recovered from the Y2K38 apocalypse. He warned us.

[@yogimew]

Be sure to stream at 2038-01-19 03:14 UTC.

[@MyAmazingUsername]

Ext4 uses a different timestamp size. Not 32 bit. Not 64 bit. They support until the year 2446. As someone who is immortal, this feels like a problem and I worry about the Y2K446 problem. 😢

[@dtkedtyjrtyj]

By 2446, btrfs will almost be ready for use anyway.

[@futuza]

We should be on Ext5 by then

[@potato9832]

It's also far easier for the OS to migrate the filesystem because user land software is unaffected.

[@themacintoshnerd]

2038 the year either steam switches to a 64-bit client or Valve finds a fix and keeps shipping Steam as a 32-bit client.

[@them2545]

It will become the very first 33 bit software. Kick the can down the road for another 70 years

[@justinliu7788]

Or just store it as 64 bits anyways (software emulation)

[@smorrow]

You can use 64-bit numbers in 32-bit programs.

[@edstar83]

We're gonna get GTA VI before Half-Life 3.

[@themacintoshnerd]

@@smorrow you should do stand up. The audience might throw things over your head but just keep at it.

[@brmolnar]

In High School, I worked on some Y2K updates for a company you've heard of. It really was all hands on deck and a 'Oh, you like computers and are good at math, here, go fix this COBOL/FORTRAN in these 57 files'. At the time, we had mainframes that were still running code that, while maintained, was originally created in the 60's and 70's. Some of the code assumed that it wouldn't be running past 9/9/99 and so that was the last day it would work because 'we thought it was a neat date'. Some code could not be fixed. I'd image there are a not insignificant number of places where the logic is something like 'if YY < 75, YY = YY+100' (if the 2 digit year value is under 75, add 100. 25 becomes 125 and the math works). It pushes the can down the road to the 2060's/70's, with the hopes that the code written in the 1970's, that I fixed in the 1990's will not still be running in the 2070's. Although the idea of having to fix this at 90 years old is amusing. All of the fixes assume a 4-digit year and will not run past 9999. We have some time on this one.

[@farsyte]

First computer I worked with, 7/7/77 was what you input for "unknown date", switched to "8/8/88" at one point (guess when). Good times.

[@justincase9471]

There is nothing more permanent than a temporary solution. 😂

[@mfaizsyahmi]

Goodbye Y2K problem, Hello Y10K problem! P.S. the implication that people would be maintaining 8000 year old equipment and code for real world applications is actually kinda insane ngl. Literally ancient magic.

[@nathanielbass771]

wonder if someone could make an AI to detect if code is using the ooD stuff and implement a patch according to what code is being used? Could save a lot of time and headaches in the long run to maintain it.

[@GummieI]

@@mfaizsyahmi The implications, that humans still exist in year 10k is insane tbh

[@Zoloft_100_mg]

WE GONNA PARTY LIKE IT'S DECEMBER 13 1901 AGAIN!!

[@charautreal]

bro's gonna play irl red dead redemption

[@tonycosta3302]

Y2K was the genesis moment for the IT industry in India. Billions of dollars were spent there to hire developers to remediate millions of lines of code. It was a gold rush that established their IT industry as a strategic vendor for tech companies.

[@m2x07]

systemd is in the list of affected software builds so I'll just blame systemd then

[@PremiumGerman]

😂

[@notCAMD]

Yay, making not using systemd a major part of your identity will finally pay off! (Probably)

[@SIackware]

systemd-analyze blame

[@lhpl]

Isn't in 1938 already? I mean Hitler has just been inaugurated and is threatening Poland, Austria and Czekoslovakia. Oh wait, that was Canada, Panama and Greenland. Off by one on the century, my mistake. As for systemd, I use Devuan. If it breaks, I switch to a BSD.

[@kenwizspoila6870]

🤣😂🤣🤣. This one had me cracking up alone at work at 0100 hrs.

[@ViniciusMiguel1988]

Don’t worry in 12 years this problem will be addressed

[@FagnerLuan]

...maybe

[@DeronJ]

For testing daemons another long-running programs, it is important to set the clock a bit before the magic date and see what happens when it rolls over. (I was around during Y2K testing.)

[@chilversc]

What if we just make the clocks get slower and slower the closer we get to 2038 so that they never actually reach it? Then we have as long as we like to fix the issue. Though I won't envy anyone pulling an all-nighter on December 31st 2037 to fix that last remaining bug.

[@BrodieRobertson]

Now that's an idea

[@UKprl]

Zeno of Elea would like credit for borrowing from his paradoxes.

[@chilversc]

No, never give Zeno any credit. He will insist on only repaying half the remaining balance, it takes forever to get him to settle his debts.

[@LordHonkInc]

I survived Y2K as a teen which means I now have an unhealthy disregard towards system-critical design flaws and will raw dog my linux box (without backups) into 2039. See y'all on the flipside, nerds 😎

[@VioFax]

None of it matters anyway. In a decade most of what we are doing will be irrelevant. I don't even keep most things. Its not like it will work.

[@EvgeniX.]

@@VioFax you don't even imagine how many factories have multi-million machinery that is controlled by an 486 pc, or the financial systems using mainframes running FORTRAN

[@randomgamingin144p]

@@EvgeniX. 4 chan

[@voyager-tc9dz]

@@EvgeniX. your local ATM is running Windows XP, so don't worry

[@EvgeniX.]

@voyager-tc9dz hahah I worry more then

[@infinitivez]

Considering just how many OLD OLD linux systems I found running back in 2020 at our local state level, I foresee some fun fun times ahead indeed. People DO know things are going to break, but they're doing the same thing they did back before 1999. Either they haven't secure the funding to fix it, or they just aren't taking it seriously because of bigger fish to fry.

[@VioFax]

Way back in 2020 I was a great adventurer too. Its easy. They will just make you buy new shit. Throw the old one away that doesn't have the gov mandatory neural management chip.

[@vanlepthien6768]

I wrote my first Y2K-safe code in the mid-70s - the hardware it was written for was retired in 1997, years later than its expected demise. In 1980, I designed and wrote an entire public utility interconnection billing system with correct date calculations until the Gregorian calendar itself breaks. Unfortunately, the system was retired because its data sources were not updated. Software lasts longer than you expect.

[@kevinforth7618]

Human nature suggests that this will be addressed in 2037, like we handled the Y2K issue in 1999

[@futuza]

Yeah I'm not fixing my code till I have to. (January 18th), see you in 13 years.

[@Neuromancerism]

Ill fix it in december. Friday the 13th. 1901.

[@terminator4625]

Oh I hate how much rework lutris and wine will need for old Windows games/programs.

[@KomiyanVT]

Everyone carrying on about systemd going south, when the real elephant in the room is losing gaming history to a maxed out counter...

[@ArdaU]

@@KomiyanVT they would add winetricks to set wine's time below 2038 then everything would work fine right?

[@williamyf]

I was the "Y2k" compliance guy for a part of a telco (the Monitoring system and IN, to be exact). There was A LOT of work behind the scenes making sure that SMSs and calls flowed during new year 2000, and that we were able to bill said calls and SMSs. And I mean A LOT OF WORK. Do not underestimate the 2038 issue. and do not underestimate the OpenVMS year 10000 issue either.

[@ahettinger525]

I'm not going to worry about VMS's Y10K issue... That's solidly someone else's problem.

[@georgehelyar]

My brother works in a hospital where y2k is still real. They did some bodge to get around it and in 2010 and 2020 they had to come up with new bodges so that they can test blood for people born after 2k I can't remember the exact details but basically bad input validation so something like :0-:9 means 2000-2009 and different symbols for 2010s and 2020s (colon is an educated guess, not sure if it's right)

[@thelord58]

Trunks warning the Z fighters be like:

[@IoraTera]

The drink

[@EthanMallonee]

Real 💀

[@KellicTiger]

I was in collage for IT back in '97. While I wasn't there for programming we were expected to take a number of programming classes. I took COBOL and Fortran. I've run across multiple people who said the Y2K thing was no big deal. Sure sparky. I didn't make over $120,000 in '98 before I was out of collage because companies like were willing to just throw money at a non existent problem. I did a butt ton of code cleanup in '97-'98 as a contractor for Northwest Airlines and a few other companies. The level of suck can not be overstated for the hours. But it was good money for a few years of work. After that I never touched programming again as it was one of the worst times I've ever had doing a job. But the Y2K bug financed my first new car in 2000 :D

[@daveamies5031]

Ha I was one of the people who worked 18+ hour days in the late 1990's to make sure the Y2K rollover was smooth, I was even on call from 10 pm December 31 till 1st Jan 2000 "just in case", and yes, on call meant no alcohol for new years.... I remember at the time there was a lot of criticism that converting all the systems to use epoc time was just deferring the problem, but many people said, I'll be retired by 2038 so it'll be someone else's problem, 64 bit computers were not really available at the time, so it was the best solution for the equipment we had. Since 2020 I started mentioning the 2038 problem to young it grads because they are the ones who will need to deal with it. Brodie I Agree, start dealing with it now, in the early 1990's people used to say oh 1999 is a long way away, and it wasn't till 1998 that people started taking it seriously at least in Australia.

[@GrzesiekJedenastka]

I still don't get why didn't we (as the industry) just use 64-bit unix time from the get go. Yes, 64-bit variables are slower on 32-bit machines, but it's the correct way to do it, and it's probably not that much of a problem anyways if you benchmark it.

[@daveamies5031]

@@GrzesiekJedenastka $$$ there were very few 64-bit unix machines, and they were VERY expensive, you have to remember organisations needed to replace their entire fleets of desktop computers, one org I worked for replaced 5000 386 and 486 pc's running OS/2v3 with Pentium 120's (yes Pentium 1's) with Windows NT4, a Pentium 120 desktop PC back then cost 3x what an i5 PC costs now, they couldn't justify the cost of going to 64-bit Unix workstations.

[@GrzesiekJedenastka]

@ You don't _need_ 64-bit machines to use 64-bit integer values. It's just slower on 32-bit, though as I said, I think the performance hit would not be substantial in most if not all applications.

[@stevegreen5358]

In 1999 I led Nokia's Y2K project for embedded systems in their offices in 14 countries across Pacific and south east Asia. This included HVAC systems, lift controllers, intruder and fire alarms, CCTV and access control systems, telephone systems etc.. Even finding all the date-aware systems in a building was difficult enough - we literally had to look in every cupboard in every room because no one knew what equipment they had. Head office in Finland didn't even know what buildings they had - we had to go to each country to find out! Then we had to identify the things we found. Many were no-name white boxes of unknown origin. Many of the suppliers no longer existed. Some equipment was stupidly old - I found a telephone system running IBM's OS/2 operating system that was installed in the 1980s. Following research and testing, about 300 systems needed to be replaced or upgraded in my area and by the European team. Mitigation procedures needed to be put in place for equipment that couldn't be fixed or replaced. You can't start this 2038 work too soon.

[@HelPap]

Y2K was both much exaggerated and completely different. There was extreme hysteria. I still remember that I had to fill in that our elevator where Y2K proof - they had nothing to do with time - only floors. Funniest was the question about our lathe machines - we produced chemicals. Real issue was, that a lot of important finance software was written in COBOL, time really counts in finance and only retired programmer could make the fixes. Before Y2K was already a similar problem in old Unix sytems - nobody noticed. We just let them run over the cliff and fixed the issue in the interface.

[@workingdemofirsttime4838]

Thanks for the mention, I'll take a look at this next week...

[@MrBelles104]

Just add 1 more bit guys, 33-bit will take us to Feb 7th, 2106, we'll never run out of that time!

[@neatoelectro3687]

add bool. Love it!

[@guiorgy]

I work on some embedded systems, and yup, they pretty much all rely on 32 bit timekeeping, at least the ones I work with. At least some of them deal with the problem by using unsigned timestamps, so there's still plenty of time to keep kicking this can of worms down the line :)

[@ElusiveEel]

yeah that sounded like the obvious fix when this video mentioned the problem, you don't need timestamps from before 1970 so there's no loss for using an unsigned int to gain another 68 years

[@jsalsman]

I guess the last time the current version of RTOS had a 32 bit time_t was in 2016? What do you see as the most difficult hold-out?

[@neatoelectro3687]

@@jsalsman which RTOS?

[@jsalsman]

@@neatoelectro3687 FreeRTOS: Migrated to 64-bit time management in 2014, with updates to its time APIs. VxWorks: Addressed the issue with 64-bit time_t support in 2015, in version 7.0. QNX: Added support for 64-bit time in 2014, with the QNX Neutrino RTOS 6.6 release. Zephyr: Always supported 64-bit timestamps, as it was designed after the 2038 problem became well-known (first release in 2016).

[@andreaspatsalides1914]

There was also a Y2K22 bug two years ago, again for similar reasons. Since the max 2^32 bit integer is 2,147,483,647 any dates represeted with the year on the first 2 digits would overflow since it switched from 21 to 22. This reall was not an issue since it was quickly fixed one way another.

[@xard64]

I guess this is one of the reasons why certificates have "Not before" date and not only expiration date.

[@WooShell]

With the crazy amount of embedded systems we've got around everywhere nowadays, which weren't there when Y2K happened, this is really going to be a lot of fun. And I'm not talking about companies still putting 386-derivates into set top boxes and that sort.. I'm talking about microcontrollers in stuff like smart light bulbs and power strips, which still have so little RAM that their libC most likely still uses 32bit date. And modules with these microcontrollers are everywhere.. imagine on 20jan2038 people not getting into their cars anymore because the shiny NFC keyless entry card has a 32bit signature date and the reader in the car thinks the card expired 70 years before the car was even built.

[@neatoelectro3687]

fuggg, that's going to suuuck.

[@TimothyWhiteheadzm]

Date related issues don't all show up on the exact day/time. The Y2K problem started causing real issues more than a year before the year 2000 because a lot of software deals with future dates. At least one commentor on this video mentions already experiencing the 2038 bug due to incorrect filesystem date stamps. It will be a slow grind to fix it and more important to get it right in advance in some systems than others.

[@draguleanionut-catrinel4303]

TempleOS no affected 😎

[@AK-vx4dy]

Y2K was not such a big problem because embedded devices were not everywhere, now they are ubiquitus. True good part of them we replace just becuse, but many will stay somewhere in dark corner, waiting to blow-up ;) My main concern now is how sure we are, that software we are pushing now (OS-es, standard libraries, file-systems) are immune, that some one run them with date 1/20/2038 and let them rollover from 1/19/2038. Apart from os-es, i wonder if how many timestamped cerfitiates or keys are immune.

[@BrodieRobertson]

That's a really good point as well

[@leogama3422]

as long as they are offline, I think we are safe

[@AK-vx4dy]

@ Why so ? Offline from public internet or they not connected to anything ? What if your frigdge bricks 1/19 ? Or your heatpump or solar inverter ? Being off-line don't change much... Or smart fridge with bulit in TV will convince you to eat old food, beacuse for it is 1970 and your juice is best before 2038 ?

[@leogama3422]

@@AK-vx4dy if these devices that are everywhere are offline but have clocks to keep time, their batteries will die long before 2038. and who cares about smart fridges? they won't turn into ovens suddenly

[@framegrace1]

Yes, but the 2038 problem is infinitelly easier to solve. At the end just changing a type fixes the issue. Y2K formats were as varied as programmers, and the solutions had to be made ad hoc. Also the interactions were a lot more complex, involving string manipulation and things like that.

[@electricindigoball1244]

I foresee this issue creating a lot of e-waste in 2038 as devices that "just worked" and that everyone didn't actively think about stop working. I don't think it's going to be a massive crisis but it may be costly especially for larger companies/institutions/organizations that might have to replace a lot of hardware on short notice. It honestly wouldn't be nearly as much of an issue if manufacturers actually supported their hardware during their usable lifespan instead of abandoning them after barely a few years.

[@markusTegelane]

this makes me wonder if my old Sony Ericsson W200i phone is Y2K38 compliant i may want to test it, just in case :) Edit: I tested it, works perfectly past 2038, however it does overflow after 2070 back to 2000 for some reason, altough you can set the year to 1970 if you want, which means the year is stored as a number that can range from 0-99 and then decoded for the user. I assume other SE phones work the same.

[@Duckly97]

Can't wait for important systems to not take this serious until December 2037

[@destructivforce2894]

I'm curious if this will be a future struggling point for code generated by LLMs. The combination of legacy code in their training data, a lack of filter for what "good" is and what "bad" code is, and a lack of knowledge of what the current year is may result in them generating y2k38-prone code, both before the deadline (possibly going unnoticed) and afterwards.

[@DUDEBroHey]

There needs to be a propaganda movie about the 2038 problem. Make it like "a quiet place" but none of the noise machines work because they rely on Unix. Or make a movie like "the purge" but the security systems don't work because of the 2038 problem.

[@nobbyfirefly57]

No worries, it’ll be fixed last minute.

[@williamsjm100]

Building high frequency models it always amazes me that we don’t have no limit arrays with integers for each 10^3 block. As running out of time stamps when switching to high frequency time scales. Modern distributed systems require much higher time agreement than just seconds and some of that is synchronisation directly tied to hardware (so you are not faking what time frame the batch is initiated).

[@bevintx5440]

I applaud your acknowledgment of the work that went into correcting the Y2K date problem.

[@guss77]

2038 is going to be a serious problem for game preservation.

[@RuddsReels]

Are you talking about disk based games and consoles?

[@guss77]

@RuddsReels any - everything that uses the posix call time() - which is everything.

[@RuddsReels]

@ What if the games stay offline? Or if you set the time to before 2038?

[@guss77]

@RuddsReels so no online games, and a dedicated machine with a misconfigured clock - i.e the machine is isolated and can't connect to the internet because TLS requires a correct clock. This is a very dedicated setup that most people won't be able to run. So Pac-Man 86 will only be able to be played in museums. Not great.

[@DamjanDimitrioski]

We can ask Thailand for the fix, they live in the year 2568.

[@Kaelygon]

oh yea, lemme just time travel to 2038 to see if my program compiles

[@BrodieRobertson]

Computers can do that actually

[@Kaelygon]

@@BrodieRobertson Yea, I am just being a nit since you didn't specify to change system time. 2038 might be finally the end of Windows XP as it's still being used on some offline systems. Time will tell if it completely bricks old consoles and other embedded devices like you mentioned

[@teknixstuff]

@@Kaelygon iirc XP works fine up until Y10K, where the system becomes extremely slow and basically unusable.

[@sharath2273]

​@@KaelygonWindows uses completely different methods for timestamping, NTFS timestamps for example are a 64 bit numbers representing 100 nanosecond intervals after 1601(which lasts until year 30000 or so).

[@TroubledTrooper]

The Y2K prevention effort, as I call it, was actually a rare moment of sanity when governments and corporations took a security problem raised by experts very seriously and successfully prevented a crisis. My praise must be tempered, however, considering that almost nothing had been done to fix most systems until right before it would have been too late, despite experts warning about it for decades. The only problem with the Y2K "panic" was people who exploited the situation's urgency to promote their own baseless conspiracy theories about what would happen, while conveniently selling their "Y2K survival packs." These hucksters made the situation farcical with their fabrications. While people were actually fixing it, they got all the limelight continuing to hype it up until the date passed and "nothing happened". The counter-reaction when "nothing happened" (though problems still occurred despite the massive amount of warning and work beforehand, demonstrating how dire the situation had been) led people to mistakenly believe it was all a hoax, simply because we had been given time and ample warning to fix it beforehand. So yeah this is why we can't have nice things.

[@gljames24]

So many iot devices will become bricked

[@el_fucko]

Well let's be honest, much of what's being sold for iot today will be bricked in some way two years from now, let alone 2038...

[@VioFax]

Sounds like a good way to usher in stuff with even more hardware level spyware on it.

[@BrodieRobertson]

I'm calling it now, there'll be some notable device released by a company you know in 2037 which releases with a known unpatched 2038 bug

[@CatFace8885]

good

[@someguy9175]

I'm lowkey kinda hoping enough software doesn't get fixed that the entire world is in absolute mayhem for a week.

[@ElusiveEel]

I hope systemd doesn't get fixed so all systems running it break

[@TheLegitAlpha]

Channel 291 incident has entered the chat

[@someguy9175]

@@ElusiveEel Nah, that would drive window server market share up. I hope Microsoft doesn't update something critical and their OS goes kaput.

[@Jroonk]

I was in IT support in 1999, and as you attested to, I had to update many of our office systems to be y2k compliant. We definitely would have had issues, but it was a manageable project to get it all done. On 1/1/2000, it was a boring day with no issues. That said I remember nobody really paid attention until 1998, maybe 1997. My guess is that in about 11 or 12 years (today is 2025), companies will pay attention and start allocating resources to it.

[@michaelmonstar4276]

5:22 - "T minus 38" - Meaning how long until 0.

[@azurplex]

Y2K was talked about for a long time but only became time to actually implement planned fixes a few years out. It was remarkably well coordinated and so well fixed that the effects were negligible and just a few quirky stories of things that could be remedies easily enough. I'm convinced 2038 will be fixed in a similar way. It may require breaking some legacy backwards compatibility in some software. Maybe once new/current systems are ready, FOSS engineers may want to patch older software, libraries and even programming languages.

[@Kotfluegel]

Tests breaking depending on the time at which they're run is wild. Java thankfully got one thing right with the latest time-API: any now() method on Dates and DateTime objects, taking a "clock" parameter. Those should absolutely be used all the time as the clock can then be mocked to either make tests independent of time or you can even simulate critical progressions of time in your system, like the clock not advancing at all between two calls, rolling back for some reason or just setting the time to sometime after 2038.

[@tomaszgora4353]

The y2k was different time. Mostly corporate entities poured giant resources into fixing stuff they depend on. These days the web stands on unit and most importantly on endless small pieces of sometimes forgotten open source projects. Which case do you think carries more potential for cracks to slip through? Not too mention the scale and spread of computing in the world in unimaginably more vast.

[@djsmeguk]

I got my start in IT working at a boutique consultancy and we did y2k cleanup stuff in 97-00. I remember reading about to 2k38 problem back then and thinking how unfathomably far into the future it was. God I'm old. I'll probably still be in IT when 2k38 hits too. Edit: x86 done for good in 2038 😂😂😂😂 my man, x86 is the underlying computer architecture on the enterprise.

[@redrealruby]

i have no idea what you were talking about during the whole video, yet I'm subscribed. 🙃

[@marble_wraith]

I vote changing the entire date system. Each year should have 13 months 28 days each + an extra 1 or 2 days at the end. Call it the triskadeck format, or Tdeck for short. Each datetime will be represented by 128bits, timezones will be represented accurate to the geode, and there will be no DST.

[@davidwakelin5609]

That tune at the end, oh my days I wasn't expecting that, my head was banging harder than :catjam:

[@13thravenpurple94]

Great video! Thanks a lot 💜

[@darkangel2347]

Here in Australia, Anzac Day and Easter Sunday will fall on the same day in the year 2038. I guess this will form a super long weekend for us all. Will the Easter Bunny arrive for UNIX users?

[@gwaptiva]

As someone who worked at a blue chip IT company in the Y2K effort. It wasn't a nothing burger, problems _did_ occur, but one: no company will admit it as the reputation damage would've been enormous and two: as you say, there was a massive effort to fix it.

[@GradythaStudips]

Fun fact, Apples HFS file system (which was used by MacOS until 2017) will suffer from this problem. Despite 64bit macOS X versions having been already patched for this problem.

[@memroyleak]

do you mean OS X Extended + Journaled? HFS was introduced post 2017

[@GradythaStudips]

@ No??? HFS IS OS X Extended + Journaled. Theres also multiple versions of HFS

[@memroyleak]

@ OH yeah, my bad, i was thinking of APFS, for some godforsaken reason i keep associating HFS with High Sierra

[@thatgotofinal]

I mostly use Java and C# so all time is on long there for very long time already, most surprising thing for me is that when the Y2K issue happen people didnt think to use that opportunity to expand the possible time range a bit more in all places. Seems like typical devs trying to estimate stuff issue.

[@sophustranquillitastv4468]

For the embedded devices, just don't do the timekeep and eerything will work fine, just only count from 0:0:0 or something like that and the time limit that has been set by the user, as if the time is never set at all. For something else, I don't have any opinion.

[@alienJIZ1990]

A lot of people, even among techs, seriously underestimate how much systems assume and rely on accurate time-keeping. Even NTP itself is often criminally overlooked and taken for granted rather than managed

[@kxuydhj]

imagine people writing 32-bit code after 2038 and trying to figure out why their code keeps breaking.

[@jademonas]

i was super worried for this bug until i realized that its a 32-bit int, so its quite logical to just make the timestamp a 64-bit int i was thinking of it needing two variables and how we would separate the values and what not but its not THAT bad of an issue

[@MikeU128]

I remember the stories about all of the old COBOL programmers getting coaxed out of retirement in the late '90s to deal with the Y2K problem. I wonder if something similar will happen to me a decade or so from now. (I'm in my 60s, so I'm hoping to not still be working by then!)

[@uuu12343]

First, we had Y2K Behold, the sequel to the award-winning event: Y2038

[@karelvanreenen8205]

Can we move the start date from 1970 to 2020 and move the problem just on? 2YK was not a proble athe company where I work at the time, but the leap year did cause the telemetery system to fail on the 29 February.

[@pi_ist_toll]

You've got to do a 2038 live stream where you test as many packages as you know with 32bit time things (no break cosmic but break 32bit time stream).

[@ShinyMew-w7x]

what about BIOSes and UEFIs? aren't those in 32 bit as well?

[@kerbalwww2]

One of the best time relate bug that i have found is in a old Amiga base software that was use for a cable TV channel. This software use a sing 8bit int for updating date and time remotely over a satellite connection. Strangely enough this bug is not in a early version of this software that run on Atari 8bit system.

[@davidioanhedges]

The real issue is the same as in Y2K - embedded systems that "just work" they don't seem to need dates, but Y2K tests showed they would fail, and they patched them, but they are still 32 bit and still out there

[@CubicleNate]

What I find fascinating is that we are a quarter of a century past the Y2K scare and this is still a problem?

[@DelticEngine]

It also depends on the resolution of the clock system such as whether it uses seconds, milliseconds, or microseconds. If seconds are used then a 64-bit value suffices, but if milliseconds or microseconds are used for extra granularity then why not just use a signed 128-bit value and forget about it? There would be plenty of resolution and plenty of time. It would also allow software to work with dates from a very long time ago with out issue, not just a long way into the future. Thinking of 128 bits and larger, as we have 512-bit processor extensions why haven't we got 128-bit or larger processors?

[@coladict]

A bigger problem than individual pieces of software is shared protocols and data formats.

[@Leisery]

It's hard to say if it would be less costing to just set up different computer times for all softwares to use, and that it's much easier than just asking all the coders involved in all current softwares to completely change how time works. As the video said, everyone seems to forget that a certain very common time variable is only some 32-bit integer or 64-bit integer, and thus pay no attention to any of this, even me. One easy solution by typical users would be to manually change computer time, but connecting to the Internet requires the computer time to be automatically set, so not very practical unless you want to isolate that system from the Internet. For a long term solution example by programmers, just prepare/change the computer time for the programs, then the real time(in 2038) can be calculated differently, making this solvable by programmers that attempt to use all the would-be-old softwares, the inner time used in programs would be decided either by users(can just set different dates, but won't work if system is set to automatically sync time with outside world) or programmers(just code to change system time until program doesn't need to sample them again) If gcc were to fix this up, a way would be to add another variable that increases each time the old time variable is about to overflow, the cost is possibly neglible since modern systems probably doesn't care about another int(4 bytes, 32-bit integer) permanently increasing for every systems out there. OS systems still have to be fixed before 2038 though, probably by just preparing a new variable for the real time or smth.

[@maunzcache]

I cannot stop thinking about what the Pokémon plushees did wrong to end up in the corner near the bookshelf :(

[@BrodieRobertson]

I don't have a better spot for them

[@alixcozmo]

I'm just now realizing how many embedded devices I have that run *very* outdated versions of linux. I hope this is fixed soon so that new embedded devices won't have software that might not work anymore after 2038. Imagine having an IP camera that just stops working in 2038. I'm pretty sure most if not all of the embedded devices I have are 32 bit too..

[@lunaqueer]

We could just add a cycle modifier that assumes that if it is null, the date is in the first time cycle, couldn't we? Run it in some sort of system date emulator wrapper thing? If you're a developer, test your software after 2038.

[@sundjinnkari]

I have thought of this problem, my first question is why are we tracking from an 'arbitrary' date? Could we not just update over that arbitrary date once the signed number is rolled over?

[@richardgilson3512]

I remember having to work New Years eve 1999 since I was the Avionics tech with the least seniority in case of Y2K issues with the surprisingly ancient gear that commercial aircraft used/still use. I was like "Why? I'm on the ground, if the aircraft data reliant systems crash I'm literally 30,000 feet below them, I can't fix it while it's in the air!" As we know nothing major happened. Due to the efforts of the software folks I had an uneventful New Years eve in the American Eagle maintenance hangar at ALB.

[@Chatsu8o]

WRT 386's in prod ... Back when I did y2k mitigation ... as you said often the BIOS was the problem. And we specifically tested and replaced MANY production machines that didn't have compliant BIOSes. This, I think, is going to be a big deal thing to do in 2037. EDIT: Often to loud applause from the people that had to use these systems.

[@shmehfleh3115]

Speaking of embedded systems, Intel only discontinued the embedded versions of the 80486 in 2007, and Transmeta still sells SoCs based on the x86 architecture. I very much believe x86 will still be alive and kicking in the embedded world in 2038. It's definitely short-sighted to expect that it won't be.

[@szirsp]

Like 5 years ago for embedded device development (that has to work for 10+ years without update) I was already checking for unix timestamp overflow and reported issues for STM32 using old libc that still have not used 64 bit int for time_t, while C for 8 bit AVR controllers had a different solution, used a different offset (0 was Y2k instead of 1970). Note that C standard does not specify time_t encoding, it's implementation defined behavior. So if you are assuming, relying on it conforming to POSIX specification, then you are doing it wrong.

[@MarkRidlen]

I've personally seen a system not boot to Windows when the BIOS was set to 2000 or later. Actually found a total of 3 systems in my small company (

[@carlosfester]

just to know, this problem is basically related to date calculation (aka uptime for example). Well, i think its a problem a computer stay online from 1901 to 2038 because the number generated by the difference of dates overflow a int type. Or, internaly, dates are stored by a int32 not a ""date"" effectively ? Is that the case, we really have a problem. It will affect windows too ?

[@bobdinitto]

I worked for Cabletron during Y2K and as we went around the table in the conference room, each announcing how long it would take to convert our code from 2 to 4 digit year fields some said weeks and some said months. I said "I'm done!" because why would I be using a 2-digit year field in 1996? That would be short sighted, no? But here we were with all this code to change and we got it done. Well, I should say THEY got it done.

[@andrewdupper973]

9:34 Minor nitpick but a lot of times compiler people refer to the 64 bit variant of x86 as AMD86 because that’s what it was initially referred to because AMD beat Intel with that one. Either way technically referring to the 32 bit variant as x86 alone is correct and the 64 bit is AMD64 or x86_64

[@BrodieRobertson]

I think I've done a video about x86 naming before, in short it's a mess