Linked by Thom Holwerda on Wed 13th Aug 2008 23:50 UTC
Mac OS X An interesting article has been making its way around the internet the past few days, titled "Top 10 Usability Highs Of Mac OS". Mac OS X indeed does some things very, very right, just like many other operating systems and graphical environments do some things very, very right. The issue with the list of the article in question is that many of the items on the list are not exactly examples of "Usability Highs" at all.
Thread beginning with comment 326855
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: a kernel panic?
by kaiwai on Thu 14th Aug 2008 06:36 UTC in reply to "a kernel panic?"
kaiwai
Member since:
2005-07-06

A funny but still nice example of Apple’s attention to detail. On the rare occasions when Mac crashes, it still does so in a respectable manner. Usability-wise it’s not perfect, since it doesn’t let the user know what went wrong and only asks the user to reboot the system. Still, beautiful and elegant.

ignorance is a bliss, right? ...


And a laundry list of 'codes' helps the end user - how? Microsoft have already demonstrated that they refuse to make available the list of error codes for BSOD's when they occur; heck, Microsoft has gone so far as to have automatic reboots instead of actually showing a BSOD.

The laundry list of Linux codes - that helps the user how? again, there is no standardised error codes, nor is there a single place to look up those error codes.

Screaming about the wonders of actually seeing a dump from a kernel panic may get your loins excited, but for the average end user - it is all Greek to them.

Reply Parent Score: 3

RE[2]: a kernel panic?
by google_ninja on Thu 14th Aug 2008 18:20 in reply to "RE: a kernel panic?"
google_ninja Member since:
2006-02-05

its something to stick into google.

Reply Parent Score: 3

RE[2]: a kernel panic?
by StephenBeDoper on Thu 14th Aug 2008 19:26 in reply to "RE: a kernel panic?"
StephenBeDoper Member since:
2005-07-06

And a laundry list of 'codes' helps the end user - how? Microsoft have already demonstrated that they refuse to make available the list of error codes for BSOD's when they occur; heck, Microsoft has gone so far as to have automatic reboots instead of actually showing a BSOD.


It doesn't help the end user - but if the end user has to bring in a support tech, they can usually decipher the error code (even if "deciphering" means "search for it in Google", which is usually the case with Windows BSODs).

IMO, the ideal would be a terse "an error has occurred" message - with an option to show more details.

That said, both of my biases are showing. As a result of doing a lot of technical support, I believe that computer software/hardware should be evaluated based on how easy it is to diagnose and fix problems when they occur (and not just how well it works in normal situations).

And as a BeOS devotee, the "ideal" I described is essentially how things work(ed) with that OS: you get a "Welcome to Kernel Debugging Land" message, with a prompt that lets you run a stack crawl, etc, if you need more details.

Reply Parent Score: 2

RE[3]: a kernel panic?
by Mystif on Thu 14th Aug 2008 21:58 in reply to "RE[2]: a kernel panic?"
Mystif Member since:
2008-05-12

"Guru Meditation"


None of what follows is meant to suggest that the average user is expected to know, or even want to know all of this - but some users do...

I can work with Windows BSODs and they can be helpful, but they are far from elegant.

However, for the user who bothers to learn there is a related tool that can be quite helpful in determining the reason for the kernel panic.

If the computer has Windows and reboots instantly than it is unlikely that anything was written anywhere. But if it BSODs you will most likely have a MiniDump file. (Haven't you ever wondered why it sometimes takes so long just to display a blue screen with white text on it?)

The OS writes something to the Event Log, which does help, but even better are the MiniDump files. But it should be understood that when you first try to view a MiniDump file the process feels quite sadistic.

I mean, here you have a file that might just tell you all the intimate details about the crash that just happened, only there is nothing on your computer that can read it. I wish Microsoft didn't make accessing them so difficult.

You have to install the Debugging Tool, and the Debug files for your OS in order to properly access the Mini Dumps. You also need to know where they are written - this will be in the Windows folder, but (I am not positive) I think the location may vary from OS to OS.

Anyway, the BeOS method sounds like the better one to me, of the ones described. It gives a simple message, allows you to dig in deeper, if you want, and the OS already includes the necessary tools.

Whatever OS I use, I just continue to hope for fewer kernel panics, and better tools for problem solving when the inevitable occurs.

I appreciate it when the OS uses its last dying breath to give me clues as to who the killer is, and I hate digging deeper and deeper only to find more and more cryptic messages that have fewer returns when searching the related OS forums.

Edited 2008-08-14 22:14 UTC

Reply Parent Score: 1

RE[2]: a kernel panic?
by Beresford on Thu 14th Aug 2008 19:31 in reply to "RE: a kernel panic?"
Beresford Member since:
2005-07-06

It helps me, and I'm sure lot's of other people that look after Windows systems. Generally speaking, the first point of call for a bugcheck code is support.microsoft.com, then Google.
And the bugcheck code get's written to the event log, even if the system reboots (unless the system really locks, then there is no evidence).

Reply Parent Score: 1