Technical strategy and performance

[Eric S. Raymond]

Jason Azze <jason at azze.org>:
> > The thing about these users is they're intensely conservative.  They
> > won't buy a time service implementation that doesn't reassure them by
> > looking and smelling like what they're used to.
> 
> This is why I try to make noise when things are broken on RHEL/CentOS
> 6.x. I don't see a builder for that OS on buildbot.ntpsec.org. The Red
> Hat Enterprise family (RHEL, CentOS, Scientific Linux, Oracle
> Enterprise Linux) and SuSE Linux Enterprise Server are where we
> boring, conservative sysadmins like to live. There are a lot of us who
> haven't moved off of RHEL 6 (supported through 2020) for critical
> infrastructure because RHEL 7 went systemd on us.

OK, then this is a good time to ponder the big question: from your P.O.V.
are we doing enough to support 6.X?  If not, what needs to be fixed?
I agree this is important and am sure Mark will too.

> Perhaps there should be a separate discussion about supported
> platforms: Where does the project claim the software will compile and
> where does it claim the software will run (and are those two lists
> different)?

Can't see why they ought to be.

Here's what the INSTALL file has to say:

This software should build on any operating system conformant to
POSIX.1-2001 and ISO/IEC 9899:1999 (C99).  In addition, the
operating system must have either a Linux-like adjtimex(2) call
or a BSD-like pair of ntp_gettime(2)/ntp_adjtime(2) calls.

There are some prerequisites.  Libraries need the library installed
to run and in addition, the development headers installed to build.

Python 2.x, x >= 5
bison
libevent 2.x
libcap
OpenSSL
GNU readline
BSD libedit
sys/timepps.h
asciidoc, a2x

We also claim Mac OS X.

Hmmmm. Daniel, shouldn't that OpenSSL be replaced by libsodium?  Please
write up an entry on that.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>