Tuesday August 31, 2004

Cycling as a metaphor for Software Development

It has been brought to my attention that my postings to date on this blog are entirely too factual and completely lacking in opinion and speculation. In fact things are so bad that if I was to post one more useful or factual article the usability of the internet would cross a "utility event horizon". Beyond this point the proportion of the internet which is accurate or useful is dangerously high¹, so high that people may actually have to believe what they read. I'm certain that's not an outcome any of us would like. I'm taking action to prevent this by publishing this whimsical piece of complete nonsense which I dreamed up when riding my bike earlier today.

Cycling is like developing software. Especially where I live, since I live in a valley surrounded by nasty, steep hills (the Pennines) and the prevailing winds are in my face. If you think about it, when you start a new project, the tasks you have to complete are like these hills. The nasty winds represent the opinions of other parties, often colleagues, who can't resist letting you know what a complete waste of time your project is.

If you can summon the enthusiasm to mount your bike and start to go up your hill, i.e. start your project, you'll soon find that hills and wind are only a small part of the challenges you'll need to overcome. Soon you'll notice the potholes in the road, designed to shake your teeth loose and permanently damage your expensive cycle. These represent the bugs and design flaws which you will inevitably encounter as you begin to convert your vision of a perfect piece of software into a imperfect reality. Of course, it's better to encounter these bugs when going uphill, since it's easier to avoid them now and there's even a chance they might be filled in before you begin your descent.

As you weave slowly up the hill, dodging the potholes and labouring in the wind, another obstacle presents itself: the maniac driving the white van. Inevitably an overweight, shaven headed yob who has no idea how much space he should leave between the side of his van and yourself. I think that this best represents competing projects from within your own organisation or from other vendors. They know their project will fix all that is wrong in the world, who needs your pathetic contribution? Best just to to smear it all over the road now before it can reach the top of the hill.

Next we have to understand the "false dawn". Often, when cycling uphill in unknown terrain, you will think you are close to the top of the hill only to find that when you cycle a little further there are still many miles to go before your reach the real crest of the hill. I'm sure that all software developers will have experienced this feeling: will the project never end?

If you are lucky you'll get to the top of the hill. Now it's time to cycle back home. This represents the completion of development on the project. You'll notice that the potholes are a lot more perilous now because you are going so fast. Just like the bugs and design flaws, almost certainly more painful when discovered by customers than when you or your colleagues find them.

There you have it. Cycling is the perfect metaphor for software development and I'm sure that we can all learn something from this thought.

There are many of features of cycling which I'm sure provide opportunities for comparison with software development, e.g. the weather, your equipment, etc... Feel free to comment if you want to extend the comparision or if you think I'm wrong. Just don't make your comments informative or useful.

¹ I'm not sure exactly what this figure is but I suspect it's something like 0.00000000000000000000000000000000000001 % (2004-08-31 10:32:31.0) Permalink Comments [3]

Monday August 09, 2004

Using poolbind to execute jobs in different pools

You are lazy. Of course you are, it's a virtue when applied to computing. You don't want to type reams of instructions and check to see if commands succeeded or failed. No way, that's just too time consuming. Joe Salaryman can waste his time doing that, but you've got better things to do.

In that case, here's a minimal script which wraps poolbind(1M) to make it easier to run a process in a particular pool. For example, let's say that I wanted to run ls(1) in pool "listings".

[1]
bash-2.05b$ newpool
usage: newpool <pool name> <command> [parameters]
[2]
bash-2.05b$ newpool listings ls
poolbind: binding pid 100964 to pool 'listings': Not owner
Bind operation failed
[3]
bash-2.05b$ su -
Password:
Sun Microsystems Inc.   SunOS 5.10      s10_63  Jul. 03, 2004
SunOS Internal Development: gk 2004-07-03 [on10_63]
bfu'ed from /bfu/s10_63 on 2004-07-22
Sun Microsystems Inc.   SunOS 5.10      s10_37  May 2004
You have mail.
# bash
[4]
bash-2.05b#  newpool listings ls
backup         bin            Documents      mnt            tmp
bfu            boot           etc            net            TT_DB
bfu.ancestor   cdbuild        export         opt            usr
bfu.child      cdrom          home           platform       var

bfu.conflicts  Desktop        kernel         proc           vol
bfu.parent     dev            lib            rootb
bfu.realmode   devices        lost+found     sbin
bash-2.05b#

1. Run the script to display the usage message. It's fairly clear I think.
2. Now try to run the script as myself. Oops, I'm don't have the privileges to bind to a differnt pool.
3. I'll become root, I know I have enough privileges now ;-)
4. Run it again and this time it works.

#!/bin/sh

if [ $# -lt 2 ]
then
        echo "usage: newpool <pool name> <command> [parameters]"
        exit 2
fi
/usr/sbin/poolbind -p $1 $$
if [ $? != 0 ]
then
        echo "Bind operation failed"
        exit 1
fi
shift
exec $*

Monday August 02, 2004

The nuances of poolbind

poolbind(1M) allows an authorized user to change the resource pool binding of a zone, project, task or process. However, what does this actually mean? As you might imagine, it means different things for the different pool-bindable entities. Here's a quick explanatory note that should help eliminate any confusion.

The main point to note is this: any changes realized through poolbind(1M) are temporal in nature and will only affect the set of processes identified as belonging to the target process collective at that point in time. By this I mean that no permanent configuration is changed.

For processes and tasks, this is a moot point since there is no way (currently) to specify that either a task or a process is associated with a resource pool. I can't really think of any reason why you would ever want such fine-grained resource management that you would want to have a configuration that specified this relationship; so this is unlikely to ever change.

If you want to permanently change the binding of a project or zone to a resource pool then you must edit the configuration (favourite editor for /etc/project(4) or zonecfg(1M) for a zone). If you want the change to take place immediately, rather than the next time you boot your OS, then you must also use poolbind(1M) to execute the temporal change immediately.

So what actually happens when you use poolbind(1M) to modify the binding of a resource pool bind-able entity?
process The process stops consuming the resources associated with its existing resource pool and begins consuming the resources associated with the new resource pool. Any new processes which fork(2) from this process are also bound to the new resource pool.
task All processes which belong to the task stop consuming the resources associated with their existing resource pool and begin consuming the resources associated with the new resource pool. Any new processes which fork(2) from one of these processes are also bound to the new resource pool.
project All processes which belong to the project stop consuming the resources associated with their existing resource pool and begin consuming the resources associated with the new resource pool. Any new processes which fork(2) from one of these processes are also bound to the new resource pool. However, new processes which join the project after this operation completes will still be associated with the configured resource pool.
zone All processes which belong to the zone stop consuming the resources associated with their existing resource pool and begin consuming the resources associated with the new resource pool. Any new processes which fork(2) from one of these processes are also bound to the new resource pool. Re-booting the zone will restore the configured resource pool binding.

poolbind(1M) is a very powerful workload managment command, especially when applied to a process collective such as a zone or a project. I'll return to the subject of poolbind(1M) later and give some examples of how it can be used to manage workloads quickly and flexibly when problems occur.

(2004-08-02 04:41:30.0) Permalink Comments [6]