News: 1603083666

How is this a fix for "Linux"? It is a patch to the optional XFS filesystem which yes is included in the Linux kernel, along with multiple other filesystems. XFS is not even used by default when installing any major Linux distros. It has to be manually selected.

Today XFS, tomorrow the world.

It's been default in RHEL since 7, which started more than 6 years ago. So you're not as knowledgeable about that Linux thing as you'd like to appear.

It's long been the default on openSUSE for /home, which by default was created as a separate partition (root is BTRFS). Latest versions of openSUSE no longer propose a separate partition, I'm not entirely certain why. The [1]official line is that

Placing it on a separate directory makes it easier to rebuild the system in the future, or allows to share it with different Linux installations on the same machine. Never quite understood why that's easier in a directory on the same partition as root than in a separate partition. If you tell the installer that you do want a separate partition for /home it will still default to XFS.

M.

[1] https://doc.opensuse.org/documentation/leap/startup/html/book-opensuse-startup/art-opensuse-installquick.html#sec-opensuse-installquick-partitioning

Really can't imagine any rationale for many distros to ditch the separate /home partition. It's one of the best things about installing Linux.

The rate we're screwing up the planet, I think we'll have bigger fish to fry by then.

If we are not careful there will be few fish left [due to over fishing and climate change] and most of them small, not big!

By then the fish would have taken over and I for one welcome our piscine overlords........

...if it was Windows that couldn't see past 2038 and not your beloved Linux.

We already know that Windows has problems with years [1]2100 , 2108 and 4501. The good news is few expect Windows to be around that long but if it is, you can put an appointment in your diary for 2100-02-29 to tell me I was wrong about that.

[1] https://en.wikipedia.org/wiki/Year_2100_problem

I would be absolutely shocked if Microsoft decided to fix something 17 years before it became a problem.

Ironic though that someone from Oracle pushes patches to an SGI filing system shipping with Linux, while Solaris still has unresolved date issues.

while Solaris still has unresolved date issues.

Which ones?

Solaris has been using 64-bit time_t for 10+ years, and should not be bitten by Y2038. Try it.

UFS as an on-disk filesystem will have issues, which are difficult to fix without creating compatibility issues with taking/restoring backups (and I'd expect that also to be true for Linux filesystems with 32-bit timestamps), but that is one of the reasons that Solaris replaced UFS with ZFS a decade ago.

The Y2K problem was known almost since people started recording years as two digits, but the response to is was basically "we'll have stopped using these systems by 1999". Whereas of course I suspect that most of the programmers coding for two digit years in the sixties and seventies were really thinking "I'll be long retired by then so I don't give a shit". Then of course it just became normal and that's how people did things. Whenever a voice was raised in dissent for the next thirty years it was drowned out. People were still coding 2 digit years well into the nineties. Then of course come 1999 huge budgets were expended on fixing code or in some cases entirely replacing software or hardware when things couldn't be changed.

You would think that lessons would have been learned, but the approach to this (and other) date rollover issues proves that they weren't.

"we'll have stopped using these systems by 1999"

What they didn't factor in was the reluctance of the PHBs to spend any money on maintaining the infrastructure/code. Same old story even today. Leave it until the last minute, or even to break, before they take their heads out of their arses....

To this day, I think the most important Y2K fix ever published was the one from the Insurance industry around 1998, which basically said "We will not pay out for any disasters caused by date-related calculation errors". As a bonus, this also covered 2038 as well...

That got the attention of Upper Management!

After much digging through the Linux include files, you can see that the time_t type on 64 bit kernels is defined as __SYSCALL_SLONG_TYPE, which appears to be a signed long integer. On x86_64. this is 8 bytes, or 64 bits.

It's been like this in the kernel for a long time (can't be arsed to go back through the kernel history).

On (legacy UNIX, so who would patch that), AIX, time_t has been directly defined as a long int since about AIX 5.1, (available before Y2K) and I'm pretty certain they carried that through into the filesystem code (this tends to happen automagically when the source is recompiled on a 64 bit system, unless explicitly turned off) by the types being defined in system wide #include files.

So the kernel has been fixed on Linux and many UNIX's for a long time There's been a range of tricks deployed to allow 32 bit binaries running to still pick up 32 bit time_t. This code will break still, but who is likely to be running binaries compiled for 32 bit systems im 2038. That would be real legacy code?

On (legacy UNIX, so who would patch that), AIX, time_t has been directly defined as a long int since about AIX 5.1, (available before Y2K) and I'm pretty certain they carried that through into the filesystem code (this tends to happen automagically when the source is recompiled on a 64 bit system, unless explicitly turned off) by the types being defined in system wide #include files.

Problem is you can't just start widening on disk data structures with a recompile. If your time_t is 32 bits in your on disk data structures you'll need to rewrite your on disk data.

The issue is unlikely to be with OS level stuff, it's all the compiled software that's assuming it's a 32 bit value that will bite people.

This code will break still, but who is likely to be running binaries compiled for 32 bit systems im 2038. That would be real legacy code?

Lots of people I expect. Not spending money is a powerful motivator. :) I'm currently working on a codebase that is nearly 30 years old, we're currently modernising it (ie, rewriting it bit by bit), but I expect the existing code to still be running 10 years down the line, and that's 32 bit.

In the 70s computers were advancing at a frenetic pace, even in the 90s when I was starting out I remember being in awe of a minidisc player I had that had more processing power than the desktop I could've bought for 10 times the price just 2 or 3 years previously.

Those days are gone now, we're at the more gentle progression curve in computing now, like many other things, we now do need to start assuming the things we're building will be around for decades.

I agree, which is what the last sentence was all about, and I also agree about the space in assigned structures.

But when it comes to filesystems, for example, there's been a bit of a tweak that allows the mounter code to identify whether the filesystem was created using 32 bit or 64 bit time_t. Provided you go through the OS acquire the info contained in things like the inodes, it's possible to allow the system call to decide how to identify and present the data, keeping the function in the core part of the OS.

Anything that directly accesses this data without the OS's involvement would need special attention, however, as would any code managing it's own datafiles.

But in the next 18 years, we will not be running 32 bit processors (support for 32 bit Intel is due to be removed from the kernel quite soon, if it's not already), and I would be surprised if any system, or even code now running will be still running when the time comes without at least recompilation. It would be really clumsy system management to also not have re-created filesystems before then either.

Because of the nature of the system call interface being changed and the way that dynamic linking works, x86 Linux is not quite as tolerant when running old code (if the version of a shared library changes on a system, quite often old binaries fails to load and execute) as some other UNIX variants (I ran a binary I compiled in 1995 on a 32 bit AIX 4.1.2 system on a 64 bit system running AIX 5.3 a few years back, and it still ran perfectly)

I worked through the 1999-2000 transition working on UNIX systems, and know that in my first job in 1981/2 (not on UNIX), some of the code I created definitely would not cope with the 2 digit year rollover (I did point it out, but I was just a junior programmer). I would be interested in knowing whether anybody had any problems with parking ticket fines in the Borough of Rushmoor around Y2K, because that is the main system I worked on (although I did also work on DLO) in the fairly miserable year I was there.

I will be retired by 2038, but I hope to be mentally able enough (and still interested) to be able to say "I told you so!"

Where thith the "aka Y2K38" come from? As is usual, when a nice and functional thing created by enigneers and used by engineers lands in the hands of laymen without two layers of protective insulation, cringeworthiness ensues. Just like, for example, the semantic version numbering (remember the 2.0 craze followed by current 4.0 folly?) or the Internet itself, the order-letter notation (or does it have an actual name?) used to great advantage by engineers somehow leaked to the instagram-using youth for whom the letter K seemed to work much better than the digit 0. I couldn't care less if they kept it using just for amusement, but it came the full circle somehow and now whenever I see the letter K on the significatn position, especially following the digit 2, I must ask explicitly whether it really mans K or is just a fancy zero. Otherwise I can't be sure whether the value is 2038 (cool new instagram number format) or 2380, which it had meant for sveral decades before instagram ruining it. Fuc0 it, people, Y2K was not Y2K00!

It means x1000. Those that identify resistor colour codes have it ingrained (or rather, kicked) into them :-)

Buy Better Resistors Or Your Grid Bias Voltages Go West...

I'm old, I am.

Bye Bye Rosie, Off You Go, Birmingham Via Great Western...

Or the less PC version

Bad Boys Rape Our Young Girls But Violet Gives Willingly

I think they really meant Y2.038K

Sounds like Oracle hit a problem with timestamps set in the future already and needed a quick fix, but didn't want to waste precious disk space either.

This should be taken as one of the first signs that this problem is starting to rear its ugly head and can't be put off much longer for software and structures that have't been updated to use 64-bit time yet.