mardi, 22 avril 2008
Par Benoît Dejean le mardi, 22 avril 2008, 08:39 - GNOME
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 ?
mardi, 18 mars 2008
Par Benoît Dejean le mardi, 18 mars 2008, 13:43 - GNOME
system-monitor is getting famous !
(This is bug#418652.)
jeudi, 21 février 2008
Par Benoît Dejean le jeudi, 21 février 2008, 00:15 - GNOME
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 
lundi, 10 décembre 2007
Par Benoît Dejean le lundi, 10 décembre 2007, 19:20 - GNOME
samedi, 24 novembre 2007
Par Benoît Dejean le samedi, 24 novembre 2007, 22:21 - GNOME
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...
mercredi, 5 septembre 2007
Par Benoît Dejean le mercredi, 5 septembre 2007, 10:03 - GNOME
JhAutobuild provides jhbuild logs on Debian Etch amd64. That's pretty useful
vendredi, 10 août 2007
Par Benoît Dejean le vendredi, 10 août 2007, 09:48 - GNOME
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 :
jeudi, 28 juin 2007
Par Benoît Dejean le jeudi, 28 juin 2007, 18:59 - GNOME
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.
Par Benoît Dejean le jeudi, 28 juin 2007, 16:03 - GNOME
I can see more and more screenshots about moonlight-based desklets.
Hey guys, gdesklets has been around since Fall 2003 !
jeudi, 21 juin 2007
Par Benoît Dejean le jeudi, 21 juin 2007, 09:39
I have a commit access to GNOME svn, so i'm able to do whatever i want with my code, and then commit it. My main free software contribution has been GNOME for a long time.
I've recently started to hack on awffull (log analyser, it's a webalizer fork, but webalizer is dead). I keep submitting patches on the mailing lists, i'm mainly interested in memory usage, which is a real issue with huge logs, and even more on 32bits (allocating more than 2GiB is risky). One of my patch provides a 7% memory usage improvement by using flexible arrays : this saves millions of malloc calls so heap admin / malloc overhead is much lower.
But, even if Steve (upstream) and the mailing list people are great and very responsive, my patches have not been merged yet. I totally understand why they are not already merged, but i have no way to provide my branch to other awffull fans. So i started stacking everything in a local git repository. But now I need again and again to resplit the patches because upstream just can't merge my changes. I now realize how much we need distributed control system (git, monotone, etc). Without it, patches get lost on mailing lists, they get obsolete, they don't apply anymore ... a big waste of work.
With a distributed control system, upstream is able to pull from contributors, merge or cherrypick.
I'm frustrated about awffull, i now better understand how people could be frustrated about GNOME.
I am sorry for everyone (hackers, packagers, etc) who work hard on free software but are unable to (easily) get their job upstream because of the stupid VCS we are still using.
mercredi, 13 juin 2007
Par Benoît Dejean le mercredi, 13 juin 2007, 14:55 - GNOME
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.
dimanche, 3 juin 2007
Par Benoît Dejean le dimanche, 3 juin 2007, 22:59 - GNOME
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 :/
Par Benoît Dejean le dimanche, 3 juin 2007, 19:34 - GNOME
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.
jeudi, 19 avril 2007
Par Benoît Dejean le jeudi, 19 avril 2007, 23:11 - GNOME
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
lundi, 12 mars 2007
Par Benoît Dejean le lundi, 12 mars 2007, 12:30 - GNOME
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.
vendredi, 2 mars 2007
Par Benoît Dejean le vendredi, 2 mars 2007, 11:15 - GNOME
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.
mercredi, 28 février 2007
Par Benoît Dejean le mercredi, 28 février 2007, 10:45 - GNOME
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.
samedi, 17 février 2007
Par Benoît Dejean le samedi, 17 février 2007, 02:14 - GNOME
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\n"
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
lundi, 12 février 2007
Par Benoît Dejean le lundi, 12 février 2007, 11:22 - GNOME
3 years ago, i deleted code that i didn't understand in libgtop. It was a mess about bitwise shift and xor.
Then came these bugs about system-monitor displaying 17179869184.0 GiB. This is about available disk space (you know, the 10% reservation for root, etc). On *BSD, available disk space can be negative... so you can get df to reports negative capacity :
$ df -h /
Filesystem Size Used Avail Capacity Mounted on
/dev/ad10s1a 496M 457M -514K 100% /
(This reminds me of mfs fun with OpenBSD 
libgtop uses statvfs/statfs functions to get disk space usage : struct statvfs members' type is fsblkcnt_t which is an unsigned integer. This means that some kernels store signed values as unsigned integers. Hence the old fun code i deleted. glibtop_fsusage members are guint64 so there is not signedness mismatch between libgtop and the system.
As I was unable to get negative values with linux 2.6.20 and ext3, I dig into GNU df code and found the very same code that was in libgtop, i guess someone copy&pasted it into libgtop a long time ago. This code does funny things to handle integers with the top bit set as negative integers.
I ended to this madness by ensuring available disk space is <= to free disk space.
jeudi, 25 janvier 2007
Par Benoît Dejean le jeudi, 25 janvier 2007, 08:39 - GNOME
I have commited a great but simple patch from Lucas Mazzardo Veloso . It uses Bezier Curves to draw the load graph instead of lines thanks to cairo. Sorry, dotclear 2.0-beta5.4 is buggy, i can't attach a screenshot.