4 ms·

Crash reporting is only needed if you write software that crashes in the first place. Do you think the SQLite developers have ever felt like they need automate

by geofft 5y ago

Crash reporting is only needed if you write software that crashes in the first place. Do you think the SQLite developers have ever felt like they need automated crash reporting from their users? (see https://corecursive.com/066-sqlite-with-richard-hipp/ https://corecursive.com/066-sqlite-with-richard-hipp/ , which got discussed recently: https://news.ycombinator.com/item?id=27718701 https://news.ycombinator.com/item?id=27718701 ) And SQLite accepts way richer input (SQL queries) from users than Audacity does (audio files). There are many ways to reduce bugs. Extensive coverage-guided testing, like SQLite does, is one. Automated fuzzing is another. Writing in languages with strong type systems that let you statically verify the program's behavior is another. Collecting crash reports is another, and it's certainly one valid way, but it's not the only way. It's pretty clear that Audacity's users, in aggregate, aren't that concerned about needing crashes fixed - or at least are less concerned about it than about their privacy. Maybe Audacity already is sufficiently bug-free for their needs! While I also think that the "telemetry" argument is overblown, and I think automated updates are basically table stakes, and I wholeheartedly agree with you re JS and Electron, I think it's entirely reasonable for users to say that they don't find automated crash reporting valuable, and I don't think that it's particularly reasonable for developers to say "We know better than you."

zxzax 5y ago
I completely disagree with your assessment, Audacity just crashed twice for me yesterday. Also, with SQLite, it seems the major people reporting bugs are people who have paid support contracts with drh, which most likely requires sending identifying information.
orf 5y ago
I’ve found several bugs in SQLite, one of them pretty fundamental and obvious. It’s a complete nightmare to report them, forcing you to use some utterly terrible forum software with limited searching, visibility and a shockingly poor UI. Genuinely the worst and most confusing thing I’ve had to use in the last decade. Sourceforge issue trackers are a step up from this. They also offer no convenient way to test your system using the latest RC/beta/alpha/whatever without manually staying on-top of the releases page and updating it. I don’t think the rest of the comment warrants much discussion, but I wanted to point that out.
- petre 5y ago
  > forcing you to use some utterly terrible forum software with limited searching, visibility and a shockingly poor UI You mean Fossil? We use it, it works great for us, doesn't get in the way, doesn't require constant rtfm. Also you could just clone the repo if you want to test. It exports to git.
- geofft 5y ago
  Are those crashing bugs, though? I'm making a very specific and nuanced claim here - that crash reporting is not a required mechanism for delivering high-quality software. If SQLite is low-quality software, but the manner in which it is low-quality does not involve crashes, then that does not contradict my claim. There are a lot of ways software can have bugs other than crashes: incorrect behavior, confusing defaults, missing features, inaccurate or nonexistent documentation, poor API design, etc. Automated crash reporting can't help with any of that. If you discovered that "SELECT * FROM users WHERE paid = 1" returns unpaid users too, that's a really bad bug, but no automated crash reporter could possibly tell the SQLite developers about it. I do agree with you that users of software at scale don't report bugs and so you can't rely on them reporting bugs; I'm just pointing out that there's no reasonable way around it except for crashes, and there are other ways to address the specific use case of crashes. There is an unreasonable way around it: add an analytics framework that tracks every click and mouse movement and keystroke your users do. There are web analytics libraries that do exactly this and let you replay your users' behavior. I hope we all agree that Audacity should not do that. (By the way, if I go to https://sqlite.org https://sqlite.org , there's a "Support" link at the top that tells me to use their forum. You can then click on the forum link, click "New Thread," and click "Remain Anonymous," and there's apparently a way to post things. I guess this forum does actually use Fossil internally according to the message at the bottom, but it seems really straightforward to me, so I am surprised at your claim that this is confusing....)

by geofft 5y ago

zxzax 5y ago

I completely disagree with your assessment, Audacity just crashed twice for me yesterday. Also, with SQLite, it seems the major people reporting bugs are people who have paid support contracts with drh, which most likely requires sending identifying information.

orf 5y ago

I’ve found several bugs in SQLite, one of them pretty fundamental and obvious. It’s a complete nightmare to report them, forcing you to use some utterly terrible forum software with limited searching, visibility and a shockingly poor UI. Genuinely the worst and most confusing thing I’ve had to use in the last decade. Sourceforge issue trackers are a step up from this. They also offer no convenient way to test your system using the latest RC/beta/alpha/whatever without manually staying on-top of the releases page and updating it. I don’t think the rest of the comment warrants much discussion, but I wanted to point that out.

petre 5y ago
> forcing you to use some utterly terrible forum software with limited searching, visibility and a shockingly poor UI You mean Fossil? We use it, it works great for us, doesn't get in the way, doesn't require constant rtfm. Also you could just clone the repo if you want to test. It exports to git.
geofft 5y ago
Are those crashing bugs, though? I'm making a very specific and nuanced claim here - that crash reporting is not a required mechanism for delivering high-quality software. If SQLite is low-quality software, but the manner in which it is low-quality does not involve crashes, then that does not contradict my claim. There are a lot of ways software can have bugs other than crashes: incorrect behavior, confusing defaults, missing features, inaccurate or nonexistent documentation, poor API design, etc. Automated crash reporting can't help with any of that. If you discovered that "SELECT * FROM users WHERE paid = 1" returns unpaid users too, that's a really bad bug, but no automated crash reporter could possibly tell the SQLite developers about it. I do agree with you that users of software at scale don't report bugs and so you can't rely on them reporting bugs; I'm just pointing out that there's no reasonable way around it except for crashes, and there are other ways to address the specific use case of crashes. There is an unreasonable way around it: add an analytics framework that tracks every click and mouse movement and keystroke your users do. There are web analytics libraries that do exactly this and let you replay your users' behavior. I hope we all agree that Audacity should not do that. (By the way, if I go to https://sqlite.org https://sqlite.org , there's a "Support" link at the top that tells me to use their forum. You can then click on the forum link, click "New Thread," and click "Remain Anonymous," and there's apparently a way to post things. I guess this forum does actually use Fossil internally according to the message at the bottom, but it seems really straightforward to me, so I am surprised at your claim that this is confusing....)