OPW Linux kernel intern develops QR code for Oops messages
linux.com
linux.com
This title as posted on HN (not in the article) is silly, though. The Linux kernel does not have "interns", this person is an intern for GNOME's OPW (Outreach Program for Women):
The latest round of kernel internships (through OPW :) just started.
a. This idea, of using QR code to capture debug info, by itself is very interesting and innovative (AFAIK). Does there exist user space applications (desktop/web/mobile ...) that do similar things ? (ie: don't send us the logs, just click a pic and attach it to your support ticket ...). I personally haven't come across any, but of course my knowledge is limited. In any case, I think this sort of log capturing for debug purposes certainly should've be done more, IMHO.
b. Something like this could have never come out of proprietary software, simply because this is someone developer's specific itch that needed to be scratched. Whenever they say that open source software cannot compete with proprietary software, because proper 'product management' doesn't exist which guides feature development or that proprietary software will do the 'hard' things that aren't interesting/fun or just too much effort, I always argue against that. This sort of thing makes such arguments easier.
Although the development model seems to more or less work for Linux because all of the corporate backing it has, despite being free, there are a lot of adages that esr started that sound like broken promises to me.
Not to say that many eyes has been proven either, but you're going to need something a lot more solid than heartbleed to assert that it's demonstrably untrue that proprietary software has more bugs because fewer people read it.
TCATB just promises but doesn't deliver. There are reasons to value free software, but practical reasons as "a better development model" or that it produces better software are hard to justify.
In my experience, if you look at the big ticket projects, there are many proprietary packages that are less buggy than free alternatives, and many which are more buggy, and it mostly depends on the project's development process and history. For example, OpenSSL and gdb are very buggy mainly because they're terrible code, while Linux and OpenBSD are in general fairly stable because their development processes are good and in turn have made the code good. gcc and Clang beat MSVC++, Chrome beats Internet Explorer, because Microsoft doesn't care enough; Photoshop handily beats GIMP because it's Photoshop. And so on.
But in my humble opinion, if you average over _all_ the software... including a lot of little projects that seem to end up with higher quality code, if only because the author was too embarrassed to release low quality code, and perhaps with the help of a few bug reports on GitHub... including medium-size projects which someone else took over maintainership over after the original quit, which would be impossible with proprietary software... including lots of low-quality proprietary NIH code where the default open source solution would be to use some already well-tested external code... open source wins by a significant margin. I am not sure this is inevitable or even correct, as proprietary software certainly has significant advantages, but I do not think it is reasonable to say it is demonstrably false.
I think it is far more likely that someone first realised they were getting extra data and then went to read the source code to see why this was happening. I think it's safe to speculate that most bugs are discovered by inspecting the behaviour of the software, not by reading the source code.
Of course, once the bug is found, having the source code makes it much easier to patch it, but it's amazing what people can do to patch bugs even without source code.
[1] https://docs.google.com/document/d/1ML11ZyyMpnAr6clIAwWrXD53...
If you're going to go to the trouble of adding extra code to handle that behaviour, why not just add functionality to the app to report its own crashes, error log excerpts, etc.? This is likely the reason you haven't come across it: it makes less sense than just providing the option to submit the crash reports directly. Less work for the user, less support overhead for the developer, etc.
> Something like this could have never come out of proprietary software, simply because this is someone developer's specific itch that needed to be scratched
I'll point out that most other OSes have a way of capturing crash reports, stack traces, memory dumps, etc. and sending them or storing them for debugging. Linux is the only modern OS I've used that doesn't have the capability to send crash reports back to the developers, which is why the QR code trick is necessary in the first place, and the QR code functionality is worse in all cases except where your storage system is completely inaccessible/irreparably damaged.
Red Hat's abrt does that: https://github.com/abrt/abrt/
Using kdump, it can also report kernel panics. Kdump acts as a kernel that is executed after the main kernel panics. The fresh kernel has a clean state and can store the dump in a file system.
the QR code functionality is worse in all cases except where your storage system is completely inaccessible/irreparably damaged
It's worse because it's not an automatic process. It's also better, because it doesn't require external dependencies like abrt and kdump -- it's part of the kernel.
I think Ubuntu has something - https://errors.ubuntu.com/
Keep this rubbish out of my kernel please.