Long live to doc-base Runa wonders: Why aren't we using doc-base? . It's indeed a good question. In the past I've pushed for using doc-base in several places, including obviously packages of mine, but also recently generating by default doc-base entries from OCaml libraries using debpkg ocamldoc, and finally also more than 100 doc-base entries shipped by w3-recs alone for the contained W3C recommendations. doc-base is based on a good idea, i.e. annotating the doc we ship with metadata so that it can be more easily browsed, and is (potentially) far better than asking our users to dig into /usr/share/doc/foo. Still, it is sadly true that in Debian is way underused. My best bet at the reason is that in the past the tools floating around doc-base were sucky. However, in 2007 some of them has dramatically improved their quality, with the noteworthy example of dhelp which has been rewritten from scratch in Ruby by Esteban Manchado Vel zquez closing tens and tens of bugs. My exhortation: please, maintainers, go back and consider (again, if needed) to register your documentation with doc-base, it is helpful and it does work. The next (needed) step for the doc-base world domination will be decoupling its classification hierarchy from that of the Debian menu system, keeping the 2 bound is nonsense. Update Runa submitted bug #469018; cool, because I was just going to do that by myself

Seems as if the Chemnitz Linux Days somehow turned out to be the only Linux event I still attend regularly. These days I miss out on most of them, simply because of a total lack of spare time, however, I somehow always make the CLT ... no matter how big the hassle may be! They're just worth it :) My talk went well, even though I actually got a bit pressed on time this year and had to cut the Q&A part. The (German) slides for my talk are as usually on my talks page.

About a year ago I stumbled upon this post which mentions the following shell keybindings: M-- for pushd .. and M-= for popd. Since the dash and equal signs are very conveniently placed next to each other, this allows fast directory navigation with accessible keystrokes and is especially convenient to move up in the directory hierarchy. Very neat.

Of course I use zsh and not bash, so I had to "port" this hack to zsh, which resulted in somewhat obscure code compared to the bash version:

function up-one-dir   set -E; pushd ..; set +E; zle redisplay; zle -M  pwd   
function back-one-dir   set -E; popd; set +E; zle redisplay; zle -M  pwd   
zle -N up-one-dir
zle -N back-one-dir
bindkey "^[-" up-one-dir
bindkey "^[=" back-one-dir

Not so pretty, but it works. The only problem is that I do most of my shell interaction through shell-mode in Emacs, not in zle-capable terminals. So I also had to write a shell-mode version, which turned out to be even uglier because I basically had to rip off the shell-resync-dirs code to handle comint interaction and directory tracking. Here it is in all its glory:

(defun ore-shell-dirnav (direction)
  (interactive)
  (let* ((proc (get-buffer-process (current-buffer)))
         (pmark (process-mark proc))
         (cmd (if (eq direction 'up) "pushd .." "popd")))
    (goto-char pmark)
    (sit-for 0)
    (comint-send-string proc cmd)
    (comint-send-string proc "\n")
    (set-marker pmark (point))
    (let ((pt (point))
          (regexp
           (concat
            (if comint-process-echoes
                (concat "\\(" (regexp-quote cmd) "\n\\)")
              "\\(\\)")
            "\\(.+\n\\)")))
      (insert "\n")
      (backward-char 1)
      (while (not (looking-at regexp))
        (accept-process-output proc)
        (goto-char pt)))
    (goto-char pmark)
    (delete-char 1)
    (let* ((dl (buffer-substring (match-beginning 2) (1- (match-end 2))))
           (dl-len (length dl))
           (ds '())
           (i 0))
      (delete-region (match-beginning 2) (1- (match-end 2)))
      (while ( i dl-len)
        (string-match "\\s *\\(\\S +\\)\\s *" dl i) ; pick off next dir         
        (setq ds (cons (concat comint-file-name-prefix
                               (substring dl (match-beginning 1)
                                          (match-end 1)))
                       ds))
        (setq i (match-end 0)))
      (let ((ds (nreverse ds)))
        (condition-case nil
            (progn (shell-cd (car ds))
                   (setq shell-dirstack (cdr ds)
                         shell-last-dir (car shell-dirstack))
                   (shell-dirstack-message))
          (error (message "Couldn't cd")))))))

(defun ore-shell-dirnav-up ()
  (interactive)
  (ore-shell-dirnav 'up))

(defun ore-shell-dirnav-down ()
  (interactive)
  (ore-shell-dirnav 'down))

(define-key shell-mode-map (kbd "M--") 'ore-shell-dirnav-up)
(define-key shell-mode-map (kbd "M-=") 'ore-shell-dirnav-down)

Phew. It's a lot of code for a seemingly simple feature, but the time it saves me probably adds up to a few hours per year, so it's worth it.

So, sometime over the past few weeks I clocked up ten years as a Debian developer:

From: Anthony Towns <aj@humbug.org.au>
Subject: Wannabe maintainer.
Date: Sun, 8 Feb 1998 18:35:28 +1000 (EST)
To: new-maintainer@debian.org
Hello world,
I'd like to become a debian maintainer.
I'd like an account on master, and for it to be subscribed to the
debian-private list.
My preferred login on master would have been aj, but as that's taken
ajt or atowns would be great.
I've run a debian system at home for half a year, and a system at work
for about two months. I've run Linux for two and a half years at home,
two years at work. I've been active in my local linux users' group for
just over a year. I've written a few programs, and am part way through
packaging the distributed.net personal proxy for Debian (pending
approval for non-free distribution from distributed.net).
I've read the Debian Social Contract.
My PGP public key is attached, and also available as
<http://azure.humbug.org.au/~aj/aj_key.asc>.
If there's anything more you need to know, please email me.
Thanks in advance.
Cheers,
aj
-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP encrypted mail preferred.
On Netscape GPLing their browser:  How can you trust a browser that
ANYONE can hack? For the secure choice, choose Microsoft.''
        -- <oryx@pobox.com> in a comment on slashdot.org

Apparently that also means I’ve clocked up ten and a half years as a Debian user; I think my previous two years of Linux (mid-95 to mid-97) were split between Slackware and Red Hat, though I couldn’t say for sure at this point. There’s already been a few other grand ten-year reviews, such as Joey Hess’s twenty-part serial, or LWN’s week-by-week review, or ONLamp’s interview with Bruce Perens, Eric Raymond and Michael Tiemann on ten years of “open source”. I don’t think I’m going to try matching that sort of depth though, so here are some of my highlights (after the break).

---

• Starting small: my first package was distributed-net-pproxy, which would claim a bunch of work units which could then be distributed over the local LAN. Useful if you’re in Australia in the mid-90s and being charged by the minute for Internet access. distributed.net didn’t allow general distribution, so I asked for (and received) explicit permission to include it in Debian. (distributed.net had a ten year anniversary last year too)
• Diving straight in: I got sucked in to the mailing lists pretty quickly, and within a couple of months was up to my neck trying to redesign the way we did releases; oddly enough that didn’t turn out quite so easy, but at least it ended up with some concrete proposals within a couple of months, pretty much synchronously with the hamm (2.0) release going out (and, I guess, about a year after I’d started using Debian…). At around the same time was, I think, my first recorded comment about trade offs regarding freeness…
• cruft: My first bit of Debian specific code was cruft (that its name, not it’s value…), which worked okay as a prototype, but got snagged up in debian-policy trying to get packages to make a note of files they’ll put on the system without telling dpkg (eg, /etc/passwd, /var/cache/apt/archives/*.deb, etc). That pretty much sapped my interest in it, and cruft stagnated until Marcin Owsiany picked it up in 2005.
• Played for a sucker, part one: a few months later I was messing around doing QA stuff and fixing bugs and as part of that did an NMU of netbase (which at the time directly contained all sorts of important tools like ping and inetd directly). That went something like:

  From: Anthony Towns
  Date: Sat, Nov 21, 1998
  There are a few bugs accumulating against the netbase package which
  you're maintaining. I was wondering if you'd mind if I made an NMU
  to fix some of them for the upcoming slink release?
  

  From: Peter Tobias
  Date: Sat, Nov 21, 1998
  No, please go ahead ... I'm quite busy right now and I would really
  appreciate any help. Please let me know if you need additional information
  about the package.
  

  From: Anthony Towns
  Date: Sun, Dec 6, 1998
  There's an NMU sitting in Incoming now. It fixes a few bugs, viz:
  [...]
  

  From: Peter Tobias
  Date: Fri, Dec 25, 1998
  due to my current job I don't have much time to work on my debian
  packages. In order to have more time for my other debian packages
  I would like to give away the netbase package. Are you interested
  in maintaining this package?
  

  From: Anthony Towns
  Date: Fri, Dec 25, 1998
  Ummm. Sure. I guess. (or, iow, *Eeeeeeeeeeeeek*!!!)
  
  

• ifupdown: As part of maintaining netbase I tried to figure out a way of fixing bugs like 31745 and 39118. Basically, Debian used to do networking by generating a script on install that you could modify by hand, and that was it – so when the commands needed changed between 2.0 and 2.2 (no more “route add -net”), you couldn’t make that upgrade “just work”. Red Hat handled it with “ifup” and “ifdown” commands that would look at a whole bunch of shell-format variables in /etc, which worked but wasn’t elegant, so I came up with something I thought was actually pleasant. It’s fundamental attitude is to be a parser – the networking commands are specifed as compile-time configuration, the description of your network is your runtime configuration, and ifupdown just puts those all together without trying to actually understand what’s going on. To some degree, that works really well – it keeps all the knowledge separate so when you’re writing an /etc/network/interfaces, you’re not worried about how DHCP works; in others it breaks down – in particular if bringing up an interface fails part way through, is it up, or down, or something else entirely?
• bugs.debian.org: I’m not entirely sure why, but in August ‘99 I decided to start running a script to stop old bugs from being permanently deleted:

  From: Anthony Towns
  Subject: BTS and old bugs
  Date: Tue, 24 Aug 1999 22:33:16 +1000
  To: debian-private@lists.debian.org
  ObPrivate: Erm. I'm not sure. It is only even vaguely relevant to
  developers.
  Since bugs #9705 and #36727 don't seem like being fixed any time soon
  and Darren hasn't managed to convert the BTS to using debbugs.deb yet,
  I've made a little script to stop us from continuing to lose bug
  reports, and am running it in my crontab on master.
  ~ajt/debian-bugs/archive/ contains hardlinked copies of the bugs in
  ~iwj/debian-bugs/spool/db (except split into sub-directories). When
  the bugs get expired from the BTS, the hardlink in ~ajt remains, so
  the file doesn't get lost forever.
  In the week or so I've been running it, some 500 odd bugs expired [0].
  

  Next month I sent Darren Benham a first version of bugreport.cgi, and at some point around then must’ve sent off a pkreport.cgi too; by the month after (October) I’d evidently been added to the debbugs group, because I was merging my archived bugs into the official debbugs directories.
• testing: So a year and a bit later and there had been some more discussions about making major changes to our release process, and since I’d done some more algorithms subjects at university by this point, dove in a bit more seriously. For me, the main challenge seemed to be keeping dependencies consistent, and it turns out validating dependencies and conflicts is an NP-complete problem, and solving that reasonably efficiently seemed like a good first step. By October ‘99 I’d come up with a first pass solution, which I think was still in Perl at the time. A couple more rounds of playing with consistency checking stuff ensued, resulting in some regularly updated lists being generated by December, and by March 2000 or so that had graduated to a simulation of testing as we know and love it today.
• Played for a sucker, part two: so after a few months of maintaining a testing suite while potato (Debian 2.2) was getting finalised for release I figured it’d be useful to get broader release experience, so asked Richard Braakman if I could help out with the last bits of the potato release. At which point he said “sure”, gave me James Troup’s email address for accepting/rejecting packages etc, then buzzed off to a mobile phone related junket in the US, and laid low until the release was actually out… A cunning plan, for sure. Happily, that didn’t take too long – I think I started around June, and potato was finished baking for release at LinuxWorld Expo in August, though it did involve about 2000 lines of archive changes and stuff mailed to James over the period, along with half a dozen mails to -devel-announce.
• Junket: In the middle of that was my first ever debconf – or technically the Debian portion of the 2000 LSM/RMLL in Bordeaux, aka Debconf 0. It was awesome – met heaps of cool people, got to practice my high school French, and enjoy some lovely red wine while gossipping about free software. Also heard RMS sing the free software song live. But the wine was great!
• katie/dak: The biggest problem with the “simulation of testing” mentioned above was it was held together with paperclips and sticky-tape; or less metaphorically, shell one-liners and hardlinks. Since packages would originally get uploaded to unstable, and then move into testing, and then get deleted from unstable, you’d end up at least doubling the bandwidth required to mirror Debian, because each package would get sent to mirrors once for unstable and once for testing. Which is fine for a simulation, but for deployment, well, we needed package pools, which in turned required a rewrite of dinstall. James did all the initial work, apart from some of the schema design and the scarier SQL, and by November had it deployed for the non-US archive, and got it onto ftp-master in December. At which point the time was ripe for hooking up testing into the archive proper, which is about the point that the testing scripts got named “britney” so as to fit in with all silly names in the da-katie suite. I’m pretty sure the rationale was that I did the final coordination of the potato release (archive changes, cd images, announcement, etc), I spent from about 3am to 10am listening to a handful of Britney Spears songs on repeat. The phrase “scarred for life” might come to mind. Since that point, there’s been lots of evolutionary changes to both dak and testing (including a rewrite of the perl parts of testing into python), but it’s all built fairly naturally from that point.
• debootstrap: I’m pretty sure my motivation for writing debootstrap was a mix of just wanting to avoid having to worry about out of date base tarballs for the purposes of keeping testing in-sync, and wondering if it was actually possible to write a script to bootstrap a Debian system from the sort of minimally functioanl environment the installer has to put up with. In the end, it turned out pretty cool – it was used by the final boot-floppies, it’s part of d-i, it makes tools like pbuilder possible, I think it helps embedded folks heaps, it’s spawned some imitators, and generally been a pretty cool exercise in hackery.
• Freedom and purity: About six months earlier, there was a big flamewar and an attempted vote on whether to remove non-free from the archive. I’d written a rebuttal and counter-proposal, but it all ended up collapsing in a heap, due to disputes about the constitution. For some reason I feel like this mail was more interesting than all the previous ones combined… That ended up needing a whole bunch of changes to the constitution: one to make it clear under what circumstances the social contract can be changed, and another on what happens when one option on a vote requires a supermajority while another doesn’t, and working that out ended up taking from October 2000 until October 2003. It was actually kind-of interesting; trying to analyse a good voting system that works in the real world has all sorts of interesting maths to it, and there’s a whole bunch of election methods guys that have studied it in a bunch of depth. And since its elections, you can have fun with all sorts of scenarious of corruption – like what if the secretary’s trying to change the results. In practice, the difference between good and bad election methods seems to turn out to be negligible, but why wouldn’t you have the best one you possibly can? A couple of months after those changes were done, dropping non-free got reproposed, and I did another counter-proposal; this time they were actually voted on, with the counter-proposal winning, by a little under a two-to-one margin. Which means we get to get rid of non-free by making it completely superfluous, rather than just near enough.

Hrm, this is going on longer than I’d hoped. Oh well, to be continued!

In November 2007 Roberto C. Sanchez filed bug #451690 in irssi: Please include a doc-base registration file. Including this file isn’t that hard, and while reading the Debian doc-base Manual I found out that “Every Debian package that provides online documentation (other than manual pages) will register these documents to doc-base.” So, if a missing doc-base registration file is important enough for someone to file a bug on, why does my /usr/share/doc-base/ only contain 69 files compared to the 1444 files in /usr/share/doc/ ?

A few clarifications on TDebs in Emdebian:

1. Emdebian needs TDebs now and although discussed in Debian, there is no implementation at this time. Therefore, Emdebian has had to go ahead and implement what we need from TDebs in a manner that should be compatible with Debian TDebs when they eventually arrive.


2. .mo files are architecture dependent and this is a problem for embedded devices, therefore the Emdebian TDeb support must take account of these problems whether or not Debian does so as well.


3. Emdebian will continue to need to cross-build existing Debian packages and if that means regenerating the TDebs to ensure compatibility with embedded devices, that will be done too. It is quite likely as Emdebian will certainly be dropping translated manpages and other content of the proposed Debian TDebs.


4. Emdebian TDebs - as the only implementation currently available - do not support anything except gettext. Again, Debian is likely to provide such support but it is not important to Emdebian because packages that do not use gettext are not in the package set likely to be useful on an embedded device.


5. Tests on non-embedded boxes are irrelevant - yes, .mo files work on any Debian architecture that you care to mention. The problem is that the conversion that is so invisible on a desktop machine becomes a real problem on an iPAQ.


6. I started off thinking that Emdebian TDebs could be Arch:all and the existing packages are Architecture: all but this is set to change. Please don't make the same mistake again and again.

I'm grateful to Frans for his comments during my FOSDEM talk - it will involve extra work to fix the Emdebian TDeb support but it is worthwhile.
Emdebian TDebs are just like Emdebian debs - they are customised versions using Emdebian methods that turn a stock Debian package into something suitable for embedded devices. Debian debs differ from Emdebian debs. Debian TDebs will (when they exist) differ from Emdebian TDebs but the principles of splitting out the .mo files and handling installation etc. are similar.
Packages files
Emdebian needs a different solution to the Debian method, at least initially - principally so that we can have a solution that works now, without extensive changes to the rest of Debian. That solution is available in Emdebian.
Selecting languages
The Debian TDeb proposed method is not implemented currently and GLib includes simple support for retrieving the list of languages selected. Again, Emdebian has implemented a solution that works now, not something that is only a proposal on a wiki page.
Eddy, AFAICT almost nothing has happened to bring TDebs to Debian since Debconf7 and until something concrete exists in Debian, Emdebian simply needs something that works - now.
So:
Q: Are .mo files architecture dependent?
A: Yes.

Q: Does it matter?
A: Yes, for embedded devices.

Q: What about this test or that test?
A: Irrelevant because the tests are done on Debian boxes that convert the data transparently, not an embedded device where the time delay would be problematic.

Q: The packages fill will explode!
A: Yes, it would but both Emdebian and Debian have solutions for this problem.

Q: How to select languages?
A: Normal methods using dpkg and locales, but these are also likely to be customised for embedded usage.

Q: Do tdebs support anything else than gettext?
A: No. Emdebian TDebs only support gettext until such time as Debian has a fully implemented solution that can be customised for embedded devices during the normal Emdebian cross builds.

From the start of the DebianEeePC project, we have used a combination of the irc channel and our wiki site to our great advantage. The DebianEeePC/HowTo/Install document has been actively maintained as we go, serving not only as a good reference for new users, but also for existing users and developers to see where improvements are being made and what is left to work out. Recently, we’ve started using the wiki for task management as well. Patterned after DebianInstaller/Bugs, we now have DebianEeePC/Bugs where we link to reports on the BTS for packages we maintain and our own usertags on packages we don’t maintain. As well, we are keeping a DebianEeePC/Todo to manage our tasks. I see from a search through the wiki that lots of other Debian subprojects keep Todo lists, but most of them have little more structure than point-form lists. A few, though, have structured these pages a bit more carefully. For instance, some of these use tables listing who each task is assigned to, when it was assigned, and when it is completed. Our point-form list is a bit more free-form regarding task assignments. Participants can register their interest in a given task and what they are doing as a subpoint of the task. As for state changes over time, we rely on the revision history on “info” page for people to be able to see state changes for particular Todo items. When something is done, it just gets dropped from the list. I haven’t exhaustively reviewed everyone’s Todo page, but from my brief survey I haven’t seen a couple of things I’ve added to try to help people choose what to do next. The first is to tag items with six difficulty/importance pairs, rating each actionable item from Easy/Urgent to Hard/Wishlist. The second is to state dependencies between items using anchors. It would be nice to see any of you are doing something similar and hear about whether it has worked out well for you. I’m happy with how the irc/wiki combination has helped with project management. In the past with a different project I’ve made an abortive attempt to use the task management system at Alioth, but it just seemed too cumbersome and nobody ended up using it. With the wiki, it appears barriers to participation in task management are sufficiently lowered that everyone is willing to help keep it up. And with irc, we can keep on top of defining and assigning (or more usually volunteering to do) various tasks, and making sure the wiki is kept completely up to date. It takes a bit of discipline to do, but after the habits are established, it gets easier, and the rewards are well worth it.

There are communal elections in my region this weekend.I'm a supporter and member of the Greens. Please support us by voting for us.Don't vote for CSU. Ever. Just think of what they've been doing towards spying on citizens, data retention and such. They fight against your freedom by blaming the "terrorists".We could use up to 20% greens, and there is no way we're going to reach that anytime soon. So it's save to vote for the Greens. Even with your vote, they'll probably just reach 10%, and that definitely is a good thing for democracy. Nobody is talking about the Greens becoming the strongest party, you know... but we could use more Greens than we currently have in the parliaments. If we have 4-5 reasonably strong parties and changing coalitions, that helps fighting corruption.

There are communal elections in my region this weekend.I'm a supporter and member of the Greens. Please support us by voting for us.Don't vote for CSU. Ever. Just think of what they've been doing towards spying on citizens, data retention and such. They fight against your freedom by blaming the "terrorists".[Yes, I am aware that these topics are national, not communal topics. But in communal topics it's the same thing. CSU wants to waste billions of money on a train which is 10 minutes faster at the airport, and which nobody is going to use because it's quite a bit more expensive. The money could be used for much better purposes, but I guess they owe some construction companies ... It is a fact that they have introduced study fees, despite the need for more high-qualified people; they should be putting more money into our universities instead of driving people away from higher education.]We could use up to 20% greens, and there is no way we're going to reach that anytime soon. So it's save to vote for the Greens. Even with your vote, they'll probably just reach 10%, and that definitely is a good thing for democracy. Nobody is talking about the Greens becoming the strongest party, you know... but we could use more Greens than we currently have in the parliaments. If we have 4-5 reasonably strong parties and changing coalitions, that helps fighting corruption.

About a week and a half ago, I had to call in to work. The conversation went about like this:

Me: I'm going to be a little late today. I'm stuck in the mud, but I'm still on the road.

Other end: (Laughter).. *ahem* I'm sorry, but that sounded really funny.

From our house, we can take either the south road or the north road to lead to the highway. The north road always has at least some rock or sand on it. The south road is just dirt. And at the corner where it meets our road, it's dirt in a flood area with lots of trees around it. Meaning that is is often impassible.

But the south road saves me 1.3 miles each way on my drive in to work. So I like to take it when I can.

Lately we've had moisture, but since it's winter, the mud and water on the south road freezes overnight sometimes. Generally I figure that if the mud all over on our own yard is frozen, it's safe to take the south road.

Last week, our yard was frozen. The mud was solid and there were patches of ice. So I started heading towards the south road. I got to the corner, and there was ice and solid-looking frozen mud. So I went ahead. And promptly fell through the ice and landed in the water -- and mud -- beneath it.

Not good. I figured I'd try to get out of it. I actually was able to move the car, and got to within 5 feet of the solid ground, but there was just no going past there. So I called a neighbor with a tractor, and called in to work while he made his way over. He wasn't sure if he wanted to pull our car out from the front, so, due to his location, he had almost a 3-mile tractor drive.

Meanwhile, I worked to get the car as far back as I could. He pulled me out with no problems. I offered to pay, but he wouldn't accept anything. I stopped at home for a quick change of clothes and shoes (I had hopped out in the mud to try to find any sort of debris or something that could provide better traction), then went in to work -- only an hour late.

I got several comments from co-workers. And some "helpful advice" regarding which road I ought to be taking for the next few days. All in good fun, of course.

Terah and I always knew it was just a matter of time before something like this happened.

So, finally, it has. What a relief!

Terah made some buried cherry cookies for me to take over to our neighbors that weekend as a thank-you. He's been pulling people out of that corner for decades, and from the sound of it, I'm just about the most boring one yet.

With my new VoIP infrastructure in place, I d like to get rid of the softphones and replace them with hardware. An obvious solution, given how I might need to replace my cellphone sometime soon, would be to check out the Nokia E65, which can do VoIP over wireless. I ve previously dismissed the Nokia E-series phones for good reasons, but Nokia had time to improve them, and I know a few people who like the E65. Waiting for the OpenMoko Freerunner is nother option. If you know of other VoIP+Wifi GSM cellphones you can advocate, please let me know. On the other hand, I might just want to get a separate VoIP phone, ideally wireless, to use at home exclusively. The problem is that there seem to be none. I checked out at least two dozens, and they all fall short for one of the following reasons:

• they are Skype-optimised, or don t even support proper VoIP. I see no need to support this.
• they combine VoIP with regular analog telephony, which I don t need. I d rather pay less.
• they are made by big players, who charge more for their brand than the product is worth.
• they come bundled with some VoIP service out there, which smells like lock-in or extra charges.

Thus, I am reaching out to the lazyweb. Does anyone know of a wireless (short-range) phone that can do VoIP at a reasonable price, either based on Wifi, or using an ethernet-connected base station (DECT). I d appreciate a note. NP: Age Pryor: City Chorus

Yesterday, my phone had a temporary fit, yet I had a bunch of important calls left to make. Since I have an account with a VoIP provider and a Swiss number associated with it, I decided to use it as a fallback. That worked. The next thing I found out was that a meeting had been cancelled, and since I was in a VoIP-related mindset anyway, I did what I ve been meaning to do for years: check out Asterisk. An excellent article by Stefan Wintermeyer in the 01/2008 issue of the German Linux Magazin helped me understand the basics of the Asterisk configuration paradigms in a single read. With 40 minutes left, I installed the Debian Asterisk packages on a test machine and by the time of my next meeting, I had the server register with two VoIP providers (one of them being the university) and routed outgoing calls accordingly: calls to university numbers went there, all others would be routed via Insphone. I also hooked up three softphones and routed incoming calls to them. I shall post my configuration once I spent a little more time with it, configured e.g. voice mail and a simple voice- or DMTF-activated menu system to distinguish work from private calls, and cleaned it up. If you care before then, ask. Asterisk is said to have a steep learning curve. Thanks to the article and the excellent work by the Debian maintainers, I climbed that curve to the point where I can make and receive phone calls in about an hour. Thanks! NP: Age Pryor: Shanks Pony

Who has already been using dd for endless data transfer without really knowing what is happening ? That is rather annoying. Sure, when the target is a normal file, you can always use

watch ls -l target

But, that won't tell you the rate of transfer, and it won't work if the target is a special file (device, pipe, ...). Fortunately, dd accepts the USR1 signal to print out some small statistics... Well, combining that with the watch tricks gives this:

watch killall -USR1 dd

And there you go, dd is now regularly printing out statistics. Pretty neat, isn't it ?

It's rare that one does something for themself, and entertainment has happen. Yesterday I had been to a cabaret and did take my other half with me. With the thought, it doesn't always have to be Resetarits, Gunkl or Dorfer I chose "Wegen Renovierung offen" ("Opened due to renovation") from and with Gery Seidl–being the child of a master-builder and having done my A-levels at a high school for structural engineering it wouldn't had been a better fit thematic wise. The role of the construction supervisor Roman Schweißer is catching right from the start, and that's not only for insiders but also for people who generally have no connection to this business branch; a human like everyone else: The internal conflict between what his boss tells him and what his heart tells him, different approaches to get that done, and at the same time trying to also work on his shaken relationship isn't easy—but for sure it's extremely entertaining and worth seeing. My other half didn't regret it to got convinced by me. Dates are still a lot left, partly sold out, partly though also from other projects to which I'm looking forward to. It's rare that a still young performer is not only just able to catch up with oldsters but also to perform with them on stage.

That's it...

Student for now :-)

Damn it, I should had wrote about it a couple of days ago. Anyway, it happened last Friday (20080222), my last day at work. After 4.5 years (exactly 4 years, 6 months and a week), I quit my job to dedicate more time for my "supposed" last year studying Computer Science at the University.

In a far far away galaxy...

During the translation of packages' descriptions, when I found something that looks like a typo or a wrong reference I try to report wishlist bugs and, when possible, provide patches, I know this is somewhat noisy, it is just to register the fact, so Smith Review can also spotted it, sorry for the noise. :-)

BTW, I would still vote for a genius if we are going to elect a mascot.

Thanks: frolic

In 1996 Peter Gutmann wrote a paper titled “Secure Deletion of Data from Magnetic and Solid-State Memory” [1]. In that paper he mentions the fact that the contents of RAM last longer at lower temperatures and suggests that data could be retained for weeks at a temperature of -60C or lower (while 140C causes rapid data loss). The paper also addresses issues of data recovery from hard drives, but given that adequate CPU power for encryption is available recovering data from a disk shouldn’t be an issue unless thee attacker can get the key to decrypt it or crack the algorithm - so disk recovery is not a hot issue at the moment. Recently some researchers at Princeton University have published a paper describing in detail how to chill RAM to make it keep its data after a power cycle and even after being installed in a different computer [2]. This attracted a lot of attention, while Peter’s paper described the theoretical concept (in great detail) the Princeton group showed how to implement the attack using materials that are commonly available. Most of the analysis of this misses some fundamental points. Any suggestion that you can wipe the RAM on power failure or on boot misses the point entirely. If an attacker can chill a DIMM and then remove it from the system then there is no chance for it to be wiped. Maybe if you had security on the PC case to detect case opening (some servers have a basic version of this) such things would do a little good, but it shouldn’t be difficult to bypass in most cases. Another common flawed analysis is to suggest that this is no big deal because sniffing the memory bus has been possible for years. While it has always been possible for government agencies and companies who design motherboards to sniff the bus, for most potential attackers it has been overly difficult. When considering the effectiveness of a security system you should first consider what your threat model is. Who is going to attack you and what resources will they be willing and able to devote to the attack? An organisation that is prepared to use expensive equipment and highly trained people to break your encryption probably has other methods of gaining access to your secret data that are easier and cheaper. The research from Princeton suggests that I could perform such attacks with my spare time and with equipment that is very cheap. I’ve been idly considering doing this to an old PC just for fun! Therefore I have to assume that everyone who has the same amount of skill and money as me can potentially compromise my data if they capture one of my machines. It is still most likely that if anyone steals my laptop they will want to sell it and use the money to buy drugs. I don’t think that I have any data that is anywhere near valuable enough to justify a targeted mugging. But my procedures (in terms of changing passwords etc) in the case of my laptop being stolen now need to be scaled up due to the ease in which data might be compromised. The best way of dealing with this would be to have the decryption keys locked inside the CPU (stored in registers or memory that’s locked in the CPU cache). The possibility of getting a modern CPU to operate at any temperature approaching -60C is laughable, and the CPU is a well contained package that can operate on its own and is difficult to attack. This would make things significantly more difficult for an attacker while requiring little effort (in fact it might be possible to lock data in the CPU cache already in which case a software change is all that is required). Update: A comment by Mike made a good point about CPU cooling. Toms Hardware performed an overclocking experiment (from 3.2GHz to 5.25GHz) and used liquid nitrogen cooling [3]. It might be possible to cool a CPU core to -60C in a reasonably small amount of time. But I still believe that it would raise the bar enough to make it worth doing. Update2: Thanks Jaime for the spelling advice.

• [1] http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html


• [2] http://citp.princeton.edu/memory/


• [3] http://www.tomshardware.com/2003/12/30/5_ghz_project/index.html

Share This

I have spent one day and a half this week-end at FOSDEM. This was not as great as expected, but mostly because i don't have the time to stay the whole sunday. Next year, I will stay the whole week-end in order to have time to attend all the speak i should be interested in. The beer event was overcrowded, but all the beer i found there was great (in particular the Floris Pear). It was also a great time to have a demonstration of the XO OLPC laptop. This little thing is funny, but i don't get the way the UI should be used. Another bad point, is that the first console allow to login as root by pressing "Enter" (at least on the one i try). I suppose this kind of device is not intended to be secured. I also have time to talk with some Debian people and some other people -- in particular one who was thinking that Windows 2000 is the best ever OS. At least, it means that there were people from different horizons -- and this is a good thing. During Saturday, i spend half of the day in the big amphitheater (Janson). The talk about Tux with Shades (Linux in Hollywood) was impressive, regarding the trailer they show us... The talk about FreeBSD was interesting -- but not impressive as a trailer. I spend Saturday afternoon in the Debian devroom, following all the different talks. I miss the one from MadCoder about managing packages with git... That's a shame because i really want to see this one. Since my train was at 12am on Sunday, i choose to only pay a visit to the different booths. I have the pleasure to have a demonstration of the EeePC on the Debian booth that really please me. I found the UI more easy to understand than the one from XO. Speaking with the person demonstrating the laptop, she explained me that EeePC is more "standard desktop" and XO more "creative desktop". Conclusion: i am not creative ;-) Also talking about everything around talks and the meeting, i think Bruxelles is a really nice city for this kind of events. ULB is not near the center of Bruxelles but there are enough transportation. There was really a lot of people attending FOSDEM, and this is a good thing. I also have the pleasure to find some people from the OCaml Meeting.

I'm going to be traveling and giving talks quite a bit this spring. Here's what my schedule looks like now. I don't think much will be added to it:

• February 29-March 1 - Houston, Texas - Matt Lee's Wedding
• March 12 - Amherst, Massachusetts - Hampshire College
• March 15-16 - Cambridge, Massachusetts - FSF Members Meeting
• March 27-28 - New York City, New York - Fordham IP Conference
• April 7 - Florence, Italy - Renaissance Panel: The Roles of Creative Synthesis in Innovation at CHI
• April 11-13 - San Fransisco, California - Lugradio Live USA
• April 17-20 - Detroit, Michigan - Penguicon
• April 25-27 - Cambridge, Massachusetts - ROFLCon
• May 5 - San Fransisco, California - Sun's Community One

I'll be giving at least one talk at the FSF Members Meeting, the Renaissance Panel, Lugradio Live, Penguicon, and Community One. Matt's wedding is private. To join the FSF members meeting you must become an FSF Associate Member if you are not already. All of the other conferences require some sort of registration. Penguicon, Lugradio Live, and ROFLCon are each cheap and each promises to be a lot of fun. The talk at Hampshire should be free and open to the public. I'll be posting more about each of these as things get closer including details about what is that I'll be talking about. If you'd like me to talk to another group or at another event while I'm town for any of the events above, now would be a good time to ask. If you just want to meet up for a beverage of your choice, that's good too. In either case, get in contact.

New Gammu testing version is out. This time release period is a bit longer than usual, mostly because my moving back to Prague. 1.18.91 again only fixes some bugs:

• Improve debug messages when connecting to phone (bug #508).
• Fixed handling of some charsets in AT engine (bug #525).
• Identify more Nokia phones (thanks to Iv n Gabriel).
• Fixed regression with DKU2 cables on Windows (bug #533).

You can download from usual place: http://cihar.com/gammu/. PS: Debian users can get packages from experimental.