Although I realize the table and most of the article is primarily concerned with 32-bit CPUs, it's unfortunate that the article fails to mention 64-bit DEC Alpha, which was the second architecture after i386 supported by Linux. And unlike i386 it's still supported.

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