OPW Linux kernel intern develops QR code for Oops messages(linux.com)
linux.com
OPW Linux kernel intern develops QR code for Oops messages
http://www.linux.com/news/featured-blogs/200-libby-clark/773488-opw-intern-develops-qr-code-for-linux-kernel-oops-messages
9 comments
This could be one of the few remotely practical uses of QR codes in existence, easily capturing ephemeral data. Now, most kernel messages can get logged to a file, but there are cases in which that's not practical.
This is pretty cool.
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):
https://gnome.org/opw/
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):
https://gnome.org/opw/
True! She was an OPW intern for the Linux kernel. See more on Kernel Newbies: http://kernelnewbies.org/OPWIntro
The latest round of kernel internships (through OPW :) just started.
The latest round of kernel internships (through OPW :) just started.
This looks like a neat program :) I look forward to seeing more cool stuff come out of it!
Welcome to the club :)
https://www.haiku-os.org/blog/mmlr/2012-07-01_qr_encode_your...
The write up leaves a lot to be desired. Using QR codes to display kernel oops messages was proposed and demonstrated back in June 2012.[^1] Matt Garret even mentions this in the lkml thread[^2] that the article links to, but for some reason the author did not bother to look into mjg's response. So I am not sure "welcome to the club" is accurate since the kernel has been a member (to the extent that this patch is evidence of membership) of the club since June 2012.
[^1]: https://lwn.net/Articles/503677/
[^2]: https://lkml.org/lkml/2014/3/18/673
[^1]: https://lwn.net/Articles/503677/
[^2]: https://lkml.org/lkml/2014/3/18/673
Awesome ! Two points I'd like to make:
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.
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.
> 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 ...)
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.
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.
Linux is the only modern OS I've used that doesn't have the capability to send crash reports back to the developers
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.
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.
It's also better on account of being accessible to a wider audience. I'd wager far more users know what a QR code is than abrt, kdump etc. If there's just a cursory error message and a QR code with dump nearly everyone can submit helpful bug reports.
> Linux is the only modern OS I've used that doesn't have the capability to send crash reports back to the developers
I think Ubuntu has something - https://errors.ubuntu.com/
I think Ubuntu has something - https://errors.ubuntu.com/
Rubbish in point b. I've scratched plenty of itches working on proprietary software that did not come from product management.
Agreed, the open source ideology as explained by esr says a bunch of things that are demonstrably not true, suggesting that proprietary software is an inferior way to develop software or that proprietary software just will have more bugs because fewer people can read its source code (yo, heartbleed!)
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.
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.
Ok, so the thing where heartbleed 'disproves' the many eyes theory has really got to stop, especially when used like a mallet as it is here. Many eyes has diminishing returns, but that doesn't mean that it isn't effective to a point. Bugs of similar scope have existed in proprietary software as long or longer, and have often even been deliberately placed as backdoors.
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.
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.
The way esr created the open source movement, he made it sound as if open source was a superior way to ensure fewer bugs in software. This is not demonstrably not true: proprietary software developers are not incompetent, and just because you have visible source does not mean anyone is going to read it, or indeed, that you will get more people reading it than if you have a paid team of developers reading it. There are many, many proprietary packages that are far less buggy than free alternatives [citation needed].
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.
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.
I haven't read esr, but I disagree with your categorical statement that "producing better software" is hard to justify. (In other words, I agree with your first paragraph's statement that open source's superiority is not demonstrably not true.)
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.
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 always figured that meant "given a difficult bug, a group of developers working on it will make it easier to solve." Not "with enough developers, all the bugs in this software will disappear."
Heartbleed? You mean, the bug that was discovered because the source was available to unaffiliated third-parties?
It is not clear how the bug was discovered. If it was because someone was reading the source code, it still took a long time for someone to read that part of the source code, so I don't think someone was backlogged with code reviews by two years.
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.
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.
I think it's perfectly clear. In the end of January, Google releases a design draft detailing how they are switching Chrome from NSS to OpenSSL[1]. Two months later, some Google employees announce they have found a major bug. I don't have any inside knowledge, but I think the causality chain is obvious - they did a security review of the code as part of the switch and found it.
[1] https://docs.google.com/document/d/1ML11ZyyMpnAr6clIAwWrXD53...
[1] https://docs.google.com/document/d/1ML11ZyyMpnAr6clIAwWrXD53...
I've worked on quite a few enterprise systems that took screen-caps on their own for error reports. As long as you test the hell out of the bootstrapping code that does all of that handling, it's a great way to take the user out of the loop.
This is true, but it can't apply to the kernel. If your kernel has crashed, it is a terrible idea to try to write anything at all (such as a screenshot) to the disk -- because the kernel's safety guarantees disappear in such a situation, you're likely to make a bad situation worse and e.g. corrupt the filesystem.
video ram, efi variables, nvram. All those should still be accessible.
What happened to storing the oops in EFI variables? You can store much more data there than you can convey through QR codes displayed on the limited screen space.
Ugh another hateful mobile phone thing being introduced just because it's new and therefore better.
What next? Removing the kernel and replacing it by web service calls to a mobile phone "app".
Keep this rubbish out of my kernel please.
Keep this rubbish out of my kernel please.
Wicked cool. I may steal, er, adopt this for our work!
[deleted]
Good idea!