SUSE Linux Enterprise 15 to receive support right up to end of Unix epoch As SUSE ascends its self-imposed ALP, this version may be the last of the fixed release cycle for openSUSE Leap. Last week at SUSECon, the annual conference for Europe's longest-established Linux vendor, the company announced the latest update to its current long-term supported enterprise server distro, SUSE Linux Enterprise …
[Author here]
> I wonder what Leap 16 will be like, based on they nebulous "ALP".
Well, I did try to look into that, but SUSE was not very happy with my take on it.
https://www.theregister.com/2024/01/17/opensuse_confirms_leap_16/
The key point seems to be that the way SUSE is implementing immutability and transactional package management leans very heavily on Btrfs, but that does have the benefit that it doesn't involve fundamental changes to the way the OS is built. So, the good thing is that it can be turned off, and you're left with something fairly standard.
What the company has not been able to tell me is if it's got any answer for the issues of Btrfs fragility:
* its habit of self-destructing if the volume fills up;
* the way Btrfs doesn't and can't give a straight answer to how much free space is available;
* so, the way snapshots easily fill it;
* and that SUSE's snapshot garbage collection is inefficient and unreliable;
* the impossibility of effective Btrfs repair;
... and so on.
If you don't use Btrfs, the problems go away, but so do snapshots and rollback and transactionality. I also asked if they were implementing Snapper on bcachefs. No reply.
This is sadly typical: all the big Linux vendors are very poor at answering technical or commercial questions. They're only geared up for marketing type stuff.
SUSE's transactional tech is very clever. It's simpler and cleaner than Red Hat's or Canonical's.
I'd be a lot happier if it didn't depend on my single least-trusted Linux filesystem, though. Secondly, as a general thing, I find tech that isn't tied specifically to one specific implementation of something is more reliable and robust, both to tech changes and market changes.
There are two problems with the use of the phrase "end of Unix epoch" here.
1. Although in general use, "epoch" can mean a period of time, in computing it is an instant in time. As per Wikipedia's entry for Epoch (computing): "In computing, an epoch is a fixed date and time used as a reference from which a computer measures system time. [...] Unix and POSIX measure time as the number of seconds that have passed since Thursday 1 January 1970 00:00:00 UT, a point in time known as the Unix epoch."
2. The end point for representable time_t values on Unix and POSIX systems varies according to how time_t is defined. It is in 2038 for 32-bit signed time_t, but much later for 32-bit unsigned time_t or for time_t with more than 32 bits. In fact, the latest revision of the base volumes of The Single UNIX Specification (aka POSIX.1-2024, published earlier this month) requires implementations to have a time_t of at least 64-bits. This makes the limit on representable times not time_t, but the tm_year member of struct tm, which (with 32-bit int) can only represent times to a little over 2 billion years from now.
You need to put your quote marks in the right place: try
"end of Unix" epoch[1]
instead of "end of Unix epoch"
to go alongside the "start of Unix" epoch[1]
[1] really "start of Unix time" epoch and "end of Unix time" epoch[2]
[2] for 32-bit Unix, as opposed to "end of 64-bit Unix" epoch or even "end of 128-bit Unix" epoch; as 32-bit has been the norm since the "start of Unix" epoch it does not need to be given any other specialisation in its name, unlike the (much newer) 64-bit time variant.
