51–60 of 88 posts
Here's an idea for how to maintain Go moving forward: keep making the damn tool however you want. The thing never would have existed in the first place if they had started with an industry survey. It was created to address a perceived need, by the people with the need, for themselves. This model is perfectly fine moving forward. Some industrial user wants a new Go feature or bugfix? Great. If it's enough of a problem…
> For every kilobyte of Go code available on GitHub, GitLab, and other Git forges, there are unknowable megabytes of private Go code that will never see the light of day (or maybe they will if LAPSUS$ decides to make that company a target). > Without knowing what ports of Go are used, the Go team can’t make sure that the right time is spent on maintaining those ports. Am I being overly pragmatic if not selfish for th…
i.e. there are 10s-100s of millions publicly available LoC, but we really need to see your private workflow without your consent.
Here's an idea for how to maintain Go moving forward: keep making the damn tool however you want. The thing never would have existed in the first place if they had started with an industry survey. It was created to address a perceived need, by the people with the need, for themselves. This model is perfectly fine moving forward. Some industrial user wants a new Go feature or bugfix? Great. If it's enough of a problem…
just for the sake of argument, wouldn't telemetry be useful to know which of these issues are most likely to benefit the majority of users?
whether that's worth the cost of telemetry is another issue.
I think that the author has kind of a Stockholm syndrome. "Users are liars, so let's spy them directly to know what we want to know". It is mind blowing how, as an user/the target, you can support that. Nothing is really anonymous and your anonymous data can say a lot about you. Telemetry coming from this IP, so company x is using go. A pattern of data coming every 2 days, so their build nodes rebuild every 2 days. T…
> Telemetry coming from this IP, so company x is using go. A pattern of data coming every 2 days, so their build nodes rebuild every 2 days.
Not true. Even if Google lied about collecting IPs, the data would be sent only every ~ year with aggregated counts so no real time usage data. And even if one could see the patterns from the data, everyone will be able to, not just Google.
Let's not trust Google. But let's not shoot ourselves in the foot by refusing any automated cooperation.
Additionally, majority of distros use package managers, so if any of the major promises of the upstream would be broken, distro packages could patch it out. This isn't forced, there are several points where anyone can stop the telemetry.
> The problem of scrying into the unknowable People really need to accept that they can't and shouldn't have full introspection into everything they're ever interested in. Even if it's a thing they care about (like their own homepage or programming language). Sure it's nice to get feedback. Sure it's nice to know that somebody uses it. But putting a tracker on everything with the argument of "will help me provide a b…
The new owners of Audacity did this and then gaslit the community about it for weeks, despite constant, almost unanimous backlash.
After that, they resolved to only add "Don't Send"/"Send" crash reporting and opt-out update checking, which only sends the OS version, Audacity version, and IP address. (They claim to immediately anonymize the IP address.) The user is notified about the update checking at first startup.
Which part of this do you consider "doing this and gaslighting the community about it"?
Here's an idea for how to maintain Go moving forward: keep making the damn tool however you want. The thing never would have existed in the first place if they had started with an industry survey. It was created to address a perceived need, by the people with the need, for themselves. This model is perfectly fine moving forward. Some industrial user wants a new Go feature or bugfix? Great. If it's enough of a problem…
Inbefore I go to a new job and find out that they are using outdated, custom patched go compiler.
> I mean, there are 5000+ issues and 330 open PRs on the go github right now
How do they know which ones are affecting the most users?
> forced google spyware in a compiler
go is open source, feel free to compile it yourself without the telemetry. Which distros will do if any major promises would be broken
Respecting the users wishes isn’t a mistake. For sure it may have a few digits less of accuracy in some dashboards but who cares. The consensus was that opt-in was the best solution, and thankfully Google went with the best solution.
They should simply allow for people to pick their default at installation. (so at download) Even better if the go tool were to have a `go update` with a `telemetry-off` flag or something. (and possibly a prompt to remind people otherwise they will complain again) Problem solved.
`telemetry-on` flag. Sending data to third parties should _never_ be implicit or the default. Every PM, marketer, and mid-level manager needs to be firmly reminded that this is grossly invasive, user-hostile, impolite, and creepy. Without an explicit agreement, it could even run afoul of wiretapping laws (unresolved in courts, as far as I’m aware).
Earlier quoted context omitted.
In that scenario, not going opt-out is not a mistake. But going opt-in probably is a mistake, because the data will be useless, so it’s a waste of time to implement.
For those conscious of the security implications of that code even existing it all comes down to whether you trust Google, I would argue at this point you definitely shouldn't. Given that if you program in Go now and have code you really wouldn't just give Google then you probably need to run all your go executions in a VM without network access. This alone is going to be ardious enough from a security point of view…
Not true. The code is open source and everyone can trivially with minimal effort check that they are sending only the data they said they would send.
Here's an idea for how to maintain Go moving forward: keep making the damn tool however you want. The thing never would have existed in the first place if they had started with an industry survey. It was created to address a perceived need, by the people with the need, for themselves. This model is perfectly fine moving forward. Some industrial user wants a new Go feature or bugfix? Great. If it's enough of a problem…
They did stop. "Go 1" is complete.
Since 2017, the project renewed itself by moving to what is dubbed "Go 2"[1], being built around community feedback. Decisions are made based on data collected from the community. Adding telemetry to increase the amount of data available is in line with the new project scope. Go 1.13 was the first "Go 2" release[2].
Indeed, "Go 1" is still there if you want to use the tool that was built for what was needed at Google and nothing more. You don't have to move into the "Go 2" ecosystem. But if others want to put their time into that, why not? That's their prerogative.