Hacker News Reader

Comment by an_d_rew | Hacker News Reader

> This, IMO, is the perfect way to do telemetry.

I understand @notRobot's sentiment, but do not agree with it.

If the default is "no telemetry", then very little telemetry will be collected.

This is an advantage to the user, but a strong DISadvantage to the collective, because the distro manager now cannot make informed decisions as to what packages are installed where and how often.

It really is a balance of "individuals vs the collective" and I don't think that answering both needs is simple, nor is it cut-and-dried.

View on HN

Why would a collective like Debian or Ubuntu need to know what packages are the most installed? I know Ubuntu has their own App Store, is it perhaps to show which apps are the most popular?

If it’s for caching, can they not see which packages are most frequently accessed over http and implement caching that way? Or is that against their privacy policy? I’m not very knowledgeable on this subject but would love to know more!

It helps deciding on priority (bug fixes) or whether a package is worth maintaining or keeping in the distribution even if it costs time or prevent some (library) upgrades, improvements or refactorings that would break it.

As a software writer, it motivates me to know that my software is used and that putting effort in maintaining it will help people. For instance, I made a small Firefox extension that requires regular updates by design. Seeing that it was installed on a hundred browsers has motivated me to maintain it. If it was just for me, I probably wouldn't have bothered so much even though this extension scratched a personal itch.

As a user, I am a bit reluctant to being tracked so a balance must be found.

Edit: the amount of downloads from the archives is not enough. Some packages are downloaded again and again by automated systems like continuous integration systems and a downloaded package can be uninstalled immediately and this would be imperfectly detected.

Perhaps when making the choice you could tell the user their problems will get more priority if they opt in.

Also using differential privacy you can gather statistics on package use while limiting knowledge about a specific user.

They used to put the most popular 650mb of packages on a CD.

Do you really need samples from that many users? Wouldn't a sampling of a few thousand users give you more or less the same results as a sampling from a few million? And if not, is it worth the bad will you're earning from your users by treating them like this?

For websites and online businesses yes you need as much data as possible. For free software I agree, I don't see a use case

A random sample – sure, if you have enough traffic to still get decent sample size, but a sample obtained by users opting in is often close to worthless because it's not random and so not representative of your userbase.

I don't think people who opt-in for such a telemetry is as equally distributed as totally random people who didn't opt-out.

The average users that you want to target don't really change those settings.

We really need a DoNotTrack-like standard for application telemetry so that sysadmins and the privacy conscious can just set some environment variable like NO_TELEMETRY to a nonempty string and not worry about it. Packages would still have to be audited and shamed for not respecting NO_TELEMETRY but thats no worse an obstacle that has faced homedirs.

Developers can get that sweet sweet telemetry by default and those that care can just set a var in ~/.profile and be done with it.

>We really need a DoNotTrack-like

Ahh...that thing that is mostly ignored because its based on goodwill?

"Mostly ignored" is [DIVIDE BY ZERO TRAP] times better than "does not exist." Would you prefer nothing at all?

That's an interesting environment variable... Wonder if laws like GDPR would get that deep enough to have effect on command line users too.

But the maintainer can still make decisions based on the telemetry which is available. It's not unreasonable to assume that the the smaller sample of uses will still be a representative sample.

Yes it is. The average user will change very few default settings, so people who opt in will have fundamentally different usage patterns because they fiddle with stuff.

Opt-out telemetry does not create informed decisions, it creates decisions based on the subset of people who don't care or don't know enough to opt out, and I have seen real instances it adds a dangerous overconfidence to the applicability of the decisions made from that data. And it's important to note that little telemetry is often enough to do a decent amount of statistical analysis–in fact, one of the first things you'd learn in a course is that you don't really need to collect data from everyone, and most sample sizes don't go above 10% of the population unless you're doing some kind of census.

"A little telemetry is often enough" -- Assuming a representative sample, right? If only a few opt in, they might climb above 10% but may not represent the population distribution.

(I'm agreeing with your first statement, but questioning your second one.)

Yes, just saying that in general if it is possible to have a representative sample (which I argue is not a thing even when you are doing opt-out, and would be willing to content is probably even less representative).

Is it such an advantage?

> Canonical’s Michael Hudson Doyle says “…the package and backend have both been broken since 18.04 LTS without being much missed.”

Reply on news.ycombinator.com