Linux Bugs.

[swestrup]

So, just to let folks know here are the various Debian bugs that I've been tracking down answers to in the last few days. Please note that all of these are things I've had to find out about because my N00B expectations of things "just working" failed. In other words, I didn't go looking for these, they came looking for me:

1. USB devices don't have their activity lights go out when unmounted. This is an important psychological signal that the unmounting has actually occurred. Nevertheless no one is working on this bug as no one can agree at which point in the unmounting process to handle this.
2. Konqueror can stall for ages while writing to a USB key. This, again, turns out to be entirely a user interface issue. It turns out that Konqueror has 'stalled' because it is waiting for a slow sync to finish. However to most of the world 'Stalled' indicates that no work is being done, not that the program is waiting for work to finish. Had they said something like 'committing data', folks wouldn't keep thinking the program had hung...
3. Automounted VFAT and NTFS devices often get mounted with the wrong options set. There are many complaints of this and at least one of them that I found tends to argue that that is what caused my VFAT-related data-corruption of last week. This seems fixable by modifying the appropriate HAL policies, but its not clear if KDE will honor the policy changes. I'm still looking into this. Of course, I should not have to grovel through hal configuration documentation to set up user mounting policies...
   
4. dhcpclient fails to send a client hostname while asking for a DHCP lease. This caused DHCP to fail until I got it fixed. Alas, the only fix in Debian is to hard code the hostname into the dhcpclient config file. This bug has been outstanding since at least 2000. (I notice its fixed in Ubuntu though).
   
5. KMenuEditor is horribly buggy. It completely corrupted my KMenu, making it unworkable. I had to delete my config files and start over. This too has been a known bug for ages.
6. KDM themes are broken. This appears deliberate, but I've yet to find any explanation of WHY they were broken.
7. Because of the above, I'm using GDM to start my KDE sessions. At least the GDM themes work, although I've not found any (GUI) way to specify the screen resolution for the GDM greeter to use. Because of this, my greeter is always in an inappropriate resolution.
   
8. Compiz-fusion is in Lenny but requires taskbar-compiz and pager-compiz in order to work correctly. These are only available for KDE 3.5.10 and Debian KDE is 3.5.9. There does not appear to be any fix for this. If I want to use Compiz-fusion, I have to put up with a buggy taskbar and pager. Compiz also appears to mess up where windows open (often they're half-offscreen). This might be a config issue, but I've yet to figure it out.

Oh, and its not really a bug, per se, but I've yet to find any way in KDE to have a panel swallow a running application. If anyone knows how to get this to happen, I'd appreciate hearing about it. I find it hard to believe this isn't doable in KDE but I find there are many things in KDE that are done in a way I find hard to believe.

Comments

[wintersweet.livejournal.com]

Sounds like tons of fun! Or just like that xkcd comic assaultdoor has posted on his door at work. (Honestly, the reason we're both primarily Mac users is that we can't deal with Windows' problems and we like Linux in theory but can't deal with its problems in practice, either. Maybe someday.)

Good luck!

[sps.livejournal.com]

Maybe #2 is a dialect thing? "Stalled" works nicely for "blocked waiting for someone to get back to me" for me - and it's what 'Zilla says under the same circumstances, I think.

[swestrup]

It is, once again, a question of what MODEL of interaction is being presented to the user. The writer of the program knows that there's a blocking layer below the file manager that can stall. The user does NOT know this, and the user interface has been carefully designed to hide the fact. Thus, the user just sees that the (aparantly) bottom-most layer has 'stalled' ie, gone into an infinite loop, ie crashed.

With respect to 'zilla, the fact that you are contacting an outside agency is MUCH clearer.

[sps.livejournal.com]

Hm. Floppy disks were always laggy. Networks are laggy. This argument assumes that users neither think of a USB device as AKO floppy disk, nor think of a USB cable as AKO network cable (but wouldn't they? Shouldn't they?).

Even hard disks take 100 million instruction times to do anything. How can I/O not be asynchronous? In fact, one of the traditional arguments against Unix has been that it doesn't 'get' this (supposedly fixed with aio, of course, but who writes aio calls?).

Maybe that's thinking about it too technically. But I'd expect even a naive user to think 'in the case, local, out of the case, remote.' Well, except for the class of folks who say 'my internet is broken,' who apparently imagine that Amazon pay little gnomes to live inside their case.

[swestrup]

No, you completely misunderstand. The problem is NOT that the writing is laggy. Its that 'stalled' implies that the writer has NO IDEA what progress is being made or when it will end. If the writer is the lowest level thing, then that is a VERY BAD sign...

[sps.livejournal.com]

I guess. But Windows is the same; when you ask for your device back it just sits there for 0-100 seconds with no feedback other than the absence of an 'ok' box....

[swestrup]

Oh sure. I am, in no way, claiming that Windows doesn't do the same thing. In fact the whole problem of presenting a user interface which suggests the wrong control model for something is endemic in modern society.

The thing is, I don't complain about it in Windows because there is nothing that can be done about it. I hope that if I point out the flaws in Linux applications that someone, somewhere, will at least take them seriously enough to fix, rather than (as seems to be the most common reaction) dismissing me as a Windows lover.

[cpirate.livejournal.com]

Re #4: It's possible that the upstream dhcpclient people simply aren't aware about Ubuntu's patch. Distros are often not so great at sending these things along. If you were motivated, you might want to post it to their list.

Of course, it's about equally likely that they do know about the patch, and don't want to take it, either because it's appallingly written or there are stupid ego clashes. Sigh.

Re #7: I had that problem too. As it happened, I didn't end up caring for quite a while, as I could still see the username/password box, and I didn't need anything else on that screen. At some point I needed to click the one other control on that screen, which is naturally located on the bottom so it conveniently gets cut off if the screen resolution is lowered (but the virtual resolution stays set high). It turns out that gdm actually pays attention to what's in your xorg.conf, whereas the rest of Gnome (including apparently what sets the virtual resolution for GDM) uses some other settings. In my case, I had to tell xorg.conf to run my preferred resolution at 58Hz instead of 60Hz, so it fit inside the reported monitor timings (it's an LCD, so neither 58 nor 60 Hz burn my eyes out).

So, er, yes, it's a bug, and no, there's no GUI way (short of a decent GUI xorg.conf editor, har har) to fix it.

Oh wait, I suppose in your case it could just be that GDM is looking for the Gnome resolution settings, which you wouldn't have, given that you haven't run Gnome. Try running gnome-display-properties as root and setting things there.

Re #8, I tried compiz for a bit, and while it looks snazzy and stuff, and the snazziness does even provide the occasional usability improvement, I found it overall too buggy and incomplete to be useful. It just takes a really long time for a window manager to mature, which was why I was kind of disappointed they decided to start compiz from scratch instead of hacking up some existing code.