<div dir="ltr"><p style="font-size:12.8px">Removing the support is a big mistake. </p><p style="font-size:12.8px"><span style="font-size:12.8px">The ability for Windows to run Linux binaries is only for Windows 10 and hasn't shipped yet. According to this article, it is also an optional feature.</span><br></p><p dir="ltr" style="font-size:12.8px"><a href="http://www.zdnet.com/article/ubuntu-and-bash-arrive-on-windows-10/" target="_blank">http://www.zdnet.com/article/ubuntu-and-bash-arrive-on-windows-10/</a></p><p style="font-size:12.8px">That means that 100% of Windows systems in existence with a released version of Windows do NOT have this feature.</p><p dir="ltr" style="font-size:12.8px">Removing windows support as it is now kills Windows as a target. I don't think that is what the project really wants to do. </p><p dir="ltr" style="font-size:12.8px">--joel</p></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, May 14, 2016 at 10:42 AM, Joel Sherrill <span dir="ltr"><<a href="mailto:joel.sherrill@gmail.com" target="_blank">joel.sherrill@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><p dir="ltr"><br>
On May 14, 2016 10:06 AM, "Mark Atwood" <<a href="mailto:fallenpegasus@gmail.com" target="_blank">fallenpegasus@gmail.com</a>> wrote:<br>
><br>
> Thanks for the update.<br>
><br>
> Simplifying those bad spots is more important than keeping code we don't know works in an OS that nobody can recommend as a good time server.<br>
><br>
> Remove it. Carefully. Try not to cackle maniacally too much while you do.</p>
</span><p dir="ltr">The ability for Windows to run Linux binaries is only for Windows 10 and hasn't shipped yet. According to this article, it is also an optional feature.</p>
<p dir="ltr"><a href="http://www.zdnet.com/article/ubuntu-and-bash-arrive-on-windows-10/" target="_blank">http://www.zdnet.com/article/ubuntu-and-bash-arrive-on-windows-10/</a></p>
<p dir="ltr">Removing windows support as it is now kills Windows as a target.</p><span class="HOEnZb"><font color="#888888">
<p dir="ltr">--joel</p>
</font></span><p dir="ltr"><span class="">> ..m<br>
><br>
><br>
> On Sat, May 14, 2016, 4:26 AM Eric S. Raymond <<a href="mailto:esr@thyrsus.com" target="_blank">esr@thyrsus.com</a>> wrote:<br>
>><br>
>> Mark Atwood <<a href="mailto:fallenpegasus@gmail.com" target="_blank">fallenpegasus@gmail.com</a>>:<br>
>> > it sounds like there is no cruft getting in the way of complexity<br>
>> > headaround or reduction.  leave it be.<br>
>><br>
>> Unfortunately, your premise is not correct; Hal's report was<br>
>> incomplete.  There are substantial amounts of Windows cruft in some of<br>
>> the trickiest places outside the port directories, notably the<br>
>> worker-thread code for async DNS lookup and the network-plumbing<br>
>> hairball.<br>
>><br>
>> The reason I am pushing on this now is that I'm still casting around<br>
>> for ways to simplify the hairball to the point where I can really<br>
>> grasp it. Complexity headaround is the exact issue.<br>
>><br>
>> Removing the Windows cruft won't completely solve the problem, but any<br>
>> complexity reductions we can get are good.  Enough of them might get us<br>
>> to where my head doesn't hurt when I look at that code.<br>
>> --<br>
>>                 <a href="<a href="http://www.catb.org/~esr/" target="_blank">http://www.catb.org/~esr/</a>">Eric S. Raymond</a><br>
><br>
><br></span><span class="">
> _______________________________________________<br>
> devel mailing list<br>
> <a href="mailto:devel@ntpsec.org" target="_blank">devel@ntpsec.org</a><br>
> <a href="http://lists.ntpsec.org/mailman/listinfo/devel" target="_blank">http://lists.ntpsec.org/mailman/listinfo/devel</a><br>
</span></p>
</blockquote></div><br></div>