Deferring the execution of a command

More than once, I have found myself running a program that calls a given script multiple times, and sometimes, way too many times. In some cases, for instance, it was only necessary to run the script once in one minute, instead of hundreds of times.
Sounds like I want something like dpkg's deferred triggers, right? pretty much so.

With this need, deferred-run was born. Example:

$ deferred-run -l lock -- echo hello world
$ deferred-run -l lock -- echo hello world
$ sleep 3
$ deferred-run -l lock -- echo hello world
[some seconds later...]
hello world

In spite of multiple calls, echo was only called once.
Best part, it only requires sh and flock.

If you are interested in shell trickery, you should take a look at its code.

ldebdiff: what local change did I make to a package?

When fixing or modifying a package I at times change the installed files directly. However, once the changes are okay and it is time to prepare a diff, having to keep track and manually diff'ing the installed files is time consuming.

That's when ldebdiff does its thing: it runs diff against the original files of a given package and the ones installed on a system.
For example:

$ ldebdiff acpi-fakekey
--- unpacked/etc/init.d/acpi-fakekey    2012-04-05 05:14:21.000000000 -0500
+++ /etc/init.d/acpi-fakekey    2012-04-12 12:10:55.000000000 -0500
@@ -4,8 +4,8 @@
 
 ### BEGIN INIT INFO
 # Provides:          acpi-fakekey
-# Required-Start:    $local_fs $remote_fs
-# Required-Stop:     $local_fs $remote_fs
+# Required-Start:    $remote_fs
+# Required-Stop:     $remote_fs
 # Default-Start:     2 3 4 5
 # Default-Stop:      
 # Short-Description: Start acpi_fakekey daemon

($remote_fs implies $local_fs)

Installed-Size: 0

Redefining the meaning of Installed-Size:

Package: gcipher
Version: 1.1-1
Installed-Size: 0

$ dget gcipher=1.1-1
...
$ dpkg -x gcipher_1.1-1_all.deb gcipher
$ du -hs gcipher
188K    gcipher
$ du --apparent-size -hs gcipher
75K     gcipher

On mirrors and why there are so few

Yes, I said few.

Even if in my blog post about Debian's ever-growing mirrors network it seemed like we have a lot of mirrors, truth be told: they are too few. There are many partial or even complete mirrors out there that are not listed.

If you are the administrator of one of those mirrors, please consider submitting your Debian mirror. It helps keep track of them and expose them to more users.

Granted, there are some that due to policies (on remote connections, bandwidth use, etc.) they are kept private. Hidden behind a LAN, hoping that people inside actually use them. As of this time, there's not much that can be done about them. If they were to be listed somewhere, there's no way for somebody to check them from the outside.

Some other mirror networks require that an IP (or a range) be whitelisted, allowing them to access the mirrors from the outside to perform routine checks. For some reason, I thought Fedora's was one of them but, apparently, they use a different approach: they ask private mirrors to run a tool.

I think that each approach has its pros and cons.

An ever-growing mirrors network

As of the time of writing, Debian's mirrors network has around 330 mirrors serving the archive over http, and around 300 serving it over ftp.

This month alone, 6 more mirrors were added. Other 6 more were added last month.

There are mirrors in 73 countries. All this couldn't be possible without the help of the sponsors.

However, some interesting questions arise: do people actually use those new mirrors? is having so many mirrors worth the extra load put on the primary mirrors?

I would personally answer: no, and maybe.

Blogosphere: When was the last time you took a look at the mirrors list and/or tried to find a mirror that served you better?

Your APT caching proxy is not that efficient

So you read about an "APT caching proxy" and that it can "save time and network bandwidth."
Sounds like something you should have, right? After all, the trade-off is just some additional disk space. APT already has its own cache at /var/cache/apt/archives/, so part of what the caching proxy would store in disk is already there.

Truth is, for a single client a caching proxy might not provide any benefit and might even cause a slowdown, but for at least one of the alternatives it is even worse: every request that goes through the proxy that requires a download from a mirror creates a new connection.

It is 2012 and a piece of software that aims to "save time and network bandwidth" can't even use keep-alive connections?

You are doing it wrong...

... when you join a team and then every other team member stops working.

(There's a possibility that you are doing such a great job that there's no need of the others, but think about the case when your work or your way of working is killing them.)