Harvard Business School of Echec - GNOME

mono apps power consumption

Benoît Dejean — Fri, 10 Oct 2008 23:10:00 +0200

Any idea why mono apps write/update ~/.wapi/shared_* files every 40s ? These files are mapped and their timestamp change even when sleeping... Please help

update: bug forwarded upstream

Thumbnails explosion

Benoît Dejean — Fri, 05 Sep 2008 13:32:00 +0200

Fri Sep 5 13:02:56 CEST wafl.dir.size.max:warning: Directory /vol/vol0/users/luser/.thumbnails/normal/ reached the maxdirsize limit. Reduce the number of files or use the vol options command to increase this limit.

Huhu. There were actually 2 x 135k files under this users's ~/.thumbnails/normal and .thumbnails/fail directories

This is RHEL 4.5, there's already a bug about it (i can't find it, but i'm subscribed to it).

I can see that ext4 raised it's dirsize limit from 32K to 64k, looks like it's not enough

API superhero

Benoît Dejean — Fri, 08 Aug 2008 21:30:00 +0200

There's a one 1.4K patch for policykit (now an external depency) support for system-monitor (~7K SLOC) to basically replace 3 lines of gksu. Oh yes i know "it's so much powerfull" (that you have to rewrite kill, renice, etc). I'd rather depend on the new Linux file capabilities...
Kov was already my hero because of the clean design of libgksu API...

He's now my superhero !

ABI vs. API compatibility

Benoît Dejean — Tue, 22 Apr 2008 08:39:00 +0200

glibtop_get_proc_mem

libgtop has a function glibtop_get_proc_mem to retrieve basic memory usage of a process. It fills a struct glibtop_proc_mem which looks like:

struct _glibtop_proc_mem
{
	guint64	flags;
	guint64 size;	
	guint64 vsize;
	guint64 resident;
	guint64 share;
	guint64 rss;
	guint64 rss_rlim;
};

Yes, size/vsize and resident/rss look like duplicate. At least on the linux implementation, even if size/vsize and resident/rss come from /proc/self/stat and /proc/self/statm, you can see in linux/fs/proc/{array,task_mmu}.c that they have the same values. So, it seems to me that the only unique members of struct glibtop_proc_mem are size, resident and share (ok there are also flags which flags which members are filled and rss_lim).

linux proportional set size

Linux 2.6.25 comes with a new stat in /proc/self/smaps called pss which is even smarter/accurate than private_dirty. There's glibtop_get_proc_map which currently have all the smaps member but not this new pss. So what is the smarter way to get this new pss in libgtop without breaking everything ?

- break the ABI ?

I could simply extend struct glibtop_proc_map. That would break the ABI, which i'm allowed to because libgtop is desktop. But that's bad practice since packagers have to rebuild everything. That's a painful migration that may delay the adoption of newer versions of the library.

- break the API ?

What about cleaning up the glibtop_proc_mem duplicate members, mark unused some of them and rename rss to pss while keeping it binary compatible ? That would make the API a bit more sensible. I've scanned the Debian/unstable archive and that would break the build 3-6 packages but i would be able to submit trivial patches to fix glibtop_get_proc_mem usage. (And also add glibtop_init(); which are missing everywhere).

- hide `pss` inside `rss` ?

So what's best ?

WTF

Benoît Dejean — Tue, 18 Mar 2008 13:43:00 +0100

system-monitor is getting famous !
(This is bug#418652.)

Power management failure

Benoît Dejean — Thu, 21 Feb 2008 00:15:00 +0100

Tonight i was hacking on my ibook on my sofa watching Extreme Makeover. Then "peeeeeeeeeeeewwwwwwwwwwwww". No more battery.
I haven't received any warning at all. Maybe gnome-power-manager is a bit broken currently on Debian/sid because of hal/s2ram/whatever on ppc. I mean s2ram and hal works, but no the way gpm likes them too (i have to manually run s2ram to suspend). But at least , I would have expected gpm to warn me, and then shutdown my laptop. Yep, i've checked, when the battery level becomes critical, it should have poweroff. But that did not happen.
Now i only trust the battery gauge LEDs.
Happy End: thanks to reiserfs and emacs, i haven't lost a single line of code

GNOME system monitor team

Benoît Dejean — Mon, 10 Dec 2007 19:20:00 +0100

Bienvenue Karl !

bootparam mem=128M

Benoît Dejean — Sat, 24 Nov 2007 22:21:00 +0100

Emmanuel is right. A lot of people in the world, our users, have computers with 128MiB. I can't believe it's possible to run GNOME with that few memory. At least you have to kill a couple of applets and disable all python plugins.
So on 12/8 i will boot my laptop with boot=128M for one day, to see what it feels like. If you want to follow me...

JhAutobuild

Benoît Dejean — Wed, 05 Sep 2007 10:03:00 +0200

JhAutobuild provides jhbuild logs on Debian Etch amd64. That's pretty useful

redundant UI

Benoît Dejean — Fri, 10 Aug 2007 09:48:00 +0200

I don't think i have a bad memory, but even if i had memory like a goldfish, i would still be able to use pidgin :

Filesystem ACL

Benoît Dejean — Thu, 28 Jun 2007 18:59:00 +0200

If you're looking for a good tutorial about ACL, this one is pretty good.
Nautilus doesn't support this yet (gnome-vfs provides support for it), but this looks just like what i'd like to get.

desklets

Benoît Dejean — Thu, 28 Jun 2007 16:03:00 +0200

I can see more and more screenshots about moonlight-based desklets.
Hey guys, gdesklets has been around since Fall 2003 !

Indiana patches

Benoît Dejean — Wed, 13 Jun 2007 14:55:00 +0200

Dear Sun Microsystems, I think your patches are bullshit. Please drop them or as already suggested, do fork.
As the maintainer of system-monitor and libgtop, i have already rejected stupid patches from you. They contain unkown API changes and a lot of dead code. The libgtop patch is the most scary. Here's a tip: libgtop code is OS specific (linux, bsd, solaris, etc have their own separate implementation) so copying linux code to solaris is obviously NOT going to work.
I can see that some of your patches are actually OK, but your people don't seem to understand how we work.
This reminds me of that private mail where you asked me to re-license libgtop to LGPL because you had some kind of packaging issues ... because you wanted to install libgtop in /foo/bar and instead of /foo/baz. Bad for you.

git-merge vs. git-log

Benoît Dejean — Sun, 03 Jun 2007 22:59:00 +0200

I no longer use svn directly for libgtop and system-monitor. I use git-svn instead. I no longer write ChangeLog. But i should because git-merge doesn't seem to preserve revision log. So dear lazy web, how i get the revision log of a branch including all revisions logs comming from merges ? Will it survive branch deletion. monotone propagate can do this but doesn't have a mtn-svn yet :/

a system crash ruined my weekend :/

Benoît Dejean — Sun, 03 Jun 2007 19:34:00 +0200

I was trying to move some Scrubs xvid from my laptop to my large screen computer using samba. I first tried gnomevfs but it was too slow : it was painfully reaching 1MiB/s using 100% CPU which is not right when moving 4.4GiB. I know i could directly use cifs instead but i switched to smbnetfs (FUSE Samba browser) which can reach easily 10MiB/s (~physical limit, i think smbnetfs has 10% overhead compared to a manual mount). smbnetfs is usually fine but using it with nautilus is the WORST idea i had since a long time. File copy did not work because nautilus claimed there was no space on device. I was about to quit but i wanted to also delete some files. I clicked 'move to trash' ... worst thing ever : my computer got instantly locked. I don't know who (gnomevfs, nautilus or fuse) started a fork bomb or a syscall storm but it was quite effective. I couldn't even log in on a tty. It's the first time since i use GNU/Linux that i lock my computer that hard. Hard reboot and data loss.

memory upgrade

Benoît Dejean — Thu, 19 Apr 2007 23:11:00 +0200

Since I upgraded my ibook from 512MiB to 1.25GiB, i live in a new world. I should have upgraded earlier to put an end to my nightmare.

User memory usage is now 450MiB so the kernel/disk/buffer cache is big and makes my system faster than ever

Back when i had only 512MiB, i used to have 300MiB of swap usage :

the switch between evolution mailer and calendar used to take 15s. It's now 3s !
starting a new terminal now only takes 1s where it lasted up to 10s !
the gnome-menu is totally new to me : it's fast ! it instantly popups where it used to trash my disk for 3s before opening.
etc, etc

You can't really understand memory issues if you don't run a computer with <= 512MiB. So boot your computer with mem=256M and enjoy

webcam integration

Benoît Dejean — Mon, 12 Mar 2007 12:30:00 +0100

I saw my cousin on Sunday. He showed me his shiny new MacBook. It is his first own computer so he is very proud of it and really enjoys the builtin webcam.
He wanted to take a photo of me : he told me to seat in front of the laptop, he then launched photo booth and took 2 shots. This application is really nice, perfect UI : single button and a countdown. Do we have anything like that ?
Then he added me to his contact list : he entered my email and as he also wanted to have my picture in, he just clicked to launch a mini photo-booth and take a photo. This is a great feature we should have in evolution.

Webcam never seemed so easy.

libsexy bugs

Benoît Dejean — Fri, 02 Mar 2007 11:15:00 +0100

Hey chipx86, would you please have a look at libsexy bugzilla ? There are a couple of annoying bugs about sexy_treeview so I had to disable libsexy in system-monitor 2.17.x.

Thanks.

gnome-system-monitor 2.17 has been compromised

Benoît Dejean — Wed, 28 Feb 2007 10:45:00 +0100

Last night, Matthias Clasen and Shaun McCance helped me fix a gnome-doc-utils bug in gnome-system-monitor tarball. I then released gnome-system-monitor-2.17.93 because I am the maintainer.

Then, somebody, who owns a regular svn/ssh account, has commited without approval unreviewed content to gnome-system-monitor trunk. He also tagged the wrong way. And in the end, he released gnome-system-monitor-2.17.94. I don't know anything about this man. I've just got an email from him to tell what he has done. Update: he even created&closed a bug against system-monitor.

gnome-system-monitor 2.17.94 is not official and not trusted at all. DO NOT USE IT.

The following are unreviewed, not trusted and have unknown content :

SVN tag GNOME_SYSTEM_MONITOR_2_17_94 and revision 1935, 1936, 1937 and 1938
gnome-system-monitor 2.17.94 tarballs on the GNOME ftp server.

Today 28/02/2007, only the following are trusted and official :

SVN tag tags/GNOME_SYSTEM_MONITOR_2_17_93 and revisions up to 1934
gnome-system-monitor 2.17.93 tarballs on the GNOME ftp server.

Security infrastructure

It would be nice to be able to GPG-sign tarballs that are uploaded to the GNOME FTP server.

evolution + bogofilter

Benoît Dejean — Sat, 17 Feb 2007 02:14:00 +0100

There is no standard bogofilter plugin for evolution. I am not happy with spamassassin/spamd/spamc CPU and RAM requirements. Like 'sa-learn --version' which takes 1.8s even on warm start...

So I wrote a tiny (stupid) ruby script to emulate SpamAssassin programs with bogofilter.

#!/usr/bin/env ruby

# 1 spam, 0 not-spam
def bogo_exec(mode)

  system 'bogofilter', '-l', mode

  exit case $?.exitstatus
    when 0
    1
    else
    0
  end
end

if ARGV.include?('--version') then
  print "SpamAssassin version 3.1.0-bogo
"
  exit
end

if ARGV.include?('--spam') then
  bogo_exec '-s'
end

if ARGV.include?('--ham') then
  bogo_exec '-n'
end

if ARGV.include?('-c') or ARGV.include?('--exit-code') then
  bogo_exec '-u'
end

I then created symlinks {spamassassin, spamc, spamd, sa-learn} -> spam.rb in my PATH. Maybe it WAS incomplete and broken, but it NOW works. No more daemon. Mail retrieval is no longer CPU-bound. Evolution and I are happy.

Update

I have fixed the script. To feed spam/ham here is what i did :

selected a bunch of messages in evolution and Saved As '/tmp/mails'
run sa-learn --spam < /tmp/mails or sa-learn --ham < /tmp/mails