<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Nov 11, 2014 at 1:20 PM, Sean Farley <span dir="ltr"><<a href="mailto:sean.michael.farley@gmail.com" target="_blank">sean.michael.farley@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=""><br>
Matthew Knepley writes:<br>
<br>
> On Tue, Nov 11, 2014 at 3:55 AM, Jed Brown <<a href="mailto:jed@jedbrown.org">jed@jedbrown.org</a>> wrote:<br>
><br>
>> KAUST (or KSA?) internet can be flaky at times and my "make" was<br>
>> (silently) hanging indefinitely while trying to connect to <a href="http://mcs.anl.gov" target="_blank">mcs.anl.gov</a>.<br>
>> Manually touching .nagged allows my build to proceed.  The hang could be<br>
>> fixed by adding a reasonable timeout, but I can't find a timeout in<br>
>> urllib.  Aron suggests that I try curl because all built-in Python url<br>
>> libraries are terrible, but I don't think we can depend on curl being<br>
>> installed, so we'd have to fall back to something.  We could implement a<br>
>> timeout using threads, if threads weren't broken on some architectures.<br>
>><br>
>> Meanwhile, the professor next to me runs Little Snitch on his Mac and<br>
>> wants to know why PETSc's build is trying to connect to Argonne's<br>
>> servers.  His first thought was that it was a there for surveillance.<br>
>><br>
><br>
> I find it hard to believe he is a science professor with that kind of<br>
> inference<br>
> from the data (you can see it retrieves a webpage). Maybe climate ;)<br>
><br>
><br>
>> PETSc has a significant number of users that work behind firewalls or<br>
>> are otherwise sensitive to outgoing connections.  Although nagupgrade<br>
>> helps people stay updated and reduces some support email, I think it is<br>
>> unprofessional and a failure mode that I'd rather avoid.<br>
>><br>
><br>
> urllib2 has the timeout argument, so we should switch. I am not sure I see<br>
> retrieving a webpage as unprofessional. Is there a better way to update<br>
> information, or do we want a model that is completely dead once downloaded?<br>
> I think people now assume that this is not true.<br>
<br>
</span>Speaking from my experience as being a package maintainer, all of 0<br>
packages do this 'phone home' in MacPorts. That's a sample size of<br>
almost 20,000 packages.<br></blockquote><div><br></div><div>If we count by usage rather than number of packages, then I believe this behavior</div><div>is the norm (Flash, Windows, OSX).</div><div><br></div><div>  Thanks</div><div><br></div><div>     Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
One of the first things we package managers would do in this case would<br>
be to remove this "feature," since, as Jed mentions, there are many<br>
valid reasons to not have a connection to <a href="http://mcs.anl.gov" target="_blank">mcs.anl.gov</a> (privacy<br>
concerns?). It is most definitely unrealistic to have this kind of<br>
behavior in production.<br>
<br>
In general, I would love PETSc to "fall in line" more with a package<br>
manager layout but that's a different thread :-)<br>
<br>
Just my two cents, of course.<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div>
</div></div>