Amar Takhar <v...@darkbeer.org>:
> No idea but I do not favour the idea of removing features to avoid adding
> workarounds. That's worse than adding utmp support back in. I think it's a
> reasonable solution for
>
> If it was more than touching a single file and adding a couple of ifdefs it
> would be a strong argument but for this case it's better to add it back in.
Please note that this code was conditioned out at the time of the
fork, and is therefore probably still disabled in Classic. I had to
repair it before it would compile.
So we wouldn't be removing a feature, exactly, if we entirely dropped
it - just agreeing with whoever last touched it before me that it was
a failed experiment.
I would be OK with either (a) leaving it as is, with a tweak to not
try building it on OpenBSD, or (b) dropping it entirely. I would be
opposed to adding, or restoring, a non-POSIX workaround.
In general, I value reducing the codebase complexity more than maintaining
marginal and semi-broken features of this kind. I came very near just
quietly dropping this one, but my general policy is to save what POSIX
can save even if I'm dubious about its usefulness.
When Hal says:
>We could easily and cleanly bypass the code that uses utmpx. That would
>screwup accounting if time stepped by more than a second.
I'm not entirely clear on the referent of "that". The *bypass* would
screw up accounting if time stepped by more than a second?
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
