FLOSS Manuals is proud to announce a three day book sprint for the Pure
Data FLOSS Manual. This sprint will take place simultaneously in New
York City and Berlin from Saturday 4 April to Monday 6 April. The Pure Data FLOSS Manual: http://en.flossmanuals.net/puredata There are possibilities to participate in person by coming to one of the
locations below, or remotely via the IRC interface built into the FLOSS
Manuals editing interface. Video conferencing may take place between the
venues as well. To participate, create a login at the PD FLOSS Manuals page: http://en.flossmanuals.net/bin/login/TWiki/WebHome?origurl=/bin/view/PureData/Introduction&skin=floss2 Discussion may also take place in the Pure Data mailing list: http://lists.puredata.info/listinfo/pd-list If you are in New York or Berlin, please join us at these locations! NEW YORK CITY * Contact: Hans-Christoph Steiner: hans@eds.org 718 360 4872 * Location (bring ID, you ll need to sign in): ITP/NYU Conference Room
721 Broadway, 4th Floor
NY, NY, USA
email me or call in case you can get past security: 718 360 4872 * Schedule:
Saturday: noon-midnight
Sunday: 10am-midnight
Monday: 9am-5:30pm (if we go later, we ll be in a different room) BERLIN * Contacts Derek Holzer: derek@umatic.nl +49 176 2812 5845
Adam Hyde: adam@flossmanuals.net +49 15 2230 54563 NK
ElsenStr. 52 (2.Hof)
Berlin, Germany
+49 176 20626386
http://www.myspace.com/enka52 * Schedule:
Saturday: noon-late
Sunday: noon-late
Monday: noon-late
SOME BASIC GUIDELINES: * This manual should address the widest possible user-base. Therefore,
objects which are cross-platform and in Pd Extended should have priority
over other solutions.
* Tone should be neutral and informative. Remember that humor doesn t
always translate well!
* Our readers are assumed to have little to no background in either
computer programming or digital signal processing, which much of the
existing documentation takes for granted. That s why this manual is
necessary! Please keep this in mind when explaining things.
* Please use existing the Audio Tutorials, Installing and Getting
Started chapters as a style guide.
* Keep the chapters small and self-contained. Ideally, chapters from
this manual could even be remixed into other FLOSS Manuals.
* Explain any jargon or technical terminology in-line the first time you
use it, and direct the reader to appropriate other chapters/manuals when
necessary.
* Please enter any new technical terms in the Glossary (we need to agree
on global format for glossary terms!).
* Screenshots:
Resolution? (Adam and I will work on this on Monday)
Please upload any complex patches, and make sure to label screenshot
with appropriate filename (see Audio Tutorials for examples)
Please keep explanatory text in the manual rather than only in the
screenshot, so that it can be text-searched by readers.
Please use anti-aliased fonts!
* All the chapters are moderated by Derek Holzer & Adam Hyde. Your
contributions will only be visible in the editing section until they
meet these guidelines, and after that they can be published to the main
page. Please let us know when your chapter(s) are ready for publishing
and we ll look them over. EXISTING CHAPTERS WHICH NEED HELP: # DataflowTutorials this section needs a lot of help in terms of style and content!!!!!
Tone is very informal, which doesn t help convey the information.
give titles to screenshots so that readers can tell which patches
match which images (some do this, some don t )
Math : examples/discussion of [expr]???
Order of connecting and [trigger] : explain the patches in-line,
rather than only in comments in screenshots (so that text is searchable,
copy/pasteable..)
Luka s screencaps are very aliased, to the point where you can t read
the ~ in the object names. Should they be redone at new resolution or
with antialiasing?
Possible janitors: Derek Holzer, Adam Hyde # PureGlossary format of object names = [italics in square brackets], must be
formatted correctly
format of glossary words in general text: we don t have one yet. Bold
on first use in chapter maybe? Needs formatting all through text. # ListofObjects incomplete, please add more libs
maybe more discussion of externals needed as well
formatting of object names? # PureLinks always welcome MORE CHAPTERS/SECTIONS TO DO (+ suggestions?): * GEM (in order of importance)(Derek can provide example patches for
much of this)
Basic VJ mixer (2 x
[gemhead]-[pix_film]-[alpha]-[colorRGB]-[pix_texture]-[rectangle] with
an alpha-crossfader)(+ platform specific codec info)
Live camera input (same as VJ mixer but with [pix_video], with
platform specific info on USB/firewire inputs what works & what doesn t)
VJ effects (using the various pix objects)
Basic 3D (that actually does something interesting, rather than just
show a sphere or a cube)
Basic movement tracking w/ [pix_blob]
GEM/video optimization/troubleshooting tips (see Troubleshooting
section of existing Pd FLOSS Manual) * MIDI tutorial
hardware:keyboards, sliders, etc,
objects: all MIDI objects
routing: input + output to/from devices or other programs * Patching strategies
Reusable abstractions ($0 etc)
GoP + other GUI creation strategies
Preset saving systems (Frank?) * Audiofile manipulation (Derek can provide examples, possibly also work
with www.pd-tutorial.com with permission?)
sfread, readsf, sfplay, etc
tables + tabplay, tabread, etc
oneshot playback without/with pitch shifting
looping without/with pitchshifting
granulation without/with pitchshifting
Extended objects ([xplay~], [xgroove~] are these stable? In my
experience, no ) * Realtime audio effects tutorial
delays: single tap, multitap, pitch-shifting, tuned comb filter, etc
filters: [hip~], [lop~], [bp~], [moog~], IEM lib filters
[vcf~]/[bp],[hp],[lp], difference between audio signal and message
controlled, building with ggee objects [bandpass],[llowpass],[highpass]
or [biquad~] (resources for coefficients?) * Sensor tutorial (HC?)
[hid]/[hidin]/[pduino]
simple circuit diagrams + photos (voltage divider examples:
potentiometer, photoresistor, etc)(hacked gamepads) * Networked data
netsend/netreceive
OSC
flash server
shell
python externals
others? * PDP/PiDiP
configuration info for OSX (+ poor performance disclaimer!)
basic VJ
networked streaming etc * Procedural Audio tutorial? (Andy?) * RJDJ tutorial? (Frank and the gang?)

The recent update to udev 0.140 lead to a system without network access to me. The error messages were:

Running 0dns-down to make sure resolv.conf is ok...done.
Setting up networking....
Configuring network interfaces...
ioctl[SIOCGIFFLAGS]: No such device
Could not get interface  ath0  flags
ioctl[SIOCSIWPMKSA]: No such device
ioctl[SIOCSIWMODE]: No such device
Could not configure driver to use managed mode
ioctl[SIOCGIWRANGE]: No such device
ioctl[SIOCGIFINDEX]: No such device
ioctl[SIOCSIWENCODEEXT]: No such device
ioctl[SIOCSIWENCODE]: No such device
ioctl[SIOCSIWENCODEEXT]: No such device
ioctl[SIOCSIWENCODE]: No such device
ioctl[SIOCSIWENCODEEXT]: No such device
ioctl[SIOCSIWENCODE]: No such device
ioctl[SIOCSIWENCODEEXT]: No such device
ioctl[SIOCSIWENCODE]: No such device
ioctl[SIOCSIWAP]: No such device
ioctl[SIOCGIFFLAGS]: No such device
wpa_supplicant: /sbin/wpa_supplicant daemon failed to start
/etc/network/if-pre-up.d/wpasupplicant exited with return code 1
SIOCSIFADDR: No such device
ath0: ERROR while getting interface flags: No such device
SIOCSIFNETMASK: No such device
SIOCSIFBRDADDR: No such device
ath0: ERROR while getting interface flags: No such device
ath0: ERROR while getting interface flags: No such device
Failed to bring up ath0.
done.

It seems, the update added rules to /etc/udev/rules.d/70-persistent-net.rules by increasing the device number and applying the last applicable NAME directive instead of the first one. This lead to the following file here:

SUBSYSTEM=="net", DRIVERS=="?*", ATTRS address =="XX:XX:XX:XX:XX:a7", ATTRS type =="1", NAME="ath0"
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS address =="XX:XX:XX:XX:XX:18", NAME="eth0"
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS address =="XX:XX:XX:XX:XX:XX", NAME="eth1"
# PCI device 0x10ec:0x8139 (8139too)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR address =="XX:XX:XX:XX:XX:18", ATTR type =="1", KERNEL=="eth*", NAME="eth2"
# PCI device 0x168c:0x0013 (ath_pci)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR address =="XX:XX:XX:XX:XX:a7", ATTR type =="1", KERNEL=="ath*", NAME="ath1"

So the devices created were eth2 and ath1 but /etc/network/interfaces contained entries for eth0 and ath0. So fixed /etc/udev/rules.d/70-persistent-net.rules and rebooted. <rant>Is it really necessary to break network access with an update???</rant> Update I forgot this one: #521521.

This has irritated me for a while in configure.ac. You've probably seen this pattern before:

AC_INIT([foo], [0.0.1])
MAJOR=0
MINOR=0
MICRO=1
MY_VERSION=$MAJOR.$MINOR.$MICRO
AC_SUBST(MAJOR)
AC_SUBST(MINOR)
AC_SUBST(MICRO)
AC_SUBST(MY_VERSION)

I finally hit my annoyance threshold for this, and the answer is pretty obvious. (If its not, or you think there is a simpler one, give it a shot - I'd like something more pithy).

AC_DEFUN([MAJOR], [0])
AC_DEFUN([MINOR], [0])
AC_DEFUN([MICRO], [1])
AC_DEFUN([MY_VERSION], [MAJOR.MINOR.MICRO])
AC_INIT([foo], [MY_VERSION])
AC_SUBST(MAJOR)
AC_SUBST(MINOR)
AC_SUBST(MICRO)
AC_SUBST(MY_VERSION)

Its not a big deal to be duplicating version numbers, but not duplicating at all is nicer.

At ICHEC one of our tasks is to help users build their software on our supercomputers. Mostly we have to change paths, etc. in code bases that are used by a handful of scientists, and we don't want to exacerbate the hard-coded path problem. We also have multiple versions of certain libraries and compilers installed, which we select using modules: to do this, you select your software environment with e.g.

$ module load intel-fc/11.0.082  netcdf/4.0-intel

This selects the compiler version, and library version. Then, this places appropriate paths in $PATH, $LD_LIBRARY_PATH. While this is useful for selecting, eg. compilers, its often not great for many build processes that expect library paths, etc. hard-coded. I also dislike adding random environmental variables: it loses the Single Point Of Truth that describes the configuration. So I've come up with the following pattern. First, record the modules used (eg. library version) in config.log if configure is used. To do this, add the following to the autoconf file or system headers:

# AC_MODULES_OUTPUT
# -----------------
# Check if the system runs 'modules', and if so, record the modules environment in the config.log
AC_DEFUN([AC_MODULES_LIST],
[AC_CACHE_CHECK[modules output if present],[ac_modules_output],
(ac_modules_output= module list 2>&1 )
if test $? eq 0; then
 AC_MSG_RESULT([Output from 'module list' was:\n $ac_modules_output])
fi
])

Secondly, For all packages, ensure that a pkgconfig package file exists. For example, we have multiple MPI implementations on our SGI system. For MVAPICH, we have a modules file:

stokes2:~$ module show mvapich2-intel
-------------------------------------------------------------------
/ichec/modulefiles/mvapich2-intel/1.2p1:
module-whatis    MVAPICH2 1.2p1 (Intel 11.0.074) 
conflict         mvapich2-gnu mvapich2-intel 
prepend-path     PATH /ichec/packages/mvapich/1.2p1-intel/bin 
prepend-path     LD_LIBRARY_PATH /ichec/packages/mvapich/1.2p1-intel/lib 
prepend-path     MANPATH /ichec/packages/mvapich/1.2p1-intel/share/man 
prepend-path     INCLUDE /ichec/packages/mvapich/1.2p1-intel/include 
prepend-path     CPATH /ichec/packages/mvapich/1.2p1-intel/include 
prepend-path     FPATH /ichec/packages/mvapich/1.2p1-intel/include 
prepend-path     PKG_CONFIG_PATH /ichec/packages/mvapich/1.2p1-intel/share/pkgconfig 
-------------------------------------------------------------------

We add a file mpi.pc to the PKG_CONFIG_PATH for each MPI implementation. So, mpi.pc looks like:

# MPI pkgconfig file for mvapich2-intel
# Normally only used to get variables $prefix, etc.
prefix=/ichec/packages/mvapich/1.2p1-intel
exec_prefix=$ prefix 
libdir=$ prefix /lib
includedir=$ prefix /include
Name: mpi
Description: netCDF libraries, include files and development tools
Version: 1.2p1
Libs: -L$ libdir   -lmpichf90 -lmpich -lpthread -lrdmacm -libverbs -libumad -lrt
Cflags: -I$ includedir 

This then means we can add the following small patch to our target software (in this case a climate code COSMOS):

 #########################################################################
 #
 #  MPI message passing root directory of the chosen compiler
 
+  # Get default MPI ROOT from the pkgconfig file if possible
+  pkg-config mpi --variable=prefix 2> /dev/null > /dev/null
+  if [ $? -eq 0 ]; then
+    MPIROOT= pkg-config mpi --variable=prefix 
+  fi
+
   if   [ $compiler = ifort ]; then
     export cc=cc
     if [ $CHAN = MPI2 ]; then
-       export MPIROOT=/sw/sarge-ia32/mpich2-1.0.4p1-pgi
+       export MPIROOT=$ MPIROOT:-/sw/sarge-ia32/mpich2-1.0.4p1-pgi 
     elif [ $CHAN = MPI1 ]; then

Such a patch is generic enough to be useful outside our institution, and means the code can build out-of-the-box on many systems. Now to add mpi.pc to Debian ... Tags programming, autoconf, modules pkg-config, ichec, work

Some time ago I wrote about the the state of GRUB2 and a milestone on getting it boot my Apple PowerBook G4 without manual intervention. More than a year later, GRUB2 has changed and improved a lot, as the community keeps growing and patches and ideas are continously being posted. Some months and commits after my previous post, GRUB broke again on Apple OpenFirmware and I'd get dropped to OF console, the amount of commits since the last known working version and the current SVN was quite big, and although I was able to narrow it to a few suspicious changes, I had no time to bisect it properly, and sadly I had to go back to yaboot for a while. But procrastinating sometimes helps, and when I should have been writing and studying, on December I gave GRUB a new try on my laptop to see if a few important changes to memory allocation would have changed anything. And it did! So after fighting quite a few problems, I was able to report partial success to grub-devel. Again, getting GRUB installed correctly was a bit challenging and needed some hackery, due to incorrectly generated device.map, and the linux module mysteriously not getting loaded. Luckily, Michel D nzer found out that this was due to a bug in sort ordering in the HFS module, which broke the lookup of files with underscores like _linux.mod, and for which he posted a possible fix by taking Linux's table of character ordering, which is a blob of hex values. GRUB developers didn't seem too happy about applying the patch: they argument that a blob like that should be well documented or written in some other more readable way, and there's a possible problem with the mix of Linux GPLv2 and GRUB GPLv3+ codebases, if a table of data like what Michel posted is actually copyrightable. The discussion ended up dying and nothing was done... until Pavel Roskin picked it up weeks later and posted a new patch, based on hfsutils GPLv2+ code, which addressed these issues. The new patch seems to have a few issues, which makes it fail as before, but hopefully it'll be fixed soon. Additionally, I wasn't able to boot using UUIDs as the search commands fails to detect the correct boot device on my system (but not on Michel's), so I had to disable that in /etc/default/grub. To workaround the linux module loading bug while the patch is fixed, I just added this ugly hack to /etc/grub.d/09_local_prelinux:

#! /bin/sh -e
# Work-around for bugs in the hfs module which makes the load of
# linux.mod fail.
cat << EOF
insmod (hd,3)/usr/lib/grub/powerpc-ieee1275/_linux.mod
insmod linux
EOF

This is enough to get the initrd and linux commands available. However, update-grub will still add search commands to your menu entries even if you disabled UUID support; I can't understand why, but I know it breaks on my PowerBook due to some OF rarety. Just removing the line from the menu entry will leave me with a working config that boots without any manual editing at GRUB prompt. The latest GRUB snapshot in Debian fixes the device.map issue, but adds one last issue: update-grub will fail due to some gfxterm detection code, a workaround is to replace an exit 1 with exit 0 when this happens in /etc/grub.d/00_header. On the weird architectures front, it's worth noting that this month Dave Miller popped up on the list and started posting patches to fix the rotten SPARC port, and I think it's safe to assume that it'll be on an usable state really soon. Impressive!

To look at the economics of open source software, you have to start with the economics of software as a category, both proprietary and open source. Note: it should be perfectly obvious to everyone that open source software works, and works quite well for some things. This article is more about understanding the how and they why. Just to avoid any confusion... If you look at software as a product, it has a couple of defining characteristics:

• It's difficult to keep people from sharing it. Not impossible, but not easy, either. It was already doable in the days of floppy disks, but with the rise of the internet, it has become nearly effortless. This means, in terms of economics, that it's "non excludable" - it's difficult to keep everyone from enjoying it once you've created it and started to distribute it.
• If you give a copy of a program to a friend, it in no way detracts from your own use of the program. Quite the contrary, it may even make your use of it better, if, say, your friend discovers how to use a cool feature, or writes a handy extension. This is different from traditional goods like bicycles. If you loan me your bicycle, you can't use it to get around. In economics, things like software (or radio or over the air TV) are called 'non rivalrous' goods - many people can take advantage of them without ruining them.

What do you get when you combine something that's "non excludable" and "non rivalrous"? In economics, these are known as "public goods": http://en.wikipedia.org/wiki/Public_good - read the whole thing if you have a few minutes, it's what I'll be talking about. As per the article, "The Problem" as it were, is the free rider problem. Let's stop and look at a contrived example: Bob is an ex-dentist and really knows what it would take to write a great program for managing a dentist's office (or pick your own example... it's contrived, don't quibble about the details). He's also a good programmer, with the skills necessary to implement the program. He talks to a few of his dentist friends, and they're enthusiastic about the whole thing. Let's look at a few scenarios of how things might play out: Bob values his time at 10 dollars an hour, and it will take him 100 hours to complete the project, meaning the whole project would cost about 1000 dollars. One way things could work is that he could find a dentist friend who needs this program, and bill him 1000$ for his time and services, bang out the code, and release it as open source software. Bob gets his money, the dentist gets his code... and all the other dentists in town get it for free, which is bound to make the dentist who shelled out the money a bit irritated, given that he's a human, not a homo-economus, and doesn't like paying and see others get the same thing for free. Let's introduce another variable: the software is only really worth 200$ to the dentist - any more than that and yeah, it's helpful, but not worth that much money (And please stay with me, I know it's contrived, but keep in mind that the situation *is* possible, even if the numbers might be different). That means that if Bob wants 1000$ for his time, but the dentist will only pay 200$, then no transaction will occur! The software won't get written, Bob won't get any money, and the dentist will be worse off because he won't have the nice program, and neither will his dentist colleagues. One way things might still work is if the dentist rounds up some friends and they all contribute a bit, however, that's kind of a pain in the neck for everyone concerned - the dentist doesn't want to get into the software business and spend a bunch of time trying to chase his friends for money, and even if 10 dentists contribute, the ideal position to be in his the 11th guy, who pays nothing, and still gets the software for free. So it's in everyone's interests to not return the dentist's calls in the hope of being the 11th guy. Also, none of them gets the software until they're all on board. So, how to resolve this problem? The wikipedia page talks about introducing an exclusion mechanism, which in this case would be a copyright system so that Bob can sell a copy of his software for 100$ and be sure that it won't be open to everyone to use. This way, the dentists get the software for 100$ less than they value it at (200$), and as soon as Bob signs up an 11th dentist, he's making more than his time/materials costs, and is therefore coming out ahead! The dentists all know that they're paying the same price, so have no reason to grumble about free riders. In short, everyone is pretty happy. Of course, in the real world, things don't play out like that all the time. There are problems with the simplified example above, some of which are very evident: the cost of enforcing copyright laws, in an age when copying is extremely easy, is very high and potentially very intrusive. However, "intellectual property" is, by and large, a compromise solution that has had positive aspects, especially when you ignore the outliers like Microsoft, and look at all kinds of niche software vendors, who make a nice living, create good products, and have happy, satisfied customers. If you look at the other solutions to the free rider problem listed on the wikipedia page, we can see how they might be applied to the world of software.

• Dominant assurance contracts

  Assurance contracts are contracts in which participants make a binding pledge to contribute to a contract for building a public good, contingent on a quorum of a predetermined size being reached. Otherwise their money is refunded. A dominant assurance contract is a variation in which an entrepreneur creates the contract and refunds the initial pledge plus an additional sum of money if the quorum is not reached. In game theory terms this makes pledging to build the public good a dominant strategy: the best move is to pledge to the contract regardless of the actions of others.

  This means that Bob goes out and gets a number of dentists to pledge 100$ to his dentist program, and if he doesn't raise at least 1000$, he'll give them each back 110$. So it's a clever solution that works out for everyone, but is still a lot fiddlier than the copyright system - Bob has to go sell the contracts and explain how things work to a bunch of people before he can get started. This might be doable with 10 dentists, but for a more mass-market sort of program, it would not be feasible.
• Coasian solution

  a mechanism by which potential beneficiaries of a public good band together and pool their resources based on their willingness to pay to create the public good. Coase (1960) argued that if the transaction costs between potential beneficiaries of a public good are sufficiently low, and it is therefore easy for beneficiaries to find each other and pool their money based on the public good's value to them, then an adequate level of public goods production can occur even under competitive free market conditions.

  That sounds an awful lot like open source software, especially the kind espoused by groups like the Apache Software Foundation, where making free software is not a moral imperative, but a good way of producing something that is not necessarily a key business component. This has proven to work very well for infrastructure type code, as well as lots of developer tools. It is less proven as a way to develop end-user software - in the example above, it's not like Bob needs help to develop his system, or that the dentists really want to contribute - they just want a working program and don't want to get involved in its production.
• Government provision This would mean that the government would be responsible for funding the production of open source software. I'm no free-market zealot, but I think the idea of the government being responsible for software products is not one I am entirely comfortable with. Of course, I do think the government has a role with places like universities, where people can do "research" in the sense of hacking on cool systems just to see what can be done, without necessarily having to be thinking of how to make a profit in the short to medium term. Software like BSD, Tcl, and plenty of other great stuff has come out of universities, meaning that in part it is ultimately funded by the government and taxes. The problem, though, is the process of refining those things down into something people are willing to buy. Would Bob go to a local government official to get a grant to produce his software? Why should Bob get the contract and not some other guy? Does the government official know enough about code or dentists to determine who should write the program?
• Subsidies Subsidies might work to encourage software production, but would probably simply be abused. It's probably not as relevant as other potential solutions. What form would it take? 1$ off your taxes per line of code written? It would be difficult to place a value on anything, and might be quite difficult to implement.
• Privileged group This, as the wikipedia page says, is an incomplete solution, and is less generally applicable. In terms of Bob, it might mean that instead of valuing his code at 200$, his wealthy dentist friend with a large practice really needs the code - it's worth 2000$ to him, and can pay Bob the full 1000$ to develop it out of pocket and still come out ahead, and he doesn't really care that much about the free riders because he's getting what he needs and the rest doesn't matter too much.
• Social norms If Bob and the dentists live in a small town, and are all good friends, perhaps Bob could still release the software, and even though the other dentists could copy and use it for free, they don't, because they feel an obligation to Bob to help him out for the work he's done. Even though they could take advantage of it for free, they would feel bad about doing so, and so each chip in 100$, which after enough people contribute, is enough to cover Bob's costs. It's likely that anything distributed on a larger scale, however, will see more free-riding, and "please pay!" might not work out. And it's probably fairly distressful for a developer to make that jump, knowing he's at the mercy of other people's good will.

None of these solutions is perfect, and all, including exclusion in the form of intellectual property laws, or simply doing nothing at all, have problems of their own. Due to the very nature of software, this is somewhat inevitable, and the best we can do is come up with good compromises, and continue to reevaluate them as technology and society change (this is something that needs to happen with IP laws, for instance).

I just discovered that mtr has some problems with IPv6 enabled hosts when using the GUI. Try the following:

1) enter "mtr ipv6-host" in shell -> works
2) enter then an IPv4 only host Hostname input line -> doesn't work

3) quit mtr

4) enter "mtr ipv4-host" in shell -> works
5) enter then an IPv6 enabled host in Hostname input line -> tracing IPv4 part of IPv6 enabled host

So, something is broken, at least for 2). One could argue if 5) might be OK or the expected behaviour, but I believe that mtr should query the AAAA records and trace for the IPv6 hostname, regardless of whether you started with an IPv4 only host first.

Is there already someone tracking IPv6 related bugs in Debian? A tag in BTS maybe? Anyway, the above is reported as #521415.

I just discovered that mtr has some problems with IPv6 enabled hosts when using the GUI. Try the following:

1) enter "mtr ipv6-host" in shell -> works
2) enter then an IPv4 only host in Hostname input line -> doesn't work

3) quit mtr

4) enter "mtr ipv4-host" in shell -> works
5) enter then an IPv6 enabled host in Hostname input line -> tracing IPv4 part of IPv6 enabled host

So, something is broken, at least for 2). One could argue if 5) might be OK or the expected behaviour, but I believe that mtr should query the AAAA records and trace for the IPv6 hostname, regardless of whether you started with an IPv4 only host first.

Is there already someone tracking IPv6 related bugs in Debian? A tag in BTS maybe? Anyway, the above is reported as #521415.

UPDATE: added blog title ;)

Dom: Yeah, we used PayPal to accept payments for accommodation for the 2008 X Developers' Summit, but a combination of staggering US bank incompetence and PayPal being, well, PayPal, means that we lost about $US4500 we'll almost certainly never see again. The whole thing was a nightmare. After that, I switched to Google Checkout and didn't have a single problem, aside from it wanting to give me the whole interface in Finnish for a while and not offering a choice.

This week I'm at PyCon in Chicago, helping to train and supervise the A/V team in recording the tutorials and talks. We have a lot of inexperienced volunteers but they're learning quickly. Carl Karsten (in charge of A/V) and Ryan Verner (another outsider with long experience from LCA) are organising things. Ryan, Dave Noble and I provide technical assistance to the rest of the team. I'm also working on my first Django app, which will be used for reviewing files. This is essentially a clone of the excellent work done by Gunnar Wolf and Damian Viano in Pentabarf. PyCon doesn't have a centralised database so this is a standalone application. Ryan is now applying styles to my horribly bare HTML, and I have a short list of bugs to fix before we ask the video team to start reviewing. The tutorials started yesterday and talks wil start tomorrow in different rooms, so we have to set up all the equipment again and reconfigure for multiple cameras. Hopefully by Saturday things will be running smoothly and I can spend some time in the city. It would be a shame to come all this way and stay by the airport for the entire time!

When I was a child, I was learning to play piano. My parents didn t have one at the time, but my grandparents did. Every evening, we d go over to their house so I could practice. I suspect I was more interested in other things most of the time, though whether Grandma has some cherry moos in her fridge, or whether Grandpa would play chess with me or do something fun in his workshop. Grandma would often be in her curlers, and we d often leave her in the evening saying goodbye in the pink fluorescent lights she had shining on her plants by the door. Other times, we d just go to visit, or I d ride my bike over. I liked helping Grandma cook or bake peppernuts. And when I was trying to learn chess from Grandpa, and Grandma thought he was being too hard on me, she d say something to him in German and I d magically start winning. Grandma volunteered at a local thrift store weaving rugs. These were made by hand on old looms in a traditional way, mainly out of donated clothes and drapes that were too tattered to sell. My mom used to drop me off with grandma while she went shopping. I maybe brought my lunch, and watched grandma, until one time I asked her if I could help. She let me, and eventually the store manager told grandma that I ought to be able to work on my own loom. Pretty soon we had a routine down: in summer, Grandma would pick me up at home, I d read a computing magazine in the car to town, and work at a loom side-by-side with Grandma. That lasted until I got too busy in high school. But ever since then, Grandma delighted in telling this whole story almost every time she saw me, and she remembered word for word what the store manager said something I never quite could remember. I remember watching Grandma care for my brothers when they were sick, or helping out my parents with whatever they needed help with. We had a tradition for a number of years of spending New Year s Eve at Grandma and Grandpa s house, and going back home the next morning. The three of us boys slept in a cold upstairs room, but we didn t care because the bed had more layers on it than we could count, and an electric blanket besides. When my Grandpa Klassen passed away in 1990, Grandma missed him but didn t get too worked up about it. She was convinced that he was in a better place, and appeared to be at peace with it. Death was a normal part of life to her, and it didn t surprise her that it happened. In the last few years, Grandma s health has been failing. Her knees have been bothering her for years, and she has also been struggling with dementia for a few years. It s been hard on me to visit her, because in some ways she hasn t been the same person I remember for awhile now, and in other ways she s exactly the same. Lately she hasn t always remembered where I live, or what Terah and Jacob s names are, we knew to expect that and are respectful of the situation. For years now, Grandma has been saying, I don t know why the Good Lord doesn t take me up to be with him yet. My bags are packed and I m ready! Last time I saw her, I mentioned that we used to do weaving together, and she couldn t remember. That was a sure sign to me that things had taken a turn for the worse. Our last several visits have ended with a big hug, and her still iron grip on my hand, with her saying, Thank you for coming! My family is so good to me. We love each other! She s been battling infections and heart problems the past few weeks. This evening, I got an email from my mom saying It s time to say our goodbyes. She had been to see Grandma today, and Grandma still managed to tell her, We love each other. As much as time has changed her in the past few years, she s still there, the same loving Grandma as ever.

After spending a considerable amount of time releasing your Free Software project to the public, you will probably want to make sure that it reaches as many of the people it could be useful to as possible. Here are a few tips to get you started.
Homepage: Is this software for me?The first thing you will probably think about is to create a homepage promoting your project. There are a lot of good tips on how to create an effective homepage, but I will focus here on the contents that you should include.

Screenshots are one of the most important elements you can include on your homepage. First-time visitors will only spend a few seconds on your site before deciding whether or not the information is relevant to them. You need to be able to summarize in a few pictures what your project is all about.

Would you be willing to read long white papers or to go through long build instructions just to find out that this software isn't going to be useful to you after all? Probably not. Make sure you can help users figure this out in a few seconds, even if your software lacks a graphical user interface.

Of course you will also want to describe the project in a few words and provide links to the source code and other services you may have available.
Hosting ChoicesWhere to put your contents is somewhat of a personal choice but there are a few things to keep in mind.

First of all, depending on the size of your project and its related data, the hosting site should may need a significant amount of storage and bandwidth. Furthermore, you should check whether download statistics are collected by your hosting provider. While not strictly necessary, it can be very motivating to watch these numbers go up!

Free Software hosting sites like Google Code, Source Forge and LaunchPad also provide different services like bug trackers and source control repositories.

Some people prefer a distributed approach to source control and issue tracking to avoid trusting their master copy of the data to a third party. Setting up a separate code repository on sites like Github or Gitorious is an option to consider.

All of these hosting providers promote the software they host to varying degrees. Have a look around before deciding where you should park your project.
Announcing your ReleaseFinally, what would a website be without other sites linking to it? The obvious place to start would be the main search engines, but that in itself is unlikely to bring much traffic in the early days of your project.

Sites dedicated to Free Software are more likely to bring visitors to your shiny new project. The most famous place for Free Software release news is Freshmeat. Whether or not you visit this site regularly, you should know that its contents is widely read and syndicated and you should not pass on this great opportunity to let people know about your software.

Other directories that may be of interest include the Free Software Foundation Directory and Ohloh (especially if you offer a publicly available source code repository).

Now that the word is getting out, it's time to start thinking about supporting these new users!

GNOME 2.26 was released last week, and I couldn't help adding myself to the long list of celebrating posts in Planet GNOME. Looking at the release notes, it looks like this release adds a good number of very visible features, and also keeps improving on ongoing transitions like gvfs.

The Debian GNOME team is obviously not ignoring this fact and started to work very hard on updating GNOME for squeeze as soon as the lenny freeze was over. First, the new versions of GLib and GTK+ were uploaded to unstable, and managed to transition to testing very easily. The rest of GNOME 2.24 bits, which had been patiently waiting on experimental for months, has been uploaded with care not to disrupt any of the many transitions the Debian release team is currently dealing with. You can have a quick glance at how things are going in our 2.24 status page, but the summary is that most of GNOME 2.24 is in unstable, with a few notable exceptions which are held back by ongoing testing transitions. Namedly, evolution-data-server is trying to trickle into testing, which is in turn holding the final bits: gnome-panel, nautilus and related packages, but we think this will be over soon. As soon as GNOME 2.24 is safe in squeeze, we'll immediately turn our focus to the new GNOME 2.26 release. Our initial plan is to package the trivial bits and leaf packages which can't break stuff for unstable, and herd the more complex modules via experimental, to avoid breaking unstable at all. There are some exceptions; we plan to keep gnome-session 2.22 in unstable/testing until 2.26.1 is released to avoid getting a broken session saving in Debian. People might wonder why we insist on hitting what would seem a dead horse by first dealing with 2.24 and not 2.26 directly. The main reason is that these packages had been ready for a long time, and were in good shape to transition to testing quickly and with little pain. Preparing 2.26 directly would mean throwing away a lot of hours of packaging and polishing effort, and it's not like we're releasing squeeze any time soon anyway. Enjoy the hopefully not too bumpy road to 2.26!