So a year and a half ago, I mentioned I was trying to learn Haskell, and I still am. It’s been going much more slowly than I hoped, since I haven’t really spent any time on it. I never write anything new anymore! So I decided to rewrite something I had previously written myself, need be damned. So I chose the RSS aggregator I wrote, harsh. harsh hasn’t changed in eleven months (and that change was just about making the location of its configuration file configurable), but I still remembered how it worked pretty closely; at least enough that I didn’t have to really go searching through its code too much. That’s probably also a function of how small harsh is; in terms of lines of code (excluding blank lines):

  config.c: 139
  cookie.c: 221
 display.c: 709
    feed.c: 577
    list.c: 96
    list.h: 16
    main.c: 96
    main.h: 84
     md5.c: 360
     md5.h: 76
     rss.c: 120
     xml.c: 276
     xml.h: 17
     total: 2787

It uses expat to parse the HTML, libnbio for socket management (which is available in Debian), and ncurses for the UI. It doesn’t have any sort of threading (libnbio does a good job of making sure that, other than DNS lookups, there’s never anything going on long enough to prevent responsiveness). About its only feature is that it will use my cookies.txt file, so that I can see my LiveJournal friends’ protected entries. I originally wrote harsh in about a day or two. It was really easy because of the 2800 lines, about 850 of them had been written in some of my other projects (list.c/h and xml.c/h) or are standard (md5.c/h). I was also really familiar with the three helper libraries from writing grim (my IM client) and stark (a tool for viewing GnuCash data files). As a learning exercise, rewriting harsh in Haskell was excellent. It’s incredibly small, does a lot of standard things (like networking and console UI), and doesn’t do a lot of non-standard things (like an AIM client does). I got to play with the Haskell light-weight threads and STM; I learned how to create a Debian Haskell package; I learned how to use ghci as a debugger with breakpoints; and I’m much more comfortable with monads and with the language in general. It did take me significantly longer to write than the C version, though that’s more due to me having to learn not just the language but some libraries along the way (like HTTP, Vty, and HaXml). I still think that it would take me just as long to write the Haskell version as the C version, but I’m still much more comfortable with C, and imperative programming in general. From a code size perspective, the Haskell version is about one-sixth the size (excluding comments):

Config.lhs: 53
  Feed.lhs: 144
 Harsh.lhs: 272
  Util.lhs: 26
     total: 495

However, that’s not a very fair comparison. In the C version, md5.c/h are included in the total count, when really they should be considered a standard library (and on the Haskell side, I used Data.Hash.MD5 from MissingH). On the C side, I did all of the HTTP request and response processing myself (which is what more than half of feed.c is about), while on the Haskell side I left that to an HTTP client library. Excluding all those things though, the Haskell version is still about one-fourth the size. Anyway, I put the Haskell version of harsh up here. If any Haskell hackers out there could take a look at it and let me know what I’m doing wrong or oddly, I’d appreciate it.

After 2005, 2006 and 2007, I did it again. Here are my yearly stats about Jabber clients! 1244 users were online on the Apinc Jabber server when I ran the poll, and 1163 clients answered. Telepathy doesn’t seem to answer to jabber:iq:version, and it seems that a bug prevents Gajim from answering in some obscure cases (even when the “send info about OS” option is enabled). Systems:

• GNU/Linux 40%
• Unknown 36% (Pidgin doesn’t report the OS)
• Windows 17%
• MacOS 5%
• Others 0% (4 clients)

Clients:

• Pidgin 27% (2007: gaim: 22%)
• Gajim 20% (2007: 22%)
• Psi 16% (2007: 24%)
• Kopete 14% (2007: 11%)
• libpurple (Adium) 6% (2007: 5%)
• iChat 4% (2007: 9%)
• Other clients with 2% or less: gajim, BitlBee, Miranda, Pandion, neos, pidgin (with ‘p’ instead of ‘P’), Trillian, Exodus, Coccinella, JabberLib, Tkabber, Gossip, Digsby Client, sim, Finch, JAJC, Bluejabb, Spark.

Exim has the habit of trying to find out about its host names and IP addresses when it starts up. This has, in the past, been an issue for the Debian packages, since a Debian system might be on a dial-on-demand modem line with expensive costs and thus should not do unnecessary DNS lookup when the MTA is started. This article tries to describe the issue and which countermeasures debian took, and asks for tips how to solve this in the case of IPv6, where our past measures unfortunately do not directly apply. I’d like to solicit opinions from people who are more experienced than me with Unix, the local resolver library including /etc/hosts and /etc/nsswitch.conf, DNS, and - especially - the customs that apply on a system running IPv6. To avoid the extra DNS lookups, the Exim packages have a Debconf option to configure exim for “minimal DNS usage”, which hardcodes the hostname into Exim’s configuration at package configuration time. This was necessary since - without this option - exim looks up its own host name in the DNS even when a completely local operation is invoked. In some cases, exim still looks up its IP address when a listening daemon starts up. This is why the Debian installer configures 127.0.1.1 (not 127.0.0.1) for the local hostname on installation, yielding /etc/hosts files like

127.0.0.1       localhost
127.0.1.1       myfoo.localdomain   myfoo
# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

However, in the last few weeks I have heard a few cases where exim does IPv6 AAAA lookups when a listening daemon starts up. An strace shows a gethostbyname2 call for AF_INET6, and if we want to continue the line we went in the past, we’d need an IPv6 address for myfoo.localdomain in /etc/hosts as well. I am now wondering how this could be implemented. In IPv4, we have 127.0.0.0/8 available for the local host and could arbitrarily choose 127.0.1.1 to configure the local host name on. In IPv6, there is only ::1, which is a single address. Would it be possible to choose an arbitrary “link local” address on lo, the loopback interface? Or is there any better way? This being said, I consider the entire 127.0.1.1 business a horrible hack which is one of the most ugly things I have ever seen. Do we have a chance to implement this in a more cleaner way, or is it still the way to go for the distribution, where we don’t know zilch about the environment where an installed system is going to be used? This issue leads to people adding their local host name to ::1 in /etc/hosts, which might re-introduce other issues that we experienced in a phase when we did the same for 127.0.0.1, eventually ending up with 127.0.1.1, or to disabling IPv6 altogether, which is a bad thing in a time where IPv6 should be enabled, not disabled. So I’d like to find a clean solution which could then be implemented in whatever part of Debian might be responsible. I tried asking this question in other places, including Usenet, before pestering my Blog to ask the Lazyweb, but obviously the people I asked before do not care for the special environment that a Linux distribution has to take care of. The only answers I got were like “that would be the local administrator’s task to fix” and “this should be taken care of in the local DNS server/setup (maybe even on the local box being installed)”. A quite frustrating experience.

OK, been quiet for a few days, at least on the blog, but in accordance with typical behaviour (for me at least) a quiet blog means a lot of things going on elsewhere. The smallest was a fix for deb-gview - combining a fix for opening files in the current working directory with a fix for the imminent dpkg 1.14.17 which modified the .changes file format a bit. That was relatively easy and I've uploaded 0.2.1 to unstable. gvfs hasn't made testing yet so there's no point in waiting for deb-gview to migrate before 0.2.1.
The largest change? Depends how you define large:

1. Large number of changes to package files - emdebian-tools 1.0.0
2. Large effect on Emdebian workload - dpkg 1.14.17

dpkg
dpkg bugs closed - emdebian-tools 1.0.0 pending - dpkg-shlibdeps is now able to look into directories containing libraries used by cross-built binaries provided that the right environment variable are set. Closes: #453267. dpkg-buildpackage will set PKG_CONFIG_LIBDIR (but not override an existing value) in case of cross-compilation so that pkgconfig finds .pc files in the directory specific to the target architecture. Closes: #439979.
These two changes will have a major effect on the overall workload required within Emdebian and give us a sane cross-building environment in Lenny which is ABSOLUTELY $^ @&*! FANTASTIC. Currently, 1.14.17 is in experimental but I've installed it on my system for testing purposes so that I can complete emdebian-tools 1.0.0:
emdebian-tools 1.0.0
Now here, I'm making some progress. A bug has been bothering me for some time with how emdebian-tools needs a Debian primary mirror to calculate various dependency information and other apt cache stuff whilst taking into account the host architecture. Simon and I now think that we can do the dependency stuff with a continually updated dpkg-cross repository and I can use libcache-apt-perl for the rest. So whereas dpkg-cross might still exist into Lenny, it is looking like apt-cross might not - at least not as an application. However, I'm not taking that step with emdebian-tools just yet. In the meantime, I'm simply using debconf to replace the automated selection of a Debian Primary Mirror and passing that mirror to apt-cross - something I should probably have setup a while ago.
As well as that bug fix, I've added a check to emchain so that users are warned if they don't actually need to run it, added the mirror support to the various scripts and removed the workarounds now fixed by dpkg.
'dpkg-buildpackage -a' is usable for nearly all packages once you have dpkg-dev >= 1.14.7. emdebuild >= 1.0.0 is only necessary IF:

1. You want to modify/update Emdebian patches (not just apply them) - i.e. if you have commit access to Emdebian SVN.


2. You need the one remaining wrapper: 'X-Build-Cross-Libtool: yes' which is my next main target. This is a package-specific problem and each incidence needs a package-specific solution via an appropriate patch. As such, the wrapper is likely to stay in place in emdebuild for some considerable time - at least until someone can rebuild the entire archive with a test that can identify which packages are still affected.


3. You want the build checks currently implemented by emdebuild but which I plan to spin out during the life of emdebian-tools 1.x. I want to standardise those build checks and abstract them into possibly a lintian-compatible check set.

Also, there should now be no need for any wrapper scripts that anyone may have devised to mangle LD_LIBRARY_PATH or PKG_CONFIG_LIBDIR - indeed,
explicit support for these within dpkg means that it is to be considered harmful from now on to touch these variables, except possibly in some specific corner cases.

Today i tried the first time to do GeoCaching with my Nokia N810 running the Maemo (which is a Debian-based Distribution). I already own a Garmin Geko 201 with which i found 100+ Caches, so this is my reference.

The GPS-Receiver of the N810 is better than the one in the Geko (at least since i use the fixed gpsd, which normally shouldn't do something on the performance, but in my case... it made me feel better), so fixes come faster, and more accurate than on the Geko. (from hearsay the SirfIII-Chip is even better)

I run Maemo Mapper on the N810, a free (as in speech) Software written to do things better than GpsDrive at least on the Nokia Internet Tablets.

I wrote some programs to be the glue between Geocaching-Websites and GPSdrive (which depends on MySQL) and i modifed those to put the information into SQLite, which is the Database used by Maemo Mapper.
If i pump all my waypoints in such a file (which are currently 94607) Maemo Mapper gets slow. so slow that Maemo Mapper becomes useless.

On the Garmin-GPS-Receiver, i can have only 500 Waypoints, but i have a 'goto'-function, so i store my destination coordinates and say 'Goto' and the thing provides me an arrow which points to my destination and shows the distance (it doesn't know about ways so it points the direction directly, but that is usually fine as GeoCachers often are so abroad that no one has maps about the area.).

In Maemo Mapper i couldn't find such a function. I can say 'Goto Coordinates' and then it centers the map to there, but there isn't a sign and no line or arrow which direction i have to turn to. This is a problem (or something for the wishlist.)

So from GeoCachers view (and those people who want to navigate for other reasons) free Navigation-Software for Linux is an area where more work is needed.

For those that don't know, I'm running for local government as the Liberal Democrat candidate for King's Hedges City Councillor in Cambridge.
Part of this involves seeing what the other parties do. I had a leaflet come through the door for the potential Labour candidate, Gerri Bird. It contained the usual bumpf, and a suggestion at the end; "google for gerri bird cambridge".
This could present a problem for Gerri. You're not asking someone to go to a site, where the information you have is constant and of a known quality. In this case, Gerri not replying to a survey from the local cycling organisation is the top hit on Google. As these leaflets are already out in the wild, the instructions can't be changed.

Something to be careful of.

There are many reasons to hate Java, it's like shooting fish in a barrel. But in the last weeks I found some more, half of them aren't even fault of the standard API (the usual culprit), and I want to share my frustration with the rest of the world. It has no unsigned types Say you want to manage binary protocols, files, etc. You'd like to store and retrieve bytes and words in machine format, of course, but you'll have a hard time finding the right value because you can't have a goddamn unsigned byte! So if you want —for example— to read the length of a string which can be bigger than 127 as a single byte, you'll end doing some aberration like this:

byte strl = foo_retrieve_byte();
int real_strl = strl < 0 ? 256 + strl : strl;

You can't inherit constructors Maybe there's something in the OOP dogma that mandates this, but if I want to define a new exception that does nothing, but allows me to differentiate a custom class of errors, I don't want to explicitly write dummy constructors instead of writing an empty class —which is simpler and cleaner— and have the four standard exception constructors for free. So, you'll have to do this:

public class FooException extends BarException  
	public FooException()   super();  
	public FooException(String s)   super(s);  
	public FooException(Throwable t)   super(t);  
	public FooException(String s, Throwable t)   super(s, t);  
 

Instead of this:

public class FooException extends BarException    

You can't declare destructors Say you've coded a nifty jdbc wrapper that automates most of the boring stuff, like automatically freeing the connection to the connection pool when there was an exception thrown, logs errors and maybe queries, handles auto-commit settings, etc. In the simple case, you'd create an instance, do some work, and then close the connection; if there was an SQL exception, you little class will take care of it and re-throw. BUT, if in the middle of your work in the calling code, you have an unrelated exception, you need to catch it or you'll leak connections, because the wrapper class doesn't have a way of handling this, even if the object gets garbage collected! In the end, I had to write tons of times the same stupid code:

try  
	j = JdbcWrapper.new(foo);
	j.doSelect(bar);
	unrelatedObject.unrelatedMethod();
	j.doUpdate(baz);
  finally  
	j.close();
 

You don't have a sane way of controlling the terminal Most of the time, when dealing with web applications, you won't need this. But when you're doing some serious stuff, you might need to write a CLI application (oh, noes!); and then do some stupid thing like asking the console to stop echoing characters so you can ask for a password. You'd think that the smart guys that designed Java would have devised an portable library to handle this trivial task, but no! Guess what I found when looking at a way of doing this? Some idiot at SUN recommending (and many dummies following) a background thread that spits backspaces faster than the user can write! Of course, SUN will tell you that using Strings is insecure for storing passwords, because they cannot be wiped out like byte arrays. But they fail to mention something as basic as not showing the fucking password in the first place, or something as important as wiping the object after using it: you can't lock memory from Java, so you risk that it could end in some slack in the swap file. No, you can't leave stdin/stdout/stderr fscking alone! When dealing with the previous problem, you say fuck portability and just call stty -echo to do the job. Well, you'll find a little surprise! Even if you don't ask for the process' reader/writer streams, the Runtime class will pipe(2) and dup(2) your child process' standard streams. With this excellent approach you cannot have a child process output stuff to the user, nor even errors; you cannot allow the child process access the tty (stty obviously can't do shit with a piped stdin). And there's no fucking way to tell it to stop crippling your standard streams! The only solution I could find was a very ugly shell hack:

Process p = Runtime.getRuntime().exec(
	new String[] "sh", "-c", "stty echo > /dev/tty < /dev/tty 2>&1" 
);

No, you can't handle signals After doing the previous hack, you find that if you interrupt your process while waiting for user input, your console will remain in noecho state. So the obvious thing is to catch SIGINT and friends and call stty again to restore the console. HA! You will find that there's no standard way of doing that, and if you really need it, you have to resort to undocumented com.sun.* classes which aren't even guaranteed to be present in every JVM. My solution was to set up a shutdown hook, which solved this problem, but would not solve other very common problems that are solved usually with signal handlers. Tags: Planet Lugfi, Planet Debian

Yesterday, I read an article on CNN called From $70K to food bank.

It describes a woman who was laid off in February from a job paying $70,000 a year. "Weeks later", with bills "piling up and in need of food for her family", she went to a food bank.

The article proceeds to talk about the subprime lending situation at great length, which is largely irrelevant to this person's situation.

Then we learn she applied for food stamps, but was denied. There's a quote from this person about how frustrating that was, and general "tugging at the heartstrings" trying to make us feel sorry for this woman with two children whose mother moved in to help make the house payment. It seems to me that this is a correct decision; someone that can pay a $2500 mortgage each month ought to move into an apartment before trying to leech food or money from social service agencies.

And that's where this story gets interesting.

She has an interest-only mortgage, and is managing to pay the $2500 bill each month.

If you're not familiar with an interest-only mortgage, here's how it works. The bank loans you money to buy your house -- say, $200,000. This is a loan, and you have to pay interest on it each month, just like a regular mortgage. But with an interest-only mortgage, you never pay off the loan. You could be making monthly payments for 30 years and still owe $200,000. In general, the only ways to "pay off" this kind of loan is to sell your house, or get a conventional mortgage that pays off the interest-only loan.

Interest-only mortgages were largely banned after the Great Depression. Prior to that time, they were how mortgages normally worked. But there are several problems with them. One is that you have to pay on them forever, even after you retire. Another is that you can't move unless you can sell your house for at least as much as the bank financed, even if you've lived there for 20 years. In times of declining housing prices and unemployment, that really stinks. People often default on the loans, and from a bank's perspective, that really stinks, too.

Interest-only mortgages are usually used by banks financing construction (we had one for a few months when we renovated our farmhouse) or other short-term projects such as professional real-estate investors that buy old houses and fix them up to sell at a profit. Except for these things, in general, they should never be used for a primary house. It's not in the interest of the bank or the homeowner.

But since you never pay off the principal, the monthly payments can be lower. It seems likely that this woman took a knowing gamble, buying a home more expensive than she could afford, and somehow found a bank willing to finance this. Problem is, both she and the bank took a knowing risk. If she ever ran into financial difficulties, she'd have to sell the house quick. But now the house is probably worth less than the value of the mortgage, so selling it won't remove the loan -- BUT it would let her pay off a large part of the principal, reducing her monthly payments and giving her some wiggle-room to buy food and pay off the rest of it.

It seems to me that she is unwilling to own up to the calculated risk she took, and wants society to help bail her out. Don't get me wrong; I think we need to help people that run into hard times. We need to help make sure they still have the tools they need to find a job and a place to stay. But bailing out people that take huge financial risks shouldn't be the job of society. Let's help them land softly, but not be enablers keeping them in a home they never could -- and still can't -- afford. Fortunately, I don't think anyone in government (or running for president) is suggesting we should.

Not only that, but her bank shouldn't have ever made that loan. Banks should be held accountable to not sell unwise products to people that rely on them for their primary residences.

Here's another interesting point: in just a few weeks, she had burned through her entire savings.

This, unfortunately, is a quite typical situation for many Americans. My financial planner, and I think most experts, suggest that everyone ought to have 6 months of income in liquid non-retirement assets (savings accounts, investments, etc.) in case something like a layoff happens. Very few Americans have this.

And when it comes down to it, isn't that part of the problem? The economy thrives on consumer spending. Or, put more starkly, overconsumption. If people start saving like they ought to, and stop feeling like they're outcasts just for not keeping up with the Joneses and buying every last gadget or the biggest house, we'd all be in better shape -- but the economy wouldn't have grown as much.

The growth it would have seen, had we all been more responsible, would have been a lot more durable and recession-proof, I think.

We are all going to DebConf8, wanna start a meme?
Last week I've bought the plane tickets for DebConf8, ... I'll be there this year as well! Since I've liked this year FOSDEM "meme" of sticking images saying "I'm going to FOSDEM" onto blog posts, here is my small contribution: an "I'm going to DebConf8" sticker for your posts. It comes in .png format, but given that my gimp skills are quite limited here is the original .xcf in case someone wants to improve upon my work. Just let me know and I'll update the online version. Here is the HTML snippet for your pages:

<a href="http://debconf8.debconf.org">
<img src="http://media.debconf.org/dc8/images/debconf8-going-to.png"
     alt="I'm going to DebConf8, edition 2008 of the annual Debian developers meeting" />
</a>

See you in MDQ. Update: thanks to Ganneff the sticker is now hosted on media.debconf.org, the links and the snippet have been updated accordingly Update: thanks to Tincho the sticker has now better (i.e. wider) margins

I've never been much of a podcast listener, largely because I haven't gotten my act together and downloaded any on a regular basis, and partly because the iPod is tied to Sarah's iTunes on her laptop, so it's not convenient to go fiddling with the iPod. If I ever manage to get back into the swing of things and get to the gym regularly, I think I'd prefer to listen to a podcast rather than straight music, so I can hopefully expand my brain while I'm slogging my guts out on the treadmill. Kynan and Shona have both talked about LugRadio events from when they lived in the UK, and I've been vaguely aware of it as a podcast (it's probably the first podcast I'd name if you asked me to name one). I vaguely knew that Kynan had been trying to organise something LugRadio related in the Valley for a while now. Well, it turns out he's succeeded, and it's good to see he's gotten some credit for it as well. Onya Kynan! So I got all excited when I went and looked at the schedule and discovered it was going to be something vaguely like a mini-linux.conf.au, I scurried off and bought a couple of tickets. Then Sarah pointed out that it's the weekend that we're going to San Diego for a four-day weekend. Oh well, at least the tickets were pretty cheap. So, if, unlike me, you'll actually be in the Bay Area on April 12th and 13th, check it out, it sounds like it'll be fun.

Hey - here's an update:

* I'm off the steroids. Last one was last Friday, spent the weekend enjoying the withdrawal symptoms, and already enjoying the benefits, like my skin is clearing up even more, I'm starting to get my voice back, and I'm less inclined to be angry at the vacuum cleaner when it runs into me. Angie tells me I'm a lot more fun to have around. Which is encouraging when one is totally dependent on another person for food. =)

* I seem to have gotten sick. It took me a bit to figure this one out, but the withdrawal symptoms seemed to be going on longer than expected. Then Angie started showing signs of them, after Leif was fussy for a day. Blech. =( Which explains why I can be cold under covers when the thermostat claims that it's 74 F (No idea in civilised measurements, sorry). Hopefully this passes quickly. Time for lots of breathing and napping. Like I could be sleeping any more during the day.

* My energy levels are getting better. I saw Andrew Pollock at noon today when he returned a CD to me, and he commented that from my walking you can barely tell I had surgery 3 weeks ago. Except for how slowly I'm going. And the full body turn in order to look to see if cars are coming when I cross the road. And the huge production to step up onto the sidewalk. A 5 minute walk no long requires me to sleep for 2 hours. Can't say the same for a 10 minute walk yet, though.

* Staples are out! I have two more days of antibiotics because the incision is still red and giving off more heat than they'd like so I'm back in next Tuesday for another checkup. Last week, the surgeon wasn't surprised by the healing rate given that the steroids are an immunosuppressant, though. So hopefully next Tuesday I get a clean bill of health and then just have to wait 2 weeks before getting some movement restrictions lifted and starting PT. And tomorrow I'll have a shower without fetish^WPlastic Wrap all over the incision. I can't shower unassisted yet, though, since getting most of my body would count as "reaching"

* Short-term disability finally approved my claim. For 6 weeks anyway. Then they want me to return to work or get better justification from my surgeon. I'm sure he'll be all professional, but I'd love it if the letter read "My client takes 10 minutes to get out of bed. He takes vicodin every 4 hours, and my nurse just recommended Oxycodone so that he can sleep more than 2.5 hours at a stretch. What do you think?"

* We have the biopsy results. And like every other biopsy result, we have... Inconclusive! Whee! At least they're no longer using the word "Sarcoma", but instead have settled on Osteoblastoma. But there's a catch - there are two types of Osteoblastoma, Aggressive and not. (I'm sure there's technical terms, but I'm tired and didn't catch them). The inconclusive bit is whether it's aggressive or not. During surgery, however, they treated it as aggressive because they didn't have the information and did what they'd do to minimize the chance of it coming back by taking out lots of extra tissue. I still get to see an Oncologist, in case there's something interesting through all of this still to learn.

* Otherwise, schoolwork extensions are all approved, our new bank likes us and is doing good things. Coworkers are popping in and saying hi, so I'm not feeling totally isolated. Heinlein is less good the fewer drugs I'm on. Or maybe it's because I'm reading "Friday".

Things are still getting better every day, even through all the sickness and such. I'm trying to catch up with people on Jabber. I still can't lift the laptop, so IRCs out until I figure out where I put the charger to the N810. It's somewhere out of reach, so as far away as the moon as far as I'm concerned.

I also want to take a moment to say thanks to Sandy and Jamu for their visits here - We're trying to arrange for people to visit us on the weekends and help us return the place to a clean state, with Kit starting the visits this coming weekend. Angie's got her hands full with Leif, and I get the joy of sitting in the corner wishing I could be useful. The result is that the house slowly falls apart over the course of a week, and hopefully weekend visitors will help us keep some measure of sanity here.

Peace and love, all.

Tks,
Jeff Bailey

My mobile music player is often missing the files I want to hear right now if I'm under way because my music collection is too big to fit on it.
Long time ago I used gnump3d which seems to be unmaintained in Debian for quite some time and then I often listened to some live streams, network connections are available nearly everywhere.
But I always wanted my own live stream with music I want to hear. There are several solutions out there for this task but they all require the creation of a playlist before the streaming starts.

Fortunately mpd provides the possibility to define different output targets and also one for streaming to a shoutcast or compatible server like icecast.

So after apt-get install mpd icecast2 (on a Debian box) you have to edit /etc/mpd.conf
There is not much to do, be sure to set music_directory to the place your music is located and the configure the output part.
Add the following to your mpd.conf and adapt some values:

The type defines that this output will be streamed to a shoutcast target. The name will be displayed by the client you use to play your stream. 8000 is the port icecast2 will listen on host "localhost" (in this example the icecast2 server is on the same host). format specifies the audio format of the stream, the first number is the sample rate in Hz, the second number is the number of bits per sample and the last number defines the number of channels (2 is stereo here). Those values should work for most of you. mount specifies the path under which the stream is available later from the server root, in this example http://localhost:8000/stream.ogg.
quality defines the ogg encoding "quality". You can also specify the bitrate instead of it. The user and password values are used to authenticate mpd at the source input for icecast2.

There seems to be a bug in the 0.13 release (which is also in Debian) of mpd that prevents this from working. I don't know the details about this bug but adding
fixes it.

Make sure to set START_MPD=true in /etc/default/mpd to enable mpd.
That's all that needs to be done for mpd.

The next step is to edit /etc/icecast2/icecast.xml.
The default configuration nearly ready to use. Configure the authentication part:

The source password is the one we specified in the mpd configuration. This is needed to authenticate mpd with icecast. source is the default user name icecast uses here. Additionally we define an admin-user that can be used to add users to icecast later because we want to protect the stream by a username and a password.
Then set .
This hostname is used to generate URLs in icecast that a user receives.

Because we want a very simple authentication for the stream we need to add some options for the mount (/stream.ogg):

I think the xml tags are pretty much self-explanatory. Keep in mind to set the filename to a location the icecast daemon has access to, that's why I used /etc/icecast2. Then you can add users with htpasswd or using the web interface on port 8000 and add a user there.

The last thing to do is to adjust the <alias source="/" dest="/status.xsl"/> setting. Change status.xsl to auth.xsl people need to authenticate if they connect to the web interface before seeing the stream information.

Now you can login via ssh on your home server and use your favorite mpd client to configure playlists on the fly, I use ncmpc for this. Of course the authentication is not secure, people who sniff your traffic can see your login data.
One thing to keep in mind is to restart mpd after restarting icecast otherwise mpd will hang and not continue to stream, this seems to be a bug.

After routing through your NAT, you should be able to play your stream via http://you.somehost.org:8000/stream.ogg.

Unhappy Birthday -- a website that tries to educate the public and encourage folks to snitch on their friends for singing the (copyrighted!) Happy Birthday song in public places -- is perhaps the most widely read thing I've ever written. It's been seen by millions and I continue to get hate mail several times a week. Last Sunday, the nationally broadcast CBC show WireTap aired an pseudonymous in-character interview with me about the site where I pretended to be a copyright high-protectionist. I think it turned out pretty well. You can listen to it on the unofficial WireTap podcast. My interview starts at a bit more than 10 minutes into the show.

I'm the happy owner of a Sony DRU-800A DVD burner, and I wanted to upgrade the firmware, as I had some little burning problems I hoped the upgrade would fix. Of course, Sony's website provides only Win32 flashers. They run under wine, but they don't actually do anything. Apparently, the way these win32 ioctls are implemented rely on the old hdc=scsi deprecated kernel interface. The trick is that we need a 2.4 kernel to get it working properly. So here are the steps I took:

1. Get a bootable sarge with a 2.4 kernel, and boot it with hdc=scsi(hdc is the device name of your burner). You might need to compile the kernel yourself for it to work properly. In any case, you should see something like that in the output of dmesg

   scsi0 : SCSI host adapter emulation for IDE ATAPI devices
     Vendor: PLEXTOR   Model: DVD-ROM PX-130A   Rev: 1.02
     Type:   CD-ROM                             ANSI SCSI revision: 02
   Attached scsi CD-ROM sr0 at scsi0, channel 0, id 0, lun 0
   sr0: scsi3-mmc drive: 0x/50x cd/rw xa/form2 cdda tray
   

2. Make sure wine is installed, the sarge version worked fine for me (more recent versions compiled by hand did not).
3. Make sure there is an appropriate /etc/fstab entry for the SCSI CDROM device. I have something like:

   /dev/sr0        /media/dvd              auto    defaults        
   

4. Make sure there is an appropriate device symlink in /root/.wine/dosdevices. With the above fstab entry, the following would work:

   ln -s /media/dvd d:
   

5. Run the flasher as root (giving write permissions for all SCSI devices to a normal user does not work)
6. Reboot (to your normal system), and check you firmware version number with

   wodim -scanbus
   

This did work fine for the aforementioned DVD burner. It did not get my DVD reader to get flashed, though. But it's worth a try, and once the sarge boot is setup, you won't lose too much time. As a conclusion, rush to get a sarge boot before lenny goes out and sarge is removed from the debian mirrors !

In case anyone out there is using my dcmd script, I'll note that it's now included in devscripts (starting with version 2.10.20). The devscripts version doesn't behave differently when called as dscp or drsync, I have the following aliases to get the old behavior:

alias dscp='dcmd scp'
alias drsync='dcmd rsync -av'

As always, feedback welcome.

Random things you can't do without being a DD (and no, DM isn't the answer).

• Access porter box to try and reproduce build failures, test patches (I know about experimental, but building isn't sufficient in some cases, e.g. when runtime errors come into play).
• Introduce NEW packages on your own (Christian, you know I'm pointing to crappy packages to get them removed, so my karma shouldn't be that bad, at least regarding this particular point).
• Sponsor people you're working with, on a regular basis.
• More generally, sponsor people who have addressed each and every problem you could find in their prospective packages, and that aren't getting any more answer on debian-mentors@.
• Vote.
• Cancel by yourself a DELAYED/n NMU in case the maintainer reacts and has good reasons to postpone an upload, without having to bug the original uploader (who also has stuff to do and sometimes happens not to be available in due time).
• Access interesting data directly, like the cause of previous REJECTs for this or that package.

Being able to read debian-private@, having a nice^Wspammed @d.o address, or getting an lwn access could be added here, but that's only bonus stuff compared to the previous items (and I'm probably forgetting others). Oh, yeah, I know, patience is the key. I'm not sure about how many months we're supposed to wait for an answer from James. I'm not sure how many years we're supposed to wait for the various DAM problems to be solved. Lucas is very worried about bringing fresh blood into Debian. Maybe there's some already, but it's not allowed to flow in. Many thanks to all developers who are making it less frustrating by doing mass-sponsoring; and to everyone showing sympathy. Not listing you all, you know who you are.

This post is both an attempt at replying to a bug against telepathy-glib, but also an attempt at explaining what Requires.private do (and don't). I am using Evolution as my example here, not to pick on Evolution or its authors in any way, but because it's a convenient example. Currently, on Ubuntu Hardy, evolution links against 75 different libraries. Amongst those, we find libz.so.1, libXinerama.so.1 and many more. I'll go out on a limb here and claim that Evolution does not call any of the functions in libXinerama directly. Let that be the assumption from here on. An obvious question then is, why does evolution link against libXinerama.so.1 if it doesn't use it? To answer that question, we need to go back in time to before we had dynamic linking. If you wanted to build a binary like evolution you had to have 75 -l statements when you linked and you ended up with the whole code for Xinerama embedded in your email and calendar client. For various reasons, we stopped doing that and switched to dynamic linking where the evolution binary just contains a reference to libXinerama. At some point we also grew the ability for libraries to contain those references to other libraries, so you don't have to hunt down all the dependencies of libfoo when you are linking with it. We also got tools such as libtool which try to abstract away a lot of the problems of building on older platforms which don't support inter-library dependencies. Now, since evolution still doesn't use anything directly in libXinerama.so.1 but just uses a library which in turn links against libXinerama.so.1, it shouldn't be linking against it. Then why is it linked with it? Again, we need to look back at history, and for this part I am at least partially responsible. pkg-config was originally written as a replacement for gnome-config and various other -config utilities. Lots of libraries and applications now ship .pc files and we have a standardised interface for querying those files. One of the problems the original authors of pkg-config faced was the problem of dependencies. They added dependencies so the authors of gst-python-0.10 could say "We need pygtk-2.0 too" and so the compilation flags needed for gst-python-0.10 would also include those for pygtk-2.0. Note that I'm using "compilation flags" loosely here, I am not just talking about CFLAGS. This did not fix the problem of inflated dependencies. Not at all. I talked with some of the Debian Release Managers back in 2004/2005 and we worked out a solution which should help us have correct, uninflated dependencies since the then-current way of handling dependencies caused big problems for migrations of packages between unstable and testing. The plan was to introduce a new field, Requires.private which would not show up unless you passed --static to the pkg-config invocation (since you need all libraries if you are linking statically). This definition of Requires.private was mostly useless since GNOME and GTK+ have a habit of including each other's headers. To make a long story short, I changed the semantics so the Cflags field from private dependencies were included even when not linking statically. A problem which pkg-config does nothing to guard against in this case is if you have libfoo.so.2 linking against libbar.so.1 and libfoo.so.2 exports some of libbar's types in its ABI (and not just as pointers, but actual structs and such). If libbar's soname is then bumped to libbar.so.2 and libfoo is rebuilt, libfoo's ABI has changed without a soname bump. This is bad and will cause problems. If your application is linked against both libfoo.so.2 and libbar.so.1, you'll still get problems since libfoo.so.2 then suddenly pulls in symbols from libbar.so.2. If you used symbol versioning, you would at least not get symbol conflicts and your application would continue to work, but you would have a spurious dependency and the package containing libbar.so.1 would be kept around until your application was recompiled. With this background, you might ask the question why we still have Requires since it is seemingly useless. For C, it is useless in all but the most special cases, just use Requires.private instead (and its sibling Libs.private). Other languages have different semantics. Some people use .pc files for other purposes such as gnome-screensaver having variables defining where themes and screensavers go. Hopefully this blog post has explained a bit about why we have Requires.private and what the difference between this and their regular counterpart is. If there's anything unclear, please do not hesitate to contact me.

For years, several important (or not so important) people have forecast the end of email. While most of what they were saying couldn t be disagreed with (important people always speak in vague, vacant terms), it wasn t until about a year ago that I noticed any effects. But over the past twelve months, I found myself frequently having to remind people of tasks, mostly outstanding emails, across the whole spectrum, and including companies who could make money from me if only they d bother replying. Statistics somewhere say that 90% or more of all mail is spam. I have very few problems with spam (and would like to describe my mail filter in a future post, but that ll take time), but I have no problem imagining how most email users out there, who are stuck with technology from the nineties (thanks mostly to Microsoft), are really drowning and thus fail at the basics of correspondence. So what s next? How should we continue to communicate, now that email has been fully embraced by the business world while it has grown to be more of a burden than a gain for the majority? Or is our society simply accumulating more and more slackers? NP: Barclay James Harvest: Time Honoured Ghosts