Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Linux Developers Consider On-Screen QR Codes For Kernel Panics

timothy posted about 6 months ago | from the take-a-picture-it'll-last-longer dept.

Bug 175

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."

cancel ×

175 comments

Sorry! There are no comments related to the filter you selected.

Dump kernel to serial printer (0)

Anonymous Coward | about 6 months ago | (#46672887)

Problem solved.

Re:Dump kernel to serial printer (0)

Anonymous Coward | about 6 months ago | (#46672923)

If there weren't the small problem of modern x86 mainboards rarely shipping with a serial port...

(There are USB, not USB-serial based, debugging cards available, but in a price range not compatible with personal budgets.)

Re:Dump kernel to serial printer (1)

Hsien-Ko (1090623) | about 6 months ago | (#46673087)

Ironically most older x86 motherboards (pre-1994) didn't have an onboard serial port either.

Re:Dump kernel to serial printer (1)

Anonymous Coward | about 6 months ago | (#46673411)

But back in the days ISA based parallel and serial cards were commonly used and low level enough (using the well known IRQ/ DMA/ memory addresses) to just work and stand in as system console. Today's PCI or USB serial adaptor cards are overpriced (rare) and just that, not the 'real thing' but higher level adaptors, leaving several of the old fashioned protocols unsupported and mostly not being able to be used as ttyS0 (or COM1) as it's neither supported by the low-level drivers nor takes I/O 0x3f8 and irq 4.

Re:Dump kernel to serial printer (3, Funny)

smitty_one_each (243267) | about 6 months ago | (#46673051)

You gonna need a big bowl to catch all them corn flakes, mister.

Re:Dump kernel to serial printer (1)

Anonymous Coward | about 6 months ago | (#46673115)

Or just display a short number code. Displaying a QR code won't solve anything, it will just obfuscate the error and leave the user without any easily memorable reference. This sounds more to me like "let's do it because it's modern and hip" rather than it being actually useful.

Re:Dump kernel to serial printer (1)

Anonymous Coward | about 6 months ago | (#46673167)

Nothing is stopping you from displaying a short summary of the error and a code number in addition to the QR code. Depending on how much information gets jammed into the QR code though, it can be a lot harder to dump that all to the screw and expect a person to remember (or even write it down correctly).

Re:Dump kernel to serial printer (2, Funny)

Anonymous Coward | about 6 months ago | (#46673453)

No! We cannot do both! It must be either one or the other!

Re:Dump kernel to serial printer (0)

Anonymous Coward | about 5 months ago | (#46674093)

Yes you can .. if you have an appointment! (see Annoying Train Passenger, The 1948 Show)

Seriously, both is better. Just because everyone at your office has a smartphone that can process QR does not mean every admin plant wide has a smartphone. This is like web designers who are still 'learning' will say "but it works just fine on my screen and my browser".

Re:Dump kernel to serial printer (1)

khellendros1984 (792761) | about 6 months ago | (#46673201)

Or do both. Short number code, some diagnostic data on the screen, and a QR code linking to more info. The QR doesn't have to be much more than a couple square cm in a corner of the screen.

Re:Dump kernel to serial printer (1)

polymeris (902231) | about 6 months ago | (#46673857)

There is only so much information you can store in a couple square cm, if you want it to be able to be reliably retrieved by a camera, qr code or not. Your comment. [google.com]

Re:Dump kernel to serial printer (0)

Anonymous Coward | about 5 months ago | (#46674135)

With a fundamental limit of the number of pixels on screen, and that being dependant on screen size so you don't want to assume too high.

Re:Dump kernel to serial printer (1)

rogoshen1 (2922505) | about 5 months ago | (#46674283)

subset of linux users with access to only one device vs the subset of linux users who would troubleshoot a machine via cell phone.... ?

Re:Dump kernel to serial printer (2)

icebike (68054) | about 5 months ago | (#46674289)

Or just display a short number code. Displaying a QR code won't solve anything, it will just obfuscate the error and leave the user without any easily memorable reference. This sounds more to me like "let's do it because it's modern and hip" rather than it being actually useful.

The QR code can not only indicate the exact location of the error, but can take you to a website on the phone, with a url long enough to log
  many key points about the error.

Even if it logs very little, developers will get more input this way than they do now, because when your machine is crashed, you can't report anything and once it reboots, you have other priorities than digging in the last crash dump.

However, other than collecting statistics, it might not do any good. Even when you do submit a dump, you get the request to install debug symbol packages and trigger the crash again. Ah, no, that isn't going to happen. Or there will be necessary drivers installed that taint the kernel, and devs wont touch it until replace your video card, untaint your kernel, and trigger another dump.

Re:Dump kernel to serial printer (1)

TheRaven64 (641858) | about 5 months ago | (#46674441)

Is the point to give the users something useful? I assumed it was to give the devs something to debug. Asking the user to transcribe a kernel stack trace is not likely to happen, but a QR code that encodes a bit of text saying 'please email to crash@linux.org' followed by the stack trace would mean that you'd actually get something vaguely useful in some cases, rather than the user just shrugging and power cycling the box.

Re:Dump kernel to serial printer (3, Funny)

flyingfsck (986395) | about 5 months ago | (#46674249)

Bah. Punch cards are so much better. You young, know nothing, whipper snappers with your newfangled hoosammawhatsits...

Good idea (5, Insightful)

Primate Pete (2773471) | about 6 months ago | (#46672895)

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.

Re:Good idea (2, Insightful)

Anonymous Coward | about 6 months ago | (#46672941)

how soon until someone accidentally posts a QR code containing confidential information, since they cannot read it themselves.

Re:Good idea (4, Insightful)

Kjella (173770) | about 6 months ago | (#46672999)

Very unlikely.. the information in a QR code is probably just enough to say "I run kernel X (build Y) and it crashed with error code Z at instruction 12345 in module 123", if it was a kernel dump that's different but I have seen these without the QR codes and there's nothing sensitive there.

Re:Good idea (3, Informative)

Zocalo (252965) | about 6 months ago | (#46673081)

It might actually be more than that. Worst case, the screen in in 80x25 text mode (assuming a PC), which gives 2,000 binary bits, but if you start playing around with extended ASCII graphics characters you could probably encode a KB of data quite easily. Hardly a crash dump, but easily enough to get across the essentials.

Re:Good idea (1)

davester666 (731373) | about 6 months ago | (#46673701)

You are confusing what is encoded in a QR code and what is displayed textually onscreen.

Re:Good idea (0)

Anonymous Coward | about 6 months ago | (#46673773)

Any data can be encoded in a QR code provided it fits in the image area. It is more data dense than text (assuming 8x8 font), even if you stretch each pixel to twice its dimensions for better camera compatibility. Stretching each pixel to 3x3 puts it roughly on par with text (if 7 bit character encoding were used), but you have the advantage of automated conversion from image with QR scaner. In graphics mode it is a solid win, no way around it, **assuming you were going to capture an image anyway**. If you were just trying to read it from the screen, there is an obvious issue with that.

In text mode it is less data dense than text, but it's not that common to run like that anymore.

Re:Good idea (2, Interesting)

Anonymous Coward | about 6 months ago | (#46673787)

You just have to reprogram the VGA font table with 2 wide by 4 high bitmaps (because you can fit 256 such glyphs into the standard vga font table), and you now have 16000 pixels to work with instead of 2000, a bitmap display with a 160x100 pixel resolution; VGA text mode is 640x400 pixels, and each virtual pixel is 4x4 screen pixels, the standard VGA font is 8x16 pixels.

BTW, you can't encode 2000 bits into a QR code with a 2000 bit bitmap, as it has parity and spatial clock recovery built in to the code.

Since the system has crashed, there is no harm in replacing the vga font table, and it is so universal that you can do it on all hardware with VGA (the font table is always at a fixed memory address in PC architecture) without any interaction with device drivers.

Of course you can also put the VGA into a standard graphics mode with no knowledge of the previous graphics card state, simply by programming known io ports with known values, this actually seems altogether more reliable than relying on the Linux framebuffer drivers which don't always work when X11 drivers are using the hardware, but could be considered reliable if KMS is used.

Re:Good idea (2, Insightful)

rnturn (11092) | about 6 months ago | (#46673937)

``Hardly a crash dump, but easily enough to get across the essentials.''

Here's a crazy idea: instead of working on displaying cutesy graphics images that need to be decoded using a smart phone and a web site, what about actually generating a freakin' crash dump? Is there a technical reason that Linux is unable to do this? If crash dumps are really not possible, how about a plain 'ol text file in the root directory containing the reason for the crash/panic?

Re:Good idea (1)

Anonymous Coward | about 5 months ago | (#46674089)

Why would adding a QR code preclude generating a crash dump like usual? If you have a crash dump and can use it, the QR code won't change anything. If the after the crash a disk is not accessable, then you now have a format that is easier to "copy-paste" in effect by using a smart phone, or if you don't have one, tediously writing down any other text information on the screwn.

Re:Good idea (1)

Anonymous Coward | about 5 months ago | (#46674147)

Crash dumps are possible and exist already, there's just not enough real estate on a monitor to view the entire dump

Plain text files aren't necessarily possible as the crash means everything is suspect and any writing to the disk a) might fail or b) might cause data loss by corrupting the filesystem

Re:Good idea (1)

jones_supa (887896) | about 5 months ago | (#46674575)

Plain text files aren't necessarily possible as the crash means everything is suspect and any writing to the disk a) might fail or b) might cause data loss by corrupting the filesystem

How does Windows do it [microsoft.com] then?

Re:Good idea (1)

thegarbz (1787294) | about 5 months ago | (#46674195)

Just from my own experience the only kernel panic I've ever encountered was due to a failed SATA controller. But conceivably bugs in new beta file systems (you jumped on the brtfs bandwagon yet?), hardddisk failure, SATA failure, or failure in the PCI controller.

Mind you that's not a reason not to do it, just that there are times when it's not useful. The same machine with the dead SATA controller also had Windows on it which managed to bluescreen without creating a crash dump.

Re:Good idea (0)

Anonymous Coward | about 5 months ago | (#46674503)

If you are able to write to the file system, the same error dump is stored to the system logs.

This is for cases when writing to a file system isn't possible, when writing to the network isn't possible, etc..

Re:Good idea (0)

Anonymous Coward | about 5 months ago | (#46674373)

I am glad they aren't attempting to use ascii art.

Re:Good idea (0)

jones_supa (887896) | about 5 months ago | (#46674587)

I'm not so sure about that. :) At least at some point the PARISC architecture has printed an ASCII cow [wikipedia.org] , complete with a speech bubble that says "Your System ate a SPARC! Gah!".

Open source software, always giving the professional appearance...

Re:Good idea (1)

Guspaz (556486) | about 6 months ago | (#46673153)

They're encoding the kernel oops. Here's one example oops they're using in that thread:

http://levex.fedorapeople.org/... [fedorapeople.org]

Re:Good idea (5, Informative)

Levex (3606037) | about 5 months ago | (#46674261)

We are encoding the full Oops, i.e. from the "cut here" to the "end trace" marker. Classic won't ever go away, and we had already created a configuration option called CONFIG_QR_OOPS that can disable this at all. In case your distro or you had compiled it in and you don't want to have QR codes on your screen, I just added a new kernel parameter currently called 'qr_oops', which can as well disable it.

Re:Good idea (1)

icebike (68054) | about 5 months ago | (#46674311)

how soon until someone accidentally posts a QR code containing confidential information, since they cannot read it themselves.

Since the crash handler itself generates the code that takes your phone's browser directly to the report site, this isn't going to be a problem.

Have you never actually uses a qr code the leads to a web site?

Re:Good idea (1)

TFlan91 (2615727) | about 6 months ago | (#46673731)

you're assuming everyone has a smartphone. this idea is completely cutting off non-smartphone users

Re:Good idea (2)

Primate Pete (2773471) | about 5 months ago | (#46674041)

No, it's adding smartphone users. I presume the basic panic information would continue to be available.

No. (0)

Anonymous Coward | about 6 months ago | (#46672897)

http://shouldiuseaqrcode.com/

Just kidding, I think it's a good idea.

Huh? (2, Insightful)

Anonymous Coward | about 6 months ago | (#46672925)

And if no one with a phone is there?

Re:Huh? (5, Interesting)

ledow (319597) | about 6 months ago | (#46672973)

You lose nothing.

Anything that could have been logged to disk will have been.

Anything that couldn't is probably FAR TOO LONG to even start taking down any other way and almost certainly will cut through the screen buffer limit anyway (every kernel panic I've had - which is about a dozen I think - was like that).

Let's compare and contrast to, say, Windows. Bluescreen with minidump and error code that has 7 million potential causes.

At least with a QR code, for those totally undumpable errors, you stand half a chance of snapping it and providing several kiloybytes of useful information for someone to work from - that they know hasn't been transcribed wrongly. And can be taken from even a completely hung machine.

It's a good idea. Someone needs to make a patch for it. The biggest problem - as always - will be making sure you can get to the point that you can write to the video memory and do so with enough processing / storage to be able to write something useful into the QR code.

Re:Huh? (0)

Anonymous Coward | about 6 months ago | (#46673033)

What is the size limit of a QRcode? Doesn't increasing the density of information contained in the image lead to the possibility of corrupt/missing data due to poor camera quality, motion blur, over/under exposure, or something along those lines?

I'm not a big fan of QR codes, but I can see this being useful. That is, if it doesn't turn out to be more trouble than it is worth.

Re:Huh? (2)

ledow (319597) | about 6 months ago | (#46673203)

Just over a kilobyte, I think.

But that can be compressed as it doesn't NEED to be human-readable any more. So you can easily fit in a few Kb of useful data, I should think.

And as data density rises, so does the error correction but if the QR code reads (you have a device that reads them directly, why bother to snap a shot then process the image separately?) then it was a success. Hover and hold until you get the beep, on almost any smartphone made this decade.

But, no, you won't get CORRUPT data. The QR code either works or doesn't, like barcodes either scan or don't. You don't scan a book and get sold a DVD. Same principle.

What you might have is trouble getting a decent QR read on a crappy low-res camera but that's - again - no worse than the prior situation where I've seen kernel-panic screenshots you can't even read, let alone decode.

Re:Huh? (0)

Anonymous Coward | about 5 months ago | (#46674159)

There's no limit in the QR code itself, just increase its dimensions. The only limit is how good the reader (camera) is. And since you want it to be readable you want to be conservative when guessing how good 'good' is.

Re:Huh? (4, Informative)

Guspaz (556486) | about 6 months ago | (#46673255)

QR codes use Reed-Solomon error correction, so you don't get missing or corrupt data (in that the QR reader knows if it reconstructed all the data correctly or not). Readers will typically only "read" the code if they manage to reconstruct the entire thing. The error correction helps compensate for poor image quality, and the fact that the image is monochrome makes things like exposure less critical. There are four levels of error correction, which allow for the reconstruction of 7%, 15%,25%, or 30% of codewords respectively.

QR codes can store up to a bit under 3KB of data (the largest size with the lowest error correction), but I couldn't get my phone to read any v40 QR codes (the largest ones), and v25 took some effort. The plan for QR codes of kernel oopses will probably fail for that reason, if nothing else (that they need v40 codes to store an entire oops, and few phones will read v40 codes).

Re:Huh? (2)

MightyYar (622222) | about 6 months ago | (#46673759)

I'm sure the folks discussing this are smarter than I am, but this is Slashdot, so I'll do some uninformed speculation anyway. Because it's fun.

The sample oops is 3134 bytes in plain ASCII. Plain old zip gives 1589 bytes, xz does a little better with 1492 (and only 1446 with lzma). I believe xz could do even better if the dictionary could be fixed and thus not embedded in the file. Doing a base64 encode on that gets to 1929 bytes.

So it looks to me (based on my sample of one...) like you could use version 27 or 28 with the lowest level of error correction. Probably let the library just scale it to whatever size is necessary.

Re:Huh? (1)

ncc74656 (45571) | about 5 months ago | (#46674191)

curl http://levex.fedorapeople.org/... [fedorapeople.org] | lzma -z9c | base64 | qrencode -t ANSIUTF8

This produces output too large to fit on most screens unless your console font is ridiculously small or your screen resolution is higher than most (my notebook has a 15" 1680x1050 panel). Also, it appears the console (on Ubuntu, anyway) doesn't handle UTF-8. Falling back to ANSI, it's even farther from being feasible.

Re:Huh? (2)

Levex (3606037) | about 5 months ago | (#46674307)

Yes this causes a big output since my (and I suspect yours as well) terminal uses size 12 fonts, but in the crash situation we do it one screen pixel per QR pixel. There is a file called qr_code.png in that folder I gave in the thread, which is the actual result unscaled. It's 147x147 which can fit on every screen I know of.
How to handle textmode is still an ongoing question. We'll first get it working on the framebuffer then maybe we'll find a solution for textmode, if it's even possible.

Re:Huh? (1)

Anonymous Coward | about 6 months ago | (#46673807)

Or they could invent a binary oops format.

All I care for understanding an oops is the stacktrace (4/8 bytes * stack-depth) and the contents of the registers (8bytes * 20 on x86_64, 4bytes * 33 on ARM, IICC) and a condition code (4 bytes), that's more like ~320 bytes.

Re:Huh? (1)

nadaou (535365) | about 6 months ago | (#46673839)

> (that they need v40 codes to store an entire oops, and
> few phones will read v40 codes).

few of today's phones perhaps. but the development of phones is
not exactly at a standstill, when QR-oops gets released with some
future kernel what will the phone technology support then?

to quote Doc Brown, you have to think four dimensionally.

Re:Huh? (1)

Kjella (173770) | about 6 months ago | (#46673261)

What is the size limit of a QRcode? Doesn't increasing the density of information contained in the image lead to the possibility of corrupt/missing data due to poor camera quality, motion blur, over/under exposure, or something along those lines?

They contain quite a bit of error correction so either it won't decode or it will with >99.99% probability decode correctly. You can store almost 3kB in a 177x177 QR code, but for the same physical area it's a trade-off between information density and readability. The bigger you make the QR "pixels" the less camera resolution you need, but the less information you can store as well.

Re:Huh? (1)

Rich0 (548339) | about 6 months ago | (#46673557)

Yup. For the most part the only way I can capture a panic/dump is by phone anyway, and a QR code would allow me to capture a lot more info than 25 lines of text in an image file.

If I post an image, I'm lucky if anybody looks at it. If I post the text of the error, there is a good chance that somebody will stumble on it using Google and actually make some use of it.

long-term applicablity? (1)

Anonymous Coward | about 6 months ago | (#46672947)

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?

Re:long-term applicablity? (2)

istartedi (132515) | about 6 months ago | (#46672993)

No, just rebuild the kernel. It should be a build option for text or QR panics.

Re:long-term applicablity? (1)

Nikker (749551) | about 6 months ago | (#46673333)

The QR code has really nothing to do with smartphones. You could take a picture of it with any camera and upload it. QR Codes are just a software library that evaluates based on white and black marks within the picture.

Re:long-term applicablity? (1)

phantomfive (622387) | about 6 months ago | (#46673651)

I strongly support backwards compatibility, but chances are you won't have anyone to send it to, if you're running a 10 year old kernel. No one will want to debug that, except maybe yourself, but then you'll probably have all the stuff you need to read it (and might even have the text output piping to somewhere else, too).

Bloat (0)

Anonymous Coward | about 6 months ago | (#46672995)

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

April first is over ! (0)

Anonymous Coward | about 6 months ago | (#46673041)

It that this is a joke , what a strange idea !

Not enough data (2)

MichaelSmith (789609) | about 6 months ago | (#46673049)

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.

Re:Not enough data (1)

wiredlogic (135348) | about 6 months ago | (#46673095)

The 40-L QR code format (177x177) encodes 2953 bytes. That is a useable amount of data for a kernel dump.

Re:Not enough data (2, Insightful)

Anonymous Coward | about 6 months ago | (#46673179)

1) No, 2953 bytes is not enough for a "kernel dump". "Kernel dump" as a term/phrase doesn't even make any sense, come to think of it. Did you mean a stack trace? Register dump? Because "kernel dump" makes me think of "memory dump", i.e. dumping all contents of RAM to swap + rebooting system (which later notices the crash dump header in swap and hopefully extracts it).

2) If just a stack trace or register dump: 40-L may be too high a resolution to reliably work when using a mobile phone camera to take a picture of an LCD screen. There's often too much noise (high ISO) in this situation. Lower-resolution QR codes means more likely successful recognition and decoding. http://en.wikipedia.org/wiki/Image_noise#Low_and_high-ISO_noise_examples

3) What I haven't seen mentioned: how exactly do the developers plan on printing a QR code when someone's using a text-only console? Don't tell me "everything on Linux console uses a graphical framebuffer now" because that's completely false (lots of folks disable this, and some distros disable it by default). What's going to happen when the kernel crashes? It uses BIOS INT 0x10 to switch to 320x200 VGA mode and show a QR code? Is it going to change the on-screen font masks/bitmaps to display "tiled" pixel data that represents a QR code?

I have a better idea: how about just keeping things how they are. People using mobile phones to take a photo of a stack trace + register dump mostly works reliably (barring wobbly hands). Console fonts are quite legible even if the person has consumed too much cappuccino, while QR codes, especially high-resolution QR codes, are going to be a lot less legible in that situation. My reaction to this proposal would be: what does using a QR code get us that we don't already have available with existing technology and methodologies in place? (FYI: the correct answer to that question is: "nothing")

Re:Not enough data (1)

Guspaz (556486) | about 6 months ago | (#46673265)

Except L implies the lowest amount of error correction, making it the hardest to read, and few devices will read 40 codes anyhow. They're enormous.

Re:Not enough data (1)

wiredlogic (135348) | about 6 months ago | (#46673363)

You don't need high levels of error correction. That is meant for printed codes that may be damaged. You aren't likely to be displaying on a screen that is so broken that large chunks are missing.

Re:Not enough data (1)

Guspaz (556486) | about 6 months ago | (#46673849)

It also means that, in marginal conditions, it can reconstruct code blocks that it didn't manage to read correctly. It's not just useful for printed codes.

Re:Not enough data (0)

Anonymous Coward | about 6 months ago | (#46673413)

Good luck getting 177x177 on a 80x25 terminal!

Linux is already so much better than Microsoft and their typical "unknown error" cop-out so there's no need to improve anything.

They make about as much sense as anything else (1)

Anonymous Coward | about 6 months ago | (#46673055)

Inscrutable error messages seem to be par for the course when you're looking at kernel panics.

Easier to simply change the console font!! (0)

Anonymous Coward | about 6 months ago | (#46673077)

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.

Wish other OSs did this... (2, Insightful)

jpellino (202698) | about 6 months ago | (#46673117)

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."

Re:Wish other OSs did this... (5, Insightful)

Anonymous Coward | about 6 months ago | (#46673207)

And with QR codes, the conversation becomes this:

"My computer froze."
"What happened?"
"It put some white and black crap on the screen."
"What did it say?"
"How the fuck should I know? It was random white and black dots! Like a fucking Rorschach test!"
"It probably was a kernel panic. What was the error?"
"I dunno, because like I said, ALL IT HAD WAS SOME DOTS AND SHIT. Then it rebooted! So it's gone! FUCK!"

How is that an improvement? Yes it's a change, but it's not an improvement.

Re:Wish other OSs did this... (1)

Anonymous Coward | about 6 months ago | (#46673775)

I can't think of anyone I know who can't identify QR codes. They're stamped over fucking everything in retail now.

Re:Wish other OSs did this... (0)

Anonymous Coward | about 6 months ago | (#46673213)

You say that... but...you know, a user that's too inept to even try to read an error message...

I don't care about unless you're paying me to.

And even if you are paying me, I generally still don't care, but I'll smile while I pretend to.

It isn't all "techbabble" or "gobbledygook"... some things may be over your head. If you don't understand it, fucking own up and admit it. Then record the damned words.

That a QR code makes it easier still means you remain a helpless fucking kitten that can't read without a babysitter.

You get the prize of dumbest comment on slashdot (2, Insightful)

Anonymous Coward | about 6 months ago | (#46673311)

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.

Re:You get the prize of dumbest comment on slashdo (1)

Anonymous Coward | about 6 months ago | (#46673921)

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 would help, some. (1)

Anonymous Coward | about 5 months ago | (#46674397)

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?

Re:Wish other OSs did this... (1)

ToasterMonkey (467067) | about 6 months ago | (#46673663)

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."

"Show me!"
"I already rebooted it."

Personally I would rather have a more sophisticated crash dump system, like other OSs, because whatever is going to fit in a QR code isn't going to help much unless you're looking up known issues in an enterprise Linux vendor's bug database. That's assuming they can cram a stack trace into QR codes, AAAAND you have a problem that leaves a predictable stack trace.

I don't remember the last time I had a Solaris system crash that didn't leave a dump (try not to giggle). It would have be be way back pre-ZFS, on a janky server without a dump partition. I'm also reading that Windows saves memory dumps to the page file going back to XP.

You go into the average Linux environment and even if it's not a "paid support is for wusses" camp, you are _EXTREMELY_ unlikely to have anything of value to send to support. Maybe your hawt X86 firmware will have logged an issue! ROFL.

Reboot and hope for the best :\

So... (0)

Anonymous Coward | about 6 months ago | (#46673131)

Is there something stopping people from taking a picture of a current kernel dump?

Really good idea! (0)

Anonymous Coward | about 6 months ago | (#46673139)

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.

Headless systems or Virtual Machines? (0)

Anonymous Coward | about 6 months ago | (#46673227)

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.

Re:Headless systems or Virtual Machines? (0)

Anonymous Coward | about 6 months ago | (#46673387)

With virtualisation, you typically get a virtual console (just like a serial console) - which means you can just copy and paste the plaintext Oops from it.

This QR based concept is meant to catch the typical user situation, the system Oopsed, froze and no longer responds - there is a lot of text on the screen, but it might have partially scrolled off screen and is generally quite hard to catch (taking a photo works, but it order to use that data, someone -the submitter or the developers- have to write it down, lots of text and hexadecimal numbers - with a high probability for typos). It is not usable for pure text consoles (embedded devices) or virtual machines, but there you already have better means to catch the textual representation of it.

I like the idea, but fear that it won't actually work in practice, for being too invasive or complex when the the kernel goes for a walk or that the QR codes are too small for being readable by a normal phone (and a not top end phone). While, of the given examples, I can easily decode the 600*600 pixel example, but the 147*147 pixel version is not decodable by my phone.

Re:Headless systems or Virtual Machines? (1)

Anonymous Coward | about 6 months ago | (#46673517)

Or enable SOL...

Progress!!! (0)

NapalmV (1934294) | about 6 months ago | (#46673303)

So, we're gonna replace the old school "Error 256" messages with bar codes? Doubleplus Insightful!!!!

Re:Progress!!! (0)

Anonymous Coward | about 6 months ago | (#46673841)

I'm not sure you know what a kernel panic is.

simple approach (1)

belmolis (702863) | about 6 months ago | (#46673353)

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.)

You use a camera regardless (0)

Anonymous Coward | about 6 months ago | (#46673355)

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.

And people think Linux is GOOD? REALLY? (-1)

Anonymous Coward | about 6 months ago | (#46673723)

And what would a Linux lover's response be if Microsoft or Apple had to resort to such messages because they can't get it right?

Fortunately for the world Microsoft does it so much better than Linux and we don't have to worry about this kind of crap.

Re:And people think Linux is GOOD? REALLY? (1)

Zontar The Mindless (9002) | about 5 months ago | (#46674295)

Do you even know what a kernel panic is, or what is likely to cause one?

No way! (3, Funny)

msobkow (48369) | about 6 months ago | (#46673757)

I am NOT buying a fucking cell phone to read a core dump.

Just fuck right off already. Not everyone wants a digital leash.

Re:No way! (1)

adnonsense (826530) | about 5 months ago | (#46674019)

You don't need a cellphone to decode QR code images.

Just sayin', like.

Worst idea I've heard in years. (-1, Troll)

Ungrounded Lightning (62228) | about 6 months ago | (#46673911)

And I've heard a LOT of REALLY BAD ideas.

Most of what has gotten worse in Unix/Linux over the last couple decades has been the progressive hiding of the system admimistration mechanisms - previously built on human-readable text configuratin files - behind GUI configuration interfaces and excessive complexity. (See upstart and systemd for examples of the latter.)

Now they want to bury the kernel error messages in a QR code? That REALLY takes the cake.

Re:Worst idea I've heard in years. (1)

Levex (3606037) | about 5 months ago | (#46674321)

They won't disappear, it's going to be optional and will be seamlessly available next to the text crash.

This would be nice, but (0)

Anonymous Coward | about 5 months ago | (#46674047)

it could wrong in some interesting ways. For example, it could transmit an infection from you desktop to your phone...

Just drop to debugger mode on reboot. (1)

VortexCortex (1117377) | about 5 months ago | (#46674059)

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 / debugger, and thus gain freedom from many limitations that current OSs have in terms of self-diagnoses, security and cross platform capabilities (without loss of performance). Hardware features like hypervisory modes and additional execution privilege rings will need to be better utilized by the OSs themselves and thus be more widely adopted to push hardware vendors towards supporting features necessary for security and functionality. Contrary to popular belief, software and hardware are closely linked, and do intermingle. There was a time when (OS) programmers requested features of hardware makers; When used in moderation such could solve many current OS problems.

No methodology is flawless. Sometimes "doing one thing and doing it well" means that the problem space needs to be increased so your "one thing" can actually "do it well". Otherwise when your one thing "panics" there may be no other thing to help it recover.

Re:Just drop to debugger mode on reboot. (1)

Anonymous Coward | about 5 months ago | (#46674265)

Am intrigued by what you're saying. It's either a late april fool, or what sounds like a very interesting project - can you provide a link to details of the OS?

Re:Just drop to debugger mode on reboot. (1)

Zontar The Mindless (9002) | about 5 months ago | (#46674299)

Or better yet, a link to source or installation image.

The matrix (3, Insightful)

BlazingATrail (3112385) | about 5 months ago | (#46674095)

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

Great idea but limited (1)

zzyzyx (1382375) | about 5 months ago | (#46674189)

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.

Re:Great idea but limited (1)

Levex (3606037) | about 5 months ago | (#46674329)

If your embedded board has a HDMI connector, then there is a great chance there is a framebuffer as well. AFAIK, most embedded system only ship a framebuffer and somekind of serial output interface. The real problem in fact is how would you get that framebuffer after a crash occured and you don't have a screen nearby to connect to the HDMI/VGA connector.

Kernel "PANIC" (0)

Anonymous Coward | about 5 months ago | (#46674193)

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".

Re:Kernel "PANIC" (0)

Anonymous Coward | about 5 months ago | (#46674285)

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".

How about "Don't Panic"?

Re:Kernel "PANIC" (1)

Zontar The Mindless (9002) | about 5 months ago | (#46674327)

From our friends over at Merriam-Webster:

panic
noun

: a state or feeling of extreme fear that makes someone unable to act or think normally

: a situation that causes many people to become afraid and to rush to do something

You were saying...?

Just show smileys (3, Interesting)

Anonymous Coward | about 5 months ago | (#46674415)

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.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>