On Tue, Nov 11, 2014 at 2:32 PM, Aron Ahmadia <a...@ahmadia.net> wrote:
> FWIW, I'm introducing a patch in the PETSc distribution in HashStack to > disable this check from the Makefiles. I see the value of this being an > opt-in check the user can run: `make info; make self-update`, but not an > automated check unless the user opts-in at configure. That's the > responsibility of the system/package manager, not a library. > I believe asking for the check to be opt-in is the same as asking for removal. Anyone who would opt-in is knowledgable enough to update. The check does not target those users. I don't actually care whether we keep this check. However, I do think the arguments advanced so far do not amount to more than prejudice. I don't think a security argument holds water for a system that downloads tarballs from other sites without any kind of check. Matt > > A > > On Tue, Nov 11, 2014 at 11:21 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... >> >> Best regards, >> Karli >> >> > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener
