Yeah, my primary computer is a Hackintosh with a 4790K (so yes, haswell). This computer with was built to have the fastest hardware that also supports Mavericks.
But, I'm running a vanilla kernel. Most Hackintosh systems have used vanilla kernels since the Snow Leopard days. The exception is AMD-based Hackintoshes, where custom kernels were common up until around 2018, when they also switched to patching in memory.
No, I'm still confused about that! I'm particularly confused because some custom Hackintosh kernels, such as the Bronya Ryzen kernel, don't contain the size discrepancy.
This is a distressing thread to me not for the consequences but how close 2038 really is. It seems almost impossibly removed from our time, but 15 years is nothing. Time is only getting faster and faster.
My plan for this if I am to survive to see it is to in 2035 roll back any machines I rarely use to 2005 or so, which will buy me more than enough time. Just so if I put them in storage again I will not have to worry about forgetting. I already have computers that haven't booted in a decade. If CMOS batteries start to die on me, past 2030 or so I won't even bother replacing them. At least then I will always be aware of what date to set it to, and it will never slip away from me no matter what.
I do not plan to use any of these computers with the internet or internet downloaded files in 15 years, I doubt any of it will even be compatible. I do hope I can keep these things running for so long, especially a machine with my locally maintained iTunes which I hope to have until I die or go deaf.
I find it more puzzling than distressing. It's of some minor academic interest, but I'm not planning to rely on prehistoric computers in 2038/40 for anything remotely important.
For my doorstop-class collector's items that I may or may not have at that point, I'll find ways to set the clock.
It's not only academic interest, there will almost surely still exist drives with HFS file systems in use a decade from now (likely legacy external storage). I wonder how Apple will handle it on newer OS. They will either use the same trick I mentioned to shift the timerange, or they will simply make mounted HFS volumes read-only and offer to convert it to APFS.
I find it more puzzling than distressing. It's of some minor academic interest, but I'm not planning to rely on prehistoric computers in 2038/40 for anything remotely important.
For my doorstop-class collector's items that I may or may not have at that point, I'll find ways to set the clock.
Indeed, I should clarify that it's distressing that the years have gone by as they have. I'll turn 80 in 2038. The actual problem presents no distress, the only issues I can think of would be outside the realm of Mac, where Win32 systems may still be in place in crucial areas. Yet Y2K was a non-event, so even this is likely to be an incidental.
Here's my idea for how to fix these date problems:
Instead of storing the date and time as a single integer counting up from the UNIX epoch, the date and time could be stored as one integer, and the year could be stored as another. The highest signed integer that fits in a 32-bit register is 2^(32 - 1) - 1 = 2,147,483,647, meaning a year stored like this won't overflow for more than 2 billion years. For a 64-bit register, it's 2^(64 - 1) - 1 = 9,223,372,036,854,775,807, so a year stored like this would take over 9 quintillion years to overflow! If we store the year as an unsigned 64-bit integer, the maximum value would be 2^64 - 1 = 18,446,744,073,709,551,615. This is probably overkill, but we can go even further by storing the year as multiple integers representing the digits of a single, larger integer.
All physical computers will certainly cease to exist once their atoms evaporate into thin air via proton decay. As of yet this hasn't been proven to occur, so we'll assume it takes the upper limit of 3x10^43 years for all protons to decay. Storing this number as an unsigned integer would require 145 bits. To do this with a 32-bit processor, we could use five registers for a total of 160 bits, or with a 64-bit processor, three registers for a total of 192 bits. I think it'd be cool to include this level of robustness, even though it's probably unnecessary.
Here's my idea for how to fix these date problems:
Instead of storing the date and time as a single integer counting up from the UNIX epoch, the date could be stored as one integer, and the time could be stored as another. The highest signed integer that fits in a 32-bit register is 2^(32 - 1) - 1 = 2,147,483,647, meaning a year stored like this won't overflow for more than 2 billion years. For a 64-bit register, it's 2^(64 - 1) - 1 = 9,223,372,036,854,775,807, so a year stored like this would take over 9 quintillion years to overflow! If we store the year as an unsigned 64-bit integer, the maximum value would be 2^64 - 1 = 18,446,744,073,709,551,615. This is probably overkill, but we can go even further by storing the year as multiple integers representing the digits of a single, larger integer.
All physical computers will certainly cease to exist once their atoms evaporate into thin air via proton decay. As of yet this hasn't been proven to occur, so we'll assume it takes the upper limit of 3x10^43 years for all protons to decay. To store this number as an unsigned integer would require 145 bits. To do this with a 32-bit processor, we could use five registers for a total of 160 bits, or with a 64-bit processor, three registers for a total of 192 bits. I think it'd be cool to include this level of robustness, even though it's probably unnecessary.
