Alternative view: by date.
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, gettingNo 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 singlefswebcam
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.