111–120 of 314 posts
Probably related to[0]. To anybody complaining that this should be opt-in: opt-in telemetry doesn't work. The reason for this is that most people don't care, but they don't care either way. They don't disable it when prompted, nor would they enable it manually. The idea of telemetry is being able to prioritize the work that will be most widely useful. For this you need a good and balanced sample of your users. You do…
Probably related to[0]. To anybody complaining that this should be opt-in: opt-in telemetry doesn't work. The reason for this is that most people don't care, but they don't care either way. They don't disable it when prompted, nor would they enable it manually. The idea of telemetry is being able to prioritize the work that will be most widely useful. For this you need a good and balanced sample of your users. You do…
The argument for this being opt-in isn't about "it works better", it is about it being ethically correct. There are a ton of things that "don't work" unless you do something unethical: that doesn't mean they are OK, it doesn't mean they should be tolerated, and it doesn't mean the people who do them--and, at the end of the day, it is people who make these decisions: there is a human being who refused to say "no" and…
Earlier quoted context omitted.
This is naive, no one ever turn telemetry on if it's turned off by default, that's the reason why it's on by default.
Still, opt-out is just inacceptable. At least with a mechanism which can easily fail, like setting an environment variable. This basically forces you to wrap the go tool in a script which ensures the environment variable to be set. As this seem to cache the results, another option is to fiddle with the cache to report bogus information.
If there is any virtue to collecting telemetry, make it opt-in. Any developer convinced of this being useful will gladly enable it. But making it opt-out is just nefarious, because most users will not be aware of it.
This is naive, no one ever turn telemetry on if it's turned off by default, that's the reason why it's on by default.
If there is any virtue to collecting telemetry, make it opt-in. Any developer convinced of this being useful will gladly enable it. But making it opt-out is just nefarious, because most users will not be aware of it.
This is naive, no one ever turn telemetry on if it's turned off by default, that's the reason why it's on by default.
If nobody would voluntarily do it, why do you think it's okay to do it at all? By your very admission, nobody wants this. Because if they did, they'd turn it on!
Oh Google - never stop being you. Not only is it going to be opt-out (because of course it would be coming from Google), I really like the whole "wait a week before sending telemetry" part that just coincidentally has the benefit of sneaking right past people that actively look for suspicious network activity when they've freshly installed something. Am I being uncharitable?
Since you asked, yes you are being uncharitable. It's rather hard to imagine that the people who are details-oriented enough to look for suspicious network activity after installing something wouldn't notice the disclosure on the download page (edit: or the release notes). On the other hand, the explanation given by Russ for delaying a week (so people have ample time to opt-out) makes sense. Do you actually think Rus…
Regardless, there are plenty of ways to upgrade the Go tool chain (snaps, distro packages, fetching latest via curl, etc) that won't result in the changes being immediately visible. Given that, I think you are painting an overly optimistic picture of a world though where everyone that cares about this is going to be immediately aware that opt-out telemetry has been added vs a lot of installs being silently swept up into this by sheer ignorance.
Also, this is going to require me to go and set environment variables in about a dozen environments to disable the collection and while I can pretty easily manage that task via ansible I'm not happy about having to jump through hoops to turn off telemetry for a freaking compiler tool chain.
Earlier quoted context omitted.
The argument for this being opt-in isn't about "it works better", it is about it being ethically correct. There are a ton of things that "don't work" unless you do something unethical: that doesn't mean they are OK, it doesn't mean they should be tolerated, and it doesn't mean the people who do them--and, at the end of the day, it is people who make these decisions: there is a human being who refused to say "no" and…
What is the argument for opt-out telemetry being unethical?
So if you want that information, find a way to ask the user first. If you can give a good and understandable explanation on how the information is useful, the users might give their consent happily.
I am left with the impression that the decision has already been made, and that we are witnessing a PR strategy to make Google appear reasonable. I think that Mr. Cox, with all the respect I hold for him, is playing the part of the "useful idiot" here.
I'm usually against telemetry but not only is the approach here somewhat reasonable, I think I actually trust Google more than, say, homebrew to not do something egregious with the data. Google is at least as broadly compliant as one can be with various standards (of questionable value, natch) but is also on the hook socially and perhaps legally if they fuck this up.
Probably related to[0]. To anybody complaining that this should be opt-in: opt-in telemetry doesn't work. The reason for this is that most people don't care, but they don't care either way. They don't disable it when prompted, nor would they enable it manually. The idea of telemetry is being able to prioritize the work that will be most widely useful. For this you need a good and balanced sample of your users. You do…
That option is a joke. The real alternative is rust - or any non-corporate platform that isn't gonna pull these kind of stunts.