3 ms·
>Emacs does not. vim does not. OpenSSH does not. Python does not. ffmpeg does not. And yet, Fedora [0], Ubuntu [1], and KDE [2] do. So what you're saying doesn
by zxzax 5y ago
>Emacs does not. vim does not. OpenSSH does not. Python does not. ffmpeg does not.
And yet, Fedora [0], Ubuntu [1], and KDE [2] do. So what you're saying doesn't paint a full picture: even if upstream of those projects you mentioned doesn't take the automated bug reports, there is likely some downstream that is using them to aggregate crash data and turn those into bug reports. It is not feasible, on a large scale, to manually comb through crash dumps and ask people to figure out how to use gdb. Open source projects don't have any special sauce here.
Also, it seems very strange to complain about companies collecting data that they're required to collect by law. "Forking" there is a fool's errand, any other company legally doing business in the same areas will be following the same laws.
[0]: https://developer.fedoraproject.org/tools/abrt/about.html https://developer.fedoraproject.org/tools/abrt/about.html
[1]: https://wiki.ubuntu.com/Apport https://wiki.ubuntu.com/Apport
[2]: https://community.kde.org/Telemetry_Use https://community.kde.org/Telemetry_Use
- geofft 5y ago> Also, it seems very strange to complain about companies collecting data that they're required to collect by law. Thanks for clearly phrasing this, because I think this is exactly what I'm complaining about. Audacity is, in fact, not required to collect anything by law, and for a very long time, it did not. It's a piece of software that runs on your computer. It doesn't even require you to have a network connection. It doesn't require the developers to even know that you exist. No law (in any slightly free country, at least) prevents the existence of software that doesn't phone home. WordStar wasn't illegal. Emacs and Python and ffmpeg aren't illegal. It is true that once you start collecting data, legal requirements start to apply, and you need to comply with requests for that data. That's a really good reason not to collect it in the first place. If all you have is a stack trace, and you have nothing personally identifying (including filenames), then the data you have is useless for any other purpose besides fixing the bug. You're protected from legal requests, you're protected from illegal requests, you're less of a target of hacks, and so forth. Fedora's ABRT, for instance, goes out of its way to ensure that any crash data they collect is suitable to make public: https://abrt.readthedocs.io/en/latest/ureport.html#ureport https://abrt.readthedocs.io/en/latest/ureport.html#ureport That's a pretty good way of squaring this circle. If the data is okay to make public, then by definition it's not a problem if anyone (law enforcement or otherwise) wants to see it, and you don't have to rely on their good intentions. Ubuntu disables Apport by default in release versions, according to the page you link: https://wiki.ubuntu.com/Apport#Why_is_apport_disabled_by_default.3F https://wiki.ubuntu.com/Apport#Why_is_apport_disabled_by_def... KDE doesn't claim to collect information about crash dumps; it just collects statistics about how it's used. It is, of course, harder to debug things from just a list of symbols. And as you say, it's not feasible to teach everyone how to use gdb. So there's a tradeoff. You acknowledge that the software isn't going to be as good as possible in terms of bug-free-ness (or you find other ways to address that problem, like fuzzing or static analysis), but in exchange, you make the software better in terms of how it treats the user's privacy.
- DominoTree 5y agoI think the question is about automatically reporting bugs versus giving the user tools to report bugs in a consistent manner if they choose to. Fedora's tool does not automatically report the bugs - it just automates the process of allowing the users to do so if they choose, and handles generating stack traces locally or remotely (configurable) and dealing with core dumps and submitting them if so chosen (again configurable), and tries to tie crashes to existing bug reports if you choose to submit the data to prevent devs from being flooded. It even has some pretty great functionality to help make sure no private/sensitive data leaks in the report, and lets you go through things line-by-line that based on a default or custom list of keywords that may indicate sensitive data (such as passwd, key, etc.) before you finally choose to submit it. And it's all done on a case-by-case basis, so for each crash you can choose whether to submit any data or not, in case you're running one app that you'd be concerned about leaking sensitive data versus another.
- asddubs 5y agoKDE does ask you every time, and then usually tells you there's not enough info and doesn't actually submit it (at least that's been my experience)