3 ms·

The Go team at Google would run a collection server. Each week, with 10% probability (averaging ~5 times per year) the user’s Go installation would download a “

by chaps 4y ago

The Go team at Google would run a collection server. Each week, with 10% probability (averaging ~5 times per year) the user’s Go installation would download a “collection configuration” to find out which counter values are of interest to the server and at what sample rate. If there's interest to use config files to determine how telemetry is done, why can't similar be done about turning telemetry off? I don't want to deal with environment variables (for a gazillion reasons) and would prefer to just use a config file. Especially when it comes to sending arbitrary information from my system to another arbitrary host. It's so strange to me that the configuration of telemetry has been escalated to uses-configs status while opting out hasn't. Really feels like opting out is an after thought.

rsc 4y ago
As designed, the system allows an opt-out _either_ by setting GOTELEMETRY=off in your environment or by running 'go env -w GOTELEMETRY=off' which writes a config file. (Specifically the one reported by 'go env GOENV'.) If you prefer to edit the config file directly, you are of course welcome to do that.
- chaps 4y ago
  That's fair, but doesn't take away from the deeply, deeply exhausting need to do this sort of niche configuration thing for everything out there, let alone even recognizing that it's needed. Never mind the unduly need to read changelogs and blog posts to make sure things haven't changed since I last used things. Have you considered using a more-generic opt-out environment variable that's not go specific? For example "USER_PREF_NO_TELEMETRY=true" would have the same effect, or would ensure that GOTELEMETRY=off is set. I have no idea if anything like that exists right now in other projects, but if it's not, then go is large enough and embedded across enough systems that it could be a good place to start.
- simoncion 4y ago
  Sure, and have to remember to do that every single time you mint a new Docker image for use in CI, every single time you spin up a new Cloud workstation, every single time you get a new physical workstation, every single time you have to run a job in a brand new environment, every single time you... etc, etc, etc. Thing that work inside the Googleplex often don't work for the rest of us. Not every company is a multi-billion-dollar behemoth that can afford to spend hundreds of millions of dollars annually to work exclusively on internal developer-tooling.

by chaps 4y ago

rsc 4y ago

As designed, the system allows an opt-out _either_ by setting GOTELEMETRY=off in your environment or by running 'go env -w GOTELEMETRY=off' which writes a config file. (Specifically the one reported by 'go env GOENV'.) If you prefer to edit the config file directly, you are of course welcome to do that.

chaps 4y ago
That's fair, but doesn't take away from the deeply, deeply exhausting need to do this sort of niche configuration thing for everything out there, let alone even recognizing that it's needed. Never mind the unduly need to read changelogs and blog posts to make sure things haven't changed since I last used things. Have you considered using a more-generic opt-out environment variable that's not go specific? For example "USER_PREF_NO_TELEMETRY=true" would have the same effect, or would ensure that GOTELEMETRY=off is set. I have no idea if anything like that exists right now in other projects, but if it's not, then go is large enough and embedded across enough systems that it could be a good place to start.
simoncion 4y ago
Sure, and have to remember to do that every single time you mint a new Docker image for use in CI, every single time you spin up a new Cloud workstation, every single time you get a new physical workstation, every single time you have to run a job in a brand new environment, every single time you... etc, etc, etc. Thing that work inside the Googleplex often don't work for the rest of us. Not every company is a multi-billion-dollar behemoth that can afford to spend hundreds of millions of dollars annually to work exclusively on internal developer-tooling.