[LEAPSECS] happy anniversary pips

[Warner Losh]

On Feb 12, 2014, at 5:36 AM, Greg Hennessy wrote:


> 

>>> Um, that is false. All linux kernels did not crash, in fact NONE of

>>> mine did.

>> 

>> "all" here was an overstatement, but the impact of the leap second

>> should never be "your kernel crashes" even if your personal kernels

>> didn't.

> 

> You should refrain from making inaccurate claims, it damages your

> credibility.


It still doesn't detract from my point: leap seconds caused aberrant behavior in the linux kernel that everybody wants to nit-pick me on, but the nit-picks don't detract from the point. The point is the aberrant behavior, rather than the slight mischaracterizations of that. Geeze, no wonder no progress can be made, people are arguing over the wrong things.


> The fact that the most recent leap second error didn't cause kernel

> crashes but caused extra cpu cycles to be spent again lowers your

> credibility.


I'm sorry, but a live lock is a crash. Claiming otherwise lowers your credibility. The Linux bug was a classic live-lock problem where no progress could be made depriving other users of CPU cycles. This is a crash, and has been considered a crash for the past 30 years or so. I've personally fixed a number of such crashes where the bug description was "crash" when more properly it was described as a deadlock or live lock..


>> MP is hard, sure, but that's not the root cause of this issue.

> 

> The root cause of this issue was an error when stepping

> a clock backwards? Why was the clock stepped backwards? To

> comply with a POSIX requirement that does not match reality?


The root cause happened in 1972 when time was changed from an fixed radix to a variable radix.


> I submit that the proper fix is to update the spec

> to match the fact that we now have days that are 86401

> seconds long, now to eliminate leap seconds.


Actually it isn't reality. Days don't have 86401 seconds, and won't for a few millennia. Days have 86400.001 SI seconds (give or take). UTC isn't "reality," but a standard for keeping the variations in that 0.001 in sync with fixed-length seconds by choosing a convention to label seconds so that is accomplished. POSIX is a standard for keeping time in a computer. These two standards are in conflict. That's the real root cause here. Claiming that POSIX doesn't match "reality" lowers your credibility. POSIX and UTC don't describe the same thing. One must change to resolve the conflict.

Warner