Also, why would you trust them more with collecting your IP than google?
Because Google has repeatedly demonstrated that it doesn’t deserve my trust. To Google, the data collected about me is a goldmine, not a liability. Users of a free Google property are the commodity in which Google trades. The customers are the people selling ads. It’s old well-explored territory.
I also fail to see how an IP address would be a useful metric for Audacity. Maybe knowing whether it is IPv6 or IPv4 could be useful, but that’s about it.
Audacity deserves some kudos for making it opt-in and being open about what they’re doing. I can’t really find fault here. Good on them for being transparent and opt-in.
I also fail to see how an IP address would be a useful metric for Audacity
This also strikes me as odd. If they want to really track for people that are using it for a longer time it fails the moment you use mobile data or get the daily connection reset from your ISP. If they just want to see when the same user does something in a span of 1-2 hours it might work. But that’s already very detailed. And a typical CG NAT will prevent any identification. Though maybe that’s fine for them if they want crash reports and some hardware statistics.
I’m irritated that I lost my post, too; I felt that even though there was a raging flamewar on GitHub, our conversation here was respectful and well-informed. At the same time, moderation is difficult and we have few moderators; it’s not reasonable to expect perfection on a shoestring budget.
The original question that Audacity’s developers wanted to answer with telemetry had nearly nothing to do with telemetry, and I think that that disconnection needs to be addressed, since this post brings up the same question. How do we make our applications crash less? Once we realize that this is the question that we care about, then it becomes somewhat obvious that there will be crashes which aren’t reported because the crash is too severe or obscure for the crash-reporting framework to recover, and that survivorship bias and Goodhart’s Law will combine to create a false image of the crashiness of the application.
The (non-ironic) frustration is that application developers are ultimately writing crash-prone software because of their programming environments and choices of programming languages and tools, rather than because of how users are using the software. This is most obvious when giving a compiler to somebody else; the behaviors of user programs must be preserved by the compiler author, through the compiler, without being able to hand-examine every future crashing input given by users.
I don’t think that it’s a problem to require application authors to have access to the platforms which they claim to support and test; I think that application authors should dogfood those features. When I wrote GPU drivers, I was unable to support GPU families for which I didn’t own at least one representative, and there were many quirky “embedded” laptop-only or game-console-only flavors of GPUs which were hard to support because we could only diagnose problems at an extreme distance.
This is my first post but losing the nice conversion I’ve had with others when the original submission got deleted was a reason for me to finally start blogging stuff like this. I would appreciate feedback.
The original post got probably deleted because it linked directly to the issue and thus fueled the flame-war even more. Sadly we’ve had some interesting comments in that thread (and 0 arguments), so I’m a bit on the fence for this one.
Yeah, I absolutely understand why pushcx did it. I just wish there was more…. granular options for dealing with cases where OP is hellthread bait but comments are (at least temporarily) fine. A lock (like old-school phpBB) and/or burying the thread off the main page might make an interesting alternative.
Because Google has repeatedly demonstrated that it doesn’t deserve my trust. To Google, the data collected about me is a goldmine, not a liability. Users of a free Google property are the commodity in which Google trades. The customers are the people selling ads. It’s old well-explored territory.
I also fail to see how an IP address would be a useful metric for Audacity. Maybe knowing whether it is IPv6 or IPv4 could be useful, but that’s about it.
Audacity deserves some kudos for making it opt-in and being open about what they’re doing. I can’t really find fault here. Good on them for being transparent and opt-in.
This also strikes me as odd. If they want to really track for people that are using it for a longer time it fails the moment you use mobile data or get the daily connection reset from your ISP. If they just want to see when the same user does something in a span of 1-2 hours it might work. But that’s already very detailed. And a typical CG NAT will prevent any identification. Though maybe that’s fine for them if they want crash reports and some hardware statistics.
I’m irritated that I lost my post, too; I felt that even though there was a raging flamewar on GitHub, our conversation here was respectful and well-informed. At the same time, moderation is difficult and we have few moderators; it’s not reasonable to expect perfection on a shoestring budget.
The original question that Audacity’s developers wanted to answer with telemetry had nearly nothing to do with telemetry, and I think that that disconnection needs to be addressed, since this post brings up the same question. How do we make our applications crash less? Once we realize that this is the question that we care about, then it becomes somewhat obvious that there will be crashes which aren’t reported because the crash is too severe or obscure for the crash-reporting framework to recover, and that survivorship bias and Goodhart’s Law will combine to create a false image of the crashiness of the application.
The (non-ironic) frustration is that application developers are ultimately writing crash-prone software because of their programming environments and choices of programming languages and tools, rather than because of how users are using the software. This is most obvious when giving a compiler to somebody else; the behaviors of user programs must be preserved by the compiler author, through the compiler, without being able to hand-examine every future crashing input given by users.
I don’t think that it’s a problem to require application authors to have access to the platforms which they claim to support and test; I think that application authors should dogfood those features. When I wrote GPU drivers, I was unable to support GPU families for which I didn’t own at least one representative, and there were many quirky “embedded” laptop-only or game-console-only flavors of GPUs which were hard to support because we could only diagnose problems at an extreme distance.
This is my first post but losing the nice conversion I’ve had with others when the original submission got deleted was a reason for me to finally start blogging stuff like this. I would appreciate feedback.
Whoa, I hadn’t noticed the previous story was deleted! Or that stories could be deleted here.
Mod operations (including submission deletions) are logged here
https://lobste.rs/moderations?moderator=%28All%29&what%5Bstories%5D=stories
The original post got probably deleted because it linked directly to the issue and thus fueled the flame-war even more. Sadly we’ve had some interesting comments in that thread (and 0 arguments), so I’m a bit on the fence for this one.
Yeah, I absolutely understand why pushcx did it. I just wish there was more…. granular options for dealing with cases where OP is hellthread bait but comments are (at least temporarily) fine. A lock (like old-school phpBB) and/or burying the thread off the main page might make an interesting alternative.
I’ve thought about this too. Maybe removing the link (but keeping the title so people could netsearch it) would be an alternative.
Audacity seems to have dropped the idea of telemetry
https://github.com/audacity/audacity/discussions/889
yeah I submitted it as I see this relevant and anti-pitchfork enough to spread it
Alternative, detailed viewpoint here: https://github.com/SndChaser/AudacityTelemetryComments/blob/main/DataCollectionVsTelemetry.md