Bernhard comes up with a few arguments in support of multiple filesystems which, in my arrogant opinion, make no sense. The first argument (about hardlinking a file to your homedirectory until something bad is discovered in one of the binaries) has been sufficiently debunked by Joey Hess. The second and third arguments are the same, really. Repeating your argument won't buy you any beer, sorry. Finally, all your arguments talk about server. I was talking about laptop. I don't know about you, but me, I'm not in the habit of loaning out my laptop to someone I don't trust. I'm not even in the habit of loaning out my laptop to someone I do trust, come to think of it. I do run some servers on my laptop, but I also have a firewall on my laptop that refuses incoming connections. This is a laptop. Not a machine in a data center. As such, the only person with access to my machine is me. Now I don't say I trust each and every bit of software that I run on my laptop, but I do trust myself. I won't start scanning my laptop's hard disk for rogue SetUID hardlinks in another user's home directory, because there isn't another user, stupid! Paranoid security is nice and dandy and totally useless. Security is all about trade-offs. Even Bruce says so: if the cost of a security measure (having to deal with with 73 filesystems) does not outweigh its benefit (protection against cosmic rays changing not only my firewall configuration, but also writing a suid CGI binary and installing that in /usr/lib/cgi-bin), then it's just not worth it. Now of course you might argue that 'having to deal with 73 filesystems' is no cost at all, in which case it would be worth it. But to me, it certainly is a cost, and one I'm not willing to take even if it did protect me against a real-life problem. And if someone were to break into my system, I'll just reformat it and recover from back-ups. I won't even have to revoke my GPG key, this time, since it's no longer on the disk.

Various people have been taken in by a pretend Debian installer/bootloader for the android G1 phone. What is it, really? Well, it's a 200+ mb zip file, containing a filesystem image of a Debian installation. About 100 mb of that is cached .debs in /var. A few minor changes have been made, and /root/.bash_history helpfully shows what was done. None of it seems to be malicious, but I did not check every file. Also included is a hilarious "boot loader" script that contains literally the following code:

echo "Custom Linux Pseudo Bootstrapper V1.0 - by Mark Walker"
echo "WEB: http://www.androidfanatic.com/"
echo "EML: admin@androidfanatic.com"
echo " "
sleep 1
echo "Starting init process"
sleep 1
echo "INIT: Debian booting....."
sleep 1
echo "Running Linux Kernel"
sysctl -w net.ipv4.ip_forward=1
sleep 1
echo "AutoMounter started"
sleep 1
echo "Type EXIT to end session"
echo "Make sure you do a proper EXIT for a clean kill of Debian!"
echo " "
chroot $mnt /bin/bash

That's worth the price of admission right there! I especially like how "init" is "started" before the "kernel". You can't make stuff like this up. So, in summary, this is a way to get a prebuilt Debian chroot at the expends of wasting bandwidth and space on your phone with unncessary bits. Running debootstrap on the phone is the correct way to accomplish the same thing. It's sad that there's such interest for Debian on the G1, and general lack of clue, that people will actually probably use this. And, like it or not, this "is" the Debian install for the G1 -- no further efforts are likely to get this kind of press. Sorta like that badly pressed CD back in the day stole the thunder of Debian 1.0. More generally, it's a pity that when people want to get Debian on a new device, be it the G1 phone or the EEE or OpenMoko or what have you; only about half of them seem to do it right, by modifying d-i and sending the modifications back to the installer team. For this rest, this kind of hand-built, unverifyable chroot gimmeckery is the de facto standard. This also shows you the kind of fact checking that slashdot and random blogs tend to do -- ie, none. (My own blog, of course, is rigorously fact-checked and edited by armies of lolcats.) (Sorry, this seems to be my week for posting corrections to other people's posts to Planet Debian. I don't mean to pick on you guys.)

Continuing with my mission to control the power to some dumb USB-powered lights... Dann Frazier confirmed my theory that a USB hub would indeed do the job. I'd already found the hub-ctrl.c program he mentioned, but couldn't get it to work with my built-in USB ports of my laptop. It seems it all depends on whether the hub will support per-port power switching or not. (lsusb -v will tell you). So off to the mighty institution that is Fry's Electronics I went. The first two attempts failed, as did a borrowed hub. It seems most (at least the cheap one) use a Genesys Logic chipset, which does not support per-port power control. Fortunately I chose products that weren't in blister packs, so I was able to return them to Fry's in as-new condition and try again. Now that I knew USB hubs would do the trick, I did some more targeted searching, and found this thread where someone had been messing around with hubs to do what sounded like what I wanted. (Incidentally, this email in the thread also provided a nice looking Python program. I'm going to look at refitting it to use the "real" Python USB module.) I emailed the poster to ask him what brand of hub he was using. The answer was the Linksys 4-port hub So I managed to track down one of them last night. Yes, it works, but the downside is the hub itself requires external power, which is a bit unfortunate. Not only do I need to use a hub to make these lights software controllable, I have to plug the hub into a power outlet. Bleh.

The phrase on this title is often attributed to Pancho Villa (1878-1923), Mexican Revolution leader. He had a fame of cruelty, killing suspects before even questioning them.
Today, it started as a very nice day. I had even time in the morning to find, fix, upload and send upstream a trivial bug in libgruff-ruby... At 11:00, I left the Institute as my father came to the city to do some paperwork... We sat having a cup of coffee in a restaurant near the office we had went to at around 12:00, and my phone rang.
And it was from work. That's never a good sign. My boss told me he was facing a massive virus infection, and decided to disconnect the firewall. I corrected him - that will do no good once the virus is in our system, if you want to disconnect anything, disconnect all of our switches.
Came back, and found him and my coworker stunned and not knowing what to do. He says, the antivirus alarm went off almost simultaneously on the two computers he had on his desk, and in few minutes over 15 computers all over the Institute were ill. The symptoms? Programs not showing up in the taskbar, copy/paste functionality b0rken, many programs misbehaved or just didn't open... They were grimly facing a complete recovery operation they have grown used to: The whole OS has become corrupted or destroyed, we will have to open the computer, extract the HD, install it elsewhere, back it up, reinstall OS and applications, restore the backup. Yes, I know too many extra steps are included here, but I have come to accept their ways of dealing with Windows. Nobody says dealing with Windows is fun. I like my work to be fun, so I stay clear of theirs.
I insisted on turning back one one of the switches, the one for the servers and my machine (and some more in the same physical area). OK'd. But they didn't want to switch on any other switch, so a traffic capture (tcpdump / wireshark) led nowhere - but at least it gave my my Google back.
They have configured the antivirus software we deploy to all of the Windows machines in such a way that it deletes upon sight any malware - And when they manually scan, they blindly hit Delete whenever anything is found as well. Of course, no infected binary was left alive for me to inspect, and the machines were dead. But I was able to glimpse at the name of the deleted file: rpcss.dll.
After googling a bit - Bliss! Joy! I found the answer. So here is the set of interactions, and how they led to this killing spree. Please remember I am a Windows newbie and speak just out of guesswork.

1. This is a fast-spreading virus. My friend Rub n at DGSCA suggest it might be related to this report submitted today; at Barrapunto there is a thread about another virus that appeared four days ago, infected 1.1 million Windows machines on its first day, and so far is around the ninth million. Update: Equivalent thread at Slashdot, for the Spanish-impaired.
2. The virus infects at least two copies of a system binary: %system32%\rpcss.dll and \Windows\ServicePackFiles\i386\rpcss.dll. Windows uses the second one to restore the first one in case it is damaged, if I understood correctly.
3. The antivirus does not detect the infection when the library files are written, but when they are linked, so it only spots it the next time %system32%\rpcss.dll is brought into memory.
4. This is a very common library - It takes care of, well, RPC. So, quite probably, this file will be linked again on the next program launch - or accessed when a running program requires anything not currently in RAM? Dunno. The thing is, the library gets linked.
5. The antivirus will happily tell you it has killed a threat! Your nice RPC library is now defunct. M talo, luego virig as!
6. So, of course, notifying the taskbar of a new window appearing, or clipboard actions, or whatnot will refuse to work.
7. Machine restart, full system scan requested. The antivirus finds de second copy of this library in the master directory (\Windows\ServicePackFiles\i386). The virus used this location so that Windows won't restore a clean version over it. But yes, it will fall again under the claws of the antivirus... I guess. Anyway, the antivirus offers to delete this file as well, and does so.
8. User is desperate. My coworkers are desperate. I am... mildly annoyed?

Once I found this line of thought... I went to a working machine, inserted my flash memory, and copied %system32%\rpcss.dll to it. Went back to a sick machine, and ran cmd. Then, it was just matter of copy f:\rpcss.dll c:\windows\system32, a simple reboot (it never hurts to reboot in Windows!), and problem solved!
Oh, as a side rant: I find it extremely annoying and sad that many people I know, sometimes with more experience as a computer operator/supporter than what I have of experience as a living human being, are so scared of using a command-line interface. They were dismayed at seeing no drag-and-drop and no copy/paste functionality were available! copy is not an option.
Anyway... Today was an experience on how a simple, mostly-harmless and quite-fertile virus is able to be terribly magnified by the presence of a trigger-happy antivirus.
Why won't they give themselves a chance to try something else? Say, GNU/Linux? :-/

From: Christoph Berg <myon@debian.org>
To: Debian Bugs Submit <submit@bugs.debian.org>
Subject: Bug#512072: RFH: mutt -- text-based mailreader supporting MIME, GPG, PGP and threading
Package: wnpp

Hi, the Debian Mutt package needs more maintainers. There are almost 200 open bugs. Some of these are already forwarded upstream and might just need some triaging/poking. Some need forwarding. Some might be fixed with a trivial patch. Others are Debian specific, mostly for the extra patches we include. There's duplicates and sub-wishlist items. We are using bts-link to link to dev.mutt.org's trac, but that also needs more tweaking. There's a new upstream version 1.5.19 pending, we need people to check which bugs still apply. The (in?)famous mutt-patched package needs love to get the sidebar patch updated to the new version, and to get some of mutt-ng's extra gimmicks and add-ons integrated. I've moved packaging to git since that seems to be the least scary choice nowadays: http://git.debian.org/?p=pkg-mutt/mutt.git The repository has been updated to 1.5.19. The mutt-patched build is disabled for now, as the patch doesn't apply. Testers welcome :) If you are interested in helping out, please get in contact with me. To get started, subscribe to mutt's PTS feed. There's no extra maintainer mailinglist, mailing mutt@packages.debian.org will work for PTS subscribers. If you prefer IRC, join #mutt on irc.freenode.net. Thanks,
Christoph

After another week, new Gammu testing version is out. The biggest change is integration of python-gammu into Gammu. This makes easier to test everything together and new tests revealed lot of bugs and memory leaks which were immediately fixed. Besides these changes, Windows Service support has been fixed and added possibility to run more SMSD instances.

• Fixed setting remote number for SMS in some cases.
• Fixed compilation under cygwin.
• Externalize eventlog support to ease Cygwin compilation.
• Integrate python-gammu into Gammu, they are anyway bound quite tightly together.
• Python C module is now gammu._gammu and not gammu.Core.
• Introduce testing for python module.
• Fixed decoding of formatted EMS messages.
• Fixed reading of RTTL ringtones.
• Fixed crash with too many animation frames.
• Fixed possible crash in LMB writer.
• Fixed several memory leaks.
• Better support for Samsung phones (bug #790).
• Fixed Windows Service Startup (bug #451).
• New possibility to run more instances of Windows Service (bug #451).

You can download from usual place: http://cihar.com/gammu/, Debian users will find packages in experimental soon.

I am happy to announce general availability of darcs 2.2.0. Getting the release For this release, we have decided to provide two flavours, depending on the build system used:

1. The source tarball, http://www.darcs.net/darcs-2.2.0.tar.gz, which can be built using the traditional autoconf-based system. This is the fully supported version. After downloading and unpacking, you can issue:

   $ ./configure
   $ make
   

   and possibly

   # make install
   

   More detailed instructions inside the tarball (file README). Please note that we had at least one report of build failure, with quickcheck-related message. The currently best workaround, if this happens to you, is to use the cabal version of the package instead, see below.
2. Cabalised source. You can either download a tarball from http://hackage.haskell.org/packages/archive/darcs/2.2.0/darcs-2.2.0.tar.gz and build manually (see the build instructions in README inside the tarball), or, alternatively, you can use cabal-install to obtain a copy:

   $ cabal update
   $ cabal install darcs
   

   This will give you a darcs binary in ~/.cabal/bin you should probably add that to your PATH.

In addition to source tarballs, we expect binary packages for various UNIX platforms will be available in due time. For Windows users, Salvatore Insalaco has prepared a binary build, available from http://homepage.mac.com/kirby81_it/darcs/darcs-2.2.0-win1.zip. You just need to unpack the directory somewhere and add it to your path (if you like). Moreover, an experimental TortoiseDarcs release for darcs 2 has been made available by Kari Hoijarvi and is looking for home. It can be found at http://datafed.net/darcs (unfortunately, at the time of this writing, the site seemed unreachable If you can help with hosting, please mail Kari.) What s New The summary of changes since version 2.1.2 (released last November) follows:

• In interactive record, it is now possible to get a list of currently selected hunks (command l). (Christian Kellermann)
• It is now possible to specify --in-reply-to when using darcs send, to generate correct references in the mail header. (Pavel Shramov)
• New repositories with --no-pristine-tree can no longer be created. This only has effect on legacy darcs-1 repositories.
• Improvements in Windows support. (Salvatore Insalaco)
• Performance improvements in darcs repair and robustness improvements in darcs check. (Petr Ro kai)
• Extensive manual and online help improvements. (Trent W. Buck)
• Support for GHC 6.10.
• Overhaul of the make-based build system. (Trent W. Buck)
• Cabal is now supported as a build method for darcs. (Duncan Coutts, Petr Ro kai, Gwern Branwen)
• First stab at libdarcs when building through Cabal, all of darcs implementation is now exposed in modules. No API guarantees whatsoever. (Eric Kow)
• Additions to Haddock documentation of the existing darcs modules for improved development experience.
• Improvements in the testing infrastructure. (Christian Kellermann, Gwern Branwen)
• Low-level optimisations in filesystem code. (Ganesh Sittampalam)
• Numerous major and minor bug fixes, refactorings and cleanups by David Roundy, Eric Kow, Jason Dagit, Dmitry Kurochkin, Thorkil Naur, Salvatore Insalaco, Christian Kellerman, Florent Becker, Duncan Coutts, Reinier Lamers, Ganesh Sittampalam, Petr Ro kai.

And a summary of issues that have been fixed in darcs since version 2.1.2 (compiled by Thorkil Naur): 525 amend-record => darcs patches show duplicate additions
971 darcs check fails (case sensitivity on filenames)
1006 darcs check and repair do not look for adds
1043 pull => mergeAfterConflicting failed in geteff (2.0.2+)
1101 darcs send cc recipient not included in success message
1117 Whatsnew should warn on non-recorded files
1144 Add darcs send in-reply-to or header In-Reply-To: x@y.z
1165 get should print last gotten tag
1196 Asking for changes in /. of directory that doesn t exist gives changes in entire repo
1198 Reproducible mergeConflictingNons failed in geteff with ix
1199 Backup files darcs added after external merge
1223 sporadic init.sh test failure (2.1.1rc2+472)
1238 wish: darcs help setpref should list all prefs
1247 make TAGS is broken
1249 2.1.2 (+ 342 patches) local drive detection on Windows error
1272 amend-record not the same as unrecord + record
1273 renameFile: does not exist (No such file or directory)
1223 sporadic init.sh test failure (2.1.1rc2+472) I would like to thank all contributors for making this release possible. Future The next release will be 2.2.1, fixing low-risk issues found in 2.2.0, or those that have been excluded for 2.2.0 due to freeze. This release will appear in two or three weeks time, depending on circumstances. The next major release will be 2.3, due in June or July this year. The focus of this release will be new features and further work on performance. Moreover, we expect that it will use Cabal as its default build system and will make first steps towards sustainable libdarcs API.

As I move to having more and more machines on my internal LAN, I felt the time had finally come that I sit down, and rebuild my network to take advantage of things such as gigabyte networking, LDAP, single-user sign on, and so forth. I'm doing partially for fun, and partially because its an interesting experiment to see how Linux from an IS environment compares to a Windows 200x IS environment (one of my former jobs was a 2000/XP/2003/Vista sysadmin position).

So, here's my current network setup
blacksteel <- *wireless* ---------------------------------------------- cerberus <-> Internet
/
dawn <------ *wired*-----------------------------------------------------
/
360 <---- *wired* -----------------------------------------------------

Online machines:
cerberus - WRT51GS
backsteel - My laptop
dawn - Development machine
360 - Xbox 360, used to play media from blacksteel

Offline machines (aka, machines I have, but haven't fired up since moving:
helios (PowerMac G4)
apollo (old Dell P3)
junker (RS/6000 rescued from the dumpster, might be dead)
alexandria (NSLU2; gave up its plug for dawn)
coldfusion (Coldfire Board, might be dead; ethernet controller is faulty, but might be able to use a USB based one to breath some life into it; can't autoreboot due to built in bootloader not supporting it; and no JTAG to sanely change the default bootloader).
siren (old MacBook Pro, has a dead internal HDD, but runs fine from an external hard drive. Was my Debian test box until its HDD went to dawn)
exodius - second WRT54GS used to be part of a WDS bridge.
unnamed dev box (not here yet, but likely soon).

Of all these machines, only apollo has a wireless card which ATM is non-functional. In addition, the wired bits of my network are 100Mbps, with a g based wireless hotspot (WPA secured). Futhermore, blacksteel, helios, and siren have gigabyte ethernet. apollo has 100MBps ethernet card. alexandria and dawn have 10MBps, which is painful, especially for NFS root.

I'll drop another 1Gbps NIC into apollo, replacing its wireless card, and give dawn, alexandria, and maybe coldfusion USB based NICs once I get around to resurrecting systems (alexandria and coldfusion don't have hard drives at the moment)

What I would like to do is use an Linux-based router and replace Cerberus. Helios has two gigabyte NICs, so it will take up this duty, as well as provide DHCPv4, and radvd (for IPv6) for the internal network. It's an old computer, and has an onboard model, and its position in my apartment will be close to a phone jack; maybe I'll set it up so I can dial in from outside the LAN in case something goes down (although my phones here are VoIP based so I dunno how useful that's going to be :-)).

Another box (I might task this to apollo, or helios) will run LDAP and NFS services, providing both a netboot based installation with preseed for fast re-installation, and NFS home folders for all machines except blacksteel (unless someone knows a great solution for having a laptop sync NFS and local home folders. helios will run mail, news, and any other untrusted net facing services, with everything else shielded behind it. All machines will run IPv4 and 6.

Anyway, this is the start of my plan in a nutshell, and I intend to continue discussion as I slowly build and implement this updated setup. Wish me luck :-).

From Today's Astronomy & Astrophysics there were two papers from the Geneva Observatory / Grenoble team on The HARPS search for southern extra-solar planets:

• XIII. A planetary system with 3 super-Earths (4.2, 6.9, and 9.2 M_e )
• XIV. Gl 176b, a super-Earth rather than a Neptune, and at a different period

These are probably part of the 45 super-Earths tentively announced by M. Mayor last June at the Nantes conference on super-Earths. He showed radial-velocity diagrams for 45 or so planets in an impressive display, but only gave details of three at the time, while the rest were being peer-reviewed, etc. Now they're drip-feeding out. Interestingly, this now makes 3 out of 7 super-Earths do far discovered as being around M dwarf stars, and another multiple planetary system. It looks more like the "metallicity" relation (larger and more frequent planets around more metallic stars) seems to be more true for gas giants than terrestrial planets. Super-Earths (potentially rocky planets, though heavier than Earth) look more abundant around low mass and less-metal stars. Now, down to work examining the characteristics of these planets. Rory Barnes and colleagues at LLPL, U. of Arizona have also been looking at these three planets around HD 40307, to determine if they are super-Earths or mini-Neptunes. They have an interesting technique of modelling the tidal circularisation of the planet backwards in time, based on its current measured or estimated eccentiricity. Tidal circularisation makes the orbit of close-in planets more circular (decreasing the eccentricity, e, to zero), dumping the energy into tidal heating of the planet (and the star). Doing this for Gl 437, for example, they showed that it would be hotter than Io, with a volcanic surface and couldn't be habitable. For HD 403007b, Hence they believe the planets are not terrestrial-like, but may be more Neptune-like. So, could these planets have oceans ? Tags astronony, super-earths, neptunes, exoplanets

Has anyone out there used a recent Nokia phone (E65 to be precise) as a modem with Network Manager 0.7? I can't seem to get the magic right, and get one of two failures:

NetworkManager: <info>  (ttyACM0): powering up... 
NetworkManager: <info>  Registered on Home network 
an 15 10:50:04 blackadder NetworkManager: <info>  Associated with network: +COPS: 0,2,"23415" 
  NetworkManager: <WARN>  dial_done(): Dialing timed out </WARN>

Or:

NetworkManager: <info>  Activation (ttyACM0) Stage 1 of 5 (Device Prepare) complete. 
NetworkManager: <info>  (ttyACM0): powering up... 
NetworkManager: <info>  Registered on Home network 
NetworkManager: <info>  Associated with network: +COPS: 0,2,"23415" 
NetworkManager: <info>  Connected, Woo! 
NetworkManager: <info>  Activation (ttyACM0) Stage 2 of 5 (Device Configure) scheduled..
. 
NetworkManager: <info>  Activation (ttyACM0) Stage 2 of 5 (Device Configure) starting...
 
NetworkManager: <info>  (ttyACM0): device state change: 4 -> 5 
NetworkManager: <info>  Starting pppd connection 
NetworkManager: <debug> [1232015456.962700] nm_ppp_manager_start(): Command line: /usr/s
bin/pppd nodetach lock nodefaultroute user web ttyACM0 noipdefault usepeerdns lcp-echo-failure 0 lcp-echo-interval 
0 ipparam /org/freedesktop/NetworkManager/PPP/4 plugin /usr/lib/pppd/2.4.4/nm-pppd-plugin.so 
NetworkManager: <debug> [1232015456.964964] nm_ppp_manager_start(): ppp started with pid
 29590 
NetworkManager: <info>  Activation (ttyACM0) Stage 2 of 5 (Device Configure) complete. 
pppd[29590]: Plugin /usr/lib/pppd/2.4.4/nm-pppd-plugin.so loaded.
pppd[29590]: pppd 2.4.4 started by root, uid 0
NetworkManager: <WARN>  pppd_timed_out(): Looks like pppd didn't initialize our dbus mod
ule

Anyone know what the problem could be?

How not to start your day, from the all-hardware-sucks department. For years, I ve been struggling to keep my machines quiet. I ve miserably failed for years, and pretty much gave up once I realised that the quiet parts I was looking for just did not exist. Last year, I finally found what I was looking for:

• big, heavy, quiet case from Chieftec (with room for 8 HDD and their own dedicated 90mm fans (up to 3) and room for 2 120mm case fans);
• ber-engineered fans from Noctua (finally some guys took a shot at engineering fans, happiness \o/);
• fanless (except for the emergency fan) PSU from Antec (Phantom 500).

I ve been very happy with this hardware for both my workstation and my filer. Well, until today. No need to mention that this hardware is not exactly cheap, but the price is right for the quality. So, wake up today, do random things, grab my TomTom, unplug it from the workstation it s sucking its power from, do things, plug it back in the USB port so it won t draw its battery. This is how it went:

• plug TomTom into USB port;
• notice the LED is blinking, and it should not;
• erupt a mental WTF? and simultaneously hear *clac* *pffzziiouuuu*;
• unplug TomTom;
• replug TomTom, notice the LED is blinking again;
• look at the machine, notice it s gone down;
• check the PSU and erupt a verbal WTF?! noticing the LED on the PSU is not lit.

Check machine temp, PSU temp, attempt to restart PSU, check UPS, check cables, replace power cable and bypass UPS. Admit defeat for this round and accept the PSU as dead. Pull out the machine, rip out the fscking damn PSU. Grab the tools, crack the PSU open. Notice bulging and leaking capacitors. Yes, this PSU is anything but cheap, yet it uses el-cheapo chinese capacitors. Antec, you suck, big time. For the past decade everybody in the industry has known that el-cheapo chinese capacitors manufactured after 1999 are total crap, using an electrolyte that isn t actually one because its formula was stolen by industrial spies who got totally PWNED and ended up stealing a bad formula. (If you need a reference, google for singing capacitors . Note that singing capacitors can also happen with good parts used in a crappy electronic design. Like that 100 Mbps D-Link switch over there, or that Sony-Ericsson mobile phone charger. Hmm. Not everybody can hear it, I do.) A healthy, young capacitor should not bulge nor leak. A capacitor that leaks, bulges or sings is a crappy capacitor and needs to be replaced with a quality part ASAP. I ve been routinely replacing such capacitors on my older motherboards (manufactured between 1999 and 2001) in the past years. I ve not had the problem in ANY of my el-cheapo PSU, and did not replace any capacitor in any of them to date. Fortunately, the machine did not suffer any further damage, nor did the TomTom. Everything is up and running again with a spare PSU. I m now going to replace the fscking capacitors on this PSU, replace the fuse, probably R&R a couple of high-voltage transistors too (they have a tendency to fry before the fuse blows out) and get it back up and running. Then I ll do the same with the other PSU in the filer, because that machine has 8 disks attached, so draws more power and hence is much more vulnerable. Fuck you Antec.

Asheesh Laroia explained how to use ssh as a SOCKS proxy if you re behind a firewall that allows you to ssh to some machine not restricted by it: ssh -D. (I don t know how common such firewall setups would be, but the one at my Uni does indeed allow ssh to the outside over authenticated wireless.) With -D, ssh will listen in a local port, and behave as a SOCKS proxy. Set it up like this:

  % ssh -N -f -D localhost:4444 external-machine.example.com

And then you can point your SOCKS-capable application at localhost:4444. Chances are, however, that the application you want to use doesn t support SOCKS (like, in my case, Git). You can use tsocks then, which LD_PRELOADS a library that will divert an app s TCP traffic through the SOCKS proxy. To use it:

  % cat >~/.tsocks.conf
  server = 127.0.0.1
  server_type = 5
  server_port = 4444
  % tsocks git pull

AIUI, this is better than setting -L forwarding because you don t need a forward for each host whose port you want to access. If you re interested in starting ssh in SOCKS mode from .ssh/config, the configuration item is DynamicForward.

You may remember that I m quite a satellite TV fan, having installed it in 2004 and compiled a FAQ. Over the holidays, I replaced my 4-year-old Digiquest receiver (terrible website) with a FortecStar FS-4400 PVR from Maplin. I d love to build a MythTV but how am I ever going to build such a small, quiet receiver for anything like that price? The FS-4400 s decoder gives a dribblingly clear picture and (one firmware upgrade later) the recorder works flawlessly. I can even watch other channels on the same transponder while recording. It has a couple of small niggles (the file manager that appears every damn power-on, the pidgin English on-screen displays and it s too easy to activate the motor), but it seems pretty good value on the whole. Now I ve a dilemma. I put a 4Gb USB stick into it, just to see how I got on with the recording. I like it, but 4Gb is enough for only 2 or 3 hours and I don t want to get into swapping sticks around like video casettes. I still don t know what s where on half my tapes. I ve seen a few places report things like Solid State Drives Getting Ready to Take Over (by Jaymi Heimbuch) with much larger capacity just around the corner, but the best rate I found today is around 1 Gb/pound for SSDs up to about 32Gb, compared to nearly 10 Gb/pound for USB-powered hard disks from around 300Gb. On the flip side, SSDs are silent and I don t know how noisy or power-hungry the HDDs are. How would you play this? By the way, if you care about UK TV, BERR.gov.uk is consulting about reducing Sky s control of itv - what s to consult about? Sky s doing all they can through the courts to drag their feet, but we need to put the independent back into independent television! Tell them by Friday 23 January 2009, please.

I got tagged in the bunnymeme. I even got nagged about it. I have to admit, drawing a bunny is kind of a relief from a busy week. Here are the rules:

1. Draw a Bunny (or more)
2. Post it to your blog with the rules
3. Name three other bloggers that should draw a bunny

Here is my bunny: And here are the three blogger friends I can think of who aren't too uptight and full of themselves to post a picture of a hand-drawn bunny:

• Hugh McGuire
• Michele Ann Jenkins
• Nicolas Ritoux

Update: there's a nice graph tracking the meme's progress. tags: bunnymeme bunny meme splitbrain

Montreal Startup invests in Control Yourself, Inc. On a more serious note, I'm glad that GigaOM has published a story about venture investment in my company, Control Yourself, Inc. ("Identi.ca Gets Funding to Make Open-source Twitter Variant"). I'm psyched to be working with Montreal Start Up to build CYI into a viable Open Source business. They've been really supportive of the Open Everything strategy, including building the OpenMicroBlogging standard. Thanks to everyone who's sent private and public congratulations. The fun part starts now! tags: identica controlyourself investment montrealstartup openmicroblogging

Open Source Jaiku The news came out on the same day that Google announced they're going to release the Jaiku code as Open Source software. I think this is great news. Hopefully, we can work together to build a federated network of microblogging sites running Open Source software connected with open standards. It's so important to have multiple implementations of any open standard, and I think Identica and Jaiku can be a good team for the microblogging world. tags: jaiku opensource openstandard google

Version 0.1.2 of r (pronounced littler) was just rolled up. This version adds two new command-line switches:

• -t selects per-session temporary directories in the same way as R does (with thanks to Paul Gilbert for the suggestion), and
• -q skips autoloading of default libraries at startup for another small yet noticeable gain in startup speed (with thanks to Simon Urbanek).

As usual, our code in our svn archive, on my r page, and in the local directory here. A fresh package is in Debian's incoming queue, and Jeff's littler page at Vanderbilt should reflect the new release soon too.

For a few weeks Laurent Vivier, Blue Swirl and myself have been working on getting QEMU PowerPC working correctly with recent distributions. QEMU used to rely on OpenHackWare for the OpenFirmware implementation on PowerPC. It is a very limited implementation (for example it as no Forth support), which is unable to boot most 2.6.x kernels with the OldWorld emulation. It is able to boot recent kernels with the PReP emulation, but things like the PCI bus emulation are not working correctly. Moreover the PReP kernels are gone with the removal of the arch/ppc tree. OpenBIOS was already used for the OpenFirmware implementation of Sparc 32 and Sparc 64 targets. It now supports PowerPC for the OldWorld emulation. As a result it is now possible to use Debian PowerPC under QEMU emulating an OldWorld machine. What works?

• Display (partly), keyboard, hard disk, network;
• Booting from CD-ROM or from disk using Quik;
• Installation of Debian Etch or Lenny (but due to a bug in debian-installer quik.conf has to be fixed manually);
• Standard Debian kernels;
• G3 CPU emulation: the testsuite results of the GNU libc 2.7 and of GCC 4.3 (Debian packages) are the same than on a real machine.
• virtio devices

What doesn t work / has to be done?

• A few devices part of the MacIO chipset are not emulated and/or are replaced by other devices: IDE, SCSI, Ethernet and sound;
• The red and green colors are reversed, in some modes only (in debian-installer for example);
• X only outputs some strange images;
• PCI devices using I/O ports don t work (like the RTL8029 card, or the RTL8139 card with the 8139too driver).

For those who want to test, an Etch image is available. You will need to compile QEMU by manually given that the version in Debian is too old and that openbios-ppc is still in the NEW queue.

I am stunned no more people have been bitten by this. Or at least, the Intarweb has not heard about it. Censorship perhaps? I haven't researched more into the causes, but anyway...
I was pushing a project I have had lingering for some time from Rails 2.0.x to 2.1.x (yes, 2.2 is already out there, but 2.1 is the version that will ship with Lenny) - The changes should not be too invasive, as it is a minor release, but there are some quite noticeable changes.
Anyway... What was the problem? Take this very simple migration:

The problem is that PostgreSQL refuses to create a hyperdimensional string field. I offer this here to you, line-wrapped by me for your convenience.

Beautiful. Now I can store strings not only as character vectors, but as planes, cubes, hypercubes, and any other hyperdimensional construct! Are we approaching quantum computers?
What is really striking is that... I found only one occurrence on tha net of this bug - one and a half years ago, in Ola Bini's blog. No stunned users looking for the culprit, no further reports... Strange.
Still, the bug was fixed in Rails 2.2 about half a year ago, although not in revisions of earlier versions. I will request the patch to be applied to earlier versions as well. Sigh.

I managed to go to FOSDEM in 2005. I enjoyed myself. I'd like to go again. No, really, I would.

In 2006 I drew the short straw while working for Black Cat; Simon and Dom went, I remained the person on the same landmass as the servers.

In 2007 I had a wedding to go to.

Last year I was too disorganised to sort out suitable transport from Northern Ireland.

I'd resigned myself to having to take off the Friday and Monday this year and fly. Except it's been moved to near the start of February, which thus conflicts with an annual dinner that gets to have higher priority. Bah.

Maybe I'll manage 2010, but I'll not be holding my breath.

My favourite IRC client is irssi. I like it so much that I even use it for all my instant messaging needs. The gateway of choice between irssi and mostly Jabber is Bitlbee. I also microblog on identi.ca, a free (free as in AGPL) microblogging service based on laconi.ca. In comparsion to the non-free and proprietary Twitter microblogging, identi.ca has all the features which Twitter turned off already again. For me the most important feature of Twitter was tweeting via XMPP (aka Jabber). Since Twitter turned off that feature, Twitter increasingly fast became unimportant for me. Identi.ca still has this feature and cultivates it further. So usually don t visit the identi.ca website that often anymore but get the microblogging stream of my friends via XMPP and Bitlbee directly into my irssi. Although this is very convenient, it has one big disadvantage: In comparison to an IRC channel, not only notices directed to me personally but every incoming notice beeps, because Bitlbee sends them either as /MSG or prepends my nick name. For normal IRC communication /MSG should beep, and you can t make exceptions for that so easily in irssi. I asked on #bitlbee (OFTC) and on #irssi (IRCNet). On #irssi funnily the first answer was I tried that yesterday, no success from Shrike. So I m not alone, although Shrike uses Jaiku and not identi.ca. Then I had the idea to get Bitlbee to not prepend my nick name for all those identi.ca notices which go into the &bitlbee channel but I didn t find a way to configure this in Bitlbee. But Shrike found a way to do this with already existing irssi plugins: The trigger.pl plugin (available e.g. in Debian s irssi-scripts package or on scripts.irssi.org) can add triggers which replace parts of the message. So the following three lines helped me to reduce the noise microblogging causes in my irssi:

/script load trigger
/trigger add -publics -masks 'identica!update@identi.ca' -channels '&bitlbee' -regexp "^XTaran: " -replace ''
/trigger save

And on the command line I just needed a symlink to automatically start the trigger plugin on irssi startup:

ln -vis /usr/share/irssi/scripts/trigger.pl ~/.irssi/scripts/autorun/

So now again only the important messages beep. :-)

After upgrading an Ubuntu mail server from Hardy to Intrepid, two users could no longer connect via SSL to send email though sendmail. One was using msmtp and the other was using Outlook Express. The msmtp issue was tracked down as a supposed deficiency in msmtp. However, this left Outlook, which is neigh-impossible to debug. From the Debian msmtp bug linked from the Ubuntu bug, it seemed that the root cause was the server sending too much data during the initial connection. Packet captures of an Outlook connection seemed to back this up: Outlook negotiated STARTTLS fine, and then just never responded to the SSL handshake. It seems that something (openssl? sendmail?) changed between Hardy and Intrepid so that instead of using the /etc/ssl/certs/ca-certificates.crt file just for verification, its contents were now being sent during the SSL handshake. (I reduced the number of configured certs with sudo dpkg-reconfigure ca-certificates , and checked on the size of the handshake with openssl s_client -connect server:port wc -l .) It spewed 143 certs sent at every connection. Unsurprisingly, it seems some clients were choking on it (I would like to note that Thunderbird behaved correctly). In the end, I configured my CAfile to aim at just a single CA (the CA used to sign the server s SSL key), and that fixed both msmtp and Outlook. How fun.