https://en.wikipedia.org/wiki/Year_2038_problem
AKA the "Epochalypse".
--
I some sense, ARM did kinda take over everything. Consider all
the places that you used to stick a 68k or a Dragonball or 8085;
what's in those now? Mostly Cortex-M, and RISC-V is coming up
On 10 Apr 2024, Digital Man said the following...
https://en.wikipedia.org/wiki/Year_2038_problem
AKA the "Epochalypse".
--
Well Ain't that a b!+c4. People haven't been 32 bit in a long time I can't imagine the newer systems have this issue???
On 10 Apr 2024, Digital Man said the following...
https://en.wikipedia.org/wiki/Year_2038_problem AKA the
"Epochalypse". --
Well Ain't that a b!+c4. People haven't been 32 bit in a long time I can't imagine the newer systems have this issue???
Digital Man wrote to tenser <=-
Re: Re: Operating Systems
By: tenser to Digital Man on Fri Apr 12 2024 12:12 am
I some sense, ARM did kinda take over everything. Consider all
the places that you used to stick a 68k or a Dragonball or 8085;
what's in those now? Mostly Cortex-M, and RISC-V is coming up
ARM is huge (especially in consumer electronics), no doubt, and
definitely PPC and MIPS are dynosaurs today, but they're *still*
used in automotive, in very large volumes, and in other
safety-critical industries (aviation, aerospace) along with other
obscure architectures (e.g. Infineon's TriCore architecture) that
won't be going away any time soon.
There are other differentiating features beyond performance and
power consumption, that keep some of these non-ARM architectures
thriving, believe it or not. :-)
I some sense, ARM did kinda take over everything. Consider all
the places that you used to stick a 68k or a Dragonball or 8085;
what's in those now? Mostly Cortex-M, and RISC-V is coming up
ARM is huge (especially in consumer electronics), no doubt, and
definitely PPC and MIPS are dynosaurs today, but they're *still* used in automotive, in very large volumes, and in other safety-critical
industries (aviation, aerospace) along with other obscure architectures (e.g. Infineon's TriCore architecture) that won't be going away any time soon.
There are other differentiating features beyond performance and power consumption, that keep some of these non-ARM architectures thriving, believe it or not. :-)
The problem is in the softare, not "the system". The system can be
64-bit and still have plenty of 32-bit time_t use lurking in its
software. Y2K38 is definitely going to blow some shit up (figuratively,
if not literally). --
digital man (rob)
That's not true. A lot of sysops run 32 bit systems to be able to run
DOS doors... But no, my main OS for regular purposes won't experience this.
--- shsbbs.net
Shurato, Sysop Shurato's Heavenly Sphere (ssh, telnet, pop3, ftp,nntp, ,wss) (Ports 22,23,110,21,119,8080) (ssh login 'bbs' pass 'shsbbs').
On 11 Apr 2024, Digital Man said the following...
The problem is in the softare, not "the system". The system can be 64-bit and still have plenty of 32-bit time_t use lurking in its software. Y2K38 is definitely going to blow some shit up (figuratively, if not literally). --
Well I will have to read more about it. If its software then Why isn't this fixed already. Guess I will have to ready about it to know why its not simple.
That's not true. A lot of sysops run 32 bit systems to be able to run DOS doors... But no, my main OS for regular purposes won't experience this.
Linux FTW. :)
Quoting Gamgee to Digital Man <=-
reason, and I know that MANY Point-of-Sale devices/systems still run
good old MSDOS. Not worth the effort/expense to update those systems,
and they're reliable.
Tiny wrote to GAMGEE <=-
Quoting Gamgee to Digital Man <=-
reason, and I know that MANY Point-of-Sale devices/systems still run
good old MSDOS. Not worth the effort/expense to update those systems,
and they're reliable.
I ran a MSDOS program for inventory / invoicing when I ran my
business and it just worked perfectly.
I still use Wordperfect office for DOS at home because it does
everything I want. I can even load work excel docuemtns (after converting) and work from home using dos.
On 11 Apr 2024, Digital Man said the following...
The problem is in the softare, not "the system". The system can be 64-bit and still have plenty of 32-bit time_t use lurking in its software. Y2K38 is definitely going to blow some shit up (figurativel if not literally). --
Well I will have to read more about it. If its software then Why isn't this fixed already. Guess I will have to ready about it to know why its not simple.
There's a lot of software out there, written 20 or 30 years
ago, that made a lot of assumptions about the state of the
world; there were a lot of programmers who thought to
themselves in 1991, "Gee, the year 2038 is a long time from
now..." and took shortcuts.
I wonder how many people will be using ARM-based Wnidows machines though.
I've heard of Microsoft working on that, but at least right now, I haven't seen anyone using an ARM Windows machine, either at work or for personal use.
Gamgee wrote to Tiny <=-
I still use Wordperfect office for DOS at home because it does
converting) and work from home using dos.
Sweet!
Re: Re: Operating Systems
By: tenser to claw on Sat Apr 13 2024 02:39 am
There's a lot of software out there, written 20 or 30 years
ago, that made a lot of assumptions about the state of the
world; there were a lot of programmers who thought to
themselves in 1991, "Gee, the year 2038 is a long time from
now..." and took shortcuts.
Speaking for myself at least, I started using time_t types for storing dates and times in C programs in 1988 and wasn't even aware that it
would ever roll-over (go negative) at any point. I don't think I
actually realized that most time_t's are signed (can go negative) and
that for those systems (C libraries), dates before Jan-1-1970 are *suppoosed* to representable in that way (as negative valeus). [libraies that use unsigned time_t's cannot represent dates before Jan-1-1970] And I'm pretty sure it was 1992 when I did the math and realized that 2038
and 2106 are going to be problematic years for 32-bit time_t-based libraries/programs. It was certainly not discussed in the programming books or among C programmers of the era. We weren't taking shortcuts, we were just following the norms. Use of 64-bit integers for most things seemed excessive/wasteful and in many environments (e.g. 16-bit systems) not practical or even possible. --
| Sysop: | Scott Styles |
|---|---|
| Location: | Oshawa, ON |
| Users: | 9 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 107:39:40 |
| Calls: | 75 |
| Files: | 371 |
| Messages: | 72,972 |