Joel Michael @jpm@aus.social
Public

So, I probably should explain this, because there’s multiple levels to this joke.

The first level is the 2038 problem, when the “traditional” 32-bit signed time_t rolls over which is going to cause at least as much chaos as Y2K prior to 2000.

The second level is that Solaris has been 64-bit capable since the release of Solaris 7 in 1998, and 64-bit only since Solaris 11 in 2011, so it shouldn’t be a problem anyway.

The third level is the “Solaris Binary Guarantee” which states that a binary compiled for previous versions of Solaris will run unmodified on future versions. However, this means that binaries compiled for Solaris 10 and earlier may be 32-bit, using 32-bit time_t.

So, yes, but no, but yes. Maybe.

EDIT: Alan Coopersmith, who is currently a release manager for Solaris, provides even more details about what’s left in Solaris that still relies on 32-bit time_t: hachyderm.io/@alanc/1145193100

Alan Coopersmith (@alanc@hachyderm.io)

@jpm@aus.social it's not quite that simple - the Solaris kernel has been 64-bit only since Solaris 11.0, but not the userspace programs - those had been kept mostly 32-bit so they could be used on either a 32-bit or 64-bit kernel, and we started converting them all to 64-bit after the #OracleSolaris 11 release - see https://blogs.oracle.com/solaris/post/moving-oracle-solaris-to-lp64-bit-by-bit and https://blogs.oracle.com/solaris/post/oracle-solaris-114-beta-progress-on-lp64-conversion - we're now up to 98.8% converted and working on finishing the last few we plan to convert and EOL'ing the rest.

hachyderm.io · Hachyderm.io

0
0
0

If you have a fediverse account, you can quote this note from your own instance. Search https://aus.social/users/jpm/statuses/114508539699675251 on your instance and quote it. (Note that quoting is not supported in Mastodon.)