The libevent issue (Was: Re: checking in)

[Eric S. Raymond]

Joel Sherrill <joel at rtems.org>:
> I have been attempting to build on CentOS/RHEL 6 and 7. I filed tickets
> based on experiences on each
> 
> CentOS 6 does not have an RPM for libevent2. Thus without special work by
> each person building NTPsec, it won't build. AFAIK this distribution is the
> latest RHEL approved for use on DoD networks. I could not find a STIG for
> RHEL 7 so any organization which requires the DISA STIG to be applied is
> stuck at 6.

This is a little bad, but not unrecoverable.  Only ntpdig requires libevent2;
ntpd, in particular, builds without it.  If we have to document that as a
limitation I don't think we're going to lose customers over it.

I have changed the ticket to have the 'build' label and asked Amar to change the
build so it fails gracefully in the absence of libevent2, making everything
but ntpdig.

> My CentOS 7 was missing a package and the build didn't disable the
> reference clocks that depended on it. Ticket filed.

This can be fixed with a relatively minor build system tweak.  I have added
that request to the ticket.

> The CentOS 6 issue raises some questions. Did we intend to support this OS?
> Long term, it highlights the problem of assuming a newer external support
> library is going to be part of a LTS OS distribution. I don't know if this
> was on the master list of supported OSes and checked when libevent2 as a
> dependency was discussed. I don't recall having a checklist OSes to ensure
> we checked all.

I guess now is a good time for me to come clean about one of the
assumptions behind my original technical planning.

I never pushed having a checklist of OSes to support for the same
reason I advocated coding to a strict POSIX.1-2001/C99 baseline.
(Joel, this discussion took place well before you were on board.)

Experience with GPSD had persuaded me that the traditional Unix
strategy of keeping a lot of porting code around just in case led to
carrying a lot of historical baggage that had outlasted its time.  I
believed having a large a-priori set of Unix variants to support would
pull in that direction as well, and it was not the direction I thought
we should go.  I believed our overwhelming priority should be reducing
attack surface by discarding code.

See the project motto: "Perfection is achieved, not when there is
nothing more to add, but when there is nothing left to take away."
This choice was not just me being cute - I viewed it as a direct
implication of our security focus.

In accordance, I deliberately went to the opposite extreme - to be as
aggressive and strict in platform requirements as I thought I could
get away with, in order to throw away as much code as possible,
and then patch around the resulting porting issues.

So far this strategy has had exactly two real downsides:

1. We've had to simulate POSIX clock_gettime() for MAC OS X using a native call.

2. The libevent2 dependency blocks ntpdig on CentOS 6 and older NetBSDs as well.

If these are the worst problems we have as a result - and that looks likely
at this point - I'm going to claim a strategic victory.  We are, as far as I
know, good on all *current* LTSes.

Now here's the controversial part:

In truth, I was anticipating something like the libevent problem
(failure to insta-port to older releases) with an attitude almost like
hope.  That is, if we hadn't run into *anything* like it, I'd consider
that I hadn't pushed quite hard enough towards "nothing left to take
away".  While I would have lived with that outcome, I would have
considered it suboptimal.

In effect, I was hoping for a sort of optimal pain level, enough to signal
strong success at the clean-up-and-pare-down without seriously messing
up functionality.  I think we have that.

I'll admit to having been a little quiet and sneaky about that
success criterion; I didn't want the arguments I'd get if I made it
explicit.

Finally, I will observe that if this let-it-break-a-little stance seems
like a dicy or over-bold choice to have made, some reflection on why
Classic NTP stagnated may be in order.  Fear of breaking anything can
be a trap; among other reasons you want a system architect around is to
exercise judgment about when it's time to bust out, judgment that takes
into account the whole-life-cycle perspective. Including considerations
like reducing downstream maintainance costs, attack surface and
defect rates.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>