I've been buying quite a lot of (usually cheapo) gadgets recently, which I'll probably introduce / review in various blog posts sooner or later. Let me start with a fun little gadget, a digital USB-based microscope. I found out about it via this thread over at lostscrews.com. You can get this (or a very similar device) e.g. on eBay for roughly 50 Euros. Mine seems to be from a company called Oasis (though they're probably just the reseller, not sure). The device doesn't seem to have a nice name, but I can see UMO19 MCU003 on the microscope, so I guess that's the name or model number. It can focus on magnifications of 20x or 400x. The image resolution is said to be a max. of 1600x1200, but in practice most of my images are 640x480, maybe I have to change some settings and/or the resolution depends on the magnification factor and lighting conditions. The device acts as a simple UVC webcam when attached to USB, so you can view the images easily via any compatible webcam software, e.g. luvcview and also save screenshots of the magnified areas (see images).

First three from left to right: SMD LED (400x), clothes/jacket (400x), random PCB (20x). The other two below: A via on a PCB (400x), and the "pixels" of a TFT screen (400x). It worked out of the box on Linux for me, the uvcvideo kernel driver was loaded automatically.

 $ lsusb
 Bus 001 Device 013: ID 0ac8:3610 Z-Star Microelectronics Corp.

I set up a wiki page for more details (including full lsusb -vvv) and sample images at: http://randomprojects.org/wiki/Oasis_UMO19_MCU003_USB_microscope I will also post some more images there over the next few days.

This is a really fun device for having a look at stuff you'd normally not see (or not well enough), and also useful for e.g. checking PCB solder joints, checking all kinds of electronics for errors or missing/misaligned parts, finding the chip name / model number of very tiny chips etc. etc. I can also imagine it's quite nice for biological use-cases, e.g. for studying insects, tissue, plants, and so on. Anyway, definately a nice toy for relatively low price, I can highly recommend a device like this. Check eBay (search for e.g. "usb mikroskop 400") and various online shops for similar devices, there seem to be a large number of them with different names and from different vendors. Just make sure it has at least 400x magnification, there are also some with only 80x or 200x which is not as useful as 400x, of course.

ikiwiki is not yet able to create a Google sitemap internally, so I'm using google-sitemapgen. To run it automatically when the website is being updated, I've changed the git hook to run it after the ikiwiki hook.

• In the ikiwiki setup file let git_wrapper point to a file which is not the post-update hook, so you're able to run it from your own skript. I'm using /path/to/myikiwiki.git/hooks/post-update.ikiwiki.
• Write a skript which runs as post-update hook and executes the created hook from ikiwiki and google-sitemapgen with a proper configuration. My versions of both files are listed below.

/path/to/myikiwiki.git/hooks/post-update

#!/bin/sh
/path/to/myikiwiki.git/hooks/post-update.ikiwiki
/usr/bin/google-sitemapgen --config=/path/to/mywikiconfig/sitemap_config.xml
exec git-update-server-info

/path/to/mywikiconfig/sitemap_config.xml

<?xml version="1.0" encoding="UTF-8"?>
<site
  base_url="http://bzed.de/"
  store_into="/path/to/bzed.de/sitemap.xml.gz"
  verbose="0"
  suppress_search_engine_notify="0"
  default_encoding="UTF-8"
  >
  <directory
    path="/path/to/bzed.de"
    url="http://bzed.de/"
    default_file="index.html"
  />
  <!-- Exclude URLs that end with a '~'   (IE: emacs backup files)      -->
  <filter  action="drop"  type="wildcard"  pattern="*~"           />
  <!-- Exclude URLs within UNIX-style hidden files or directories       -->
  <filter  action="drop"  type="regexp"    pattern="/\.*"     />
  <!-- Exclude ikiwiki directories -->
  <filter  action="drop"  type="regexp"  pattern="/helponformatting/*"           />
  <filter  action="drop"  type="regexp"  pattern="/ikiwiki/*"                    />
  <filter  action="drop"  type="regexp"  pattern="/markdown/*"                   />
  <filter  action="drop"  type="regexp"  pattern="/openid/*"                     />
  <filter  action="drop"  type="regexp"  pattern="/pagespec/*"                   />
  <filter  action="drop"  type="regexp"  pattern="/preprocessordirective/*"      />
  <filter  action="drop"  type="regexp"  pattern="/sandbox/*"                    />
  <filter  action="drop"  type="regexp"  pattern="/shortcuts/*"                  />
  <filter  action="drop"  type="regexp"  pattern="/smileys/*"                    />
  <filter  action="drop"  type="regexp"  pattern="/subpage/*"                    />
  <filter  action="drop"  type="regexp"  pattern="/templates/*"                  />
  <filter  action="drop"  type="regexp"  pattern="/theme/*"                      />
  <filter  action="drop"  type="regexp"  pattern="/wikiicons/*"                  />
  <filter  action="drop"  type="regexp"  pattern="/wikilink/*"                   />
  <filter  action="drop"  type="regexp"  pattern="/wmd/*"                        />
  <!-- Exclude css files, favicon and javascript -->
  <filter  action="drop"  type="wildcard"    pattern="*.css"                         />
  <filter  action="drop"  type="wildcard"    pattern="*favicon.ico"                  />
  <filter  action="drop"  type="wildcard"    pattern="*.js"                          />
  <!-- Exclude ikiwiki.cgi -->
  <filter  action="drop"  type="wildcard"    pattern="ikiwiki.cgi"                   />
</site>

See the examples and README files in /usr/share/doc/google-sitemapgen/ for an introduction into configuring google-sitemapgen. So far the generated sitemaps works very well, especially for search engines which are not able to use the rss feeds like Google does.

Yes, folks. If you haven't been stalkfollowing me on various other online channels (Facebook, Linkedin, Twitter, etc.), it might have appeared to you as if I was no longer alive. A blog with no updates in over 6 months! Heavens. However, the truth is that I've had a number of pressing matters to attend to. Mostly they relate to my personal finances and to my Fathers' health. Fortunately both of them are slightly better now. I shall endeavour to post once a week, or more frequently, when I've got interesting news / reviews / rants I'd like to share with all three of you (Hi Mum! Hi Dad! Hello you other weirdo!)

In the local dialect here in Padova, Italy, "ovi" means "eggs". For those who aren't native English speakers, "to lay an egg" means to fail at something or do it poorly. The connection is very appropriate.
To see what it was about, and if it was worth pursuing, I decided to submit a couple of simple applications to Nokia's OVI store. Nothing fancy, or that I'd spent much time developing, and they were actually little things I'd done for myself before the ovi.com store came out, but I had hoped to see about making a bit of money out of the time invested nonetheless.
So I went ahead and started adding them, with a quick glance the publisher guidelines. Too quick, as it turns out. A month after submitting my application, their "QA" process lets me know my application is not going to be accepted because it's not signed. Uh... yeah? Couldn't you have simply run a script on the file I uploaded to tell me the same damn thing? It's not exactly as if you have to have a human look at the file with a hex editor to determine whether it's signed or not. My phone can tell, of course - presumably Nokia ought to be able to figure it out programmatically and let me know? Sure, I should have read their big, long document prior to starting, but come on, it would have saved everyone time if their software had simply informed me that my application, being unsigned, was not ok. Now, when it comes to signing, Java ME is pretty much the worst in the business, although Apple is giving them a run for their money. At least Apple does it to make the applications good for their users (for their definition of good).

• Java ME: Ovi suggests using http://javaverified.com/ - where it costs $200 to sign up, and then something like at least 75 euros to run an application through *their* whole process. For each version. The hell with that!
• Android: you have to pay $25 to get access to the marketplace, but can self-sign applications. For free. Put that in your pipe and smoke it, Nokia & Larry.
• BlackBerry: I was sure this one was going to be expensive and painful given that BB is mostly aimed at big companies that could certainly spare the money. It's not: $20 gets you a certificate that you can sign everything you want with, and it's pretty quick and painless to get it. This is how Nokia ought to be doing things in terms of signing applications.
• Apple: $100 gets you the dev kit and then you can submit your apps to the somewhat bureaucratic and slow apple approval process. Plus you have to own a mac to develop on, if you don't already have one. But still, only $100 a year, and you can do as many apps as you want.

So there you have it, Java ME involves more fees than the other ones, and is probably as slow and bureaucratic to boot. I'm not going to find out, though, this pretty much concludes my experiment with ovi.com - there's no way I'm going to spend all that money on a little fun application that I'd only sell for a few euros. Being a fan of open source and openness in general, my next phone will certainly be Android based. I think someone at Nokia probably realizes things are broken: they appear to be working on a way to make it not cost anything to sign Symbian apps. But I don't have a Symbian app, so that's pretty useless for me. Oh, and while I'm bitching about their whole process, their publisher interface was down all of last weekend in order to "add a new set of metadata which will improve the Ovi Store user experience". It took a whole weekend of downtime to add that?
Furthermore, I signed up for Ovi as soon as it came out - I was going to push Hecl to it (but didn't bother at the time) but now it appears they want 50 euros from you just to sign up. Here's a hint: save your money.

Actually they're more interested in freedom, to be no longer slaves to humans. I don't think it's any spoiler to mention that an electric sheep does appear in the book.

This is a classic science fiction story of a dark not-so-distant future. In fact given that it's over 40 years old it could be set in some alternate now. Some disaster has occurred and many have either left earth or died. Some andriods, or andys have escaped and bounty hunters are after them.

You may not know the book by its correct title, but you may of heard the movie that is based upon it, called Blade Runner. Like most movies based on books, it takes some of the concepts and ideas of the book but in my opinion is a pale imitation.

I'm glad I read this book. It hasn't aged that much and it's very though provoking. Sci-Fi often uses some alternate reality to put a mirror up to what happens in the real world and this book is no exception.

And a token link to Debian, if you want you own electric sheep you can install the screensaver electricsheep package which draw pretty fractals on your screen.

Related articles by Zemanta

• Philip K. Dick Journals To Be Published In 2011 (huffingtonpost.com)
• Philip K. Dick on Blade Runner (kottke.org)

Well the latest version of PSmisc is almost finished, so I pushed the tar archive up to the spot for the translators, waiting for the updates before it gets released.

It reminded me that perhaps a lot of people don't know how their programs get translated. Perhaps there are some that could even contribute. The nice thing about the translation systems is that you don't need to know programming to help.

PSmisc uses the translation project as its method. The program itself uses gettext for the translation part which makes a single text file called a POT file. A translator takes this text file and makes a po file, such as it.po for the Italian translation and then translates, which basically means editing the file, reading each first line of a set and writing the translation on the second line.

For the programmer, once it is setup it is pretty simple to use, just mark your translatable lines and follow some simple rules, mainly about not embedding too much in a string. I've used this system for years for quite a few of my programs and there is little added work for me.

Unfortunately, translating is hard work and should be a long-term commitment. Having a look at the translation project's Translation Matrix and you can see that some languages do suffer, though there are some very good results there too. Particular kudos goes to the Vietnamese group which I think is just Clytie who does a marvellous job and is often the first translation file I get.

For the Debian project, there are many places where translations can occur. There doesn't seem to be a centralised place for this, but some of the places they use translation work are:

• Translating The Debian website
• Debian Description Translation Project
• Debian debconf (configuration questions when you install packages)
• Translating Debian News

I have announced the Debian Community Poll in my former blog post. I have closed the poll today and I will start publishing its results now.
What is the codename of the current stable release?This is the only compulsory question with the intention to block spammers. The correct codename is Lenny but I have accepted almost any answer that is somehow related to Debian. Version numbers, names from Sarge to Experimental, even well known codenames and version numbers from Ubuntu have been counted as correct. 22 partipants answered wrongly and their submissions got removed from the result set. A whopping number of 3258 submissions have been accepted and get analyzed now. Thanks to all participants!
How long have you been using Debian?

• 33.6% answered 6 - 10 years
• 32.7% answered 2 - 5 years
• 16.6% answered more than 10 years
• 15.5% answered 0 - 2 years
• 1.7% did not answer

On what kind of hardware are you using Debian?
Multiple answers are allowed for this question and that is why the values do not sum up to 100%.

• 80.5% are using Debian on the desktop
• 62.4% on the server
• 56.9% on the notebook
• 21.7% on the netbook
• 11.6% on embedded device(s)
• 3.2% on other device(s)

The following other devices have been mentioned: smartphone, virtual machine, nettop, NAS, HTPC, workstation, pendrive, live cd, cluster, thin client, router, rocket flight computer, ibm mainframe, and automatic bar tender.

Do you contribute to Debian?

• 50.0% choose answer #5: I don't contribute on a regular base.
• 31.2% choose answer #4: I'm regularly helping other Debian users.
• 8.0% choose other (see below) or simply did not answer
• 4.9% choose answer #3: I'm regularly contributing to Debian packages without uploading them by myself.
• 4.5% choose answer #1: I'm a Debian developer.
• 1.4% choose answer #2: I'm a Debian maintainer.

The following other answers have been provided:

• upstream developer or contributor
• translator
• bug reporter
• advocator
• former DD or DM
• prospective DD or DM
• mirror maintainer
• package/installer tester
• documentation writer
• donator or debconf sponsor
• debconf organizer or helper

How do you think about the Debian Free Software Guidelines (DFSG)?

• 46.0% choose answer #2: I like the DFSG but it is not the most important reason for using Debian.
• 36.6% choose answer #1: The DFSG is very important to me. I could live with many changes in Debian but I would be very upset if Debian would allow non-free software into its main component in the future.
• 10.1% choose answer #3: I don't know.
• 4.9% choose answer #4: I don't care.
• 2.4% did not answer.

Are you using Debian derived distributions, too?
Multiple answers are allowed for this question and that is why the values do not sum up to 100%. There were a lot of different answers but the most frequent are:

• 47.1%: Ubuntu (Kubuntu, Lubuntu, Xubuntu)
• 40.8%: no answer; this was the only way to say that someone does not use a derived distribution
• 11.0%: other (see below)
• 7.0%: damn small linux
• 4.8%: Sidux
• 4.3%: grml (juxlala)
• 2.2%: Knoppix
• 1.6%: ELive
• 1.4%: Maemo

The other answer includes the following distributions: 64studio, ALT Linux, arch linux, ArtistX, BackTrack, BRLix, Canaima GNU/Linux, catix, cdlinux.pl, CloneZilla, CrunchBang, Custom, ddwrt, debian arm userspace for zipit z2, DebXO (?), DreamLinux, Easy Peasy, eb4, eeebuntu, EMC2 Ubuntu (linuxcnc.org), Emdebian, Estrella Roja, Fedora, Finnix, Gentoo, gNewSense, Hackable:1, Kanotix, Kuliax, LFS and CLFS, LinEx, Linux Mint, live CDs, live-helper, Mepis antix, Musix, My own LiveCD, Mythbuntu, OpenInkpot, openwrt, paipix gnu, Parsix, Peppermint, personal debian derived, proxmox, Puppy, PureOS, qtopia, SHR, simplyMEPIS, Skolelinux, slackware, SymphonyOS, Toutou, Trisquel, tty GNU/Linux, UHU Linux, Univention Corporate Server, vinux, Voyage, Vyatta, whiite, Xandros, Xarnoppix. Not all of them are derived from Debian.

- to be continued -

Adobe recently announced they have (temporarily) stopped working on the amd64 version of their Flash Player for GNU/Linux. The previous releases contain a big security issue, which makes them totally unusable. As I didn t want to wait until the flashplugin-nonfree package to be updated to support the i386 plugin through nspluginwrapper (as suggested in #586273), I have decided to simply switch to the free alternative: gnash. After a few hours with it, I am now able to use most of the websites I usually visit, including Youtube and Dailymotion. Note that I use Iceweasel, which does not support WebM (for now), nor H.264 (which will never be supported by Mozilla). Youtube support is brought by a Greasemonkey user script available at: http://turanct.wordpress.com/2010/02/25/gnash-youtube/
The only tiny drawback is that the videos load in pause mode. For now, everything else seems to work fine. Users of other browers (Chromium, Safari, Opera) can try their HTML5 beta: http://www.youtube.com/html5 It is even easier for Dailymotion, as the videos on their HTML5 beta program are encoded in the Ogg Theora format, which is natively supported by Iceweasel/Firefox >= 3.5. To ease things, I have written a small Greasemonkey script which simply automatically redirects www.dailymotion.com to openvideo.dailymotion.com. This script can be downloaded here. The drawback is that videos won t play before they are loaded completely, which is not a big problem anyway. I still cannot play the videos avilable on Vimeo, and have noticed while wirting this post that the Flash file uploader of WordPress didn t work with gnash (obviously, WP provides an alternative way for file upload). I will go on with this experience as long as I do not see major issue with gnash.
I will also update this post, or add comments, if I encounter other issues, or find any alternatives. I would be curious to read your comments if you have run similar experience.

I've always thought about collecting random bits of useful/interesting/cool Unix features and the like. Before I let that rot indefinitely in a text file in my $HOME, I'll post it in a series of blog posts. So here's bit #1: Everyone knows /dev/null, and most will know /dev/zero. But /dev/full was unknown to me until some time ago. This device will respond to any write request with ENOSPC, No space left on device. Handy if you want to test if your program catches "disk full" - just let it write there:

$ echo foo > /dev/full
bash: echo: write error: No space left on device

My project. This post assumes that the reader has read my last post. This was a week full of segfaults, failed assertions, changes in the user data and other crazy stuff. I started working on the allocation of memory on the freed lines. In the first glance, it seemed to be much harder than the small changes I ve done to free memory in lines, because of the a never-seen-before-by-me datatypes being dealed with in alloc_for_copy(), from rts/sm/Evac.c: gen_workspace. But in a short time the code of alloc_for_copy() has shown itself to be simple, and it was easy to do an initial implementation. I went in the same path I was going on before, trying the simplest solution that works. For instance, the line representation used is not ideal, because groups of lines are not considered, but it was the simplest at that time, and I plan to improve it latter. The gen_workspace data type contains a pointer to an area of a block that is not being used (todo_free) and a pointer to the end of that area (todo_lim). When a space for an object is requested, it s allocated in this area, and todo_free is adjusted. If the area is full, a new block is requested. My intended change was to return the first free line of the generation when the object is smaller or equal to the size of a line, and use the current approach otherwise. This is the simplest way I could think, but has the problem that the only one object is allocated per line. This was a known issue.

    if(size <= BITS_IN(W_) && gen->first_line != NULL)  
        to = gen->first_line;
        gen->first_line = (StgPtr) *gen->first_line;
        return to;
     
    ws = &gct->gens[gen->no];

After that I got the first round of segfaults. One problem I could spot so far was in the code in rts/sm/Sweep.c, related to the liberation of the lines. The block is allocated by need, and there s a pointer to the first free byte, free. This free space is used by alloc_for_copy(). So, we should only think of lines in the region already allocated in the block, that is, where the address is smaller than free.

                    if(bd->u.bitmap[i] == 0 && bd->u.bitmap[i - 1] == 0 &&
                       start + BITS_IN(W_) <= bd->free)

But the segfaults, memory corruptions, etc, kept going on. I tried some restrictions, like allocating in lines only objects with the exact size of a line, or very small objects (size == 2), or allocating just one object for generation, or only one object at all. I also tried checking for the type of the allocated object, to see a correlation with the problems I was having. Nothing helped by now. So I thought I should work on other things, so that maybe my mind gets clearer and I can spot the problem. I followed the suggestion of using todo_free and todo_lim to make it possible to allocate more than one object in a line. I liked this change, since I had the impression that it fits better with the rest of the code than the initial implementation, and it will be easier to addapt it when I improve the representation of the free lines. As I said, I wanted something to work while I think in how I ll solve the segfault problems. The bad side of this choice is that I ll not be able to test it, since it s just a reimplementation of the same idea in the allocation code, and is not expected to work. The good size is that it may work, and solve the problems I was having by accident.

    if (ws->todo_free > ws->todo_lim)  
        if (size <= BITS_IN(W_) && gen->first_line != NULL)  
            ws->todo_free = gen->first_line;
            gen->first_line = (StgPtr) *gen->first_line;
            to = ws->todo_free;
            ws->todo_lim = ws->todo_free + BITS_IN(W_);
          else  
            to = todo_block_full(size, ws);
         
     

I got the same results as with the older implementation, and no ideas about how to solve it (yet). So I thought about another thing to work on, which I m talking about all through this post: improve the free line representation. This has the advantage of being testable, since it s unrelated to the allocation code, and may give me an idea about how I can fix the segfaults. The bad side is that it probably won t fix my problems directly. I m working on it right now.

---

Following a suggestion, I ve started using gdb to see what was happening in the GC instead of including printfs everywhere, and it s been useful. I ve noticed that sometimes printf is more effective, but sometimes gdb is much better.

I hope that some of you, outside the French Cabal, are able to understand French. I would be sorry if you missed the whole fun of this. The story starts at http://lists.debian.org/debian-l10n-french/2010/05/msg00178.html. In short, someone apparently named "Alain S<shhhhdonttellmyname>" mailed the debian-l10n-french mailing list to request for a message written in march 2006 by someone else whose name is also S<shhhhdonttellmyname> to be removed from the debian-*user*-french mailing list archives. "Someone" then politely answered him with http://lists.debian.org/debian-l10n-french/2010/05/msg00179.html, trying to use as less irony as possible. At least, this "someone" refrained himself to explain that, doing so, yet another copy of Mr S<shhhhdonttellmyname> name was being replicated over dozens of servers all over the world, also exposing that he's probably living in Antony, Bourg La Reine, Chatenay Malabry, Chevilly Larue, Fontenay Aux Roses, Fresnes, L'Ha Les Roses, Le Plessis-Robinson or Sceaux, in France. Later on, this "someone" received many private mails from that Mr S<shhhhdonttellmyname>, which got automatically and gradually classified as spam. Funnily, a few days later, that "someone" received another mail from another person, posting from the very same IP address and requesting for such removal again. That "someone" being Very Evil and a little bit pissed off answered with http://lists.debian.org/debian-l10n-french/2010/06/msg00136.html which is untranslatable. So, this is why I hope you can read French. Have fun.

Just going on how they treat matters regarding the internet, it seems that the current Australian government is trying to beat the previous government's poor record. Where the previous government seemed to think the internet a scary and unimportant thing that they didn't really understand and therefore ignored it, the current government seems to be trying to do something, but like a lot of other things they do, do something badly.

Internet Filtering
One of their bright ideas is to censor the internet, by putting some rather large filters right in the middle of all the ISPs. Supposedly this is going to protect the children, though other than some mad ranting by Senator Conroy he hasn't said which children or how.

The clearest information is that it will block Refused Content or RC rated information. The problem with this is there is no clear definition what this is. With no clear boundary you can get what is "scope creep". Bit by bit, each group with their own agenda will try to get whatever they don't like banned. Some will fail, but others will get their little set of demons onto the list.

From "children overboard" to the strange siezure of the wikileaks founder's passport when he returned to Australia, you can never trust the government fully. As the filter list will be a closed list, who is to say if it is right a particular webpage or website should be banned? Books or films that are banned are known, you can find out what they are and why. A proper discussion and review can then be undertaken. By contrast, you won't even know something is banned unless you try to visit it.

I've personally seen the "great firewall of china". What is filtered is often arbitary, though anything that is embarassing to the government is filtered. It slows a lot of sites down and makes others look strange. Do you really what to live in a country where the government decides what ideas should be seen? Or even a country that places like China can point to and say they are doing the same thing, so its all ok?

Data Retention
The next bright idea by the government is to make ISPs keep 10 years of internet browsing history of all their users. This would be like tapping everyone's phone, just in case you did something wrong in the next 10 years.

There hasn't been much detail about this proposal but let's assume for a moment that it keeps URLs. Now of course most people's internet addresses move around, so you will also need to keep some sort of log of which account used what address for the same time.

The URLs will tell the government which websites you have visited, but URLs also tell them which pages you visited. You can also often assume which pages you read and which you didn't because of the time between this viewed page and the next.

Search engine queries are also encoded into a url. Google searches usually have something at the end of the url which is what you were searching for. There is also a chain of visited pages, so someone looking at a log could see your search, you go to a site, perhaps you then visit a banking or paypal site (have you bought something now?)

Even if you think you have nothing to worry about what the government might do with this information, including future governments, this information has to sit somewhere. Data sitting around for 10 years has 10 years time of being stolen or copied. Perhaps some activists obtain this log and publish a list of names of people who visited a particular website.

There is current laws for lawful interception. This is where the police or another security agency goes to the court and says a particular person has done certain bad things and asks if they can intercept their internet traffic. It's the same rules if they want to tap your phone. Except for "fishing trips" where police just randomly look at information from anyone hoping to trip up on something, what is this system going to be used for?

What can you do?
If you're not happy about either, or both, of these new proposals, it is time to do something about it. Visit the website Open Internet Website for what you can do. One of the things is to

Related articles by Zemanta

• Censorship Down Under (spectrum.ieee.org)
• China Says Will Keep Blocking Online Content (abcnews.go.com)
• Australian Censorship Minister Claims People Under Attack From "Spams Through The Portal" (inquisitr.com)
• Australian Gov't Seeks To Record Citizens' Web Histories (yro.slashdot.org)

It s widely regarded that passwords should be changed regularly. The Australian government declared last week the National Cyber Security Awareness Week [1] and has published a list of tips for online security which includes Get a stronger password and change it at least twice a year . Can a Password be Semi-Public? Generally I think of a password as being either secret or broken. If a password is known to someone other than the sysadmin and the user who is authorised to use the account in question then you have potentially already lost all your secret data. If a password is disclosed to an unauthorised person on one occasion then merely changing the password is not going to do any good unless the root cause is addressed, otherwise another anothorised person will probably get the password at some future time. Hitachi has published a good document covering many issues related to password management [2]. I think it does a reasonable job of making sysadmins aware of some of the issues but there are some things I disagree with. I think it should be used as a list of issues to consider rather than a list of answers. The Hitachi document lists a number of ways that passwords may be compromised and suggests changing them every 60 to 90 days to limit the use of stolen passwords. This seems to imply that a password is something that s value slowly degrades over time as it s increasingly exposed. I think that the right thing to do is to change a password if you suspect that it has been compromised. There s not much benefit in having a password if it s going to be known by unauthorised people for 89 days before being changed! Fundamentally a password is something that can have it s value rapidly drop to zero without warning. It doesn t wear out. Why are terms such as Three Months used for Maximum Password Ages? The Hitachi document gives some calculations on the probability of a brute-force attack succeeding against a random password with 90 days of attacking at a rate of 100 attempts per second [2]. I think that if a service is run by someone who wouldn t notice the load of 100 attempts per second then you have bigger security problems than the possibility of passwords being subject to brute-force attacks. Also it s not uncommon to have policies to lock accounts after as few as three failed login attempts. Rumor has it that in the early days of computing when the hashed password data was world readable someone calculated that more than 3 months of CPU time on a big computer would be needed to obtain a password by brute-force. But since then the power of individual CPUs has increased dramatically, computers have become cheap enough that anyone can easily gain legal access to dozens of systems and illegal access to a million systems, and it has become a design feature in every OS that hashed passwords are not readable by general users. So the limiting factor is to what degree the server restricts the frequency of password guesses. I don t think that specifying the minimum password length and maximum password age based on the fraction of the key space that could be subject to a brute-force attack makes sense. I don t think that any attempt to make an industry-wide standard for the frequency of password changes (as the government is trying to do) makes sense. Can there be a Delay between a Password being Compromised and being Used by an Attacker? Hypothetically speaking, if a password was likely to be compromised (EG by having the paper it was written on lost or stored insecurely) for some time before an attacker exploited it, then if the password was changed during that time period it could solve the problem. For example when a company moves office there is the possibility of notepaper with passwords to be lost. So if the sysadmin caused every user password to expire at the time of the move then a hostile party would be unable to gain access. Another possibility is the theft of backup tapes that contain the list of unencrypted passwords. If users change their passwords every three months then the theft of some four month old backup tapes will be less of a problem. Another possibility concerns the resale of old computers, phones, and other devices that may contain passwords. A reasonably intelligent user won t sell their old hardware as soon as the replacement device arrives, they will want to use the new device for some time to ensure that it works correctly. If passwords expire during this trial period with the new device then passwords stored in the old device won t have any value. The down-side to this idea is that people probably sell their old gear fairly quickly and making passwords expire every two weeks would not be accepted well by the users. It seems to me that having bulk password changes (all passwords for one user or for one company) based on circumstances that lead to potential insecurity would do more good than changing passwords at a fixed schedule. How are Passwords typically Compromised? Dinei Flor ncio and Cormac Herley of Microsoft Research and Baris Coskun of Brooklyn Polytechnic University wrote a paper titled Do Strong Web Passwords Accomplish Anything? [3] which discusses this issue. The first thing that they note is that nowadays passwords are most commonly compromised by phishing and keylogging. In those cases passwords are typically used shortly after they are stolen and the strength of a password never does any good. That paper suggests that banks should use stronger user-names rather than stronger passwords to combat the threat of bulk brute-force attacks. Can a Password Last Forever? If a password is entered in a secure manner, authenticated by a secure server, and all network links are encrypted or physically protected then there should never be a need to change it. Of course nothing is perfectly secure, so for some things with minimal short-term value or which can be used without anyone noticing there is a benefit in changing the password. But in the case of Internet banking if a hostile party gets your login details then you will probably know about it in a few days when the bank calls you about the unusual transactions from foreign countries long before a 90 day password change schedule would have done any good. Maybe one of the issues determining whether a password should be changed regularly is whether an attacker could use long-term read-only access to gain some benefit. Being able to read all the email someone received for a year could be a significant benefit if that person was a public figure, and there s usually no way for an ISP customer to know that someone else is downloading all their mail via POP or IMAP. Should a Password be the only Authentication Method? It is generally agreed that an authenitcation method should ideally involve something you have plus something you know. That means a password and a physical device such as a smart card, token with a changing sequential password, or a key such as a Yubikey [4]. If the physical device can t be cloned (through some combination of technical difficulty and physical access control) then it significantly improves security. When a physical device is used the purpose of the password is merely to stop someone who steals the physical device from being immediately exploit everything the password only has to be strong enough to keep the accounts secure until a new token can be issued. The combination of something you have and something you know is very strong. Having a physical token stored on the desk next to the PC that is used for logging in provides a significant benefit, then an attacker needs to break in to the house and can t sniff the password by compromising the PC remotely. Conclusion In all aspects of security you need to consider what threats you face. If an attacker is likely to launch an immediate noisy attack (such as transferring the maximum funds out of an Internet banking account) then changing the password regularly won t do any good. If a subtle long-term attack is expected then changing the password can do a lot of good but a physical token is the ideal if the account is valuable enough. But to put things in to perspective, it s technically possible to use a mobile phone camera at close range (or a SLR with a big lens at long range) to take a photo of keys that allow reproducing them. But this hasn t stopped people from carrying their house keys in an obvious manner that permits photography or leaving them on their desk at work. Also I ve never heard of anyone routinely changing the door locks in case a hostile party might have got a key although I m sure that such practices are common in highly secure locations. Few people even take their house keys off the key-ring when they have their car serviced! Related Posts Defense in Depth and Sudo when using sudo can increase security and when it can t.
Logging Shell Commands how to log what the sysadmin does and what benefits that provides you, it doesn t help if the sysadmin is hostile.
Logging in as Root should you login directly as root?

• [1] http://www.staysmartonline.gov.au/news/news_articles/feature/national_cyber_security_awareness_week
• [2] http://psynch.com/docs/password-management-best-practices.html
• [3] http://www.usenix.org/event/hotsec07/tech/full_papers/florencio/florencio.pdf
• [4] http://etbe.coker.com.au/2010/03/15/yubikey/

People s the deadline is fast approaching. Don t worry though, the best ideas come under deadlines and your proposal need not be lengthy. So get those typing hands out and submit a proposal (a few sentences suffices) for a presentation!
The annual Debian conference is being held in NYC this year. First time
setting foot in the imperial empire. Are you doing something related to
free software that might be interesting to share, show off or talk about
at Debconf? I bet you are! We are looking for art installations,
performances, movie screenings, maybe you are wanting to host a
roundtable/panel discussion, coordinate a workshop (you dont have to
know the subject deeply to do this!). I know the deadline is soon, but don t let that scare you. The
submission requirement bar is very low, and we are flexible! here is the submission information: [1] ********************* Calling all potential contributors to DebConf10! One more week until
the final submission deadline! The DebConf team is excited to announce that we are now accepting
proposals for contributions to this year s Debian conference! We
invite you to submit proposals for how you would contribute until the
deadline: soon There are many ways you can contribute, you could present a technical
paper, host a panel discussion, put on a tutorial, do a performance,
an art installation, a debate, host a meeting (BoFS, or Birds of a
Feather Session), or other possibilities that you devise. This year we
are also accepting proposals for tracks=E2=80=94a thematic grouping around a
particular subject, and people to coordinate those tracks. If you are
looking for ideas of things that you could contribute, or have ideas
for things that you would like to see happen at DebConf, have a look
at the Contribution Brainstorm[0] page. DebConf talks will be broadcast live on the Internet where possible,
unless otherwise requested. Videos of the talks will be published on
the web along with the presentation slides and papers. =3D=3D Step 1. Submit Proposal =3D=3D Proposals should provide an overview of your proposed contribution,
similar to an abstract, and be no more than 600 words. Since
contributions can cover a range of issues, please describe what your
proposal covers, be it political (Free Software, law, advocacy,
access, etc.), technical (d-i, OpenPGP, etc.), social (Debian
structures and groups). It s okay to hit all three of these. Your
proposal should also include some information on why you re qualified
to present, or coordinate this topic. For example, you can include
links to posts you have made to Debian mailing lists or other material
that indicates your qualifications. Proposals and their abstracts will
be accepted until May 1st, 2010, 23h59 UTC. To submit your proposal, go to Penta[1] and register as an
attendee. Once you are registered, there is a Submit a proposal
link. You will see your proposal on the site. You can choose between
different presentation types. If you are unsure what type you should
use, please read our glossary of definitions[2]. If it s not there for
some reason, or you have questions, please contact us immediately at
mailto:talks@debconf.org. =3D=3D Step 2. Committee Review =3D=3D The review committee for this year will make its decision by May 1st,
2010. All correspondence will be done by email. =3D=3D Step 3. Paper Submission =3D=3D Like last year, we are asking for papers to be submitted along with
the presentations. A full paper is optional, however we strongly
encourage you to submit one if possible as we intend to provide
written information along with transcripts of the sessions for later
viewing. Having written papers in advance will allow us to get
translations done to help non-native-English speakers feel more
comfortable with the topics presented. Papers are due by July 1st,
2010, and should cover the topic in reasonable depth (3 pages A4 text,
plus pictures and diagrams). We will use LaTeX to typeset the
proceedings. Please submit your paper formatted in LaTeX. Should you
be unfamiliar with LaTeX earlier submission in plain text is also
fine. =3D=3D Step 4. Live Presentation =3D=3D Longer presentations may have a break in the middle and should include
workshop items that directly involve the participants. If using slides
or any other presentation, please consider that your audience will
consist of people who use free software, and your choice of
application to prepare and display the slides should reflect this if
at all possible. =3D=3D Fine Print Publication Rights =3D=3D DebConf requires non-exclusive publication rights to papers,
presentations, and any additional handouts or audio/visual materials
used in conjunction with the presentation. The authors have the
freedom to pick a DFSG-free license for the papers themselves and
retain all copyrights. The presentations will be recorded, and may be
broadcast over the Internet. Any copies of the presentation will be
made available =3D=3D Failure to Submit =3D=3D In the event that a deadline is missed we reserve the right to revoke
any offer to present. =3D=3D About DebConf =3D=3D The annual DebConf conference is a technical and social forum for
Debian developers, sponsors, affiliates, and friends. It allows
various groups within Debian a chance to come together, network, and
share their work. Until we see you in the big city,
DebConf Talks Team [1] introduction written by Micah Anderson

Friday I took the day off for us to go camping. Due to the birth of Oliver, our last time camping was in 2008. Back then, Terah had asked me what I wanted for father s day, and I suggested camping. Except when she was pregnant last year (and then Oliver was little), we have sort of had a standing plan to go camping twice a year: around father s day and my birthday. She says that s way more camping in a year than anyone needs. Anyhow, Jacob doesn t remember the last time we went camping; he was not quite 2 at the time. I explained that we would sleep in tents, and he d get one just his size. He laughed at that. Then I explained that he would get a bag to sleep in, and he thought that was hilarious. He kept talking about tents and even more so about sleeping bags until he actually got to be in one. It seems like each time we go camping, we wind up somewhere else. We ve camped at Kanoplis Lake and Marion Park and Lake in the past few years. But this time we went to Cedar Valley Reservoir near Garnett, KS. It was a nice place to be, with some wilderness camping areas far from any RV hookups (though right next to a gravel driveway where we could park). Almost as soon as we got out of the car, Jacob found a partially-burned stick left in a fire ring. So of course his hands were black pretty quick. He kept track of that stick the whole time we were there, and used it for everything he could think of. His favorite use, though, was at the lake to splash water: The lake really was his favorite feature. He loved to throw rocks and sticks in it with me, to splash himself, and to stick his feet in. Oh, and to splash me. The pier was also a great thing for him he at first thought it was a boat, then really wanted to go. I made him hold my hand the whole time, and he liked walking on it. But he was frustrated that he couldn t reach the water. Somehow, Jacob acted as if he could sit in the hot sun for hours, just making small splashes with a stick. I, on the other hand, felt the 90-degree heat strongly, and eventually we found a shady spot to play in the lake. Oliver enjoyed crawling around on a blanket or on the grass. Though Terah put a stop to that after she noticed that he came across a pile of fish heads and was about to reach for one and put it in his mouth. We cooked over a campfire Friday night and Saturday morning. It took me a lot longer to start a fire than normal. Part of the problem was that there had been a lot of rain in the area, and it was humid, so there was little kindling to be found. Plenty of larger pieces of wood, so once the fire got going, it burned nicely. We cooked brats, brought along some homemade bread, had grilled foil-wrapped potatoes, and had stir-fry vegetables. Oliver got to eat with us too, of course: Terah is a big believer in smores, so after supper we made some smores Jacob predictably got sticky from the marshmallows and chocolate. Jacob started asking when I d set up the tent almost as soon as he found his stick. All afternoon he kept asking. Finally we got it set up, and of course he was so excited that he played inside it for an hour before he fell asleep. Terah had bought a $4 lantern at Walmart to give to him to use in his tent. I told him that there would be a surprise lantern in his tent for him to use. And he loved his lantern. It could turn on, off, and flash red. At one point he asked me, Dad, do you have a surprise lantern too? No, I will just use my flashlight. He looked a bit sad about that. For about 5 seconds. Then he turned on his lantern again. Here he is with it, still playing happily about 2 hours after his bedtime: And in the morning, of course he was still wanting that, but also wanted to play with his digital camera (a kid s version that also has a simple game or two on it). Without leaving the tent, of course. Oliver was getting hungry while we worked on breakfast, so I gave him some bread to munch on. We used our cast iron skillet to fry some bacon for breakfast. Then Terah made some pancakes in the skillet (with the bacon grease). Greasiest and best pancakes ever. After that, we had some fried and scrambled eggs. After that, we had more smores (I wasn t kidding about Terah being a big believer in them.) Jacob decided that he wanted to play in the other tent. He enjoyed playing with Terah, Oliver, and the air mattress (that Terah appreciated as much as I thought it took up too much space in the car). There s a little window on the back that can open to a screen or open completely. Jacob and Oliver enjoyed looking out of it while open. Or rather, Jacob enjoyed that, while Oliver enjoyed licking it. I had my Droid with me to keep an eye on the weather. The forecast for several days had called for a 20% chance of storms on Saturday. I checked Saturday morning at 7, and it still called for 20% chance of storms after 1PM. We decided we d pack up our tents after breakfast so we could stay as long as we liked or leave on short notice if we preferred. Clouds seemed to be building, though, so I checked the forecast again at maybe 9. Now it called for 60% chance of thunderstorms and heavy rain before 1PM. Guess I shouldn t have been surprised; it is Kansas after all. As I had the first tent about 90% put away, it started to rain. We rushed to get the rest of the stuff in the car, and by the time we did, it was raining heavily. We had planned to spend at least part of the afternoon there, but decided we d look for another place to stop on the way home. We stopped first at Garnett s North Lake, as the rain had let up for awhile. We spotted a fishing pier that Jacob wanted to walk on, but the bridge out to it was underwater, so we passed on that. While Terah fed Oliver in a shelter, Jacob and I played on some swings. Then we walked down to that lake. Jacob carefully came to an abrupt stop and looked both ways at each disused road between us and the lake, saying OK when it was clear to go. The rain picked up again, so we started heading towards home. It got quite heavy, with thunder and everything, which Jacob didn t care for at all. Both boys went to sleep, though. We stopped at Marion Reservoir on the way home. Jacob hadn t been able to play in the lake at Garnett (the place we stopped had a bank that was too steep) and so we played there. He waded into the water at the swimming area, and predictably enjoyed yes throwing rocks into the lake. When we got home, I set out the wet tent and tarps (it s not good to store that stuff wet) to dry there hadn t been rain at home yet. Camping s a lot of work, but it was a good family activity. I m looking forward to our next time, and hope we can choose a weekend a little less hot and damp.

The world around me seems to whirl these days. One week ago, I graduated from MIT. People I've known during the last four years have been dispelling to various parts of the globe one by one, day by day. California, Canada, Indonesia, Seattle. Some will be back again. Some will not, or if so only to visit. pika is a continuous bustle of activity as the summer has commenced and it has filled with creative and adventurous MIT students who've suddenly found themselves having free time. A hammock being built on the roofdeck. Thrice-weekly icecream forays. Common areas overflowing with people playing musical instruments, chatting, and messing around on laptops. Summer's warmth has arrived, bringing with it farmer's markets, strawberry picking, and swimming expeditions. While it's wonderful to get to meet so many new people living in a college environment, I can't help but feel sadness thinking about everyone who's left. There are always more friends to be made as new people arrive, but old ones moving away leave bittersweet memories, and the new relationships are always a bit different as the age discrepancy between me and others changes. Or the me-the-ephemeral-collection-of-thoughts-which-when-regarding-other-people-sometimes-involve-the-mentor/mentee-distinctions-caused-by-one-party-being-older-or-more-knowledgeable-than-the-other-at-least-in-certain-areas changes. The end of a semester always feels like this, but this year even more so as the people I started university with start down new paths. For me, that was going to involve staying on at MIT to complete a one-year master's program, the "M.Eng." in electrical engineering and computer science. That plan, too, has changed. I've deferred the degree and accepted a full-time engineering position at Ksplice, an exciting early-stage Linux startup here in Cambridge. I'd been working at Ksplice part-time since January before joining full-time immediately following graduation. Ksplice is the realization of ideas I saw being born on the whiteboard at SIPB when I was a freshman, and it's fun to see that play out in a small, ever-changing, low-bullshit company. All in all, there are many more exciting things down the road, and, working at an MIT startup, I haven't even escaped the MIT/Cambridge reality-distortion bubble yet. Still, it's tempting to resist change and let myself romanticize the good old days, hoping to catch every person I've ever enjoyed spending time with and hold them down here forever. That's not the way life works, though. Change happens.

For the second time (First time was in 2008; I didn't join in 2009 as I travelled to Nicaragua on that date), I took part of the World Naked Bike Ride. The WNBR is a global effort, where people in ~150 cities all over the world go cycling nude on the streets of our towns, with varied demands, including:

• Safe conditions for cyclists (mainly aimed at car drivers, at the society at large, but also requesting proper infrastructure measures from our respective governments)
• Raising the consciousness that every individual has a bit of power to free us all from oil-produced pollution
• Tolerance, acceptance of people who are not exactly like us
• Lower the ecologic impact of humans against the world

One of the things I most like about WNBR is its diversity. Not everybody goes for the same reasons. As people who read me often will know, I took part because I believe (and act accordingly!) that the bicycle is the best, most efficient vehicle in by far most of the situations we face day to day, but we need to raise awareness in everybody that the bicycle is just one more vehicle: On one side, we have the right to safely ride on the streets, like any other vehicle. On the other side, we must be responsible, safe drivers, just as we want car drivers to be. Ok, and I will recognize it before anybody complains that I sound too idealistic: I took part of the WNBR because it is _tons_ of fun. This year, we were between 300 and 500 people (depending on whom you ask). Compared to 2008, I felt less tension, more integration, more respect within the group. Of course, it is only natural in the society I live in that most of the participants were men, but the proportion of women really tends to even out. Also, many more people joined fully or partially in the nude (as nudity is not required, it is just an invitation). There was a great display of creativity, people painted with all kinds of interesting phrases and designs, some really beautiful. Oh, one more point, important to me: This is one of the best ways to show that we bikers are not athletes or anything like that. We were people ranging from very thin to quite fat, from very young to quite old. And that is even more striking when we show our whole equipment. If we can all bike around... So can you! Some links, with obvious nudity warnings in case you are offended by looking at innocent butts and similar stuff:

• My WNBR 2010 Mexico photo gallery
• My friend Jes s Wong, professional photographer, was documenting WNBR His gallery
• Media presence (as far as I have seen):
  • El Universal, Saturday 14:30, reporting the Ride had finished and the streets were again... Safe?
  • El Universal, the note printed in the next morning paper: Pedalling nude, they demand respect towards cyclists
  • La Jornada: Cyclist protest
  • La Cr nica: They pedalled bare naked
  • Organizaci n Editorial Mexicana (OEM): Hundreds of cyclists protested nude on Mexico City because of the oil spill Well... not exactly, but close :)
  • Qu ! (Espa a): Around three hundred naked cyclists toured Mexico City
  • rpp.com.pe (Per ): 300 nude cyclists toured the main avenues

As for the sad, stupid note: 19 cyclists were placed under arrest in Morelia, Michoac n because of faltas a la moral (trasgressions against morality), an ill-defined and often abused concept. Also, by far, most of the comments I have read from people on the media, as well a most questions we had by reporters before or after the ride were either why are you going nude (because that's the only way I'll get your attention!) or But many people were not nude! (nudity is not a requirement but only an option.

My testing of Debian upgrades from Lenny to Squeeze continues, and I've finally made the upgrade logs available from http://people.skolelinux.org/pere/debian-upgrade-testing/. I am now testing dist-upgrade of Gnome and KDE in a chroot using both apt and aptitude, and found their differences interesting. This time I will only focus on their removal plans. After installing a Gnome desktop and the laptop task, apt-get wants to remove 72 packages when dist-upgrading from Lenny to Squeeze. The surprising part is that it want to remove xorg and all xserver-xorg-video* drivers. Clearly not a good choice, but I am not sure why. When asking aptitude to do the same, it want to remove 129 packages, but most of them are library packages I suspect are no longer needed. Both of them want to remove bluetooth packages, which I do not know. Perhaps these bluetooth packages are obsolete? For KDE, apt-get want to remove 82 packages, among them kdebase which seem like a bad idea and xorg the same way as with Gnome. Asking aptitude for the same, it wants to remove 192 packages, none which are too surprising. I guess the removal of xorg during upgrades should be investigated and avoided, and perhaps others as well. Here are the complete list of planned removals. The complete logs is available from the URL above. Note if you want to repeat these tests, that the upgrade test for kde+apt-get hung in the tasksel setup because of dpkg asking conffile questions. No idea why. I worked around it by using 'echo >> /proc/pidofdpkg/fd/0' to tell dpkg to continue. apt-get gnome 72
bluez-gnome cupsddk-drivers deskbar-applet gnome gnome-desktop-environment gnome-network-admin gtkhtml3.14 iceweasel-gnome-support libavcodec51 libdatrie0 libgdl-1-0 libgnomekbd2 libgnomekbdui2 libmetacity0 libslab0 libxcb-xlib0 nautilus-cd-burner python-gnome2-desktop python-gnome2-extras serpentine swfdec-mozilla update-manager xorg xserver-xorg xserver-xorg-core xserver-xorg-input-all xserver-xorg-input-evdev xserver-xorg-input-kbd xserver-xorg-input-mouse xserver-xorg-input-synaptics xserver-xorg-input-wacom xserver-xorg-video-all xserver-xorg-video-apm xserver-xorg-video-ark xserver-xorg-video-ati xserver-xorg-video-chips xserver-xorg-video-cirrus xserver-xorg-video-cyrix xserver-xorg-video-dummy xserver-xorg-video-fbdev xserver-xorg-video-glint xserver-xorg-video-i128 xserver-xorg-video-i740 xserver-xorg-video-imstt xserver-xorg-video-intel xserver-xorg-video-mach64 xserver-xorg-video-mga xserver-xorg-video-neomagic xserver-xorg-video-nsc xserver-xorg-video-nv xserver-xorg-video-openchrome xserver-xorg-video-r128 xserver-xorg-video-radeon xserver-xorg-video-radeonhd xserver-xorg-video-rendition xserver-xorg-video-s3 xserver-xorg-video-s3virge xserver-xorg-video-savage xserver-xorg-video-siliconmotion xserver-xorg-video-sis xserver-xorg-video-sisusb xserver-xorg-video-tdfx xserver-xorg-video-tga xserver-xorg-video-trident xserver-xorg-video-tseng xserver-xorg-video-v4l xserver-xorg-video-vesa xserver-xorg-video-vga xserver-xorg-video-vmware xserver-xorg-video-voodoo xulrunner-1.9 xulrunner-1.9-gnome-support aptitude gnome 129
bluez-gnome bluez-utils cpp-4.3 cupsddk-drivers dhcdbd djvulibre-desktop finger gnome-app-install gnome-mount gnome-network-admin gnome-spell gnome-vfs-obexftp gnome-volume-manager gstreamer0.10-gnomevfs gtkhtml3.14 libao2 libavahi-compat-libdnssd1 libavahi-core5 libavcodec51 libbluetooth2 libcamel1.2-11 libcdio7 libcucul0 libcupsys2 libcurl3 libdatrie0 libdirectfb-1.0-0 libdvdread3 libedataserver1.2-9 libeel2-2.20 libeel2-data libepc-1.0-1 libepc-ui-1.0-1 libfaad0 libgail-common libgd2-noxpm libgda3-3 libgda3-common libgdl-1-0 libgdl-1-common libggz2 libggzcore9 libggzmod4 libgksu1.2-0 libgksuui1.0-1 libgmyth0 libgnomecups1.0-1 libgnomekbd2 libgnomekbdui2 libgnomeprint2.2-0 libgnomeprint2.2-data libgnomeprintui2.2-0 libgnomeprintui2.2-common libgnomevfs2-bin libgpod3 libgraphviz4 libgtkhtml2-0 libgtksourceview-common libgtksourceview1.0-0 libgucharmap6 libhesiod0 libicu38 libiw29 libkpathsea4 libltdl3 libmagick++10 libmagick10 libmalaga7 libmetacity0 libmtp7 libmysqlclient15off libnautilus-burn4 libneon27 libnm-glib0 libnm-util0 libopal-2.2 libosp5 libparted1.8-10 libpoppler-glib3 libpoppler3 libpt-1.10.10 libpt-1.10.10-plugins-alsa libpt-1.10.10-plugins-v4l libraw1394-8 libsensors3 libslab0 libsmbios2 libsoup2.2-8 libssh2-1 libsuitesparse-3.1.0 libswfdec-0.6-90 libtalloc1 libtotem-plparser10 libtrackerclient0 libxalan2-java libxalan2-java-gcj libxcb-xlib0 libxerces2-java libxerces2-java-gcj libxklavier12 libxtrap6 libxxf86misc1 libzephyr3 mysql-common nautilus-cd-burner openoffice.org-writer2latex openssl-blacklist p7zip python-4suite-xml python-eggtrayicon python-gnome2-desktop python-gnome2-extras python-gtkhtml2 python-gtkmozembed python-numeric python-sexy serpentine svgalibg1 swfdec-gnome swfdec-mozilla totem-gstreamer update-manager wodim xserver-xorg-video-cyrix xserver-xorg-video-imstt xserver-xorg-video-nsc xserver-xorg-video-v4l xserver-xorg-video-vga zip apt-get kde 82
cupsddk-drivers karm kaudiocreator kcoloredit kcontrol kde kde-core kdeaddons kdeartwork kdebase kdebase-bin kdebase-bin-kde3 kdebase-kio-plugins kdesktop kdeutils khelpcenter kicker kicker-applets knewsticker kolourpaint konq-plugins konqueror korn kpersonalizer kscreensaver ksplash libavcodec51 libdatrie0 libkiten1 libxcb-xlib0 quanta superkaramba texlive-base-bin xorg xserver-xorg xserver-xorg-core xserver-xorg-input-all xserver-xorg-input-evdev xserver-xorg-input-kbd xserver-xorg-input-mouse xserver-xorg-input-synaptics xserver-xorg-input-wacom xserver-xorg-video-all xserver-xorg-video-apm xserver-xorg-video-ark xserver-xorg-video-ati xserver-xorg-video-chips xserver-xorg-video-cirrus xserver-xorg-video-cyrix xserver-xorg-video-dummy xserver-xorg-video-fbdev xserver-xorg-video-glint xserver-xorg-video-i128 xserver-xorg-video-i740 xserver-xorg-video-imstt xserver-xorg-video-intel xserver-xorg-video-mach64 xserver-xorg-video-mga xserver-xorg-video-neomagic xserver-xorg-video-nsc xserver-xorg-video-nv xserver-xorg-video-openchrome xserver-xorg-video-r128 xserver-xorg-video-radeon xserver-xorg-video-radeonhd xserver-xorg-video-rendition xserver-xorg-video-s3 xserver-xorg-video-s3virge xserver-xorg-video-savage xserver-xorg-video-siliconmotion xserver-xorg-video-sis xserver-xorg-video-sisusb xserver-xorg-video-tdfx xserver-xorg-video-tga xserver-xorg-video-trident xserver-xorg-video-tseng xserver-xorg-video-v4l xserver-xorg-video-vesa xserver-xorg-video-vga xserver-xorg-video-vmware xserver-xorg-video-voodoo xulrunner-1.9 aptitude kde 192
bluez-utils cpp-4.3 cupsddk-drivers cvs dcoprss dhcdbd djvulibre-desktop dosfstools eyesapplet fifteenapplet finger gettext ghostscript-x imlib-base imlib11 indi kandy karm kasteroids kaudiocreator kbackgammon kbstate kcoloredit kcontrol kcron kdat kdeadmin-kfile-plugins kdeartwork-misc kdeartwork-theme-window kdebase-bin-kde3 kdebase-kio-plugins kdeedu-data kdegraphics-kfile-plugins kdelirc kdemultimedia-kappfinder-data kdemultimedia-kfile-plugins kdenetwork-kfile-plugins kdepim-kfile-plugins kdepim-kio-plugins kdeprint kdesktop kdessh kdict kdnssd kdvi kedit keduca kenolaba kfax kfaxview kfouleggs kghostview khelpcenter khexedit kiconedit kitchensync klatin klickety kmailcvt kmenuedit kmid kmilo kmoon kmrml kodo kolourpaint kooka korn kpager kpdf kpercentage kpf kpilot kpoker kpovmodeler krec kregexpeditor ksayit ksim ksirc ksirtet ksmiletris ksmserver ksnake ksokoban ksplash ksvg ksysv ktip ktnef kuickshow kverbos kview kviewshell kvoctrain kwifimanager kwin kwin4 kworldclock kxsldbg libakode2 libao2 libarts1-akode libarts1-audiofile libarts1-mpeglib libarts1-xine libavahi-compat-libdnssd1 libavahi-core5 libavc1394-0 libavcodec51 libbluetooth2 libboost-python1.34.1 libcucul0 libcurl3 libcvsservice0 libdatrie0 libdirectfb-1.0-0 libdjvulibre21 libdvdread3 libfaad0 libfreebob0 libgail-common libgd2-noxpm libgraphviz4 libgsmme1c2a libgtkhtml2-0 libicu38 libiec61883-0 libindex0 libiw29 libk3b3 libkcal2b libkcddb1 libkdeedu3 libkdepim1a libkgantt0 libkiten1 libkleopatra1 libkmime2 libkpathsea4 libkpimexchange1 libkpimidentities1 libkscan1 libksieve0 libktnef1 liblockdev1 libltdl3 libmagick10 libmimelib1c2a libmozjs1d libmpcdec3 libneon27 libnm-util0 libopensync0 libpisock9 libpoppler-glib3 libpoppler-qt2 libpoppler3 libraw1394-8 libsmbios2 libssh2-1 libsuitesparse-3.1.0 libtalloc1 libtiff-tools libxalan2-java libxalan2-java-gcj libxcb-xlib0 libxerces2-java libxerces2-java-gcj libxtrap6 mpeglib networkstatus openoffice.org-writer2latex pmount poster psutils quanta quanta-data superkaramba svgalibg1 tex-common texlive-base texlive-base-bin texlive-common texlive-doc-base texlive-fonts-recommended xserver-xorg-video-cyrix xserver-xorg-video-imstt xserver-xorg-video-nsc xserver-xorg-video-v4l xserver-xorg-video-vga xulrunner-1.9

There has been some discussion on the Debian IPv6 list about how the function gethostbyname() has changed. The manual page says this function is obsolete and with good reason.

A new feature of the function is that if a hostname has both IPv4 and IPv6 entries then the order of the return values is not predefined. In fact it used to be you'd get the IPv4 addresses first, then the IPv6. That has now changed and with the more recent glibc you will get an IPv6 address first. Quite often old code doesn't even check the address family or the size of address structure but just copies the relevant 4 bytes. You then get the first part of an 16-byte IPv6 address wedged into a 4-byte IPv4 address structure which basically means you get a mess.

The fix is pretty simple by changing the system call from gethostbyname() and using getaddrinfo() instead. If you only want the IPv4 addresses, perhaps because other parts of the code have not been checked or changed, then set the hints variable to return only IPv4 addresses.

If one of your packages is starting to play up and unable to connect to certain remote places and is instead trying to get to some "random" address, have a quick check for gethostbyname(). A quick grep across the source code may save a lot of debugging time.