Recent Rawhide (F10 Alpha and Beta) has one of the oddest features ever (Gnome Power Manager level of "odd" here). Whenever one runs ssh (including scp) for the first time, a dialog pops up, asking for a "password to unlock keyring".

Entering any kind of password fails: the dialog reappears again. I must click "Deny" to proceed. V.odd.

It's a little scary to realize that someone well-meaning interposed some pretty big chunk of [currently broken] software into something as fundamental as ssh. Who knows what else it does aside from contacting my X.

P.S. This can be disabled, right? Right?

UPDATE: Peter Robinson e-mailed that the missing package is seahorse. Also, there's apparently a stuck ~/.gnome2/keyring/login.keyring. Removing that gets it regenerated and functional, so gnome-keyring-manager can be used.

In case anyone is curious, GNOME hooks ssh by setting SSH_AUTH_SOCK to something like /tmp/keyring-HIZ5We/ssh. The socket is created by gnome-keyring. Apparently, ssh hooking cannot be disabled selectively.

I wrote before that it would be great if GNOME provided a central persistent keyring for applications such as Pidgin (which otherwise stores your Gmail password in plaintext). Unfortunately, they began with hooking OpenSSH, which has its own secure key management already, and left Pidgin out -- where this kind of capability would actually be useful.

UPDATE LATER: Ka-Hing Cheung wrote me that a plugin for Pidgin to use gnome-keyring exists. It was written under the auspices of Google Summer of Code, and is likely to be merged in a couple of releases.

I have a laptop with Synaptics touchpad, and one of the biggest annoyances in its implementation is how the "wheel" strips act upon the GUI element where the mouse is pointing regardless of the current focus. It took years to beat focus-follow-mouse people into a marginal submission, yet they still find every crack to seep through, like kerosene. Naturally, this behaviour is not tunable.

Another retardity in this area is the behaviour of the panel. Some genious came up with an awesome idea to flip windows if panel receives a wheel click. The problem with that is, a strip on the laptop is difficult to make to deliver just one click, so the function is useless to me. Also, it is too easy to hit the strip accidentially (which would not be a big deal if not for the enforced focus-follow). So, for one reason or the other, I would like to disable this behaviour. I don't even want to seek excuses for this wish. Just do it. But it's impossible.

So far the only group that displayed a clue in this was, strangely enough, Mozilla. They fixed bugs I filed and in general had an understanding of various input and display technologies, despite only being browser people. You'd think desktop developers would know how a touchpad differs from a wheel mouse.

UPDATE: Chris pointed out in comments that a fundamental reason exists why wheel behaves this way: the extra button events are mouse buttons, and those go where pointer points. I knew it, but it didn't click. I still think that applications should be able to work around this, although perhaps at the cost of some extra events being delivered.

After noticing that the annoying and useless (for me) orange star has no setting "go away forever", I concluded it was time to use "rpm -e". However, we have another case of House That Jack Built: system-config-printer needs /usr/bin/system-install-packages (because, you know, it wants to pull printer drivers for you automagically). But the system-install-packages is a part of the gnome front-end, not PackageKit itself (why? a mystery), and that includes the orange star (it's called pk-update-icon). Godly.

At least it's not a throbbing red eye, and not restarted when killed. Also, Yet Another Sneaky Daemon They Sprung On My System While I Looked The Other Way (packagkitd) quetly disappears after a while, releasing my precious memory. I sense some good intent here, but it's not good enough.

P.S. I'm testing if "Check for Updates: Never" and then killing means "go away".

P.P.S. Nope, it still restarts on the next login, and checks for updates. What part of "never" is unclear here?

Seen today:

  PID USER      PR  NI  VIRT  RES  S %CPU %MEM    TIME+  COMMAND
23015 root      20   0  311m  63m  S  1.0  7.4 148:50.50 Xorg   
23661 zaitcev   20   0  446m 9324  S  1.0  1.1 117:00.18 gnome-power-man

So, the process which is supposed to save my CPU cycles is responsible for consuming almost as much as X server, which does a heck of a lot of work. Isn't it ironic?

I suspect Gnome Power Manager loses its mind when I close the lid overnight.

Today I plugged my iPod in, and Rawhide launched Rhythmbox, which chugged along for about half a minute, then crashed. At least it did not wipe the player's database. WTF, I thought I had all auto-run types set to off...

Looks like there were some changes. No more unchecking umpteenth type of crashware.

To compensate for a good thing, they worked extra hard to hide this panel. It's not reacheable from any parts of System menu. File Browser has to be started, and its Preferences adjusted.

UPDATE: The last part is untrue, I missed the right item. Thanks ucc_journal for the correction.

Every time I log in, it promises not to show the message again, but then does.

I suppose I should clean some keys in gconf-editor, but which?

Also, tinkering with the registry is so Windows.

UPDATE: The BadName below turned out to refer to a font name. My speculation about the DirectColor was bogus. GNOME is not picky!

I mentioned it in passing before, but did not elaborate. I have two identical Rawhide systems, a laptop and a desktop. Everything works dandy on the laptop, but a number of GNOME programs (including Firefox) abort immediately with "BadName (named color or font does not exist)" on the desktop. What could be different?

It looks like the diff of xdpyinfo(1) outputs has a clue:

@@ -78,14 +79,7 @@
     red, green, blue masks:    0xff0000, 0xff00, 0xff
     significant bits in color specification:    8 bits
   visual:
-    visual id:    0x22
-    class:    DirectColor
-    depth:    24 planes
-    available colormap entries:    256 per subfield
-    red, green, blue masks:    0xff0000, 0xff00, 0xff
-    significant bits in color specification:    8 bits
-  visual:
-    visual id:    0x4a
+    visual id:    0x3a
     class:    TrueColor
     depth:    32 planes
     available colormap entries:    256 per subfield

The problem only started hapening after the libpciaccess thing, but it does not tell us if DirectColor existed in the previous X server or not. The libpciaccess rework caused a big gap in my updates, and possibly Cairo or GTK regression slipped into it. In fact, I seem to recall that Firefox worked on top of my patch for SiS, although I'm not sure.

Most of the GNOME continues to work, so it's not the same issues as the abandonment of 8-bit visuals, apparently.

I guess I'll just have to file a bug and see where it takes us, although... what component to use?

Snapped a minute ago on Rawhide (look at the corrupt icons):

I reported this bug a year ago, IIRC. But it's still with us. I really should get off my ass and fix it, but since it involves GNOME, that would require some major learning. Which would probaly be probably a good thing, actually... But I'm always busy with some stuff. And who isn't?

UPDATE: Actually, it was two years ago.

UPDATE 2: Ajaxxx says that ssh tricks X into thinking that pixmaps are in a shared memory segment. And they are... on a different host.

... I ran "yum update", and the following started happening:

The transient always disappers before I am able to aim xwininfo at it. Usually it occurs when I'm watching my anime, but not always. What in the world is this?

Somehow this reminds me the old joke about GUIs: First humans moved out of caves; then they invented writing; now they invented intuitive GUIs; all that remains is to return to caves.

UPDATE: Thanks everyone for the comments. Apparently, gnome-power-manager gets a dbus signal that the brightness needs adjustment, then attempts to adjust it. The window is a brightness indicator, similar to the volume indicator (although I cannot grab the slider with the cursor). Since gnome-power-manager is utterly useless, I always apply rpm -e to it, but this time I wanted to report a bug when it crashed in a default F7 install, so I left it in. Also, fortunately for me, it is too broken to adjust the brightness and so it never hurt anything. The adjustment is done through /proc/acpi on this laptop, and works perfectly with echo(1). BIOS even remembers it across reboots.

UPDATE: Richard Hughes replied in comments, with the official word, so thanks. By the way, he also was upset at insufficient appreciation... Although his comment was not personally directed at me calling gnome-power-manager "useless", I should not have written that. I own an Inspiron 1501, where brightness keys deliver keypresses instead of being intercepted by SMM BIOS, and thus a software brightness adjustment daemon would be quite useful indeed if it worked.

To clarify, personally, I do not think that the brightness change on idle is a good idea, because it does not fit the use profile which I think typical. If I want to see something on the screen the brightness is already lowered. Lowering it further is entirely pointless, because I would not be able to see anything, and so it would do more good to power down the display completely. X already does that. But perhaps someone might want the feature... I cannot think under what scenario, but display technology varies so much that I do not presume to know all use cases. Just think of something innovative like OLPC.

I decided to one-up my daughter by buying an identical Dell Inspiron 1501, only with a bigger 83 mA*h battery. I have it all up and running now, almost. I even learned to how change the LCD brightness with "echo -n 62 > /proc/acpi/video/VGA/LCD/brightness". The only issue remaining is the horizontal scroll, which drives me crazy.

The problem is, applications tend to intepret it wrong. For example, Firefox ships with horizontal scroll flipping pages, which causes awesome effects if you visit a form-heavy website. I'm sure many Evoks double-charged their credit cards to bring us that information, but by now everyone knows how to change their mousewheel.horizscroll.withnokey.action to zero. GNOME's panel is just as bad, or perhaps the wnck-applet is. A horizontal scroll event causes it to flip to the next window. Since accidential scrolls deliver dozens of events at a time, each time it happens the desktop explodes in a kaleidoscope of flappling windows. And to make matters even worse, some wise guy made scroll to follow pointer instead of focus, so you don't even have to click into the lower panel: just move your finger to the lower edge of the pad and voila, the eruption occurs.

Unlike the Firefox, wnck-applet does not allow this behaviour to be disabled. Bad GNOME, no cookie.

{Update: See also bug 187412 [187412].}

By far the worst thing in Gaim is how it persists in not providing users with any information about the sources of messages, even when it can to provide the information. The classic example is the most useless information window ever:

Not even the account through which the user is coming is mentioned.

But wait, it gets worse. The dialog above is summoned with a user action. But actually, you can spam anyone completely anonymously with these popups:

Just what were they thinking when they coded the thing?

I try to stay away from UI debates. I am not a UI expert, so what do I know. But this is just weak, people, totally weak.

{Update: I understand that the spam payload is delivered in the guise of a server message, which is why it gets its popup. Thus, the message is not associated with a specific originator, and the fault is with Gtalk for allowing Brazilians to abuse itself this way. The point, however, is that Gaim should not throw pop-ups for no good reason. Just create a "server message" tab if protocol is so weak.

I created a couple of RFEs and see how far it goes. Not that it would shame anonymous retards from making idiotic comments, but the point "you should file bugs" is made often by reasonable people as well.

1602801: Do not Pop Up, Use A Tab.
1602806: Create a Join Window Mode. }

{Update 2006/11/25: Regrettably, I have to abort the experiment with Kopete and stick with Gaim. I just managed to get it to work, but it was too much of an effort. Also, it pulls too many dependencies. I removed kdebase, kdenetwork, kdnssd-avahi, kdelibs, kon2-fonts, kcc, kon2, and qca-tls, but I do not know if I got them all. In the end I do not know it Kopete produces popups on server messages like Gaim. But it does have a separate window for chats, so it's not a groundbreaking improvement.}

Yesterday was a day to forget.

I ran "yum update" on Tuesday, and yesterday I got hard lock-ups at my laptop. My attempts to get NMI Watchdog to work failed, though I think it is not surprising. I remember the times when this laptop refused to boot outright if local APIC was enabled, so the surprising part is that modern kernels with lapic even get into user mode and have NMI counts flipping.

I looked at /var/log/yum.log, and saw that xorg-x11-drv-ati was updated. My Dell D600 uses Radeon. I added 2 and 2, downgraded xorg-x11-drv-ati, and... lockups still happen. Yes, I did reboot with a power cycle.

Then, I downgraded gtk2. That seemingly fixed the problem, so gtk2-2.8.19-2 works, gtk2-2.8.20-1 fails. I dutifuly filed a bug. But heck no, the system still locked later. It just wasn't as easy to trigger as with the new gtk2, but it was there.

I downgraded gtk2 down to 2.8.17-1.fc5.1, pango from 1.12.3-1 to 1.12.1-1.fc5.1, libX11 from 1.0.0-3.FC5.0 to libX11-1.0.0-3, glib2 from 2.10.3-1 to glib2-2.10.2-1.fc5.1. Nothing helped. But there were no other relevant updates (from running "ldd /usr/bin/pan").

So, having wasted whole day, I had to give up. And today everything works fine. What gives? Can it be that a segment of a shared object got "stuck" somewhere? Nonsense, surely. Yes, I undone the prelink as well.

Anyway, I'll figure it out eventually, but for now I don't understand just how a benign desktop GUI library manages to get the box stone dead. Aren't we supposed to be better than Windows in this regard?