User: Password:
|
|
Subscribe / Log in / New account

Single-point-of-failure is implementation problem

Single-point-of-failure is implementation problem

Posted Feb 26, 2011 15:56 UTC (Sat) by foom (subscriber, #14868)
In reply to: Single-point-of-failure is implementation problem by blujay
Parent article: First look at Ubuntu "Natty" and the state of Unity

I dunno what OSX he's using, but I've never had that happen in OSX...

In OSX, every process draws and handles its own menubar. If one process goes comatose, it will stop drawing its menubar when you switch to one of its windows, and so the menubar from the last process you visited will still be visible on the top of the screen (but, unusable because the process you just switched to is dead). If you switch back to another live process, it works fine. and handles its own menubar just fine.

Perhaps tshow gets confused because of the how you can have the dead process's windows in front, and it still looks like the menubar for another app should be active, while actually it's not. Or maybe his OSX really does somehow manage to wedge the entire menubar reguarly. That would presumably have to mean that the window manager itself was wedged.


(Log in to post comments)

Single-point-of-failure is implementation problem

Posted Feb 26, 2011 21:59 UTC (Sat) by tshow (subscriber, #6411) [Link]

> I dunno what OSX he's using, but I've never had that happen in OSX...

10.6.6 with all the updates except the latest iWeb patch. Hardware is Macmini4,1, 2.4GHz core2, 2G RAM. The only addons of note I'm running are TunnelBlick and the Kensington trackball drivers.

I've had both kinds of menu misbehavior. It probably doesn't help that I'm on a bottom-spec mac mini, mind you.

I regularly see "the wrong menu" as it were, where one program has focus but some other (wedged) program has drawn the menu bar. The program with focus usually works properly (including menu shortcuts), the menu just looks wrong.

For some reason, this often happens with programs used in conjunction with emacs; I'll have emacs up, but something else has scribbled on the menu. On the other hand, given how much time I spend in emacs, I'd bet there's sampling bias.

I also occasionally (maybe every 10h or so of flight time) have a program beachball and take the menu with it. When that happens, no menu shortcuts work at all, and the menu is usually incorrectly or only partially drawn. When this happens it doesn't seem to take the rest of the window management with it; I can still resize and move windows, open new programs and switch focus both with the clover-tab and by clicking (and with expose, for that matter), but keyboard shortcuts for menu entries don't work and the menu is often junk.

Mind you, it may be the mac itself. I've had some interesting problems with this beast. For example, it snow crashes my samsung monitors (isn't having a CPU in everything wonderful? Now even mundane things can crash...). That is, if the monitors are on when the mac shuts down, there's a roughly 10% chance that one or both of the monitors fill with what people familiar with analog TVs would call snow (though it's slightly more saturated than that). It takes a hard power cycle of the monitors to get them back. The linux boxes and the windows box don't do that, and they're all hanging off the same KVM. I've also gotten the snow crash a couple of times with monitor(s) plugged directly into the mac.

I've also had a couple of kernel panics, a few hard freezes (both the "only the mouse works" and the "wow, this looks like a win3.1 graphics crash from the early 90s" style... if my colleague wasn't getting similar results on his mini, I'd have suspected I had bad RAM or something.

Though maybe we both have bad RAM. It wouldn't surprise me; despite Apple's reputation for quality, when they drop the ball they can really drop it hard. See the debacle about macbook power supplies, for example; my old TiBook has reached the point where the power charger actually spits sparks and hits second degree burn temperatures when plugged in.

At any rate, yes, single point of failure is an implementation problem, but it's an implementation problem affecting the flagship of the global menu fleet.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds