Wow. I just stumbled over the SIL Fonts, which I haven't heard of before. Looks like an absolutely great project. Not only are these fornts released under an open license (I haven't read it myself, but many of these fonts are in Debian...), but above all I really liked the selection of supported systems with icons by each entry: The Old Windows 3.1 Windows flag stands for tested on Windows , the very old rainbow colored apple for tested on Mac , our official (and current :-) familiar swirl not only for tested on Debian, but for Debian package available . I mean: while it's not uncommon today to see some kind of Linux support in software (or other downloads), explicit Debian support is not that widespread. And seeing this side by side with the two very outdated logos for the two other mainstream OSs (and Ubunut not even being mentioned on this page) is ... what, exactly? Wishful thinking? An ironic comment on how the (conputing) landscape should look like? Made me smile, in any case.

In a time where things should be calming down in preparation of christmas, some have it a bit more hectic than the'd probably hoped.

I know, preaching to the choir and all that. But this can't be said often enough (and perhaps the odd non-Debian person stumbles upon this...): Here's another example of how amazingly fast free tech support works: The newest Linux kernel (Debian package version: 2.6.32-1) wouldn't boot on my QNAP TS-419P NAS (see also my earlier posting about the device). Now, since I don't have a serial console cable, I can't really help a lot to debug this (and I am extremely happy that the people at QNAP have thought about recovery: it's trivial to just flash a working kernel or firmware image via DHCP and TFTP), bu still Martin Michlmayr immediately took the time to help me and soon could reproduce it on one of his own machines. The problem has been identified, I got a fixed kernel, and a patch is on his way to the kernel maintainers. All in the after literally just a few days.

Biggest, in terms of money involved, piece of equipment is a nice piece of glass to put in front of our camera. Since my wife had been using a Canon SLR since forever (and we stayed with that when moving from the EOS 300 to the current EOS 40D), the choices to upgrade from the kit EF-S 17-85mm f/4-5.6 basically have been:

• EF-S 15-85mm f/3.5-5.6 IS USM: since it's been announced with the 18Mp 7D it should be quite good on the 10Mp 40D. Newest design, certainly one of the best IS on Canon, true wide angle.
• EF 24-70mm f/2.8 L USM: The old trusted one. No IS, but a constant f/2.8. Narrowest zoom range of the lot. A real tank, at almost 1kg.
• EF 24-105mm f/4 L IS USM: The other full frame L lens. Not quite as big, longer, but only f/4.
• EF 24-70mm f/2.8 L IS USM: including waiting for it to be announced and available, of course.

In the end I got the EF 24-70mm f/2.8 L USM, because the EOS 40D is no high ISO monster (we don't plan to upgrade immediately.) Also: I bought the Tokina AT-X 116 PRO DX (11-16mm, f/2.8) a while back and we're quite happy with that so wide-angle is covered. And since we're often shooting indoors (family and other events), f/2.8 is a big plus. On the tele end, there's quite a gap from the 24-70 to the old EF 100-300mm f/4.5-5.6 USM [age of the page to reflect the age of the lens ;-) ] but then the latter is probably the next lens to be replaced anyway. Since I only got 24-70 I can not directly compare these lenses. But after a few early tests I think I'm happy with the 24-70: while it seems to be a bit soft wide open at 24mm and at 70mm, it seems to be very sharp center to edge even at f/2.8 when used in the 35-50mm range. (Note that the 40D is a crop sensor camera, so I'm nicely using the sharp center area of a lens designed for full frame!) Yes, it's huge, so for casual walking around the 17-85mm will probably still get some use. Time will tell. And since it can, potentially at least, be used on a a EOS 5D Mk II, I now have another gadget to covet. Although this would mean giving up the Tokina 11-16mm. Anyway, not for quite some time yet... (The test also included the venerable EF 50mm f/1.8, Mk I, and I must say I'm quite surprised how sharp that one is in the f/4 to f/11 range.)

After I had been living with mostly the same electronic toys over the last few years (ok, I got the netbook earlier this year, but that's about it... and it might even count as a serious work tool given how much I came to use it) all the toys I've agonized over buying suddenly appeared on the doorstep within these two weeks... First part was the QNAP TS-419P which I bought after reading about QNAP on Martin Michlmayr's blog. The decision was quick when I realized that at least part of the Debian related information was not hidden in some obscure web forums but was there on the QNAP wiki itself, indicating quite some level of support from the manufacturer. Beyond that, tbm does an awsome job supporting QNAP users like myself through his excellent QNAP / Kirkwood pages and also, since Debian installer support for the 419 is not quite finished, by email. Kudos to him! So, once I get past some remaining obstacles (for some reason, the initrd refused to mount a raid1 root device when I tried it at first; working on that, but it's not that easy to debug without console access...) our old storage / Internet router (very old! Pentium II 350MHz with 128M RAM and its probably third internal disk, which became ridicolous to use when I bought a (big) external USB disk and realized it only has USB 1...) can be retired. Should be good for the environment, too, I should hope, in terms of power consumption even considering that I now run 3 more disks.

Yesterday was a very disappointing day: it was officially determined that there are more idiots than non-idiots in Switzerland :-( I hope this will get corrected soon, but I fear it won't.

Just read Mark Kretschmann about application naming. Another consideration is: will the name show up in Google? Some projects have been extremely bad at this, the prime example I'm thinking of is the KVM virtualisation module in Linux. I'm treating KVM as the name here, since the term Kernel-based Virtual Machine is not even a name, really... (ok, it has become popular enough so that linux-kvm.org now shows up at the top.)

I was just seeing the headlines about Google's SPDY technology which, as far as I understand right now (haven't read the LWN article yet) is trying to accelerate HTTP by doing fancy things within the TCP stream. I'm just thinking: why not do HTTP over UDP instead, like DNS does? This would cut down latency for small requests a lot, and for big transfers, the added latency woulnd't matter that much. How could that work?

• For starters: either the browser always tries UDP first and falls back to TCP, or the server could advertise UDP capability in its HTTP headers. Either way, browser would need to have a small cache on where UDP can be used. Given that all browsers already carry lots of databases (content cache, cookies, pop-up policies, form completion, ...) I don't hesitate to propose this additional one...
• If it is established that a server for a domain can handle UDP requests, lots of heuristics could be used to determine wether the browser should send UDP or TCP requests; the end result would always be that the server is free to either respond with the content in an UDP packet if it fits, or decline an UDP answer with a please use TCP 3xx response code.

I figure that with today's JavaScript enabled, Ajaxy web, many requests (and responses, of course) would indeed be small and would fit in an UDP packet (especially since I'd say content should be compressed in any case without special negotiation.) OTOH, encryption would be hard (or, at least in a first protocol revision, not supported) and since persistent TCP connections are available, maybe this is just unnneccessary. I don't know. But I'm not sure if persistent TCP connections are actually that widely in use on web application where a user might click on a button every few minutes. How long do browsers and servers keep the TCP connection open?

I am eager to get feedback on some of my pictures. Some people already liked them, so the ego is quite well right now... :-)

A topic I've been trying to understand more about for some time is color calibration. I've used lprof to get a very rough starting point for my old CRT (sorely in need of replacement by now...) Since hardware colorimeters are not cheap and probably not many can be used with Linux (I've not really looked, to be honest) I've wondered if I couldn't use the one device that is (should be) calibrated that I already have: my camera. With some kind of feedback loop like shoot screen, analyze img file, adjust settings, shoot again (and the same process for the printer, and, possibly a bit more error prone since the freshly calibrated printer would be used to produce the template, the scanner), shouldn't it be possible to arrive at sane settings? The camera explicitly allows using sRGB or Adobe RGB color model, so I'd think the colors should be more or less narrowly defined, at least when shooting raw or using manual white balance. (Another thought: I have a dual screen system. Can X even do this? And if X can do it, is it possible to tell Gimp to set this up? But this is just idle speculatio. I've not really looked at Google's results yet, either.) Update: Haven't really thought about ambient light. But the display emits light, so I'd shoot the screen in a darkened room, with white balance of the camera set manually. OTOH thanks Jo l if I can get a colorimeter for not much above 100$, it's not worth investing too much time. I had always thought these devices were much more expensive. divide_by_zero Yes, I know CRT are usually much better than LCD, but OTOH my screen apparently starts to show its age: it will suddenly, and visibly, change brightness and color every few hours. I suspect the high voltage circuitry is not too stable anymore... And I won't buy another CRT, those things are just huge...

I've just read Vincent Sanders' Bits from the kernel team. First, a big thank you to him: this kind of detailed information about what the team intends to do, down to a very technical level, is needed much more often on d-d-a. Debian is about producing a distribution, which in the end comes down on how to make independently produced pieces of software work together, so getting all the fiddly bits right is the most important aspect of Debian's work. (And it is also where I think Debian still does better than all other distributions I've ever used.) What immediately sparked this article is (could it be otherwise? ;-) the part I didn't like too much about these Bits: ... was discussed ... ... was resolved ... ... further investigation ... would occur. and right at the top ... a member of the release team ... Of course the team should work together as a whole. Of course it isn't really relevant who of the release team was present. Of course, this information is contained in the minutes. But on the whole, these Bits read a bit like a press release of a large corporation where the spokesman reads a communique prepared for him by a marketing team responsible. I miss the personal touch that should in my opinion run in parallel with our promise of openness: it's not only that we don't hide bugs, it's also that we're not hiding behind a corporate identity , but that we're not afraid to name names (No, this is not in a foundation document as such. It's my interpretation of openness.) A start is simple use of active vs. passive: Why not we discussed/decided ... instead of it was discussed/resolved ? (It's used in a few places, I note.) I appreciate that naming names with each action item is probably better left in the minutes, but at least naming the release team member (he's not just a functionary...) and perhaps at the end a short paragraph about who was there would have improved the announcement. Also: none of the items has an ETA obviously Debian is famous for not having any ETA's but we're trying to change this, aren't we? So why not give at least a rough estimate which tasks would take a week, a month, half a year... to complete? I'm sure you discussed it (have yet to read the minutes), if only to guesstimate what is realistic within the timeframe of the squeeze release cycle. Debian not only is no company, but it's also, and I hope I'm not the only person who thinks this is important, a Linux distribution where no corporate body has the power to force changes on the community. The single person is important, because it's the single person who in the end decides to implement a thing this or that way. It may be the outcome of a team discussion and a team's decision, but the work is done by individual people and not by employees impementing a corporate policy.

xor WNS - White Noise Signal with a TIME set of instruction , and a computational temporary set of instructions to produce a real one time PAD when every time

And obviously

this is a none mathematical with zero use of calculation algorithm
...
We use 0% of any mathematical calculation algorithm

I propose we replace the AES implementation in GnuPG by this revolutionary new encryption non-algorithm which will be open for all as an open source free for personal use only (Brought to us, you may have suspected this by now, by Bruce Schneier)

Ross Beazley, you do not have permission to re-publish my blog entries (without even asking for permission, without a link back to my blog, and with added ads no less) on your blog. I expect you to remove all my articles within the next 2 days (you are aware that what you are doing is copyright violation?) I don't see a way to contact you on the aforementioned web page either. (To people on Planet Debian: he is mirroring the whole Planet Debian. Maybe I'm the only one who doesn't like this?)

Yes, this is a dear lazyweb... I'm more and more confused about IPSec on Linux. Has anybody done a more or less recent summary about IPSec and Linux? All I find is quite old and probably doesn't apply anymore... About the only thing I'm sure about is that FreeS/WAN is officially dead. But otherwise? Openswan vs. strongSWAN vs. KAME (or is that ipsec-tools?) And what about the kernel side? Are they now all using the same code or are there still patches? It would probably best if the hypothetical knowledgeable person would not comment here but insert a relevant notice at the top of http://wiki.debian.org/IPsec, to avoid having yet another obscure page (mine) show up in Google...

Yes, we're all doomed. Especially, Debian is doomed. We're relying too much on public key cryptography, which is based mostly on the factorization problem (getting the two big prime numbers that essentially make up a public key is hard.) And now they [Link to Bruce Schneier, where I've got the news from] have gone ahead and have built a working quantum computer, which can solve the factorization problem very quickly. So, will we have to re-check all Debian software that was signed with an RSA key in the last few months? The huge number that the quantum has successfully cracked was:

15

Email on a desktop Unix system is apparently a hard topic. At least, so far nobody seems to have solved it to my satisfaction... That's where the Pony Express comes in: a sensible /usr/bin/sendmail implementation for desktop sysstems:

• No queue, no running processes.
• pass users' email to a mail hub
• support per user outgoing mail hub and SMTP authentication + TLS.
• still allow local mail delivery, so stuff like cron will deliver to local mailboxes.

Mercurial repository is available; Pony Express is written in Python 3. I'll not upload a Debian package right now since as far as I've seen Python 3 is not supported by the usual Python helper scripts. Status: Lots of missing features and probably lots of bugs, but I use it from kmail to deliver mail, and the commandline "mail" also works. But that's the extent of the testing it has received so far, and in addition it's also one of the first things I've ever done in Python, so consider yourself warned. Still, feedback and patches welcome. Update: Daniel, no, I can't. I missed msmtp when I looked for a solution after I saw that nullmailer and ssmtp wouldn't do what I wanted. Update: cate / simon: my apt-cache search skills obviously suck, I didn't find esmtp either. Oh, well... I wanted to learn Python anyway, and since Pony Express is basically a frontend to Python's smtp library, it was not that much work. lamson sounds interesting for other projects, I'll have to look at it. From the description it's not what I want here, though. Marius: kmail does its own queueing, so I usually use the send later option and send non-local email from the commandline only while connected. I'll have to think about a non-daemon, non-cron queue style that suits my need (event-triggered from if-up.d perhaps), but as soon as I start to accept mail that I can't immediately get out of the system complexity goes up quite a bit. Developing PX into a full MTA would still be a fun project and I've got a few other ideas that I could incorporate. Not tonight, though ;-)

Did you know that most pan makers recently were forced to increase their prices because their pan lids (covers?) have the handle on the upper side? The reason is that the maker of our recently purchased pan lid has patented the innovative this side down technique and is now busy collecting license fees from pan lid makers who didn't previously have this idea. (Yeah, sorry, the picture is crap, I didn't pay enough for my mobile phone. But if you doubt me, please have a coffee at my house and admire this high-tech implement.)

Thinking that this might be worth hacking on tail (because I felt the functionality would be better kept there than in head), I started to have a look at its source. Lo and behold! tail -n +N already does exactly this... (Obviously a followup to Zack's comment on my previous posting.)

A script I keep reinventing again and again: installing those binary packages from a self-compiled package where the other (presumably older) version is already installed on the system. I don't have time to make this generic right now, but still...

for i in *deb; do 
    echo $ i%%_* ;
done   xargs dpkg -l 2>/dev/null \
      buthead 5 \
      cut -f 3 -d \  \
      while read p; do
         echo  $ p _4.2.3-1vbi_i386.deb;
      done \
      xargs sudo dpkg -E -i

Update: I don't know how I managed to see -E in dpkg's manpage but miss -O which is right above it. Thanks, Guillem. Josh: Either my english is just not good enough, or the manpage of debi is from a slightly different reality. I just can't make out what, exactly, the tool tries to do. (Ok, since dpkg -iOE does exactly what I want anyway I didn't try very hard either.) Update: RTFM.

Think on the meaning of what you say if you close a bug with could not reproduce .