Michael Lotz added code to generate QR-code for the KDL (Kernel Debug Land) ouput (which pops up when the kernel crashes). No more blurry photos with debug output, but a QR code which decodes to the clear-text KDL debug output. Here’s one of the relevant commits, an example showing a QR code, and text from decoded sample QR code.
Who thought this was a good idea?
Lets use a smart phone to decode the error message … Why not I dunno write some data to disk? Surely that would have been simpler.
Edited 2012-07-02 18:29 UTC
simpler only if it works
if it doesn’t it can destroy data
don’t forget that you can’t trust the kernel anymore when it KDLs
Windows does it fine. Sorry.
Windows is also not alpha-state software with only a handful of active developers that are actually familiar with the internal workings.
While running Windows, remove your system SATA disk/ssd and check how it works fine.
Now imagine that instead of human removal the cause is disk controler going crazy sometimes, not definitively. Or it’s manufacturer driver is immature and don’t have this quicky hardware workaround (disclaimer: all kernel crashes appearing in this comment are fictitious. Any resemblance to real ones, pending or past, is purely coincidental…)
How do you get enough data to discover the root cause?
Plus, please notice that Haiku don’t have the resources Microsoft had to wrote its Windows kernel, and still it took a lot of time to reach a mature kernel crash features set. And calling the bluescreen a mature kernel debugger is kinda funny, BTW…
Edited 2012-07-03 09:39 UTC
Right, because that’s going to work reliably when the kernel panics.
Well, to be fair, most people don’t even know what a kernel panic is – or what it means…
Most OSes just do something fancy, like ‘bluescreen’, or reboot.
the BSOD is actually pretty advanced.
Considering it does it in the users own language and logs the result in the event viewer.
But hey lets just vote me down.
So English is Danish, eh?
No BSOD is actaully in the users own language for the most part. Including Danish I suspect.
Oh well, normal OSAlert Crap.
Edited 2012-07-02 20:35 UTC
Amusingly, I think that was what most people were thinking when they read *your* comment.
Well still it doesn’t invalidate the first sentence. The Windows Kernel panic is multi-language.
No other OS does that to my knowledge.
The fact that you are unaware of the fact that the second most popular desktop operating system also has multi-language kernel panics kind of calls into question the validity of your posts in this thread so far.
As does your abrasive tone, but alas.
Edited 2012-07-02 20:54 UTC
Nonetheless, whether I was incorrect in that aspect .. as I already admitted by saying “To my knowledge” … maybe you missed that part of the sentence?
Both can write their kernel panics to their primary disks. Which was my point all along as you already knew.
Edited 2012-07-02 21:13 UTC
Most OSes spend more time fixing bugs than making their crash screens pretty. Translating catastrophic error messages doesn’t help much, as advance computer lingo is a foreign language to most users, and it prevents googling the error message.
WAT.
How dare and OS log and display the Kernel panic.
Whether it is foreign to non savvy users, it is important to those that may understand such messages.
Edited 2012-07-02 21:24 UTC
I would expect that every OS logs and displays the error (Haiku does as well, this is supplementary since writing to the disk may not be possible). Multilingual error messages are sort of useless.
I have no idea what the Dutch word for harddrive is, but I can google the error message and find out what’s going wrong (especially with a nice QR code so I don’t have to type it, and even nicer if I can do it while the system reboots). What wouldn’t help me is translating an obscure error into English so I get nothing when I google for it. Or even worse, I’d need to decipher the slaughtered metaphor term that didn’t survive three translations (e.g. “Wrong Mode” for a syntax error in a configuration file).
I am not against translating simple error messages, like “unable to contact server”. But when you get more advance errors (e.g. a BSOD), then it needs to be in the language of development. Of course, if most computer jargon is in English then it’s a silly to translate error messages into something that takes knowledge of two languages to understand.
I wonder how being in the end-user language make the low level and techie kernel panic message more easier to understand…
But, sure, that’s a kinda unique feature, indeed.
Maybe for a reason others OSes don’t find it that useful, but hey your mileage could vary.
I don’t see how that’s relevant at all. Windows only ships with a single language, I would therefore expect it to produce all its error messages in the language it ships in, and that language alone. Most other OSes ship with multiple languages available on the same installation media – in those cases it would make more sense as there’s only one version of the OS involved, not a different one for each language.
You don’t have any idea what you’re talking about. Windows, though I am not a supporter, factually ships with support for more than one language. Its error reports are generally by error code which can then be looked up in translation tables and allows the system to provide (in many cases) localized error messages. In Linux there is no database of error codes, there’s only printk messages, and so there is no good way to auto-translate errors. Thus, the OP’s analysis is accurate as far as it goes.
>multilingual Windows BSOD
I call BS.
Only the best ones does both
Better would be to reboot into a google search of the BSOD error message/s that one didn’t have time to read when it booted.
Noway. End-user may choose to stay in that “live-bsod” mode and enjoy reliable web surfing instead of return fixing his usual Windows experience…
Works pretty well for Windows. You keep on slagging off the OS but it does these important things well
The primary storage medium is already known, so as a programmer myself … writing log.txt to the root partition should be f–king trivial.
I cannot fathom why anyone would think this is difficult to do.
Edited 2012-07-02 20:38 UTC
Your KDL is caused by an issue relating *to* storage. How do you propose writing anything to the disk?
Your KDL is caused before any relevant busses are enabled. How do you propose writing anything to disk?
Why do you feel the need to make this volume of posts on one single topic without introducing anything new?
I dunno maybe I think it is better to fix the root cause of the problem then to make a barcode and then use that as a debugging tool.
Just Saying.
This doesn’t even make any sense, are you serious or just trolling? Do you asume that every kernel panic will happen on the developer’s system so he can fix it right away?
That’s chicken and egg: how do you fix the root cause of most kernel panic in an OS without having solid crash reports in the first place?!
Promise, when Haiku kernel will be rock solid, we’ll remove the qrcode feature and use instead a disk log writer. Happy?
BTW, why keeping a kernel disk log writer if your kernel don’t panic anymore at all? Why instead of making Windows BSDO multi-langugage aware Microsoft don’t fix the root cause of these BSODs in the first place?
Simple answer: because kernel developers needs it.
Period.
Now please, let’s move on.
Please don’t remove it (looks like you’re involved?), I think it’s great / brilliant / cute, an awesome idea… maybe even all informational popups etc. should have qrcode?
Though, I can see one downside – unpleasant shudder when seeing some random large QR code somewhere.
(kinda like my buddy used Windows error sound for SMS arrival, which made some people in public transport visibly disturbed, a bit)
Now I also wonder if QR code (~animation?…) could be extended to quickly transfer smallish amounts of data; I imagine it could possibly often be more immediately intuitive than bluetooth or wifi.
Edited 2012-07-06 02:19 UTC
I LOL’d. ^_^
It’s just an extra feature to aid in the process of reporting bugs when the kernel crashes. The old method of taking a screenshot using a camera still works fine.
As for me, I don’t have a smart phone
but I also haven’t seen Haiku crash in a long long time on my computer. 
Or you could spend time writing the error log to the primary storage device which the OS already knows.
One of the possible causes of the kernel panic is not being able to access said device, so where do you suggest to write the log?
But let’s say you actually dump the file. What if the system doesn’t boot anymore? Do your move the partition / drive to a different Haiku machine?
Do you realize this is an, WIP OS with no stable release right?
Edited 2012-07-03 00:14 UTC
Writing data to a storage device requires a lot of hardware control to *still* work. What happened when the boot device is an USB one and the panic is due to USB bus controler or its driver code? How do you write anything to a data storage device in such case?
Same goes for ATA bus, which is not *that* trivial to access.
Meanwhile, displaying data is simple: just write bytes at a well-known address within framebuffer addresses range. Simple and highly reliable.
What was not simple and reliable was copying the data displayed that way.
Edited 2012-07-03 09:35 UTC
Relax, would you? It’s simply an alternative way to get the information out of the kernel debugger in order to be able to copy it into bug reports. Since most modern systems don’t have serial ports any more, it can’t be captured that way, and photographs of a computer monitor are large, unwieldy and can be a pain to get focused properly without cutting off important bits of information.
One of Hakiu’s goals is to “build the operating system of the future”. Something like this is exactly the type of thing that helps fulfill that goal.
Err Event Viewer in Windows or at least a Kernel dump.
It is the 21st century my friend, people have worked out how to write text file to a hardrive.
Edited 2012-07-02 20:46 UTC
And how do you get the text file to the kernel developer???
Remember, the machine doesn’t actually work reliably – otherwise it wouldn’t be generating kernel panics.
This is so fricken obvious – I can’t believe you are still arguing about this…
Yes, I’ve never seen Windows Event viewer “loose” a critical error message… evar! Same goes for kernel dumps.
You are completely missing the point. The information being displayed is of no use at all to an end user. On Windows you get stop codes – are you saying a stop code conveys useful information to the user? It is a completely meaningless number…
Haiku is not Windows or Linux. The userbase is very small and is under rapid development. Googling stop codes or other such nonsense to try and figure out why something is going wrong (as an end user) is likely to be very hit or miss, mostly miss. The real purpose of the information is to allow a kernel developer to determine what went wrong. That is, btw, the real purpose of the information for Windows too – the fact they you can often look up stop codes on the web and gleam out what is going on from them is due to its popularity – nothing more.
More importantly though, for it to be of any use to anyone it has to be communicated to the developer… How exactly do you get the debug log off the hard-drive of the machine that doesn’t work reliably???
The whole point is to make it simple to communicate the information to a developer. It is much cleaner to get an easy to decipher QRCode than it is to try and squint it out of a bad photo of a monitor.
Sure, the stop code approach (which serves roughly the same purpose) works too, but stop codes are just keys to a lookup – the stop code itself means nothing unless you already know where in the code they get hit. Using QR codes you can actually put a fair amount of meaningful information INTO the “stop code”.
I suspect Haiku is not far enough along yet to get religious about how they handle kernel panics internally, different subsystems likely dump/panic in different ways (with differing levels of detail). This is a catchall mechanism to deal with the issue of inconsistent error handling.
I would like to see something as consistent as stop codes used for Haiku as well one day, but I think this QR code thing is a lovely idea for the time being. And it will remain useful even if they get to that point (as a way to convey additional information).
It may seem a bit odd but it’s not such a bad idea. The Linux kernel developers are presently considering patches that would print a QR code to the screen in case of a panic (and for just the same reasons).
<patent troll mode>
Quick, Haiku guys, let’s secure this patent!
</patent troll mode>
Well, at least Haiku will be a prior art of something
Edited 2012-07-04 07:22 UTC
I think that’s an awesome idea… maybe all informational popups etc. should have qrcode.
A good candidate for http://wtfqrcodes.com/
Not really… this is less of a WTF, and more of a “why hasn’t someone thought of that before”.
It’s exactly the same old behaviour – dumping debug info to the screen on a crash – but it does so in a way that a reliable digital copy can be made (instead of a hand-written transcript, or a blurry photo of the screen). Brilliant.
Michael also wrote a blogpost about this feature:
http://www.haiku-os.org/blog/mmlr/2012-07-01_qr_encode_your_kdl_out…
Wow. That’s actually pretty darn cool.
Yeah, that was my reaction too. It’s not much more complicated than the traditional approach of dumping “techie gibberish” to the screen, but it does so in a way that allows that info to be copied off the machine in an error-free manner. It’s a brilliant idea.
‘Write to disk’ is actually supported, in some cases, that is if you’re able to reboot the machine (working keyboard in kdl or a reset button that most laptop don’t have). The bootloader has an option to write the previous syslog found in RAM to a FAT32 formated usb drive.
It’s all there :
http://dev.haiku-os.org/wiki/ReportingBugs#Syslog
edit: keyboard reboot method
Edited 2012-07-04 10:22 UTC