Showing posts from October, 2012

Fedora 17, Gnome 3, Windows disappear on undocking -- xrandr workaround

The behavior of Gnome 3 with more than one monitor is a bit counterintuitive, at least for me. Depending on the value of gsettings set workspaces-only-on-primary you get one of two behaviors. If this variable is set to " true " (default) then however many workspaces you may happen to have on your "main" monitor, you always get and see the same workspace on the external monitor. So you as you navigate up and down on the main monitor, what you see on the external monitor never changes.  So you get N + 1 workspaces, where N is the number on the main monitor and the 1 neverchanging workspace lives on the external monitor. If, on the other hand, this variable is set to " false" , than you get just as many workspaces on the external monitor as you do on your main monitor and they move in tandem or lockstep as you navigate through your dynamic workspaces. You can also obviously drag windows back and forth between workspaces. (I

Fedora 17 laptop freezes on resume from suspend - downgrading kernel fixes.

This is really and the bugzilla really says it all. Something broke for certain laptops around the time of Kernel 3.5.0-2.fc17.x86_64 in that laptop suspend works just fine but on resume the screen turns a lovely shade of gray and if you manage to get a TTY you are treated to a litany of messages like Aug 15 01:58:44 tp kernel: [13984.546007] [drm] nouveau 0000:01:00.0: PFIFO: channel 4 unload timeout Aug 15 01:58:55 tp kernel: [13995.124015] [drm] nouveau 0000:01:00.0: Failed to idle channel 2. Aug 15 01:58:55 tp kernel: [13995.125006] [drm] nouveau 0000:01:00.0: PFIFO: channel 2 unload timeout Aug 15 01:59:00 tp kernel: [14000.130020] [drm] nouveau 0000:01:00.0: Failed to idle channel 3. Again, as stated in the bugzilla, downgrading to an earlier kernel solves the problem. The bugzilla says that 3.4.6-2 (and presumably earlier) works fine, but when I used yum to look for earlier kernels, it was able to find 3.3.4-5.fc17.

Deja Dup thinks current computer name is bar but it should be foo

Fedora 17 x86_64 - running the "Backup" utility aka Deja Dup. Set it up previously and ran at least one backup. Now a regularly scheduled backup starts and get an error message along the lines of "Computer Name Changed" "The existing backup is of a computer named foo but the current computer's name is bar. If this is unexpected you should backup to a different location". In my case the actual (incorrect) name of the "current computer" was something like which made absolutely no sense at all.  (I made up the numbers which represent an ip address but the is what it really said). So what gives? "Backup" is really "Deja-Dup". "Deja-Dup is really a GUI front end for "Duplicity". "Duplicity" is apparently written in Python. When Python decides to figure out the current computer's name, it calls                           socket.getfqdn() So I

Fedora 17 x86_64 Cisco Webex Meeting Desktop Sharing

This is a complicated issue made even more complicated by the fact that although I got something "working" I don't yet fully understand all of the details. But assuming that having something working is better than not, then here goes with what I know, even if there are some holes in the understanding. Given a Fedora 17 x86_64 system, the challenge is to get Cisco Webex Meeting with Desktop Sharing working. The problem is actually quite easy if you ignore the Desktop Sharing requirement. All you really need to do is to get Java working along with the Java web plugin, which is sometimes referred to as and sometimes as I can recommend this page  at the "if-not-true-then-false" website. My takes on Java are I prefer the Sun/Oracle implementation to the open source OpenJDK. On the above referenced page I prefer the JDK option to the JRE option. On the above referenced page I prefer the "absolute" version to the &qu