Slashdot Mirror
Linux Developers Consider On-Screen QR Codes For Kernel Panics
An anonymous reader writes "Linux kernel developers are currently evaluating the possibility of using QR codes to display kernel oops/panic messages. Right now a lot of text is dumped to the screen when a kernel oops occurs, most of which isn't easily archivable by normal Linux end-users. With QR codes as Linux oops messages, a smart-phone could capture the display and either report the error string or redirect them to an error page on Kernel.org. The idea of using QR codes within the Linux kernel is still being discussed by upstream developers."
Problem solved.
I'm not sure how hard it would be to pull this off in practice, but kudos to the team for improving (or at least thinking about) better usability from the kernel out.
http://shouldiuseaqrcode.com/
Just kidding, I think it's a good idea.
And if no one with a phone is there?
I worry about the long-term applicability of QR codes. In 10 years, are they still going to be convenient to read, or is some guy going to have to dig out an old smartphone to read the error output from his decade old system?
Great, now even the kernel depends on qr libraries. What do I use now? /sarcasm off
Who else remembers the heated discussions then systemd did this? But I forgot, if the kernel does it it is great, if systemd does it, it is bloat
It that this is a joke , what a strange idea !
QR codes are highly redundant and don't actually contain much data. There isn't enough space for a stack trace or anything like that. Probaby not even a register dump on those big modern CPUs.
http://michaelsmith.id.au
Inscrutable error messages seem to be par for the course when you're looking at kernel panics.
Just change the console font to a smaller one!! And take a photo with your phone. Or just run headless with a serial logger. Why add extra complexity to something that is really simple and already adequate? There is no problem to be solved.
Anything's an improvement over:
"My computer froze."
"What happened?"
"It put some message on the screen."
"What did it say?"
"Something about an error."
"What error?"
"I dunno. It had some numbers and letters and stuff."
"Win treats sysadmins better than users. Mac treats users better than sysadmins. Linux treats everyone like sysadmins."
Is there something stopping people from taking a picture of a current kernel dump?
This is a damn good idea!
Nothing much to say, posting as an AC, post will thus stay moderated to 0 and nobody will pay attention to this comment, but I just wanted to have a place to say that this is great!
Here, I feel better posting these few bytes for the foreseeable future.
I work at a small site ( 100 physical machines) used for heavy computation and simulation in a compute grid. They're all headless blades with lots of memory and disk and we connect though a networked application called IPMI either in Java or via web-based management interface on a special management port. There are no graphics or text screens connected to these systems.
So, how would such a code displayed? Would it be integrated into the IPMI console, which I understand is becoming a data center standard. We know there are memory or fan problems or if the machine has been opened when there's a logging event in the IPMI log, even down to the memory bank that had the error. Error logs in Fedora show nothing or say there's an error but not where.
This is a great idea for a desktop, but of little use in a datacenter unless it's integrated with the datacenter management architecture.
So, we're gonna replace the old school "Error 256" messages with bar codes? Doubleplus Insightful!!!!
Really? You think your end user who hasn't got the brains to take a screenshot of human readable text and send it to you and who probably has never even heard of QR codes is going to have the presence of mind and technical knowledge and ability to take a picture of the code and send it to you?
That has to be one of the dumbest things I've heard on slashdot...and that's REALLY saying something.
It's even more worrying that the Linux Kernel devs are giving this idea the time of day.
How about a slight modification of a classic: Just change the background color of the display. Even 1 byte RGB gives you 256 messages. (I guess lighting would affect this.)
The article was illustrated with an image of a screen of debugging code. The image was taken with a camera. If you can take a picture of a QR code, bout can take a picture of a dump of error code.
I am NOT buying a fucking cell phone to read a core dump.
Just fuck right off already. Not everyone wants a digital leash.
I do not fail; I succeed at finding out what does not work.
The point here is that in a kernel panic, there's no way to save a screen shot or copy-and-paste anything into a file - all you have is (probably) a full kernel dump and a message on the screen, which can be transcribed with errors, and Step 2 is rebooting.
it could wrong in some interesting ways. For example, it could transmit an infection from you desktop to your phone...
This is why my alternate OS eschews absolute minimalism and includes mandatory "userspace" features in its design, so it can rely on them being present. I handle the whole (multi) boot process within the OS, so I can launch other OSs from within a running instance. Boot process integration was necessary for firmware segmented loading (optionally put part of the OS in firmware, see: Coreboot). Since the OS handles boot itself it can avoid immediately crapping all over memory at boot and instead upon soft-boot the early-environment kernel detects whether the OS is resident in memory, whether the kernel halted properly in a "panic" or froze due to other lockup/powerloss, whether an unrecoverable error occurred, what the error message(s) are, walk the memory manager and move pertinent information out of the way into previously unused memory pages, then load the 2nd stage kernel into RAM with the debug option enabled (unless --no-debug is passed by its bootstrap loader's manual override). Finally the OS continues its boot process and its built in debugger launches, so I can read any detailed prior error messages left, save/print them, and attempt to debug the last thing the kernel or any of its programs was doing, or mark the prior memory free and return to standard operations. While there is no guarantee the RAM is still valid I can even attempt to restore program states and resume operation after a "panic" (if the bug was something small fixable via correcting a few erroneous bytes of memory).
Unlike Linux, my kernel includes many dedicated features of a full operating system, such as text editor, assembler, disassembler, compiler, file-system, debugger etc. so it is larger than Linux kernel itself in footprint. I can optionally remove some of these essential features if needed for my embedded projects, but I never have since memory isn't that expensive -- Being able to debug via serial console a glitched robot after reset is a godsend. Less modularity comes with its downsides, but the pros of being able to deploy programs as cross platform byte-code and have the OS "compile on install" programs into its private internal file system, and cryptographically sign the cached binaries to optionally secure the entire boot process and all running processes, far outweighs the cons. Being able to debug itself is just a side effect of other design decisions.
My "Toy" OS design has many similarities with classic OSs of old (bytecode instead of BASIC baked in), and seeks to address problems I foresaw with lack of hardware enforced sandboxing API in modern OSs: My kernel can run a program or its modules as emulated bytecode if the code is untrusted, or is loaded as a plugin. I use more than just the two userspace / kernelspace execution privilege levels in order to hardware-enforce something like a submodule level SEGFAULT to grant applications more control over their plugins or runtime scripts (also compiled as bytecode by the OS via scripting API).
4 execution privilege rings are available on x86, as opposed to 2 on ARM and thus some security features are not hardware enforced on ARM -- this is an instance of modern monolithic OS design influencing hardware design (everyone's using only 2, so ARM has 2 rings), much as C'ish calling constructs influenced x86 chipset instructions (ENTER, LEAVE, etc.) which BTW lead to inherently insecure practices such as placing mutable parameters and code pointers on the same stack (stack smashing / overrun is prevented via separate call and data stacks, kind of like good ol' FORTH used -- I'm only able to do so because all executable code is required to pass through the OS compiler / sanity checker).
I'm now seeing many of these features appear piecemeal in higher level constructs: E.g. Google's NACL bytecode for Chrome "apps", or .NET bytecode being able to go native, or Android's JIT and its native code interface, etc. I think future OSs would benefit from adopting better software deployment systems by incorporating a compiler / debugg
I prefer all my BSOD, crashes and core dumps to use the Matrix dripping green characters and pixel crap method of reporting errors. It's easier to see the patterns. Guru meditation # 42
I think it's a great idea to make error reporting easier. I recently experienced an oops but didn't report it because there was no immediate way to do it. However relying on a framebuffer being present is a mistake, in my case it was on an embedded headless system, and framebuffers generally are available only on desktops which are far from being the majority of Linux usage.
Can we please replace the word "panic". Panic is a feeling, felt by living creatures, not computer programs.
This is not a Disney movie. Computer code does not "panic".
Do you even know what a kernel panic is, or what is likely to cause one?
Il n'y a pas de Planet B.
They won't disappear, it's going to be optional and will be seamlessly available next to the text crash.
Cheers Levente Kurusa
The current model of kernel panics is broken.
Currently, we can diagnose a fault if: The user has access to the console (unlikely, machines are usually in data centres, though some of them manage to set up KVM properly) and can take a screen shot (more likely, nowadays, thanks to phone cameras) and the useful information (the backtrace) hasn't scrolled off.
This solution addresses the third part.It does nothing to address the first; and makes the second worse. (You really expect the QR code to be useful after it's been displayed on the crustiest monitor in a datacentre, captured at a weird angle on a phone and sent to us as a badly compressed jpeg?)
I understand the technical reasons why the crash cannot be written to disk - the kernel has crashed, disk drivers are in a bad state.
But can we please write to a reserved partition with a dedicated driver, or something? Or make netconsole a default?
Linux must be ubuntufied. We need to hide everything because it's way to complicated for the common user or his dog. We need more splash-screens to hide all the stuff that makes no sense anyway. Who want's to know if a module didn't get loaded? As a matter of fact, we should remove unnecessary logs (like message, dmesg, audit), because nobody gives a rats ass. Also: Why have a console? Or init-mode 3 ? People want the graphical stuff, let's get rid of all the ballast like command-line. Those few people still using ancient tools like 'make', 'vi' or (o my god) 'ifconfig' should go and find themselves something else to brag with. Linux MUST go mainstream.
Do you want to mail them physical screenshots? With a qr code, you can mail text.
when my smartphone (that I am supposed to capture the QR code with) is the device running linux and having the kernel panic :)
There are a number of advantages of doing this, non-technical people are likely to be familiar with QR-codes, most people have access to digital cameras and resources to convert the QR code to a link and using this works as long as the screen can be written to. Storage system failure or network system failures wouldn't be a hinder to provide a thorough failure analysis.
The sole disadvantage IMHO is that one have to have a QR encoder resident and functional at the time of a panic. Not a big problem.
Now they want to bury the kernel error messages in a QR code? That REALLY takes the cake.
This is not burying or hiding. It's there in full view if you have a decoder, and even better, you can send it to a mailing list without having to transcribe the sodding thing by hand. Bonus: no transcription errors!
Seems like a win to me especially as no one is ever planning on making it mandatory. It's a fantastic option if you don't have a convenient way to log a serial console.
I'm massively not a fan of exsessive complexity, but this atually sounds like a neat idea.
SJW n. One who posts facts.
Linux was beaten as the first by a long shot. Haiku has had this for 1 3/4 years.
If you gave me a choice between a printer and a giraffe with explosive diarrhoea, i'll get my ladder and my raincoat
A problem has been detected and Slashdot has shut down to prevent damage to your brain
The problem seems to be caused by the following user: ANONYMOUS COWARD If this is the first time you have seen this Stop error screen, refresh your browser. If this screen appears again, follow these steps:
Check to see if any new topics or comments are properly displayed. If this a new comment, ask Slashdot to filter Anonymous Coward comments you don't need.
If problems continue, disable or remove any newly-posted Anonymous Coward comments. Disable short-term memory options such as recall and storage. If you need to use Moderator points to remove or disable comments, press the drop-down menu below the comment, and then select -1 Troll.
Technical information:
*** STOP: 0x0000050 (0x616E6f6E,0x796D6F75,0x7320636F,0x77617264) ***
*** ANONYMOUS COWARD - Address 63726170 base at 706F7374 datestamp 35343134/code
If you gave me a choice between a printer and a giraffe with explosive diarrhoea, i'll get my ladder and my raincoat
Do you have panic attacks too, "PhRooT-LooP"? Lmao http://slashdot.org/comments.p...
Can kernel panic info also be saved to a disk log instead of just showing it on the screen? It could also be logged to a USB drive or something connected to the network or in the extreme case, CMOS space in BIOS.
Whatever the method, the log information should be easily accessible on reboot without the use of cameras/cell phones etc.
It says, `` ... most of which isn't easily archivable by normal Linux end-users. Abnormal Linux end-users easily archive the text. If you have to use QR codes ... maybe you aren't the right kind of Linux end-user. Just saying.
"Consensus" in science is _always_ a political construct.
http://peoplescanningqrcodes.tumblr.com/
I'd file this under the "Gee, mom, look what I can do" school of programming. It makes the assumption that every Linux user in the known universe has a smartphone and enough data minutes left in the month to play around with a QR code and a web page. I'm a great believer in the "KISS" principle: Keep It Simple! Your powerful computer just fell down and can't get up, so now you want to make it create and display a fancy bit of graphics? This sort of error is too important to rely on playing "stupid computer tricks"! What if it's a text-only server installation and there *is* no GUI available to display the QR? What if displaying the QR code *itself* causes an error? I'd hate to be using version 1 of *this* change! Besides, this sort of fancy error display belongs in User space, not the Kernel (IMHO). Simplifying the error message with ordinary, everyday language the user can actually write down with (gasp) pencil and paper is a much better approach than trying to impress people with how 1337 you are. /rant
"My country, right or wrong; if right, to be kept right; and if wrong, to be set right." --Senator Carl Schurz (1872)
Seriously, this looks like a solution in need of a problem - And worse, a "solution" that breaks a critical aspect of existing functionality, namely, "human readability".
Instead of making note of a few key points in the message, this will require taking a picture of the screen just so you can "automatically" Google the meaning of an unintelligible pattern of dots. WTF, guys, in what world do you consider that an improvement?
It also ignores the reality of Linux's dominant niche - Not as end-user desktops where poor widdle grandmas might get confused by all that technical information; but rather, as servers-on-the-cheap. And where do servers live? In the server room. I don't know about how your company does things, but many (including mine) don't allow cameras in the server room, and that includes cellphones. And I don't even work for any sort of especially high-security company.
If you really want to make panics more intelligible, just reduce them to the few items of useful information they actually contain - No stupid register dump, no stack trace, no list of a dozen maybe-related-but-almost-never-really modules. List the type of panic, the faulting module, and just the top of the call stack. That alone provides the level of detail most people can do something about - "Looks kinda like that new video driver blew up, better roll back and see if the problem goes away". Anything more than that only matters to kernel devs, and for that, we have debugging and verbosity command line options they can set.
TLDR: If, by default, a panic scrolls a 40x25 text screen, you've failed. Adding the requirement of a smartphone and internet connection only makes it worse.
Good idea, but I hope they keep all existing systems in place, and make it optional. Graphics drivers are massively complex, and are probably a significant source of oops. If displaying a QR code means that the kernel needs to interact more with the drivers, and (oh god i hope not) change the resolution to display a QR code, then I expect more fail. People can take photos of the crash messages in 80x25 character consoles anyway, so let's not destroy that.
I'm just waiting for Fedora to stop prompting fresh users to report bugs that require creating a freaking bugzilla account. Not all users are developers, you've already alienated most of them with gnome 3 and other simplifications, and the rest DO NOT CARE to follow the bug.
Man up and do it like a proper OS. Don't bother the user with inconsequential development housekeeping details. You wanna hear about problems, make it simple. I bet there are thousands of problems that form clear patterns yet aren't being reported because you're asking a novice OS user to do a developer's job. That ship has sailed long ago.
How is using using QR codes any improvement over such dusty techniques as unique error numbers, like "ABEND 07235453" - other than it doesn't require any discipline in registering error numbers?
Wouldn't integrating the frame buffer into kernel oops messages be one (small) step into the MS/Windows disease of integrating user land GUI primitives in the kernel?
This seems to be a solution for desktop (or laptop) Linux only - so it shouldn't be the default.
Most of the time when I'm dealing with Linux, it's either as a tablet (android), a server (used to run 150 headless servers, now I run only about 30), or as an embedded device from the low-end (an internet camera or a WiFi router running DD-WRT) to high-end (research lab equipment supported by a vendor.) My work desktop (Ubuntu) already hides as many error messages as possible, and I don't expect any Linux desktops in an office/workplace setting to reveal such messages - whether they're text, QR code, or cryptic IBM-like ABEND number.
Yes, it'll help Linux geeks report kernel oops messages to the kernel developers better (provided they can capture the image). But for most uses of Linux, it's unnecessary complication.
I run Linux on a server. No GUI. It has a problem. Now what?
There is NO GUI server to display the error.
Phrased differently, if the error logging ties the kernel to a specific UI model, it means that the kernel just jumped the shark
Yes, I do. http://i.imgur.com/zMyvT.jpg
I think having the option to scan the QR code with a simple message to do so is one more way to get the info needed.
Aiming a smartphone at the screen is easier than framing a screen with your phone's camera and hoping for a solid shot without a flash before it does something even stranger.
They're used on beer ads, chain pizza ads, breakfast cereal and at Disney parks.
So yes, I think the average end user has a shot at this.
I'm thinking of Windows in particular, that usually ends up with anywhere from one to a dozen lines of codes to reference.
Linked to a database, it has all the info you need.
It's pretty reliable stuff: http://datagenetics.com/blog/n...
Which is likely why people would rather scan QR codes than take pictures of every magazine ad they see.
"Win treats sysadmins better than users. Mac treats users better than sysadmins. Linux treats everyone like sysadmins."