Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
Nicholas Bodley wrote: > I'm guessing one of two things: A configuration problem that slows normal > functions to a crawl, or the KDE developers' use of a bloatware high-level > language that in practice produces dismally inefficient executables (or > misuse of X Window functions, by any chance?). I doubt it's the latter. I haven't used KMail in a few years, but here's some things to look at: - if your home dir is on NFS, and you don't have the NFS locking daemon working, things that need to lock usually fall back to a very inefficient locking method. - change the format of the mailbox. If it's currently mbox, try it as maildir (or visa-versa). See this for some fun discussion: http://www.courier-mta.org/mbox-vs-maildir/#theend > As to unresponsive UIs, I came across an interesting interview* with a > developer (CK, just about sure; very distinctive name) who did Many Good > Things for the kernel, but said farewell to helping with kernel > development, iirc because he felt that senior Linux developers apparently > didn't care much about UI response times and such. > *in an online Australian (iirc!) journal (apc? I know APC makes UPses...) I wonder what the issue was specifically, since the kernel has been incorporating a lot of the low-latency/real-time patches lately, mostly in the name of audio support. To me, that seems like probably the same type of stuff the kernel would need to manage UI response times... Matt -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ Discuss mailing list [hidden email] http://lists.blu.org/mailman/listinfo/discuss
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |