When my friends Karen and Annina were confronted with an offensive
sticker on the laptop of someone working at our lab, they organized a
very constructive and effective intervention.
I was so impressed that I made a short illustrated write-up of the
story on my wiki.
The new release 0.1.1 of
r (pronounced
littler) was just rolled up.
The only new feature is due to a suggestion by Paul Gilbert: r now reports
the value of the optional status variable when calling
q() at the end of a script:
$ r -e'q(status=42)'; echo $?
42
This can be very useful to signal exit codes and branching on those in
other scripts or Makefile. We also applied a patch to manual page which adds
some examples there (thanks, Seb!) and made some small changes to tests and
examples.
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.
The Debian Live team is pleased to announce the first beta of Debian Lenny's Live images.
Although we missed releasing images for Etch along with the installer images, we are now prepared to release live images within the regular Lenny release process. This is the first official release of Debian Live and the whole team has been working hard during the past 2.5 years to make Debian's own live systems become a reality.
Nevertheless, we do need your help to find more bugs and improve the live systems, so please try them out. The images are available at:
http://cdimage.debian.org/cdimage/lenny_live_beta1/Please also have a look at the known issues listed below. Main features 100% Debian The build process of Debian Live basically consists of creating a Debian chroot, installing one or more kernels along with live-initramfs (a set of hooks into initramfs-tools for handling booting from read-only media) and generating a bootable image from that. This process is handled by live-helper, a collection of shell scripts that allow us to automate and customize this process. Considerable care is taken to ensure that the resulting live system is not tainted by the host system and that installed packages are not modified morethan absolutely necessary. This ensures that Debian Live really is Debian, and not "just another" a Debian-based live system. Flavours Although live-helper is a toolkit to produce your very own live systems with only a few steps, we also provide prebuilt images that are meant to be used as reference systems for end-users. Currently, this consists of the three major desktop environments (GNOME, KDE and Xfce), as well as a small 'standard' image without a graphical environment. For the desktop environments, package selection is performed by 'tasksel' with the respective desktop task, whilst the 'standard' image contains only packages of "Priority: standard" or greater, notwithstanding a handful of live-specific packages (console-common, eject, file, kbd, live-initramfs, locales, sudo and vim-tiny). Image types Debian Live offers prebuilt images for CD/DVD discs, USB sticks (or any HD-media-like device), tarballs (for PXE netboot) as well as a bare squashfs image to boot from the web directly. Live Magic Live Magic is an GUI frontend around the live-helper scripts, offering a subset of the features of live-helper in an easy-to-use graphical user interface. live-magic 1.0 was recently uploaded to sid and is the recommended version. It currently supports 7 languages. Live Installer Live Installer is a special udeb for the Debian Installer that (optionally) replaces a part of d-i in order to install the system from the live image instead of to bootstrapping it from .deb packages. This way, a live system can be easily installed to the harddisk, ensuring that the look and feel of the installation (including preseeding) works the same as the regular installer process. Unfortunately, live-installer does still have a few minor bugs left and is thus not included in our builds yet; we hope to be able to include it in the next beta. Known issues in this release
Now if you have a server with 8 or 12 disks (both of which seem to be reasonably common capacities of modern 2RU servers) and if you decide that RAID is not required for the swap space of DomUs then it would be possible to assign single disks for swap spaces for groups of virtual machines. So if one client had several virtual machines they could have them share the same single disk for the swap, so a thrashing server would only affect the performance of other VMs from the same client. One possible configuration would be a 12 disk server that has a four disk RAID-5 array for main storage and 8 single disks for swap. 8 CPU cores is common for a modern 2RU server, so it would be possible to lock 8 groups of DomUs so that they share CPUs and swap spaces. Another possibility would be to have four groups of DomUs where each group had a RAID-1 array for swap and two CPU cores.
So I got bored tonight and figured I'd write a game...
I'm genuinely not sure whether I've seen this concept before, or came up with it myself. I suspect the former. I know that I sat down with the intention of coding this game and knew how it would play and what the mechanics would be.
Having said that though I cannot think of a similar game I've played - though parts are obviously derivitive.
Anyway the aim of the game:
apt-get install libsdl-perlCode: ObQuote: The Chronicles of Riddick
I’d been having problems connecting my laptop to my router to the Phone Coop using a new network cable that I laid under the floor just after the new heating system was installed. It’s a 1970s building - cat-5 wasn’t installed with the original wiring and mains homeplug networking is tricky on this wiring layout. The growing number of people with WiFi and video senders on my hillside (70% of UK users “never or rarely switch off their broadband wireless routers”) seems to be causing more interference and slow-downs, so it seemed worth installing a wired connection while the floors were up.
The connection seemed to work fine, but then kept stopping for 20 seconds at a time - that’s just long enough to break network connections, but barely long enough to start up debugging tools, let alone get useful output.
I was pretty sure the cable wasn’t at fault - Paul tested it with his fancy test gear when he completed the wiring for me. That left the hardware: my much-hated Belkin F5D7630 and the Realtek 8139 in the bizarre Compaq Evo N1015v. I’ve still not got around to replacing that Belkin and it’s been behaving itself well enough recently, while the Compaq has run smoothly once I actually got Linux onto it.
I found the end of this Ubuntu Forums thread which pointed to this archlinux bulletin board thread which suggested pnpbios=off pnpacpi=off in the boot options. After adding that, the 20-second network pauses have stopped. But why? The ACPI and BIOS in this laptop are generally troublesome (and it looks like this also happens on some Presarios), but what in particular is going wrong this time? Will I suffer ill effects from switching off PNP options? Time will tell, I guess.
I've written a simple perl script using SOAP to add some useful data to the RC bug list (or any list of bugs). It can easily be extended but right now it supports simple things like the date the bug was filed, short description of the package, the name of the maintainer, the most recent upload data, the debtags for the package, apt-cache policy data and whether the bug is already tagged pending.
The LSB spec invents things without consulting distros. Like the whole init scripts thing. But that s not as bad as depending on RPM or requiring a specific layout.What can be very frustrating is that we do reach out to all the major distros, and a number of the less major ones. But we don’t talk to every single person on every single distro; we can’t. We also try to follow best practices for an open project: open version control, open IRC, open mailing lists. Part of the problem may be that we also talk to independent software developers, and sometimes, distro people aren’t prepared to hear what developers are saying. So, it looks like we’re pushing things on them, like predictable directory layouts, hooks for working with the user environment, different options for software installation, and the like. We used to just listen to distros and do what they wanted. Part of the reason there’s still a lingering perception that “the LSB failed” is that software developers saw us as irrelevant. And they were right: we were irrelevant, because we only listened to the distros. So now we listen to both sides, and try to get them to talk to each other, and act as a go-between when they don’t seem able to. I had an eye-opening experience in Berlin in 2006. We talked to packaging people, and talked about the need for cooperation between package managers and third-party installer tools. A lot of people thought that was a bad idea. So we got them together with some major ISVs in Berlin, and told them to figure it out. And they did figure something out, and surprise! Communication between package managers and third-party installers became a good thing, at least if done right. And we don’t have a problem with the “done right” part, either. We made a few attempts at proposals for the communication system above, and someone has created an independent implementation. Some of those proposals came under sharp criticism. And we’re cool with that; happy, in fact, that it got attention. So if you want to find out what’s going on with us, and what terrible things we’re going to make you do in the future, check out our project plan, sign up for our mailing list, or just come by our IRC channel (irc.linuxfoundation.org, #lsb) and ask some questions. We try to be friendly and helpful.
I took a note of the various talks I attended at DebConf, with the aim of writing a few notes about each so that I could try to explain to my work mates exactly what I get out of going. However I think a lot of the benefit is about general face to face contact with fellow DDs and random conversations that happen. Having worked from home for over 3 years I'm finding it quite nice to be back in an office with people
working on the same things as me; there are conversations that you will have over a quick cup of coffee or in the corridor that you wouldn't bother typing on IRC or email or picking up the phone for. Debian is a lot like a large organisation full of telecommuters and DebConf provides a vital opportunity for us to have those "minor" conversations that prove quite useful and to remind each other what we're actually like in person.
I didn't end up writing a lot of notes during the talks so these are just snippets after the fact. If I'd been more organised I'd have done a write up on a daily basis rather than leaving it all until the week after. A lot of the below is fragmented thoughts, but the longer I leave it the less relevant it gets and the more chance I forget something. It'd have been up faster if I hadn't been fighting Movable Type to try and get some sort of headings.
Sunday
This week has been a little hectic, as I’ve been struggling with testing different versions of the GNU/Linux kernel.
apt-get install dfu-utildfu-util -l shows you a list of devices it can
access. If you see more than once, you need to specify in all
dfu-util commands which one you want, using -d
USBID. In my case, I have to always use dfu-util -d
0x1d50:0x5119dfu-util -a kernel -R -D
/path/to/uImagedfu-util -a rootfs -R -D
rootfs_filename.jffs2dfu-util -a u-boot -R -D
uboot_filename.bindfu-util -a u-boot_env -D env.new-U instead of -D.
Networking via USB
All of the distributions I tried, by default configure the USB
as a gadget with
ethernet over usb. You can form a lan with it using the
cdc_ether module, and you will find your phone
preconfigured as 192.168.0.202 expecting to find a
gateway at 192.168.0.200.
I made myself this script to start and stop networking with the
phone:
#!/bin/sh
case "$1" in
start)
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE -s 192.168.0.200/29
ifconfig usb0 192.168.0.200 netmask 255.255.255.248
/etc/init.d/dnsmasq start
echo 1 > /proc/sys/net/ipv4/ip_forward
;;
stop)
echo 0 > /proc/sys/net/ipv4/ip_forward
/etc/init.d/dnsmasq stop
iptables -t nat -F POSTROUTING
ifconfig usb0 down
;;
esac
Besides doing masquerading, it also brings up dnsmasq so that
the phone can always find a DNS together with the router.
Another useful trick is to configure the phone to share the
approx cache with the laptop:
deb http://192.168.0.200:9999/debian unstable main
deb http://192.168.0.200:9999/debian experimental main
deb http://pkg-fso.alioth.debian.org/debian unstable main
So yes, my laptop can now be turned into a phone charger with
networking, DNS and apt cache services. I shall look into hooking
that script into dbus to have it run automatically when the phone
is plugged and unplugged.
Changing the ringtone in Debian
In case you don't like the default ringtone, this is how to
change it:
vi
/usr/share/python-support/fso-frameworkd/framework/subsystems/oeventd/receiver.pydef _play( self ):decoder =
gst.element_factory_make, if needed. The list
of available plugins is on the gstreamer website.filesrc.set_property/etc/init.d/fso-frameworkd restart and maybe
/etc/init.d/zhone-session restart/usr/share/python-support/fso-frameworkd.
Configuring the bootloader
You can connect to the u-boot bootloader via a serial
terminal on /dev/ttyACM0. Type help and
you will find that it can do a lot of things. The OpenMoko wiki has
pages on the
bootloader itself, its
commands and the
environment.
The environment is the configuration of the bootloader, similar
somehow to /boot/grub/menu.lst. Unlike grub, you can
edit the environment from within the bootloader and then save it
using the saveenv command.
What I did:
setenv menu_3 Boot from microSD (FAT+ext2):
setenv bootargs \$ bootargs_base rootfstype=ext2
root=/dev/mmcblk0p2 rootdelay=5 \$ mtdparts ro\; mmcinit\; fatload
mmc 1 0x32000000 \$ sd_image_name \; bootm 0x32000000setenv bootdelay -1setenv
boot_menu_timeout 99999setenv stop_in_menu
yessaveenv~/.ssh/config):
Host debian
HostName 192.168.0.202
User root
HostKeyAlias debian
Host qtopia
HostName 192.168.0.202
User root
HostKeyAlias qtopia
I’ve ordered some USB charging leads for various portable devices, mainly because I’ve already got mains-USB and car-USB power adapters (they came with a bluetooth headset that charges from USB) and I agree with things like this:
“management of an individual charger for each device is becoming a pain in the backside. Since the USB power form specification is a standard, ANY charger with sufficient load capability should be able to charge ANY device.” (from USB As A Power Source)but I’ve also heard that charging from USB is greener - or more precisely that because your computer’s power supply is running anyway, it uses less electricity to plug battery chargers onto the Universal Serial Bus than to plug in “wall-wart” DC adapters. But is this claim true? Claims from USB recharging product sellers concentrate on the obvious “less waste compared to disposable batteries” strength, although some smarter chargers cut power to charged devices - it’s not clear whether the mass-market USB battery chargers do this, but the reasons and the electronics don’t look that complicated. China (not famous for environmental protection yet) now requires USB-charging of mobile phones while a mobile phone industry body has recommended the same approach in general. However, there are concerns about whether Power over Ethernet is making networks less green, which might be true for USB if devices demand more high-power sockets and device makers don’t include intelligent control electronics (which people generally don’t want to pay for). Is USB charging greener than mains charging? I’m not sure and I haven’t found any great answers - can you? I guess in the worst case, I can try some tests with a power meter later…
Debian Integrated Solutions. (DIS, pronounced "dish".) 
(This is a more detailled and hopefully better structured explanation
of the topic of my Lightning Talk during Debconf)
With the ever growing number of packages in our archive we need
ever better methods to structure, sort, and search this collection.
While projects like debtags
try to improve the search in packages, my idea is about improving
the way the results are displayed.
There is one relation between packages that is currently never strongly
featured when presenting package meta-data:
the source ↔ binary relation.
Usually package managers operate either on binary packages
or source packages, but seldomly do they expose the fact that
one is generated from the other.
In the trivial case of one source package producing one binary
package there is probably nothing to gain. But there are a large
number of source packages where this isn't true (at the moment
about 29% of all the source packages in main build more than
one binary package, together producing about 61% of all binary packages).
I have the idea (which so far is nothing more) that if we could
present packages through their source packages that this could drastically
reduce the number of packages to choose from and make some common
search actions more effective.
This is not by any meaning a trivial task, though, since on the
other hand not all source packages necessarily produce binary packages
that have much to do with each other, and even for the ones that do,
the exact relationship between the binary packages can vary greatly.
Also some source packages are really belonging together but are split
to make maintenance easier (e.g. KDE and X.org). These splits might not
necessarily make any sense to an user.
Some ideas what to implement in terms of code to make it easier to
let the user benefit from the fact that multiple binaries have the
same source:
As everyone can see in the
graph of release
critical bugs, the number of RC bugs in etch had constantly risen
since the release (which was already noted in some other blogs) up until last
week. Since I suspected that this number included a lot of false
positives, I began to triage this list last week during Debconf.
I started with identifying all bugs that were filed against the
version in etch, but really only meant the package in testing/unstable
(but can't be interpreted correctly with version tracking alone since
the version in stable, testing, and unstable is actually identical).
There are a lot of
reasons why an RC bug might be valid for testing/unstable, but not
for stable, even though they share the same package:
Computer security is generally defined as the following:
Session Started with Agent (Sneha Ranga)
Agent (Sneha Ranga): "Due to circumstances that have affected Dell Communications I am temporarily unable to pull up any information. The down time is temporary. We apologize for the inconvenience, as we value your time as a customer. Please contact us back after an hour."
Session Ended
From: Debbie@Dell.com
Date: Thu, 18 Oct 2007 13:08:18 -0500
To: jgoerzen@complete.org
Subject: RE: Dell mailing list
Thank you, Mr. Goerzen, your request to have the below address
information removed from our marketing lists has been received:
[ my address here ]
We will process your request promptly. However, it may take several
weeks for some changes to take effect. If you are still receiving
catalogs after thirty (30) days feel free to email me. Sorry for any
inconvenience you may have experienced.
Thank you,
Debbie
I keep getting your Dell Home and Home Office catalog. I have tried for months to get off your mailing list. I have called in, talked to people in multiple departments, who have promised to remove me from the list. I have contacted you online. NOTHING IS HELPING. This has gone on for MONTHS.
PLEASE NEVER SEND ME MAIL AGAIN, EVER, AND DO NOT RENT OR SHARE MY NAME.
My address is above.
The code on the mailing I received is: [ snipped ]
If you are currently receiving our catalog or mailings and would like to be removed, please visit the following web page and select the appropriate link under the "Opt-out of direct mail, phone or fax communications" heading: http://www.dell.com/OptOut
Thank you for signing up for Dell Email Subscriptions. Please save this email for your records.
mode server
tls-server
dev tap0
server-bridge 10.5.6.1 255.255.255.0 10.5.6.200 10.5.6.209
ifconfig-pool-persist /var/run/openvpn-ip.txt
keepalive 10 60
ping-timer-rem
persist-tun
push "route 10.5.6.0 255.255.255.0"
push "dhcp-option DNS 10.5.6.1"
ca /root/easy-rsa-2.0/keys/ca.crt
key /root/easy-rsa-2.0/keys/ressukka.net.key
cert /root/easy-rsa-2.0/keys/ressukka.net.crt
dh /root/easy-rsa-2.0/keys/dh1024.pem
client-to-client
up /etc/openvpn/ovpn-ressukka.sh
and the up script:
#!/bin/sh
# Bind the tunnel interface to the bridge
BRIDGE=br0
ifup $1
brctl addif $BRIDGE $1
There is nothing really special about that configuration. The
server is in TLS mode configures a bridge. The keys are generated
with easy-rsa by following a openvpn howto entry. The up
script just binds the tap0 device to the network
bridge after bringing up the device.
Next I created the interface configuration by adding the
following to /etc/network/interfaces:
iface br0 inet static
address 10.5.6.17
gateway 10.5.6.1
netmask 255.255.255.0
bridge-ports eth0
The trick here is to create a single bridge with just the
eth0 device. We use the up script for openvpn to add
the tunnel device to the bridge. Otherwise the bridge would never
contain the proper devices.
Client
As for the client, you simply set the client to use the
CA-certificate and Host key created with easy-rsa, set the hostname
and tunnel type. Tunnel type is assumed to be a tun-device instead
of tap, so in my case I needed to change it too.
There is no need to tell the client anything else. Everything
else will be negotiated through the tunnel. And since I use
NetworkManager to set up my tunnels I didn't have a need to drop in
to a shell even once at the client.
Next.