On the other hand, MS-DOS, which internally uses a 1980 year-epoch with a byte-sized year counter (and does not use a seconds-based epoch unlike Unixes), will be fine up to 2107, and Windows NT's timekeeping has a range of approximately 30000 years. Despite the elegance of the 1970 seconds-epoch, it's interesting to see how other systems designed roughly around that time period, a little later but not by much, chose to do something else, and as a result became quite a bit more future-proof.

Back then, digital computers were only 25-28 years old. There was no such thing as legacy hardware back then, in our terms. Designing for a 68 year lifespan -- nearly three times the entire duration of the industry to that date -- probably seemed excessive!

32-bit Unix timestamps would have a broader range than MS-DOS timestamps if they made the same sacrifice in resolution and only had 2-second precision rather than single-second precision [1]. And if Unix timestamps additionally used 32-bit unsigned numbers to sacrifice the ability to represent timestamps before the beginning of the epoch, then the year 2038 problem would instead be more of a year 2242 problem.

[1] https://docs.microsoft.com/en-us/windows/win32/api/winbase/n...

Also, why should people care about your special snowflake OS? The C standard doesn't even specify that time_t has to be an integral type, but anyone who expects code to cope with a floating point time_t is deluded. Why is your case any different?

The ISO C11 standard only says that time_t is a real type that holds values >= 0. The minute you start performing arithmetic on that type and checking if the result is less than zero you're entering undefined behaviour territory. For example, does the following program halt?

  int main() {
    for (unsigned i = 1; i >= 0); --i)
      ;
  }

On a 16-bit machine when memory cost close to a dollar a byte?

Tell me again how free the creators of Unix should've been with it.

glibc time64 support is still work in progress, as I wrote in the article

Any system which needs to display the correct time needs to have a mechanism for updates.

The time_t wraparound is a bit deeper and more serious, granted.

The BSDs have no problem with breaking user space, Net/OpenBSD has been using 64bit time_t for a while. And starting with 6.8 OpenBSD's default file system uses 64bit timestamps.

With that said, I think Linux's "never break user space" is one of the main reasons Linux is so dominant. And that is making the time_t work harder to complete.

https://www.adelielinux.org/ is an example of a Linux distro built on musl-1.2, so you can use that beyond 2038 on 32-bit hardware.

> No, it will not fail. In the worst case, from the viewpoint of a programmer it will work as expected: it will be reseted to date 1901-12-13 20:45:52:

This said, I hope you don’t really plan to be still using that thing in 18 years’ time.

Why would they stop working? Very few apps care the exact time.

And if we want we can just reset the clock back for a system that does not care.

I wouldn't be surprised at all if there were some original embedded systems still running machinery and the like in a century from now, catastrophic events notwithstanding. The sort of low-power embedded systems likely to be running DOS don't really experience any wear. There's quite a bit of equipment in the "low-level" manufacturing industry which is around a century old, and has basically been in continuous operation since it was installed.

The bigger issue would be ISA control cards and the like. A HN user recently posted a link of "new" ISA boards for sale, but the latest CPU support was Pentium 4 (about 20 years ago).

No, you can find plenty of ones that will hold a recent i7:

https://www.dfi.com/product/index/1502

https://ipc.msi.com/product_detail/Industrial-Motherboard/AT...

http://ibase-usa.com/english/ProductDetail/EmbeddedComputing...

(I wish they would make "ultimate" mobos with all the interfaces in between too --- I mean if ISA with a Coffee Lake CPU is possible, how about a pair of IDEs, floppies, and parallel ports too...)

._.

http://arstech.com/install/ecom-prodshow/usb2isa.html

Even if you assume it can boot DOS, it doesn't mean it can run DOS. No DOS has drivers for a lot of modern hardware, and they're never going to be written.

> (If not, sounds like a bug.)

BIOS is buggy? Say it ain't so! Say! It! Ain't! So!

Additionally, over the last several years, I've used it on probably a dozen or more different "makes and models" of enterprise server hardware to update firmware (BIOS/HBA/NIC/SSD) and can't recall experiencing any major issues while doing so (fortunately, more and more of these bootable firmware update utilities are now Linux-based!).

That's with FreeDOS 1.0, by the way. A quick check shows that it was released in 2006, making it a fair bit older than the servers I most recently used it on. For what it's worth, FreeDOS 1.2 was released four years ago and the third release candidate of 1.3 was just released this past summer. It seems that FreeDOS, at 26, is still alive and, in fact, doing quite well!

To be clear, I've not actually attempted to boot any of the other DOS systems in, well, quite a long time -- at least 10 years for MS-DOS and likely 20 years or more for DR-DOS and PC-DOS -- as I haven't had any reason to. FreeDOS has been a superior replacement since before the turn of the century.

In my case, FreeDOS is booted via (i)PXE and the "hard disk" (image), which contains the various firmware images, utilities, etc., is downloaded via HTTP and loaded as a ramdisk. In those rare instances when it's actually been needed, it is just so absolutely useful.

Honestly, I'd be a bit surprised if MS-DOS (a.k.a. PC-DOS) did not (for the most part) also "just work"(TM) ...

... and, now that I've said that, I'm fairly confident that MS-DOS 5.0 (1991, IIRC?) is also available on the netboot server. I can't confirm that at the moment but (assuming it is) now I'm quite curious so I'll try to remember to try booting my workstation into it the next time I happen to restart it.

Of course, if New York's subway controls are anything to go by, 2107 is pretty reasonable.

Clipper/xBase systems that do their job is one niche of MS-DOS apps that refuse to die. Another niche I know of, is gambling machines (one-armed bandits), for some reason people kept using DOS (at least they moved to FreeDOS by early 2000s).

Doing DB operations is relatively simple, formdata entry and validation is super easy, supports modules, OOP and even compiles to native code.

Yeah not good for networked operations, but in many mom and pop shops it isn't needed anyway.

Even VB/Delphi for all their RAD capabilities were already much more complex than Clipper, but they messed up their migration into the GUI world and CA Visual Objects was too complex for the Clipper crowd.

COBOL/FORTRAN/Prolog/etc type applications are out there, apparently, and if you're in the right place at the right time you can entrench reasonably effectively, at least short term.

However, these types of jobs also have their own unique pain points. This recent article (they surface reasonably frequently on here), and the comments, make for good reading: https://news.ycombinator.com/item?id=25148840

As for PHP+et al, I recommend these for their overall simplicity, relatively low learning curve, and ability to scale "well enough", for above-average values of "well enough". PHP itself isn't the most ideally designed language, but it can actually get things done. Furthermore, its reputation as a "simple" or "stupid" language, like eg VB6, can also serve to catalyze the upper bound of expected complexity of a particular solution. This has the downside of maybe a bit of isolation from truly interesting challenges, but allows for a slower/relaxed and perhaps more maintainable pace. (And there's nothing stopping you building something Facebook-sized if you needed to.)

On the client side, HTML5 is expansive and... very backward compatible with how things have been done for the past 20 years. Elitist forum commentators may make snooty noises about your use of tables, but Chrome won't. JavaScript could be a harder language to reason about, especially for simple enhancements like fetching bits of data which won't require learning pages of theory first.

Finally, my recommendation to focus on the Web is that, well, once you grumble and context-switch to "ugh, fine, HTML+JS", everything else can roll in incrementally as you go along.

With something stuck in the 80s/90s, sure, you guarantee that you're completely isolated from the firehose... at the cost of being objectively less economically viable in industry.

At least here, the businesses that still ran xBase were the ones unwilling or unable to pay decently for maintenance and/or migration, and that was the situation 10+ years ago.

Haven't looked into Harbour featureset, but I feel xBase in general is simply too simple for new developments. Even mom-and-pop stores need features way beyond the Clipper/MS-DOS capabilities.

The language is outdated, too; even Delphi/Lazarus sounds too 1990ish to me, I have fond memories of Delphi and Object Pascal but it is impossible to justify using them in a world with so many good new languages.

NASA still uses PC-DOS based IBM PCs to control things.

DOS doesn't crash like Windows.

GRR Martin uses Wordstar and MS-DOS to write his novels because he does not want to be distracted by pop up windows and system alerts and updates.

No, it crashes like DOS. I suppose if your application is well written and you have fully exercised the functionality that you use, it might be more stable, but "reliable" is not a word I would have associated with those systems.

ANY bugs will be in the application.

I once wanted to copy/record the layout of a particular PC's boot up sequence, and (without a camera) got the great idea (uh oh) to use the Pause key while staring at the BIOS screen.

I think... I think it worked too well.

Once I'd copied the layout onto paper and hit a key to un-pause the system, it started behaving... very weirdly. I don't remember exactly what it did, but I do remember getting really freaked out because something was very wrong.

What I do remember was playing a game (to test/see if the system would settle back down) and, as time went on, keyboard input became progressively less and less responsive and erratic, and the system started beeping like crazy, almost like the keyboard input buffer had indigestion.

IIRC, the machine hung shortly thereafter and would not turn back on (read: initialize video and POST). O.o

To this day I still wonder what happened to that poor box, and a part of me wants to buy another AT&T Globalist 515 and film it to see if the fault(?) wasn't specific to my machine and maybe figure out exactly what happened.

My initial theory was flash corruption; it's also possible I overheated the CPU, especially given the lack of a heatsink, but it was a 486DX2-66, which didn't need a heatsink, and I'd used the Pause key in DOS plenty of times prior with no issues.

Legacy systems exist in all walks of life, for all kinds of systems. They've solved the problem they were set up for, and so even maintaining them is often something management can be unwilling to set a budget for.

There's an oft shown, but rarely sourced, image suggesting that the US Navy food service management system was running on MS-DOS in 2011, and if that is accurate, I can't find any suggestion they have since changed that situation.

Unfortunately, all of these are frequently true of legacy systems. Only a small number are relatively bug free. Most are simply unmaintained. Few are easy to interface with.

I have no particular problem with old software and hardware. But the massive expenditure leading up to Y2K is demonstrative of the legacy problem. Let it rot until an impending crisis forces your hand, costing far more than if you had simply maintained it.

The more important the system, the higher the existential threat for the organization if you just let it be.

I do understand that it's a thankless job, so this needs to be enforced from up high.

And it will make it available over PC/TCP, using a chain of adaptors and converters from 100BASE-TX.

Don't tell me it's such a small change that it does not matter. That's the attitude everywhere, and the results can be seen. Those living at the US west coast experienced the fires, not to mentio Australia. Myself I used to ski 3 months 20 years ago, maybe 1 month in a warm winter. Now I hardly get over 3 weeks, less than 1 week in a warm winter.

There is a sweet spot for low cost chips, I think its 40nm due to mask costs, manufacturing gets exponentially more expensive from that point on, which is the reason they haven't upgraded. Anyone knows if there are signs this cost is coming down over time?

I think the main point is to use 32bit on new nodes too. Using 32bit instead of 64bit is always more energy efficient unless perhaps you really need 64bit for your application, which most applications don't.

What I think will happen is that the huge amount of money that goes into developing mobile phone SoCs, which are clearly trending towards 64Bit while still requiring low power consumption, will cause that technology to trickle down and be used in ever lower cost markets as time passes and those initial costs have been recouped. The Apple M1, as a system, is clearly crazy power efficient, even at 5nm. And again, if you need an ultra-low power sleep mode, because you only wake up once a day to send some sensor data out, its probably not running Linux in the first place.

You can't make chips arbitrarily small, because you end up wasting more of your wafer for the area between the dies and for the wire bond pads. If the chip size stays the same but the CPU gets smaller, most of the chip is for off-core components and the CPU has less impact on the total cost and power consumption.

You could use more complex CPU cores, or simply more cores, for better performance, but then you also need a faster memory interface (wider buses, LD-DDR4+ instead of DDR3, ...) to make actually use of the performance. These lead to higher memory capacity as well, but then you can't actually use the available memory as you run into 32-bit addressing limits.

I wouldn't rule out shrinks of existing 32-bit SoC families to 22nm or below to lower cost once those processes get cheap enough and there is still demand for compatibility, but there is a good chance that 28nm SoCs is where 32-bit ends. (note that I'm not talking about the dozen or so additional ARC/Xtensa/RV32/Cortex-M/... microcontroller cores on high-end SoCs, as those are not the ones running Linux).

I could not find any actual paper with real use case comparison. Have you got one?

Sure, if you use any kind of 32bit mode then you'd use less energy in theory. But if we leave the responsibility to the software developer, then we all know what happens :)

The sweet spot for power efficiency has apparently moved from 28nm to 22nm, which uses less energy than either 28nm HKMG or 14nm FinFET and is also closing in on 28nm on cost.

There no mainstream 32-bit cores on 22nm or below (yet), so there is a good chance that the coming generation of low-cost 64-bit SoCs on 22nm will beat all 32-bit chips on performance, power consumption and cost.

that's not entirely true. they consume less energy in run mode, but in deep sleep the leakage currents are higher than with larger nodes. this is relevant for ultra low power applications, but those don't run linux anyway.

I do only cross-country skiing.

Could also call it an irony that if mention a concept with 2 variants, the reader automatically assumes the more commercial, the more industrialized, the more polluting variant today.

Are you sure that running two production lines and supporting both of them long term is more sustainable than killing one of them?

> By law of physics they could be built using less resources during production and during their lifetime.

If you want to go that way, why not even more efficient arm cortex?

For all purposes actually in my case. The best notebook I've ever bought was/is the HP EliteBook 2530p; it runs 12 hours on battery, more than I need for my work day. I bought a new one in 2009 and a couple of used ones and parts since then. Most of my software and firmware development happens on this machine (Linux i386; I also have to support macOS though). It always works, never had downtime (I can replace parts within minutes if need be). Even Netflix works. And of course also all the embedded systems I produce are 32 bit, about half of them with Linux (the others are microcontrollers).

It's not. GNU pre-dates Linux by nearly 10 years. But even if you're talking strictly about kernels, 386BSD and Hurd were started before Linux.

> Just fork the repo and maintain 32 bit code yourself if you want to keep it.

I've often noticed -- and not just on here -- that when commenters prefix "just" to a sentence, the work involved is usually non-trivial.

That was the joke, yes. The post I was responding to was complaining about "forced" obsolescence while there is nothing of the sort. Upstream maintainers want to drop some legacy code so they can spend more time on newer machines. GP apparently does not want to upgrade and is now complaining that other people don't do the non-trivial work of keeping 32 bit linux updated for free.

Maybe 64 bit CPUs can get more resource efficient than older 32 bit models. But that's a misdirected use of resources if you use such technolgy to make 32 bit CPUs obsolete. With the same technology 32 bit will always use less resource-demanding than 64 bit. And the claim was that 32 bit has so many use cases (basically all phones and many PCs) that economics of scale are possible.

Of course the nonsense model that you don't pay for Internet services directly, but use Javascript and a lot of other bloat software to run advertisements on your phone to pay via a massive detour is not an energy-efficient approach.

https://en.wikipedia.org/wiki/Embeddable_Linux_Kernel_Subset

I am not familiar with it to say whether it really wasn't that useful for inherent reasons or whether vendors in that space were just more lucky to defend their proprietary solutions than the (mainline) Linux competitors.

> Linux was first written as a desktop system for IBM PC compatibles, ...

> The earliest i386, ... processors all got phased out over time, ...

> The table shows the 32-bit desktop platforms that proved popular enough to make it into mainline Linux and stay there, supported mainly by loyal hobbyists:

> ...

> Platform: IBM compatible PC

> Architectures: ia32

> Earliest supported machine: PS/2 model 70 486

Wha...? Where is i386 in the table?

"Nuke 386-SX/DX support" was submitted to 3.8 in Dec 2012 (http://lkml.iu.edu/hypermail/linux/kernel/1212.1/01152.html), but explicit support existed up to that point since Linux's inception in 1991. I mean, Linux was written for the 386! That was the chip you had to be using since Linux's memory manager was built on top of its MMU.

I accept I may be completely misreading/misunderstanding something here.

ia32 seems to be a a more relevant descrition

When the article says

> Linux was first written as a desktop system for IBM PC compatibles, and was eventually ported to almost every other desktop platform available in the 1990s, including a lot of the early Unix workstations across all architectures.

Because of the juxtaposition with the subsequent platform table, I think a lot of people might be misled into think that both 64-bit CPUs and 64-bit Linux was late to the game. But 64-bit Linux existed as a first-class environment before it supported any other 32-bit architectures like MIPS, PowerPC, or SPARC; before Linux gained any commercial attention (DEC notwithstanding); and AFAIU before there was any kind of serious commitment to syscall ABI stability.

GCC supported "long long" on 32-bit architectures since at least 1989, before Linux even existed.[1] I think some Unix environments supported 64-bit off_t on 32-bit architectures before Linux was ever ported to Alpha, and possibly before Linux existed. In any event, using long long for off_t was a done deal by January 1995 at the first Large File Summit (LFS) meeting. The first two slides at https://web.archive.org/web/20000903063117/http://ftp.sas.co... suggest using long long for off_t was assumed; the year-long summit was apparently concerned with all the other details. That suggests long long was a relatively well worn and mature type in Unix C environments.

Moreover, Linux didn't even get LFS support until several years after the LFS POSIX API was formally published in 1996.[2] It could have implemented a similar solution for time_t and time-related syscalls at the same time it did for off_t and file operations. LFS support has been the default for such a long time even on Linux that today nobody even questions whether 32-bit binaries support 64-bit file operations. Instead Linux apparently waited another 15+ years just to implement that exact solution.

In other words, the potential to recognize and address the representation of time_t--and 64-bit types on 32-bit architectures more generally--existed basically from the very beginning of Linux and only grew more pressing and easier to implement, at least in terms of toolchain support, with each subsequent year. That's noteworthy. Not because it proves the Linux developers were mistaken or had the wrong priorities, but because it shows they weren't blindsided by the issue. The history can provide guidance for people to navigate similar dilemmas today, regardless of whether one would have left the issue on the table until later in the day, like Linux did, or chosen to address it earlier on.

[1] In 1989 GCC supported long long by calling into a library, similar to what it does for some intrinsics when not natively supported. I'm not sure when GCC began open coding 64-bit operations (i.e. generating inline assembly for all operations on 64-bit types).

[2] Not until 2.4.0 judging by http://linuxmafia.com/faq/VALinux-kb/2gb-filesize-limit.html

For time_t, I remember it first getting discussed seriously among kernel developers around 2010 as it became clearer that we had misjudged how long 32-bit systems would be around for, how much work it would be to fix it, and how long before 2038 things would fall apart from bugs. Before then, the general thinking was we could either delay dealing with it until the 2030s or 32-bit Linux would just not be there any more.

I would consider the LFS transition a user space failure, as glibc never made that the default and Debian still builds some packages with 32-bit off_t to avoid breaking the interface between libraries. As late as 2018, glibc was still merging architecture ports (csky) that default to a 32-bit off_t, despite the kernel having 64-bit off_t since 1994 (linux-1.1.46) before any non-i386 ports were added, and all new architectures in the kernel only supporting 64-bit off_t since 2011.

https://github.com/s3fs-fuse/s3fs-fuse/pull/1039

The other kind of lame consequence of that is I have to use Chromium rather than Firefox, which irks me just a little.

Other than that, the RaspberryPi 400 is a really nicely put together little machine.

Probably by 2106 the machines will be responsible for coding, and it will then be their problem; or, civilization might collapse, so any people remaining will have bigger worries. Or (best case) both.

(And, FWIW: my expectation is that civilization will have collapsed because of the machines taking over, and the only thing that will save humanity is when they all keel over and die on February 7, 2106.)

You go through and subtract 50 years from all date values you have in storage, change the date display code to show everything based on 2020, and you've kicked the can on the problem down to 2088.

Treating a 32-bit timestamp field as unsigned seconds since the epoch at least keeps backwards compatibility with existing software up until 2038.

That's probably what you needed to do anyway, if you want the code to compile correctly on systems with 32 and 64-bit time_t.