Landfill of Wisdom

Mutt is my mail client of choice. The reasons are simple: It... is fast is usable from the command line (a big plus) lets you do essentially anything to a message supports hooks for very flexible configuraiton And the tip of the day -- how to fix unreadable (as in -- mojibake mail) to be readable again. Highlight the mail in the index and press "e". This will fire up your editor (vim in my case) and load the full mail in it. Find the "Content-Type" header. Edit the value of the "charset" field on the line. If there is no such header just add one: Content-Type: text/plain; charset="iso-2022-jp" If the subject of the mail is also unreadable, do the following: Install maildrop Select the Subject line and pass it to this command cat | xargs -ifoo reformime -h "foo" | iconv -f iso-2022-jp -t utf8 | xargs -ibar reformime -o "bar" -c utf8 . In vim speak, this means /^\csubject: Shift-V!cat | xargs -ifoo ... Play around with the

So I got XEN working but the network interfaces on my host became a mess and it is somewhat related to my naming conventions. I like to name my interfaces with easy (at least to me) to understand names. For example, my local interface is named "lan". The one that my PPPoE connections are running over is "inet". A third card going to my neighbor is called "nei". On my desktop where I was testing XEN I only have one interface -- lan. When I start xend, the default network-bridge script is trying to set up some bridges (another option I had to recompile here), and is trying to move the configuration of my physical interface to the new bridge and rename the bridge to have the name of my interface (after renaming the interface itself of course). What happened is that udev kicked in when the new interfaces showed up as it is doing its best to keep my interfaces with consistent names. That pretty much did the mess, except that the network-bridge script itself wa

So, I had some time to see why XEN refused to work last time . The first obvious problem was that I had not loaded any modules. So far, so good. I quickly loaded all back-related modules, specifically netloop, netbk, blkbk, and xenblktap. Not loading these would give weird errors about a device not being connectable. One would think that XEN can give more understandable error messages. The case is that it would give the same message if you're missing the module and if the path to the file representing a block device is invalid. So, be careful. Loaded the modules and "xm create" behaved much better. No errors, but it hang for a long time. I didn't know how to interpret the output of "xm list", so I had no clue if the guest domain was running or not. I tried "xm create -c" but it would just bail (after a 30 second wait) with a message that it cannot connect to the console. "netstat -tnlp" did not suggest that anything is listening on a 59xx

I decided once again that it is time to give XEN a try. I decided to try it on a newer Athlon 64 X2 with virtualisation capabilities. That latter is important, as my overall intention is to also try OSes that are "incompatible" with XEN. I know that there are other alternatives but I'll write on "why XEN" some other time.