>2038, 2K38, Y2K38, Epochalypse resistant technologies

So I guess I'll have to give up my oldtech after some time due to this. I have a trusty Tomato firmware router and LTE modem and I don't see the point replacing them however they're not built to last and are hardcapped at year 2038 by the OS. My PC will be fine since the BIOS can get beyond year 2038, my file systems can already do >2038 now too (XFS with bigtime) and my kernel and desktop environment is now also quite ready (just checked now, KDE time/calendar used to be limited, they fixed it) >THE PROBLEM: (1)my home router (2)my trusty router-4G modem (3)my phones (a 5G and a 4G one) (1)Right now I don't know any router that supports years beyond 2038 that also support open firmware (fresh tomato / openwrt). I can only hope they implement the fix early. (2)As for my modem, it has some really cool modifications and features (such as PCI/band control, sms/ussd), and root access though still suffers 2k38 issue without a doubt. I don't know any that could replace the modem aside of running a 4G/5G usb stick in serial mode and plugging it to fresh tomato - those though can overheat a lot!! and the USB2 isn't able to keep up with the data speeds (hard to find USB3 modem that support serial mode, unlocking, and the listed features above). (3)As for phones, it still is very affected though you may find several claims "e.g, quora" denying this with cliams that "it only affects 32-bit and everything is 64-bit now" well guess what: they're wrong. I checked the newest phones on showcase recently and they're not even epochalypse ready in the calendar/clock settings (and as if!! they will implement a fix on a system update, it's convenient obsolescence and demand for companies). With that in mind I think it would be nice to develop OS that is resistant for the issue since these old tech epochalytic tech will pour the "e-waste" market and I love being eco-friendly. What's your plan? Any suggestions?

lets just all pretend its 1970 again that'll fix it

this problem doesn't concern me, i am prepared for the amount of old tech i will gladly find

far as i remember bios without battery defaults to old date. So you could literally sleep this problem away doing nothing. Only question would be how do you go online with old tech since all standards require synced time. Maybe could automate +20years for all your networking api calls to time.

>>70751 mind telling me your backup plan (or setup)? I'm eyeing on some usb dongles to run in serial mode, directly plugged on PC or some 2k38 resistant routers. seems that 4G isn't going out anytime soon though I think it's still a problem that these are bottlenecked by the usb2 speeds. also yeah I'm trying to prepare for the old tech tsunami that will come soon. it should hurt less to break a few firmwares or so trying to hack the OS when they get so cheap. implementing a global OS for such (allowing 2038+) is profitable endeavour. time for me to step up my game.

Dude you'll have a hard time finding 4 & 5g support in 2038. AMPS lived for 30 years in the US due to govt regulations. 3G in the US was about 20 years. I know it's still around some places but it's being dismantled. The first 5g towers popped up in the US around 2018 which would mean given 20 years they'll be torn down in 2038. The epoch might even be a good excuse for them to expedite replacing any 4g and 5g hardware since it'll be expensive for them to operate and have a reasonable chance of failure. So I don't think you need to worry about what your 4g and 5g devices are doing for the rollover.

>>71010 Changing the linux kernel and other firmware out on these devices won't help you because the radio chips all run their own firmware and OS. I admittedly don't know a lot about it but running something lighter than full blown linux probably saves a boatload of money and is easier to verify and certify.

>>71011 5g has clear speed advantages over 4g and 4g clear advantages over 3g, but the speeds that can be attained with 5g don't seem like will be even realistically attained in a very long time, and even then it probably wont be needed ( who needs more than 10gbps ?)

>>70365 >lets just all pretend its 1970 again I'm cool with this. Lets' get a do-over.

>>71010 either upgrade to compliant hardware/software or live with it. i'm pretty sure we will have this figured out 15 years from now. can't exactly afford not to

>>70364 why did you make this? are you ghay or have aspergers >2038, 2K38, Y2K38, Epochalypse resistant technologies you mean not using C? ive been doing that since 2008 (since the nerds here dont actually understand computing: im saying i store unbound data structures. fixed size "ints" are C brain damage)

>>71235 Anyone wishing to use Mac OS X before Snow Leopard (10.6), for example, will be affected by the Y2K38 bug and will affect how programs work, the date of saved files, etc. I guess for nostalgic purposes using old Mac OS X versions comfortably, it would be rather disappointing to have one's operating system malfunction because it can't register a date beyond January 19th, 2038. Regardless, all versions before Mac OS High Sierra (10.13) have a Y2K40 bug because of Apple's HFS+ file system not being able to recognize dates beyond February 6th, 2040. 32-bit Linux distributions are affected by this Y2K38 bug as well, granted they are running a Linux kernel earlier than version 5.6, which would probably be rare to see in use by 2038, but you never know.

Am I stupid or can't we just set the clocks back to an inaccurate date? I remember I had some settings messed up my old windows 7 machine years ago and the clock and calendar was always busted for some reason but the machine still worked. I was 14 so I didn't really care about it tell time right.

>>71292 I'm no expert but I'm very sure that it will continue to work fine. The main issue is that web browsing will be almost impossible because TLS. You might still be able to do it by somehow passing the actual current date to your web browser in a different way, though. Y2k was feared because it could cause issues with things like banking systems and other corporate infrastructure. These obviously got patched before it was an issue.

>>71301 the 2038 bug is also almost completely patched already. 64-bit Linux doesn't even give users a way to generate a 32-bit timestamp any more. It is entirely likely that the only devices that will be really affected are embedded devices, and those almost never rely on accurate calendar date measurement.

>the MINIX and [redacted] backdoors on most systems falls victim to 32-bit epochalypse, refusing to work anymore >all hardware (assuming their serial flash hasn't expired yet) becomes freed of the big backdoor >just before y2q quantum break arrives so uhmm yeah oldtech will be the most secure device post y2q since all modern devices have more wireless tech embedded (which makes it very vulnerable to y2q while not freed by epochalypse). I'm guessing I'm still sticking to my toasters then.

>>71301 not very sure but I think what happens is that unmaintained websites/boxes and such which weren't able to use modern kernel (5.2 was it?) and fs will get hit so there will be some sites that will never see the day again. for systems they needed to use Ext4 with 256byte inodes or higher, while XFS can use bigtime (which only came to fruition in around 2018). others which weren't able to would refuse to get file inputs, otherwise a bunch of file dates issues (which might also be bad for fs journaling). >>71292 many phones already bricked itself when the clock was set to the max 2038 date. it was also proven to have bricked iphone users when phones took the 2038 date-serving "ntp server" router so yes they might run fine but some devices will break/