lundi, 10 septembre 2007
Par Benoît Dejean le lundi, 10 septembre 2007, 22:44
So this weekend, i used a DSL without any NAT, so my laptop was assigned a public IP by DHCP. My ulog log was spitting a lot, mainly on tcp port loc-srv / 135. Instead of sending REJECT, i opened my iptables and started the following ruby program to actually open all these connections. When someone sends me a SYN, I reply politely.
require 'socket'
require 'etc'
nobody = Etc.getpwnam('nobody')
loc_srv = Socket::getservbyname('loc-srv')
Dir.chroot('/var/run/empty')
Dir.chdir('/')
server = TCPServer.new(loc_srv)
Process::UID.change_privilege(nobody.uid)
print <<"EOF"
uid/euid #{Process.uid}/#{Process.euid}
chrooted in #{Dir.pwd}
listening on address #{server.addr.inspect}
EOF
clients = []
loop do
begin
client = server.accept_nonblock
rescue Errno::EAGAIN, Errno::ECONNABORTED, Errno::EPROTO, Errno::EINTR
IO.select([server])
next
end
# remember client so the connection stays opened
clients << client
print "#{client.peeraddr.inspect} connected\n"
end
This script needs to be started with some privileges in order to bind on 135, but then it drops its priv and chroot to somewhere safe. That was very instructive, after ~10minutes, ss | grep -c loc-srv was reporting more than 280 connections from ~80 differents hosts.
What a storm. I'm definitely safe under my GNU+Linux umbrella 
And Ruby is fun 
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.
mercredi, 30 mai 2007
Par Benoît Dejean le mercredi, 30 mai 2007, 12:33
I don't like the way bugs are handled on Mozilla's bugzilla. The Firefox Preferences UI is totally screwed :

which is obviously an arch-dependant bug.
Edit: Thanks everyone who also reported the same bug. It is actually a 2 year old bug
vendredi, 27 avril 2007
Par Benoît Dejean le vendredi, 27 avril 2007, 16:02
Au début de ce mois, à l'invitation de mon ami Luc, RMS est venu donner une conférence sur le logiciel libre dans les locaux de l'UPPA à Pau. Sa conférence portait plus précisément sur les libertés garantie par la GNU GPL et l'Eglise d'Emacs. L'UPPA vient de publier la video (596Mio) de la conférence.
dimanche, 22 avril 2007
Par Benoît Dejean le dimanche, 22 avril 2007, 00:51
I have discovered a nice bug in my code. I had some stuff about iterating a std::list<> and removing some elements at the same time. Like the following :
std::list<> l;
iterator it(l.begin());
while (it != l.end()) {
if (...)
it = l.erase(it);
else
++it;
}
Then i moved from std::list<> to std::set<> (ordered set). The code didn't compile as is because std::set<>::erase returns void. The STL documentation says Erasing an element from a set also does not invalidate any iterators...
. OK then, no return value.
std::set<> s;
iterator it(s.begin());
while (it != s.end()) {
if (...)
s.erase(it);
++it;
}
It worked nicely for a long time. But once i got a double free crash. In order to debug it, i added many print. For example {1 2 3 5 6 7} - {3} shoud have printed {1 2 5 6 7} but instead i got {1 2 2 5 6 7} or {1 5 6 7 2} !
So i read again the documentation : Erasing an element from a set also does not invalidate any iterators, except, of course, for iterators that actually point to the element that is being erased.
. Bon sang !
The correct way to do it :
std::set<> s;
iterator it(s.begin())
while (it != s.end()) {
iterator next(it);
++next;
if (...)
s.erase(it);
it = next;
}
vendredi, 20 avril 2007
Par Benoît Dejean le vendredi, 20 avril 2007, 11:01
I am a big fan of the bash completion feature but i recently discovered it has a cost : my bash heap is 3536KiB.
This looks big because I often run more than 10 shells.
So i tried -norc --noprofile and heap was then 932KiB, more decent. Just for fun, I straced bash and discovered that it was sourcing twice /etc/bash_completion and as there is nothing to prevent it from being reloaded, it really loads and process twice the same completion files. I checked my /etc/bash.rc and ~/.bashrc and they were both . /etc/bash_completion.
I've fixed my ~/.bashrc and bash heap is now 2232KiB. x10 so it actually saves up to 10MiB of memory on my system: yahoo !
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
mardi, 3 avril 2007
Par Benoît Dejean le mardi, 3 avril 2007, 15:06
I am working on a bunch of utilities in ruby to process logs and parse hundreds of webalizer reports. I track my work with monotone which runs fine on Windows. I also use monotone to track appliances configurations.
One on my scripts analyses about one thousand of HTTP documents of ~50KiB each. ruby net/http module is perfect to retrieve them. This script is quite slow because of the regex it uses like %r|Foo.+?<B>(\d+)</B>(?:.+?Bar.+?<B>(\d+)</B>)*|m. But as the script runs every night on my desktop, I don't really care if it takes 10 seconds or 10 minutes. It is clean and easy to extend and that's what matters to me.
I have found that slow regexp is a common ruby issue : here's a simple demonstration. More details about regular expressions performance.
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.