Technical strategy and performance
Eric S. Raymond
esr at thyrsus.com
Thu Jun 30 12:31:27 UTC 2016
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
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
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>
More information about the devel