> On Nov 11, 2014, at 2:43 PM, Karl Rupp <r...@iue.tuwien.ac.at> wrote: > > Hi, > >> There is a difference between a library and an end-user application. >> Having "updaters" for end-user applications seems to be the >> status quo >> on Windows and to a lesser extent on Macs, but is resented on Linux. >> Having a library do these checks is not okay anywhere. >> >> >> I remember a session at the Google Summer of Code where some guy >> from one of the open source wikis shared his experiences with having >> embedded a 'counter pixel' in a release. In short, his lesson >> learned was that any kind of "phoning home" is an absolute no-go >> unless made *very* clear to the users (plus opt-out). This was >> pre-Snowden, so many people are now much more sensible with respect >> to these matters... >> >> >> I am all for a configure opt-out, and noting it in every piece of >> documentation. My impression of the level >> of sophistication of most users is that we will see few opt-outs. > > I bet that some Germans would still be very upset about an opt-out rather > than an opt-in (yes, this is a cultural issue...). > > Is there much value from a nagupgrade check at configure-time? Those who > download a fresh copy of PETSc don't have any benefit from the check. After > the installation, the check has no effect
Karl, I don't understand? Is there a bug in the current code? If the user has write access to the $PETSC_DIR directory it will print a nag at most once every 24 hours. Otherwise it will print a nag every time they do a make with the PETSc makefiles. Is it not working for you? Barry > (Matt, I remember your fieldsplit slides where you say that students only > install at the beginning of your PhD, then work entirely with options). For > those who configure frequently, a regular update is part of the work flow > anyway. So, who really benefits from nagupgrade? > > Best regards, > Karli >