First of all an introduction for the readers outside of Switzerland: Swisscom is a monopolistic organization which has the right to install DSL infrastructure in Switzerland and sells those line to the Wholesale-Customers (aka the “normal” providers).
Some weeks ago Swisscom increased the bandwidth for the business customers (aka myself for example) and since then my connection failed at least once per day. The only solution to fix that was resetting the whole ADSL modem which fits as a bridge to PPPoE and then restart the pppd after all. Since I’m not often at home but use the machines from remote over ssh to read mail, irc, debug dns stuff, test software on one of the public sid machines. So, my systems are totally unreliable.
I wrote a mail to my provider some weeks ago, didn’t really get e good feedback. When I called them by phone I was told that Swisscom reduced my bandwidth again and this should resolve the problem. Dear Swisscom, it still does _NOT_ work and I have several disconnects per day. I wanted to use my machines when I was at Debconf7 last week in Scotland, but at the time when I arrived at Teviot my line was down and I had to read my mail during this time via IMAP from the 2nd MX.
I also have the feeling that my provider doesn’t want to help me, nobody gave me instructions on how I could debug this better, they just gave me a formular to open a troubleticket itself and there I would need to subscribe that all costs have to be payed by myself what I can’t as a student. Ok, so I have a total unstable Internet connection and as it looks like I have to switch from ADSL to Cable internet in a few months, even if that also has big disadvantages.

I’m still figuring out whether Twitter is more than a distraction. It occurs to me that it has perhaps the three most important design elements for a successful new web-based (and particularly social-networking) technology:

1. Twitter works as a simple general-purpose tool with very little structure determining how, exactly, people are supposed to use it. Compare, for example, with the many social networking sites (Friendster, LinkedIn, Tribe.net, etc.), each of which have a fairly specific idea about how people should use it (dating, professonal networking, and, um, whatever they do on Tribe, respectively). The only limitations on how Twitter can be used are a few aspects that are defined by the medium — basically, messages short enough to fit into an unextended cell phone text message.
2. Twitter doesn’t duplicate any existing system or medium for communication. Compare, again, the social networking sites, each of which has some version of “email” that is internal to the site. Would I ever want to “send someone a message through LinkedIn” if I actually had their email address? Twitter, on the other hand, doesn’t have an exact one-to-one correspondence with any existing email, text messaging, or instant messaging systems. It’s a sui generis form of communication.
3. Twitter doesn’t require everyone to sign up to participate. Anyone can follow my Twitter feed without actually having their own Twitter account. This is essential to solving the “critical mass” problem. Of course there are benefits to establishing an account, but as far as I can tell, the only features that you don’t get without an account are those which necessarily would require an account. (Compare, again, most of the networking services mentioned above, where you need an account to view people’s profiles.)

(Add to this, of course, the now standard requirement that Twitter is free, at least as in beer.) Now, I’m still not exactly sure how best to use Twitter, but there are some interesting commercial and non-commercial applications featured on the Twitter blog, e.g, this promotion from Dell, and this guy “Twittering My Diabetes.”

Share This

So, I'm back from Holidays, to find we now have a new Government in Ireland. (An unexpected choice of government, of which more later.) We were camping in Fouesnant, in Brittany; Family & Friends might like to see the holiday snaps here). Camping in France went well. With three children aged 7, 4 and 2, there is only so much you can expect from a family holiday. Like it or not, you have to mind the toddler fairly consistently, and the older kids would like your full attention too. This is a holiday ''for'' the kids; plan also a break ''from'' the kids later (a long-weekend, with kids at grandparents, for example). This was our first time camping abroad, and its well recommended. While we went touring with a camper van with the two older children two years ago, this is different in that we were at the campsite for almost two weeks: the kids got to meet and play with others in a way they couldn't before. Also, there were good facilities at the site in Fouesnant, and the swimming pools in particular were appreciated (Caveat emptor though: there were no lifeguards or supervision. We went off-peak, and there were apparently two accidents in the time we were there: a broken kneecap and chin when people came down the slides too soon after others and collided). It was the first time the children (a) had pocket money to spend, and (b) were able to walk to a (campsite) shop to spend it. Lessons were learnt in the finiteness of pocket money, especially by Caoimhe . The weather was fairly good: two wet days (though not overly so, compared to what we're used to in Galway); enough to give the 'authentic camping experience'. And for the children especially, just warm enough. Long drives South were not an option with young kids, and we wanted to see Carnac and Brittany in general. We went touring to two places: Mont St. Michel, on the way down, Carnac, and locally around Quimper and Concarneau. At seven, Cormac is beginning to be old enough to enjoy this, but Sadhbh at 2 is too young, and easily aggravated. Caoimhe can appreciate some of it, such as the well recommended Breton museum in Quimper, seeing the local costumes and clothing is just her style at the moment. We're looking forward to going back when the kids are older, or we can enjoy touring on our own. The camp site is dominated by English / Dutch / Irish. It is still term-time in Britain and Ireland, which meant the children on the site was full of 2-4 year-olds, with a shortage of playmates for Cormac. Next time, synchronise with English school times, etc. We went during Cormacs term-time because it was much cheaper (1000 Euro) than high-season. If Cormac was having difficulty in school things would have been different, as it is, we had no qualms in doing so. Things will probably be different next year with Caoimhe also in school at the same time, and we would go later. Suffice it to say I think synchonisation of school timetables is a bad idea, as it has led to these huge price differentials and parents taking their kids from school. As a friend with experience of the French school system points out, they've spent the last 40 years desynchronising their timetables ... So would we go again, or buy our own tents, etc? possibly. The brochure for next year arrived already, with large discounts for booking early ... Tags holiday, family, france, brittany, cormac, coimhe, sadhbh

Web applications are in constant competition for a user's attention. Unlike shrink-wrap software, there's often no captive audience, and web apps must gently guide and woo users to help them to the best experience of the software. This is particularly true when considering the problem of collecting personal details from a user. Collect too little information, and your app might not be able to function effectively. Collect too much information, and you raise the barrier for participation with your application. Users may either not be bothered, be alarmed at the apparent intrusion into their privacy, or fill out bogus information.  One size doesn't fit all
I originally stumbled on the issue in the development of Expectnation. The amount of information a conference speaker needs to give the organizers is significantly more than that of, say, a reviewer. An organizer will often want postal and phone details for a speaker, which are largely irrelevant to the review process. All conferences and events rely on the willingess of participants, so the path to participation needs to be as frictionless as possible.
Thus, a one-size-fits-all personal details form didn't make sense for us. At best, we could have simply made more fields optional, but that would result in missing information that we really did need. Another solution would be to provide a dedicated personal details form per user type, e.g. different forms for speakers and reviewers. This is a non-starter, however, as users can take on many roles within a conference. So, we had a problem on our hands: different levels of interaction with our application requires different levels of personal information. We also had a second problem, which is that not all events and organizers want the same level of information. For example, a user group event is unlikely to need the same amount of information from speakers as an academic conference. Thus we have two axes on which the amount of information required varies: by role, and by event.  Our solution: progressive disclosure We concluded that we wanted to adhere to two principles in the collection of user information for Expectnation:

• collect as little information from users as possible, and
  
• allow organizers to determine the level of information they wish to collect.

The first objective was achieved by constructing a matrix of information items against user role, with the possible values of required, optional, unused for each item. We then achieved the second objective by allowing this matrix to be varied over each event. We've named this concept "progressive disclosure." What this means in practice is that a user is only ever asked for the information required to fulfil the roles they have within Expectnation. If they take on another role, they are asked for the additional information at that point, and not before. Implementation concerns
Extract from disclosure level editing UI It would be untrue to say that progressive disclosure is simple to implement. A user in our system will have disclosure requirements that are the union of all of their roles in all of the events they attend. Within Ruby on Rails, this means the conventional validation logic is useless to us, as it only deals with static requirements. Secondly, disclosure requirements are expensive to compute, so we need to cache them, with the inevitable addition of issues such as cache invalidation. Beyond the data model issues, the user interface issues are, if anything, more troublesome. From an end-user's point of view, the difficulty arises when we need extra information from them, and presenting this in a way that makes sense. From the event organizer's point of view, we have the challenge of presenting a controlling user interface for rather a complex concept. Organizers must be able to change the level of required information either globally, or per-event. We opted for a grid presentation, an extract from which is shown in the screenshot in this article. Over time we'll be able to see how effective this interface is, and what we can do to improve it. Finally, we have chosen sensible defaults for all disclosure levels, as the best result would be that organizers have little need to reconfigure the settings in the first place. Making it look easy Because Expectnation is a general application for organizing events, rather than targetting one specific one, we've had to construct a framework for minimizing user information collection, as opposed to simple implementation of known scenarios. At the end of the day we have added a fairly complicated subsystem and an extra degree of complexity to our codebase. However, the result from the user's point of view is increased simplicity and a streamlined experience. Every time you embark on something that wide-reaching and complex, you have to ask yourself whether the feature is really worth it. In this case, though, the answer is a resounding "yes". The user is the most important factor in our software, and making their life easier in an unobtrusive manner is a priority.

• Expectnation blog: Only ask users for the information you need

ept-cache related You finished wesnoth and you're looking for more?

$ ept-cache related wesnoth -t clean
wesnoth-editor - map editor for Wesnoth
wesnoth-server - multiplayer network server for Wesnoth
wesnoth-tsg - The South Guard official campaign for Wesnoth
wesnoth-ttb - A Tale of Two Brothers official campaign for Wesnoth
wesnoth-utbs - Under the Burning Suns official campaign for Wesnoth
asc - turn-based strategy game
attal - turn-based strategy game
xbattle - Concurrent multi-player battle strategy game
crimson - A hex-based tactical game
stratagus - realtime strategy game for Unix and X
fcmp - Free media files for FreeCraft
wormux - funny fight game on 2D maps
stratagus-gl - realtime strategy game for Unix and X - OpenGL version
boson - core package for Boson
netpanzer - online multiplayer tactical warfare game

You're looking for a package sort of like mutt and firefox?

$ ept-cache related mutt firefox -t clean
mozilla-thunderbird - Transition package for icedove rename
balsa - An e-mail client for GNOME
mozilla-mailnews - Transition package for Iceape Mail & Newsgroups and Address Book
mozilla-thunderbird-dev - Transition package for icedove-dev rename
mozilla-thunderbird-enigmail - Transition package for enigmail rename
mozilla-thunderbird-inspector - Transition package for icedove-inspector rename
firefox-gnome-support - Transition package for iceweasel rename
mozilla-firefox-gnome-support - Transition package for iceweasel rename
mozilla-thunderbird-typeaheadfind - Transition package for icedove-typeaheadfind rename
firefox-dom-inspector - Transition package for iceweasel rename
etpan-ng - console mail user agent based on libEtPan!
firefox-webdeveloper - Transition package for iceweasel rename
firefox-greasemonkey - Transition package for iceweasel rename
tkrat - Mail user agent with POP, IMAP, mh support using Tk
thunderbird - Transition package for icedove rename

All of this in ept-cache 0.5.7 uploaded tonight to unstable. Remember to ept-cache reindex after upgrades, as the indexing algorithm sometimes improves. With 0.5.7, for example, it generates an index which is something like 66% smaller than the previous versions.

I’m currently developing In Your Face, a free software 3d basketball game. I have reached the moment to create an scripting interface to be able to script cool AI’s. After having a look at LuaBind and Boost::Python I’ve decided to go with QtScript. I’m quite happy with it, but I’m facing an issue that I’m having problems to figure out. I’ll probably send it to Qt Interest, but I’ll try to explain it here too to see if I get an answer. I have a whole hierarchy of classes that I want to export. The base class is Action::Base, and there are plenty of other actions, like Action::MoveTo or Action::Shoot. I’m (almost) already able to do stuff like this from JavaScript:

function enter()
  var teamPlay = new TeamPlay();
  var al = new ActionList();
  var mta = new MoveToAction(0,10);
  al.append(mta);
  teamPlay.insert(0,al);
  state.setTeamPlay(teamPlay);
  state.setChanged();

Everything works fine except the “append” call. “append” takes a pointer to the abstract class Action::Base. If I invoke it with a MoveToAction object, I get an “incompatible types” error. I have tried adding a toAction() method to MoveToAction which returned a QScriptValue-wrapped Action::Base *, but I’m still getting the same error. Anyone has a QtScript example where something like this is done?

Using tags to enhance a keyword search A pet problem of mine to solve is that when you do a keyword search for "image editor", gimp does not show up. This is indeed because the description of gimp does not include the word "editor". And if you are a gimp developer, please don't change this otherwise I don't have a good example to point at anymore. Now that I have a Xapian engine in ept-cache, I already managed to make gimp actually appear somewhere in the search results through approximated matches. But I know one can do better: debtags is very good in providing data that brings gimp back to the world of image editors. So, how can one use tags to improve the xapian results? Today the Xapian developers told me. I've implemented it in ept-cache 0.5.6, that I've just uploaded to unstable. After you install it, do an ept-cache reindex to rebuild the index with debtags in it. The system is very clever: here is how it works. First you prepare the query as usual: tokenize, stem and so on:

// This is the nice ept interface to Xapian
TextSearch textsearch;
Xapian::Enquire enquire(textsearch);
// Set up the base query
Xapian::Query query = textsearch.makeORQuery(keywords.begin(), keywords.end());
enquire.set_query(query);
// Get a set of tag-based tokens that can be used to expand the query
vector<string> expand = textsearch.expand(enquire);
// Build the expanded query
Xapian::Query expansion(Xapian::Query::OP_OR, expand.begin(), expand.end());
enquire.set_query(Xapian::Query(Xapian::Query::OP_OR, query, expansion));
// Get the results as usual
    Xapian::MSet matches = enquire.get_mset(pos, 20);
for (Xapian::MSetIterator i = matches.begin(); i != matches.end(); ++i)
    ...

And this is how you build the expanded query:

// This functor filters out all tokens that are not tags
// (tags are indexed with a 'T' prefix)
struct TagFilter : public Xapian::ExpandDecider
 
    virtual bool operator()(const std::string &term) const   return term[0] == 'T';  
 ;
static TagFilter tagFilter;
vector<string> TextSearch::expand(Xapian::Enquire& enq) const
 
    // A Xapian RSet is a list of keywords that can be used to 'expand'
    // the search to show more documents like a set of given ones
    Xapian::RSet rset;
    // Select the top 5 result documents as the 'good ones' to
    // use to expand the search
    Xapian::MSet mset = enq.get_mset(0, 5);
    for (Xapian::MSet::iterator i = mset.begin(); i != mset.end(); ++i)
        rset.add_document(i);
    // Get the expansion terms, but only those that are tags
    Xapian::ESet eset = enq.get_eset(5, rset, &tagFilter);
    vector<string> res;
    for (Xapian::ESetIterator i = eset.begin(); i != eset.end(); ++i)
        res.push_back(*i);
    // Pass the tags to the caller, who will OR them to their
    normal keyword search
    return res;
 

For the last couple of months, both at the Ubuntu Developer Summit in Mountain View and on the #upstart IRC channel, we’ve been discussing the changes we want to make to upstart for the Feisty Fawn release of Ubuntu. This will ship with a version of upstart based on the 0.3 series (it may end up getting called 0.5 before release); the primary goal for this are to have an init system that is suitable for general standalone list in any Linux distribution. I’ll be giving a talk at linux.conf.au 2007 in Sydney with that aim, I hope to persuade at least one other major Linux distribution that it’s the right solution. A complete list of the specifications and bugs being targeted for the 0.3 release can be found in Launchpad. The rest of this post will introduce some of the shiniest new things. Writing Jobs Upstart takes care of starting, supervising and stopping daemons itself; unlike in the init script system where you have to write code to do that yourself, often using a helper like start-stop-daemon. All you need to is give the path to, and arguments for, the binary you wish to be started.

exec /usr/bin/dbus-daemon

Some jobs, especially quick tasks, will usually be written as shell scripts. To save having to write a separate file and invoke it, you can include shell script code directly in the job file instead of using the exec stanza.

script
    echo /usr/share/apport/apport > /proc/sys/kernel/crashdump-helper
end script

Usually it’s not sufficient to just start a binary and wish it well; you frequently need something to be run before it is started to prepare the system, and sometimes something after it terminates to clean up again. For these purposes, additional snippets of shell code can be given – to be run before the binary is started, and after it has finished. Unlike init scripts, these do not need to start or stop the daemon itself; that’s done automatically based on the exec stanza.

pre-start script
    mkdir -p /var/run/dbus
    chown messagebus:messagebus /var/run/dbus
end script
post-stop script
    rm -f /var/run/dbus/pid
end script

For consistency, executables may be specified with pre-start exec and post-start exec instead of shell scripts as above. It’s sometimes useful to be able to run something after the binary has been started; for example, you may wish to attempt to connect to the daemon to determine whether it is ready to serve requests. post-start script or post-start exec can be used to this.

post-start script
    # wait for listen on port 80
    while ! nc -q0 localhost 80 </dev/null >/dev/null 2>&1; do
        sleep 1;
    done
end script

It’s also useful to be able to notify a daemon that it may be about to be stopped, or delay it for a while. pre-stop script or pre-stop exec can be used for this.

pre-stop script
    # disable the queue, wait for it to become empty
    fooctl disable
    while fooq >/dev/null; do
        sleep 1
    done
end script

Events Events are now quite a bit more detailed than in previous versions; they’re still named with simple strings that are up to the system sending the event, but they can now include arguments and environment variables which are passed through to jobs being started or stopped as a result.

initctl emit network-interface-up eth0 -DIFADDR=00:11:D8:98:1B:37

This command will now output all of the effects of this event, and will not terminate until the event has been fully handled inside upstart. Events such as the above can be used by jobs that examine the event arguments and environment within their script:

start on network-interface-up
script
    [ $1 = lo ] && exit 0
    grep -q $IFADDR /etc/network/blacklist && exit 0
    # etc.
 end script

or matched directly in the start on and stop on stanzas:

start on block-device-added sda*

The events generated by job state changes have also changed. Previously both jobs and events shared the same namespace, which not only caused confusion but actually caused some problems when one accidentally named a job after an event. The two primary events generated are now simply called started and stopped; they inform you that a job is fully up and running, or fully shut down again. The name of the job is received as an argument to this event.

start on started dbus

The started event is not emitted until the post-start task (described above) has finished; so the post-start task can delay other jobs from starting because they can’t yet connect to the daemon. Likewise the stopped event is not emitted until after the post-stop task has finished. The other two events emitted by a job are special; they are the starting and stopping events. The reason they are special is that the job is not permitted to start or stop until the event has been handled. This means that if you have a task to perform when your database server is stopped, but before it’s actually terminated, it’s as simple as:

start on stopping mysql
exec /usr/bin/backup-db.py

MySQL won’t be terminated until the backup has finished. This is especially useful for daemons that depend on each other, for example HAL needs DBUS, it shouldn’t be started until DBUS is running and DBUS should not be stopped until HAL has been terminated. All the HAL job needs is:

start on started dbus
stop on stopping dbus

Likewise if tomcat is installed, Apache should not be started until tomcat is running; and tomcat should not be stopped until apache has been terminated. All the tomcat job needs is:

start on starting apache
stop on stopped apache

Failure Nothing goes smoothly all of the time, sometimes tasks the job runs will fail, or the daemon itself will die. As well as providing the ability for a crashed daemon to be automatically restarted, upstart ensured that other jobs are notified with a special failed argument to the stopping and stopped events.

start on stopped typo failed
script
    echo "typo failed again :-("   mail -s "typo failed" root
end script

And if any job started or stopped by an event fails, it’s possible to discover that the event itself failed.

start on network-interface-up/failed

States While tasks such as configuring a network interface, or checking and mounting a block device are usually performed as a result of events; services are more complicated. Services normally need to be running while the system is in a certain state, not just when a particular event occurs. Therefore upstart allows you to describe arbitrarily complex system states by referring to events that define their changes. For example, many services should be running only while the filesystem is mounted, and at least one network device is up. We have events to indicate the changes into and out of these dates, we just need to combine them:

from fhs-filesystem-mounted until fhs-filesystem-unmounted
and from network-up until network-down

The until operator defines a period between two events, the and operator ensures we’re within both of these periods. Perhaps we need to be running while any display manager is:

from started gdm until stopping gdm
or started kdm until stopping kdm

Or maybe we only want to be run if a network interface comes up before bind9 has been started:

on network-interface-up and from startup until started bind9

These “complex event configurations” can appear in any job file; and any job file itself can serve as a reference for other jobs. They will be started and stopped at the same time as the named job:

with apache

Omitting the exec or script stanza from a job file means that it simply defines a state that can serve as a reference for others. As such, the multiuser state is simply a job file that defines it. As an added bonus, these states can still have pre-start, post-stop, etc. scripts.

There are many articles on the Interwobble telling you how to set the process title on Linux; they all concentrate on the problem of placing an arbitrarily long string in argv[0] to report status information in the process list. But what if argv[0] is fine, and what you want to do is remove the following arguments from the process list? Perhaps they contain sensitive information, or perhaps they’re just likely to be surprising. A fictional example may look like this (I’ve added the $ to demonstrate a later problem):

11234 ?        S      0:00 some-program --username=foo --passphrase=bar$

How not to do it The first thing you’ll probably try is just setting those arguments in the argv list to NULL. For example, with code like this:

for (i = 1; i < argc; i++)
    argv[i] = NULL;

That won’t work because that array is just a list of pointers to the real area in which the arguments are stored, and is local to your main function. Modifying it has no effect what ps and similar see. The next thing you might try, as a C programmer, is setting the first character of each argument to a NULL byte. It’s not unreasonable to assume that these strings are likely to be NULL-terminated. You might use code like:

for (i = 1; i < argc; i++)
    strcpy (argv[i], "");

But that doesn’t seem to work either, in fact, what you get in the process list is something rather odd and unexpected!

    11234 ?        S      0:00 some-program  -username=foo  -passphrase=bar$

All that’s done is lost the first character of each argument. In frustration, you might try overwriting the entire argument with NULL bytes, e.g.

for (i = 1; i < argc; i++)
    memset (argv[i], '\0', strlen (argv[i]));

Checking the process list, that will have seemed to have worked…

    11234 ?        S      0:00 some-program                                $

On closer inspection though, it’s not perfect. You’ll notice that the line ends with spaces in place of where the arguments used to be. If the number or length of arguments you’re trying to hide is particularly long, you can end up with strange blank lines in ps output. Not ideal. Why this happens To understand why this happens, we need to understand how the kernel reports the command line to ps. ps reads the /proc/PID/cmdline file, with contains the entire command line as a single character array, with each argument terminated by a NULL byte. Looking at it with od -t c, we see something like:

0000000   s   o   m   e   -   p   r   o   g   r   a   m  \0   -   -   u
0000020   s   e   r   n   a   m   e   =   f   o   o  \0   -   -   p   a
0000040   s   s   p   h   r   a   s   e   =   b   a   r  \0

When we changed just the first character to a NULL byte, we ended up with:

0000000   s   o   m   e   -   p   r   o   g   r   a   m  \0  \0   -   u
0000020   s   e   r   n   a   m   e   =   f   o   o  \0  \0   -   p   a
0000040   s   s   p   h   r   a   s   e   =   b   a   r  \0

ps is just assuming that \0 represents any argument gap, so outputs an ordinary space character every time it encounters one. This is why the first character of each argument appeared to be replaced by a space, and the rest were still printed. When we overwrite the arguments, we ended up with:

0000000   s   o   m   e   -   p   r   o   g   r   a   m  \0  \0  \0  \0
0000020  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
0000040  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0

Writing all those zeros didn’t change the length of the command line character array, so ps got all those NULLs and output a space character for each one, assuming it was an argument break. What we need to is decrease the length of this character array, so ps only sees the first argument. How to do it The kernel maintains internal pointers to the start and end of the arguments array in the process address space. When you ask for the cmdline file in /proc, it replies with all of the characters between these two positions and a length of the difference. The kernel doesn’t provide us with any method of moving this pointer, so we’d initially appear to be stuck. However there turns out to be a very nasty solution. In order to support processes changing their title, the kernel has to support the arguments possibly overrunning into the environment space. If it thinks this has happened, it concatenates the environment space onto the end of the buffer and returns the entire area with the length set to the length up to the first NULL byte. All we need to do is fool the kernel into thinking we’ve overrun into the environment space, it’ll then just call strlen on the arguments list and return only the first argument; exactly what we want! What technique does the kernel use for deciding whether or not the arguments have overrun into the environment space? It checks whether the final character in the argument space is NULL or not. Thus paradoxically, to hide the argument list from ps, we remove the NULL …

if (argc > 1)  
    char *arg_end;
    arg_end = argv[argc-1] + strlen (argv[argc-1]);
    *arg_end = ' ';
 

The check against argc is necessary, as we don’t want to remove the NULL character on the end of argv[0] as that would cause the first environment variable to be inadvertently concatenated. Now when we look at ps, we see just the program name:

    11234 ?        S      0:00 some-program$

And even when we look in /proc/PID/cmdline, we only see the program name and no additional arguments.

0000000   s   o   m   e   -   p   r   o   g   r   a   m  \0

One of my pet dislikes are those people that pay lip-service to a particular problem, such as Accessibility, Internationalisation or Usability, without actually thinking about them. My favourite example can be found at the Trafford Centre in Manchester, England. Somebody there has clearly realised that accessibility is a problem, and ensured that every single sign has Braille added to it so that partially-sighted or blind people are able to read what they say. They’ve only been paying lip-service to the problem though, and not thinking about it. The evidence? The following sign, mounted directly on a door, with Braille on it: Do not stand directly in front of this door.

Just prior to the “State of the Coffee Cup” talk on Sunday, Tom Marble sent a quick invitation to Steve Langasek, Sam Hocevar and myself to have a chat with Simon Phipps about the CDDL and some of the concerns that have been raised on the debian-legal list lately – particularly about choice of venue. Unfortunately in the ten or fifteen minutes between the mail and the meeting, we couldn’t find Sam, but we managed to grab Don Armstrong to join in instead. It’s a couple of days later, and I’m going from memory, not notes, so this is paraphrasing. Simon’s primary concern was one of predictability – Debian accepted the Mozilla Public License back when it was released (and prior to Mozilla and other software tending to get dual licensed under the GPLv2) which is what the CDDL was based on and contains almost the exact same terms. Simon’s comment was that if you’ve accepted that then, reviewing new licenses from scratch and coming up with different results really makes it hard to work with you, and worse makes it look like you’re basing your conclusions more on who proposed the license rather than what the license actually says. Don and Steve seemed to mostly appreciate that point, but still thought that choice of venue was harmful and unnecessary, and that it’d be nice if Sun – as pretty much the primary organisation currently behind any of these licenses – would take some steps to reduce that harm: limiting choice of venue to when both parties in a dispute are multinational, for example. Simon’s concern there was that updating the CDDL would require a lot of effort internally – getting buy in from all the groups in Sun using the CDDL, as well as getting the wording changes approved from the appropriate legal advisors, and convincing the lawyers of Sun’s commercial partners that the changes weren’t going to be a problem later; and committing to all that work when a new versions of the GPL is about to be released and it might be a better thing to work on getting the relevant software available under that, or even the GPLv2. On the other hand, Simon thought that making (binding) statements about Sun’s interpretation of the license seemed to (eventually) work reasonably well for the DLJ, so might be something that can be done again for this issue. And while that only counts for Sun, we can fairly easily ask if other authors of CDDLed stuff agree with Sun’s interpretation for their software, and only worry about possible problems if it turns out they don’t. That’s pretty much where we ended up I think, with Simon suggesting that we work out what exactly needs to be clarified with Tom, and then get it passed back up to Simon to get signed-off on. And hopefully that’s what’ll happen over the next little while. :) (The somewhat more interesting question of whether we can combine CDDL’ed OpenSolaris (in particular Solaris libc) with GPLed userspace tools such as dpkg to produce a Debian OpenSolaris distro is still up in the air – Sam’s currently waiting on a response from the FSF legal team on one of the questions that concerns Debian, aiui; but they’re currently flat out working on GPLv3 as you might imagine. Oh well – in the meantime, there’s always Nexenta!)

Since I'm not at Debconf, I've been filling in time in the early mornings by randomly browsing Facebook. Chris Lamb had a post on a function called fnreduce, which clearly wandered past on planet when I was away. Since I was bored, I wrote a simple haskell version:

fnreduce :: [(a->a)]->a->a
fnreduce [] value = value
fnreduce (a:as) value = freduce as $ a value

Line by line, its clear how it works. The first line is the type sig, which says that the function fnreduce takes a list of functions, and a value of type a, and a gives back a value of type a. The functions all need to be of the type a->a, which means they take a a and give back a a. a is a type varible, which means it can be replaced with any type you feel like, for example: Int or String. The second line merely defines a base case, which says that if the list of functions is empty, it just returns the value given. The last line does all the work, and says that fnreduce on a non-empty list is computed by taking the first element of the list, computing the new value using it, then calling fnreduce on the rest of the list and the new value. This is how most list processing works in haskell. I'm left with two quick questions: the first is how to define it in terms of a fold, which it clearly is. The second is how to escape the a->a resriction, which lamby's can do. Since I'm writing haskell, I'ld like to do this in a type safe way, to have my cake and eat it too. This cant be done with haskell's type system, but I may run it past Edwin for his two cents if I remember...

IPMI stands for "Intelligent Platform Management Interface", an interesting feature deployed on nowadays servers. I can't forget that question I made some months ago about an extra ethernet port on the IBM server machines we were working with on those days. The answer was quite simple: it is almost of no use at all; at most you can get some stats and diagnostics but it is mainly intended for hardware technicians.

Liars (or ignorants)! Anyway, it is quite useful. It is the IPMI port which can be used for several managements actions (even from the running system) such as power cycle the machine, get some stats, establish a watchdog interface and the like.

Uses?, are they need to be told?. As a first glance you can get reports about the machine from the operating system itself without the need of physical access to the datacenter. You can also restart a machine which is failing to reboot by itself in case you can login one more time in the system. But... even more, you can do all that (and more) from a remote system (don't exhitate, it is password protected, at least, in case you configure it so). So the next obvious uses are for cluster fencing and stonith (shot the other node in the head) without the need of power control hardware.

It is a pity we didn't knew that when we configured the SAP cluster in my previous job despite the serial cable almost did it work. Sure Mr Navas will be interested in knowing about this technology :-)

Oh, a simple example:

# ipmitool -I open chassis status
System Power : on
Power Overload : false
Power Interlock : inactive
Main Power Fault : false
Power Control Fault : false
Power Restore Policy : always-off
Last Power Event :
Chassis Intrusion : inactive
Front-Panel Lockout : inactive
Drive Fault : false
Cooling/Fan Fault : false
Sleep Button Disable : not allowed
Diag Button Disable : allowed
Reset Button Disable : not allowed
Power Button Disable : allowed
Sleep Button Disabled: false
Diag Button Disabled : true
Reset Button Disabled: false
Power Button Disabled: true

Another one:

ipmitool -I open chassis power reset

Ooooooops. Next post after crash :-)

A question that people often ask about wind power (and was asked in the comments section of my previous post) is what can be done when the wind speed decreases in an area. There are several methods that can be used to address this problem. The easiest option is to simply have wind farms spread out over a large area and interconnects that can spread the load. This greatly reduces the problems but is not a total solution. The next step is to have a series of power plants that can quickly ramp up supply to meet the demand. One good option for this is gas-fired power plants, while they aren’t ideal for the environment they are cheap to build and can react quickly to changing demand. If a gas fired plant is only used when wind speeds are low it should on average be running at a small fraction of it’s peak capacity and use little fuel. Another good option is hydro-electric power which can be turned on quickly, which doesn’t produce any CO2 emissions and is already used widely (about 10% of Australia’s electricity is provided by hydro-electric power). The ideal solution is to have every user of grid power know when the electricity is cheap (when there is a surplus of wind power) and when it’s expensive (when gas or hydro power is being used). Then non-critical services can be run when electricity is cheap. For example you could put clothes in your washing machine and program it to start the wash when electricity becomes cheap, some time during the day there will be a cheap time and the washing will get done. Once consumers know when electricity is cheap (via X10 or similar technology) they can use that information to determine when to use electricity generated from photo-voltaic cells on their roof and when to use grid power. The same technology can be used for heating and cooling of your home or office, turning off the A/C for an hour or so is only going to be a problem in the middle of summer or winter, for most of the year any heating or cooling could be done with cheap electricity. These technologies are all being developed at the moment (I once briefly worked on a system that could be used as a pre-cursor to managing home electricity use for times of cheap electricity).

Share This

# foo=bar
# name=foo
# echo $ !name
bar The above example shows how to make a bash environment variable reference the value of another. # echo $ !f*
foo fs_abc_opts fs_name The above example shows how to get a list of all variables beginning with “f” (NB the wildcard can only go at the end).

Share This

Right, so as announced I finished my thesis this week. Its translated title is (if anyone want to know)

"Design and Implementation of a Model for the Retrieval of Free/Libre Open Source Software using a Case-Based Reasoning System".

Writing it certainly was an educational experience but I am still happy it's done now. Especially the last weeks where rather unfunny, more so since about ten days before my deadline we had a massive heat wave here in Lower Saxony. Now that it's done I am still waiting for enthusiam to kick in. So far weariness still prevails. Maybe also because finishing my thesis does not yet end my studies. We also have to do written and oral examinations which will take place in July and after. So at the moment I spend my days mostly sleeping and trying to muster up enough wanderlust for my trip to DebConf7. (At the moment the prospect of traveling long distance with trains and cheap flights and then be surrounded by a few hundred happy people is still rather daunting.) Anyway, in order to give an impression of my last weeks and months and to sum this all up, a list of random notes, taken during the last weeks, of what I learned while writing my thesis:

• 6 months are NOT a long time!
• 10.000 chars are not enough to model a Debian package description
• 50 chars are not enough to model a Debian package name (YES, THAT MEANS YOU, libmaypole-plugin-authentication-usersessioncookie-perl!)
• osi.org does not belong to the Open Source Initiative but to Ontario Swine Improvement (Ontario Swine Improvement (OSI) is an industry-run organization dedicated to providing swine improvement and genetic products, programs, information and expertise. Our goal is to help Ontario pork producers achieve competitive advantages and excellence in the global market place.)
• I must not procrastinate.
  Procrastination is the mind-killer.
  Procrastination is the little-death that brings total obliteration.
  I will face my thesis.
  I will permit it to pass over me and through me.
  And when it has gone past I will turn the inner eye to see its path.
  Where the thesis has gone there will be nothing.
  Only I will remain.
• Dr.-Ing. Roland Bless rules! (So does his LaTeX class for theses.)
• Working without internet is possible. It is even better than working with internet. Simply leave gaps where you need to look up stuff and fill them in in the evening.
• Losing half a litre of blood does not impair my fitness for (brain) work.
• Working with version control requires a minimum of intelligence attention. Unfortunately mostly so when ending work (dead tired) and when beginning to work (dead tired).
• Side effects: Insomnia, itchy area on left leg, belly aches, little blisters on the sides of my fingers, headaches, slight but constant petulance.
• "I know what I want to say, getting it on paper is the least work." - WROOOONG!
• German is such a crappy language to write scientific texts in. Special greetings to the generic masculine. Gah!
• When the cat's writing her thesis ...
  The fun time's over now, darling ;)
• "I have don't really like proof-reading your thesis in PDF, can't you just send me the Word file?" is not what you want to hear from your proof reader.
• Good: Debian, vim, subversion, LaTeX, bibtex, evince, xpdf, pdftk, PostgreSQL, OpenOffice.org, dia, gimp, phpESP, tea, coffee, ramen, chocolate, electric fan, eating at the uni's cafeteria twince a day, raw cornflakes straight from the box, frida (my trusty laptop), power naps, pizza, people understanding my true problems, the freedom to burry myself in my work and absolutely and utterly neglect anything else until I am finished.
• The flat can look worse. Much!
• Bad:
  • The FSIL (student council for teaching students) belt grinding(!) tables on the balcony in front of the students' working rooms.
  • People trying to be nice and asking how it's going with the thesis.
  • Fellow students greeting me with "Hey still here?"
  • Our evil DPL blogging about his highly addictive monsterz just when I got to work.
• I'll do it after I handed in the thesis.
• I'll see a doctor about it after I handed in the thesis ...
• I should commit much more often (svn that is)
• How come there are so many extra 'i's in your thesis?" Because it's Linux!
• Sense of time is overrated.
• Print shop guy is mean.
  A = Me, overtired, having formatted and doing last changes to this document the whole night through and on until 20 minutes before the printing appointment.
  B = Print shop guy
  
  B: You know that's not A4 ...
  A: WHAT?!
  B: Yea, it's too big.
  A: WHAT?! But, but, I ... That can't be!
  B: I'm telling you, it's too big. See, 0.3mm too long and 0.12mm too wide
  A: ... *death stare*
  
  
• The examination office is now located in the fourth floor in the building next to the post office at the Hindenburgplatz.
• Tolimar is the most patient and understand guy I've ever known.
  Thank you!
• 6 months are SUCH a long time!

Chat with bubulle These are a few notes from a chat with Bubulle about package descriptions. Check a description against keywords To see what packages would match certain keywords, and how:

ept-cache dumpavail keyword1 keyword2   grep-dctrl -sPackage,Search-Score .

To check how much a package would match certain keywords:

#!/bin/sh
PACKAGE=$1
shift
ept-cache dumpavail "$@"   grep-dctrl -sSearch-Score -FPackage -X $PACKAGE

Technical details in the descriptions The programming language used to implement the software and the X UI toolit used by the software can also be removed from descriptions: Debtags offer a better place to store this information, and most package managers now show tags together with the package description. Submitting descriptions for review Submitting descriptions for review to the Smith Review Project means posting them to the publicly archived debian-l10n-english mailing list, and that may turn off some. It would also be interesting to change the description template generated by debhelper to mention the Smith Review Project and a link to description guidelines Description guidelines There are various description guidelines that could use consolidation and eventually inclusion in the Developers Reference. For example, Writing package descriptions is a very good guide, but most of the unsolved issues at the end have actually now been solved by the Smith Review Project.

While I already have some experience in explaining this Debian thingy to people, who are more or less familiar with Linux and free software, next week I have a special job: Explain Debian -- and how free software projects work -- to people, who aren't familiar with that. It's a university course, which just learned the boring theory. Licence work, a bit of history, etc. A complete different audience than I used to speak to: So far all but one of my talks where with people who visited my talk because they were interested in the topic... some came even, just because they like my talks! I'm not yet sure, how to handle that. Beside the difficult audience (which might be even more difficult, because it's rather hot here), it might be further complicated by the techniques: It's a kind of shared course, a cooperation of the University of Hildesheim and the University of Saarland; slides are transmitted via vnc, audio and video are transmitted in both ways via a software I haven't seen before; half of the audience here half there... and if you ever visited one of my talks, you might know, that I'm a walker type of guy: I run around, gesticulate, point things out on my slides, sometimes I even go right into the audience and talk to people directly. And now I can't really do this, urg. But all that's solvable, the main questions remains: How do you explain how Debian works, what Debian is, to people who just learned about the four freedoms? I was asked to aus dem N hk stchen plaudern. That's a German idiom; don't know how to translate that. In this case it means more or less that they would like to hear stories, not see organigrams. Well... so far my Idea is to reuse some of my old slides from an old talk¹ and add some nice examples, showing the see the need, solve the problem approach. Perhaps I'll use reportbug-ng and debtags as examples. If you have any ideas, better examples: Feel free to mail me. Would be perfect if I could get your ideas before Monday. Thanks. 1: Note to myself: I really need to sort my talks page out.

After asking for testers of a libacpi snapshot I got a fair amount of test mails. Thanks to all the people who tried it and helped me!!

Now I finished with coding, testing and documenting everything and happy to release version 0.1 of libacpi.

It is a general purpose shared library for programs gathering ACPI information. It fully implements information about fans, batteries, ac states and thermal zones (apart from trap points).

Try it out on: http://www.ngolde.de/download/libacpi-0.1.tar.gz.

There is also an online documentation (well doxygen generated) on http://www.ngolde.de/libacpi/doc/html/.
test-libacpi.c is an example on how to write programs using libacpi.

For more information download the tarball, have a look into the manual, test-libacpi.c, README and the doxygen documentation.

The next step for me is to port yacpi to libacpi which was also the reason for libacpi since I first wanted to rewrite it and thought it might be useful to have the functionality in a library. There are not yet Debian packages for it because I am really busy at the moment so if you want to maintain it, feel free to do so.

Yesterday and today, I've spent most of the time sitting next to Dami n Viano (des), feeling 1337 because we are doing exactly the heavily recommended pair-programming thingy with a Rails application that everybody in Debconf is familiar with: We are adding some stuff for our beloved video-team in Pentabarf! Now, Pentabarf is -as we were trying to explain earlier on, amidst angst and frustration- a strange beast: It looks like your regular Rails app. It smells like Rails. But it tastes like Java.
For some reason, the Pentabarf author (who I sincerely expect to meet soon - yes, he is coming to Debconf as well!) decided not to use Rails' killer app part, the one which has got most interested people into the whole framework, ActiveRecord. For all of the object-relation mapping needs, uses something called Momomoto.
To its defence, Momomoto is a lightweight library. This has the great advantage that, although it completely lacks documentation, its source code is very easy to follow, and it takes just a couple of hours (and forehead-wall bangs) - Much unlike ActiveRecord. But on the down side, as lightweight as the library is, the model it uses is completely suboptimal for many of our (so far really simple) uses. We have a simple view, for example, that runs in at least On^3 (measured in independent DB queries, of course). Going through a different model, it could at least be cut to a much nicer On^2.
Anyway... I'm relieved. The extension the video guys wanted is not that large, and it's mostly done. It is surely showable by tonight's meeting (modulo a couple missing bits, of course, but it's just bits), and will be ready no matter what by tomorrow. I'm just sorry I had to throw des aside, as pair-programming for two days in a row for the best portion of the day is not good for sanity.
Well, neither coming to Debconf is, so whattheheck... ;-) At least I could get a bit of my mail and RL work backlog processed.