Problem

Discussions are sometimes started by mailing a few different mailing lists so that all relevant parties have a chance to be aware of a new topic. It’s all nice when people can agree on a single venue to send their replies to, but that doesn’t happen every time.

Case in point, I’m getting 5 copies of a bunch of mails, through the following debian-* lists: accessibility, boot, cd, devel, project.

Needless to say: Reading, or marking a given mail as read once per maildir rapidly becomes a burden.

Solution

I know some people use a duplicate killer at procmail time (hello gregor) but I’d rather keep all mails in their relevant maildirs.

So here’s mark-read-everywhere.pl which seems to do the job just fine for my particular setup: all maildirs below ~/mails/* with the usual cur, new, tmp subdirectories.

Basically, given a mail piped from mutt, compute a hash on various headers, look at all new mails (new subdirectories), and mark the matching ones as read (move to the nearby cur subdirectories, and change suffix from , to ,S).

Mutt key binding (where X is short for cross post):

macro index X "<pipe-message>~/bin/mark-as-read-everywhere.pl<enter>"

This isn’t pretty or bulletproof but it already started saving time!

Now to wonder: was it worth the time to automate that?

While investigating the case of some packages responsible for uninstallability on the s390x architecture, I stumbled upon one FTBFS on a single architecture, reported as #673590 (<insert some nice words about software shipping with a decent testsuite>).

Given the int versus size_t question was asked, I grabbed this old (it’s UNIX!) reference: 64-bit and Data Size Neutrality.

Among other things, it describes the “everything is 32-bit” to “64-bit is becoming the new standard” slow conversion process, where keeping compatibility with existing applications was a high priority. It has a nice description of so-called C data models, making it possible to refer to them quickly: LP32 and ILP32 in the 32-bit world; ILP64, LLP64, and LP64 in the 64-bit world. I won’t go into detail here, this page has a nice table and lots of explanations about pros and cons for those.

(On a personal note, I discovered those on xorg-devel@ when I saw patches floating around, which were about optimizing data sizes for this or that data model, by picking the right types.)

While standards may be boring, this page makes it really easy to understand which data types to use, to ensure the best 32/64-bit compatibility possible. It’s even full of dos and don’ts. See the second half (Porting Issues) for details.

Keeping an eye on something with a webcam is really easy: just a matter of setting up for example (c)vlc to multicast from /dev/videoX to the network, and done.

Example:

# Streaming:
cvlc v4l2:///dev/video0 --no-audio --sout "#transcode{vcodec=mp2v,vb=3072}:std{access=udp,mux=ts,dst=224.0.0.1}"

# Playing, possibly on a remote machine:
vlc udp://@224.0.0.1:1234

Notes:

• v4l2 vs. v4l depending on the distribution (sid vs. squeeze).
• Triple slash needed, two for the v4l[2]:// part, one for the device (/dev/video0).
• Why this address? See Wikipedia’s Multicast address article.

Possible problems:

• If switches don’t have IGMP snooping enabled, throwing multicast at them turns it into plain broadcast. In other words: instead of having packets sent to the hosts subscribed to that multicast address, everyone gets those packets, polluting the network.
• Trying to stream from multiple devices may fail, due to USB bandwidth issues. At least that can be seen with two random devices using the uvcvideo module, getting No space left on device when the second (c)vlc is started.

Where to go from here:

• fswebcam to the rescue! It can capture a frame from a given device. The following options are particularly useful: --resolution to request a specific resolution (the device will fall back to another resolution if the requested one is unavailable); --frames to specify the number of frames to capture (lower noise, but possibly higher blurriness).
• A tiny python wrapper around it makes it possible to set various webcams, with different options (number of frames, delay between two captures, resolution), operating at the same time thanks to the help of the threading module. To avoid encountering the same bandwidth issue, a tiny lock ensures a single fswebcam instance runs at a time.
• That also makes it possible to save all images as videoX-timestamp.jpg and to “log”rotate them after a while, for further viewing/reviewing during a given time window.

• Thanks to ImageMagick, it’s also trivial to process the captured images:

   # Only keep a rectangle of width W, height H, starting at the point (X,Y):
   convert -crop WxH+X+Y capture.jpg capture.jpg
   # Include a timestamp on the top-left corner:
   convert -box white -font Fixed -draw "text 2,12 \"$timestamp\"" capture.jpg capture.jpg
  

• Keeping a videoX-current.jpg symlink for each /dev/videoX device is trivial.

• Add to that a lightweight webserver and a single page showing the most recent capture for each device thanks to the symlinks, with a meta refresh of say 5 seconds, and tada! Keeping an eye on multiple things at once. Of course that’s not a real video, but that can fulfill some needs.