[LEAPSECS] happy anniversary pips

[Harlan Stenn]

Warner Losh writes:

> 

> On Feb 12, 2014, at 1:50 PM, Harlan Stenn wrote:

> > The conclusions I draw from the utter lack of any similar reports from

> > non-linux systems are:

> > 

> > - either those kernels/libraries did not do leap-second processing, or

> > - they did and their code worked

> > 

> > Do you have different conclusions?

> 

> Yes.

> 

> Linux is more popular and examined than other systems. Linux is more

> open than Windows, so bugs there won't be as well publicized. Linux is

> more popular than FreeBSD, which also handles leap seconds in the

> kernel. There have been about half a dozen bugs in FreeBSD's leap

> second handling that I've fixed over the years. The code mostly works,

> but I'm sure if it were studied in detail some aspect of leap seconds

> wouldn't be handled pedantically correctly (absolute timeouts for

> condvars in posix will, for sure, take a second longer to timeout

> across a leap second boundary).


Doesn't pass my "smell" test.

I know lots of folks who run Windows, nobody reported seeing this
problem there.

I run FreeBSD on *lots* of boxes, many different versions.  None of them
saw this. 

We're not talking about pedantically correct, we're talking about
locking up the box.


> Linux is also has a higher rate of change and rewrite than FreeBSD,

> which is another reason it gets tripped up by these issues more

> often. The number of extant linux kernel versions is quite large

> compared to most other systems as well. With this much change, there's

> sure to be something overlooked, and quite often it is the "edge"

> cases, like leap seconds.


So you are saying that Linux is a paragon of quality and design and
development, and as proof of this you offer a painful screwup as "the
exception that proves the rule"?


> Other systems are less open, and sweep this data under the rug is also

> a valid conclusion.


That implies their customers didn't write about it or complain to
anybody.

I think I don't have anything more to add to this discussion.

H