You're pretending people are mocking Mrs Segolène Royal because she's a woman, well, I don't think it has any chances to be true. It's IMHO a reason for many people to be addicted to her without even thinking to listen to what she says.

I've listened to many of her interviews, those are pathetically void and empty. She's not able to use correct and decent French, and when I listen to her, I'm often under the impression to talk to my butcher. If I imagine her in the middle of an internationnal summit, I'm just plain afraid. When I try to sum up her ideas, I come up with a big nothing. That's just air and wind.

I can't say the UMP is very kind with her but hey, she's a candidate to the presidency, she should grow a skin, chose a real communication manager (Montebourg, BWAHAHAHAHAHA), etc… Recently, presidency candidacy has begun to look like a show. She's making pirouettes over pirouettes. How can you blame other candidates to just push her a bit so that she fall on the nose ? That is indeed unfair, but:

• it has nothing to do with the fact that she is a woman, that's a very very very bad argument, to me it's even in her disfavour, because it looks like that: « look it's only a woman, please be kind with here » WTF? if she's going to be the French President she has to be a bit stronger than that, and beeing a woman or not is totally irrelevant ;
• I'm not sure she really needs to be pushed hard to fall, her campaign (atm) is a long succession of "rattrapage aux branches".

So I'm under the impression that you defend her because she's a woman, which is certainly a way for chosing your favourite candidate, but it's not in my criterion list (neither as a pro or a cons) for such an election. And I'm not that sure she won't attend to the second turn. The "She's a woman" criterion will weigh on the election in a way that we didn't met before, and that is very hard to estimate.

The discussion about hooks in dpkg able to run some kind of commands (ldconfig, update-menus, …) occured more than once on the list. I've grown tired of many of the packages upgrades that wanted to rebuild my initrd's three time in a round, or to the incessant fc-cache runs, and so on.

So I've hacked a tool called apt-delay, that achieves that, through some hacky $PATH manipulations, diverts some commands to very small ones that just record that they have been called, and then an apt DPkg::Post-Invoke command lists all of them, and run them at the end of each dpkg round.

Even it may look ugly, it's very small, sloccount says:

   ansic:          548 (91.79%)
   sh:              49 (8.21%)

It now only deals with update-initramfs, ldconfig and update-menus, as a proof of concept.

You can try it yourself, you just need to:

   $ git clone git://git.madism.org/apt-delay/
   $ cd apt-delay
   $ debuild # only needs debhelper
   $ sudo dpkg -i ../apt-delay_0.0.1_${arch}.deb

and that's all.

You may want to tweak /etc/apt/apt.conf.d/99apt-delay and use /usr/lib/apt-delay/post-invoke -d that will enable some debug output, so that you can see at each apt run what has been delayed or not.

Please remember that this is a proof of concept (even if it should not harm your computer, it may have problems, or even be broken sometimes ;P)

Comments, thoughs, ideas are obviously welcomed.

your work is very much appreciated.

that's an incredible tedious work. Really thank you.

I'm quite upset with the POSIX APIs. I'm trying to write some kind of simple piece of software, to be included in a mail chain, doing a lot of DNS queries, mostly to RBLs.

I've met two kind of problems:

1. the POSIX API is synchronous, and absolutely no usual API for non blocking requests exists, there is of course:
   • adns, but it's very bloated, does not work with ipv6,
   • c-ares, but it's quite bloated, does not work with ipv6, and need select (cannot be used with epoll e.g.),
   • libdnsresolv (hahahaha, that's an horrible patch over the BSD resolving API, it's horrible, yuck),
   • udns, that's the best of the four, but still, the code do not feels very well, solid (do not check recvfrom/sendto errors e.g.).
2. there is no way to escape the system resolver, which is good for usual applications, but very bad when it come to RBLs.

The second point is in fact the worse. On mail queues I administrate, there is also very often a bind that is used as a caching DNS resolver. Very well, except that it complectely sucks with RBLs. RBL generate a lot of queries that resolve and that you will almost never ask again before its TTL expires, and the other kind of queries you do get NOT FOUND answers, that are usually not cached.

Too bad, the most useful answers are the NOT FOUND ones, and the cached answers are just here to make our local cache use huge amounts of memory for nothing. So RBLs just end up poisonning your system efficiency. That's quite ridiculous.

I'd really love to have a decent async resolver API, and a way to tell my DNS cache (here BIND) that the domains serves a RBL, and that I (for at the same time the sake of the RBL and from my system) want specific caching features for it. I fear that it wont be possible, and that I will end up writing some API specifically designed to craft DNS queries to the RBL servers (once again there is absolutely no reason to use forwarders for that, as it will end up by screwing your forwarder cache for almost no gain, and won't save you from a lot of useless queries with no answers at all).

The good point is that the kind of queries you need to do to RBL servers is indeed completely trivial:

• only A and maybe one day AAAA queries ;
• a query will never be greater than 512 octets, so only UDP is needed ;
• you only have to ask the NS that serve your RBL (and here we use the local resolver API, to benefit from the caches), and query that RBL, no recursion is needed.

Then implementing on top of that some efficient caching (RBL-aware) will be rocking fast, and way more efficient than bind caching, without the poisonning effects. A big gain — I hope. What suprises me the most, is that I've not found anybody speaking about those side effects of RBLs on nameservers, almost no discussion at all. Very surprising for a protocol that is so vital for the internet as a general rule.