Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Will there be a compile-time option to disable telemetry.

Repositories for binary packages could compile their versions with telemetry disabled.

It's interesting how "tech" companies with billions in cash cannot afford to hire beta testers.

Perhaps the data is collected not only for the purpose of "improving the software". Perhaps the so-called "tech" company, which is actually the world's largest advertising company, wants to use it to make more money. Imagine that.

How would anyone verify that what this employee claims about how telemetry data will be used in the future. Google is a non-transparent company. It's business is advertising. Without that business, there's no money to pay this employee. We know what he wants to improve. His job security and his compensation.

A more truthful statement would be that the data is collected for the purpose of "improving Google's return on advertising". If it isn't, then from a business perspective there is no point in collecting it.



Telemetry enabled by default is not OK.

If want voluntary data from users, ask for it. When a "tech" company knows the answer would likely be "no" then they avoid asking for permission. Hence, "enabled by default". Most people do not change default settings.


This is not Go adding telemetry to binaries built with it. Is limited to the Go tooling only. It's good practice to read the announcement. Otherwise you end up making incorrect statements.


Nothing in GP's comment ever even suggests that the Go compiler would insert telemetry into binaries. It's good practice not to put words in people's mouths.


Perhaps, it may have been a bit of a stretch on my end, but not unfounded given ...

> Repositories for binary packages could compile their versions with telemetry disabled.

... the overall tone of the comment, and peer comments that seem to believe that this is the case. Only GP can confirm their belief to where telemetry would be implemented.

One does not have to "compile with telemetry disabled" but rather disable telemetry with an ENV VAR. It is the "compile" part which has me believe GP believes that this is embedding telemetry in binaries built with Go, which is not what is happening at all.


A runtime option for disabling telemetry has little value for build tools because any random build script can re-enable it without you knowing. Even more so if it's an environment variable for opting out, because it's so common for build scripts to clear environment variables for legitimate reasons.

Whether there's a compile time option to disable telemetry altogether is what many downstream packagers would probably be interested in.


> This is not Go adding telemetry to binaries built with it.

Oh, that sounds like a good idea. Lets do that next!

/s


Alternatively, we can remove the new telemetry code by hand before compiling the Go compiler.

Is it still possible to compile the latest Go compiler using the Go 1.14 compiler (C source). Documentation states it is possible but when I tried compiling Go 1.20 with Go 1.14 as the bootstrap I got a message asking for at least Go 1.17.


You'd have to maintain multiple projects to do this completely

- go tool

- gopls

- govulncheck

That's a lot of effort so you can avoid ~1 report per year?

> Based on the sample rates, the Go installation might send a report containing the counter values of interest. Typical sample rates would be around 2% (averaging ~1 report per installation per year), but very rare events could be sampled at a higher rate, up to the 10% limit. As more systems take part in transparent telemetry, the overall sample rate on any given system will decrease, because only a fixed number of samples is necessary.

Have you read what they are proposing?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: