<div dir="ltr">Kill it</div><br><div class="gmail_quote"><div dir="ltr">On Sun, Jan 29, 2017 at 9:05 PM Eric S. Raymond <<a href="mailto:esr@thyrsus.com">esr@thyrsus.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Mark Atwood <<a href="mailto:fallenpegasus@gmail.com" class="gmail_msg" target="_blank">fallenpegasus@gmail.com</a>>:<br class="gmail_msg">
> Is there a reason to keep dumbclock?   Maybe it exists as a starting<br class="gmail_msg">
> framework for when someone wants to write a new clockdriver?<br class="gmail_msg">
<br class="gmail_msg">
Actually, I only left dumbclock in because you said "keep it for the lulz"<br class="gmail_msg">
during the conversation about some other refclock that we ended up dropping.<br class="gmail_msg">
<br class="gmail_msg">
You've put your finger on the only even weakly persuasive argument for<br class="gmail_msg">
keeping it.  But:<br class="gmail_msg">
<br class="gmail_msg">
1. If we want a simple model for an old-school refclock, a couple<br class="gmail_msg">
others are handy.  The most obvious is refclock_local.c; zyfer and<br class="gmail_msg">
spectracom would also be good. In fact the spectracom driver (under<br class="gmail_msg">
its old WWVB or "Type 4" name) historically *was* the model for several<br class="gmail_msg">
other drivers - it's often cited in header comments.<br class="gmail_msg">
<br class="gmail_msg">
2. If it were up to me, nobody would ever write an old-school refclock<br class="gmail_msg">
again.  Makes more sense to write a parse template for the generic<br class="gmail_msg">
driver.  You get more code re-use that way.<br class="gmail_msg">
<br class="gmail_msg">
So no, I don't see remaininh value in keeping it.<br class="gmail_msg">
--<br class="gmail_msg">
                <a href="<a href="http://www.catb.org/~esr/" rel="noreferrer" class="gmail_msg" target="_blank">http://www.catb.org/~esr/</a>">Eric S. Raymond</a><br class="gmail_msg">
</blockquote></div>