Anyone who has been near Circular Quay would have noticed the Diamond Princess at port in the OPT. Melinda raised the obvious question of how big it was compared to the Titanic.

Ship

Length

Beam (width)

Height

Tonnage

Passengers + Crew

Source

Titanic

269m

28m

18m

46,328

3,547

Wikipedia

Diamond Princess

295m

37.5m (excluding bridge wing)

62m

113,000

3,770

cruises.com.sg

So the Diamond Princess is about 10% longer and over twice as wide, and weighs about 2.5 times as much. Apparently they both had the same top speed of 23 knots. The height I'm not sure about; the Wikipeida article says the height is from waterline to top deck but the other article doesn't specify. From looking at it, it certainly could be 60m from waterline to top deck, it is extremely tall. This at least gives you some perspective if you get to see it up close; however I think there are other ones just like it, I seem to remember seeing something very similar parked outside Venice.

Martin Pool reminded me of The Innovator's Dilemma by Clayton M. Christensen.

This book examines why great companies miss the boat with new technology. He talks about disruptive technologies; those technologies that start out under performing established offerings. They're usually cheaper, smaller, simpler and have features that appeal to fringe customers (i.e. those customers who haven't already bought existing offerings).

These disruptive technologies often creep up on established offerings; as illustrated in the graph below.

The problem is that the disruptive technology doesn't become viable for all customers for some long period of time. Companies who listen to their customers end up developing their existing lines (to meet existing customer demand) until suddenly that customer demand is now met by the disruptive technology. At that point, the sustaining technology is out of businesses; nobody wants it. Christensen gives many examples, especially with disk manufacturers. Companies making 14 inch platters were catering to mainframe customers who needed storage in the 300Mb range, not the 30Mb range 8 inch platters of the time could offer. However, it wasn't long before the 8 inch platters were in that range, and by that stage it was too late for the 14 inch platter companies.

Disruptive technologies grow by opening up new markets. The book gives the example of hydraulics and digging equipment; initially hydraulic arms could not dig as much dirt as the steam and cable counterparts, however house builders, interesting in digging shallow, narrow ditches for the post-war housing boom, snapped up the new offerings. It sure beat digging ditches by hand. Eventually the disruptive technology of hydraulics caught up to cable based diggers, which were less reliable and more unsafe (imagine a cable snapping with tons of load on it), putting most of the cable based digger companies out of business.

But the cable based companies could not offer hydraulic diggers to their customers; for a long time they could not dig as much so those customers who need to excavate a lot of dirt would not buy them. It would have been a very bad managerial decision to move the company to hydraulic diggers and loose all your big customers. They followed what their customers wanted and went out of business for it.

The book goes on to talk about strategies for companies to manage this change. However, Linux in specific and open source software in general is clearly a disruptive technology. Where exactly Linux is on the line is an open question, I think somewhere after the red circle but before the green circle.

The evangelism prevalent in some areas of Linux and Open Source development has always struck a difficult chord with me. Concerted efforts to sell open source as something better because it is open source have never really made sense to me.

This graph illustrates to me why. Big gigantic changes can't be made by big gigantic companies. Switching to what I (we) can see as a disruptive technology is not in their interest, because it probably does not meet their customers needs. They essentially need to wait until it is too late; to when the disruptive technology has caught up to them sufficiently to provide an alternative to the status quo.

As a disruptive technology you grow by opening up new markets on your way to "world domination". You need to focus on your technology, and keep pushing up the development line to get closer and closer to that green circle. Marketing of course plays a part, but the performance of the technology has to be there. I strongly believe that sufficiently good technology starts to speak for itself -- the bottom line with software is that it does what you need it to do in a way that helps you do it. It is for this reason I think a Freshmeat announcement of version N+1 is infinitely better than a press release about Linux/Open Source blah blah blah.

I think it is important to keep this in mind. People digging the biggest holes couldn't move away from cable based excavators until hydraulics could move as much dirt as the old technology. With software, moving the dirt equates to features, support, ease of use, compatibility and a myriad of other challenges. I look forward to the day Linux is the biggest shovel of all!

After a request I enabled comments. I also tied a script into mutt so I can delete comments when I'm notified of them. So the comment policy is pretty much "I decide".

I hope the spam stays away and interesting people visit, but we'll see. I may sound old fashioned but I still prefer email.

To keep some technical content, note the comments.py file distributed with the Pyblosxom 1.2.1 contrib collection is not the latest, and if you are getting issues with "Mapping Key Not Found" when you post a comment, remove the call to decode_form (hack) or otherwise figure out what the blog charset encoding/decoding is trying to do (nice, but if you only care about English I don't think it will bother you).

I from time to time want to create a quick static web form to run where PHP etc isn't involved. The best way I've found to do this is with the HTML_QuickForm PEAR package.

To install it on Debian, just install the php-pear package and run sudo pear install HTML_Common HTML_QuickForm and then you can easily create really nifty forms.

For example, the comments form below was created with the following input.

<?php

require_once 'HTML/QuickForm.php';

$form = new HTML_QuickForm('comments_form');

$form->addElement('header', null, 'Add a comment');

$form->addElement('text', 'author', 'Name', array('size' => 50, 'maxlength' => 50));
$form->addRule('author', 'Please enter a name', 'required', null, 'client');

$form->addElement('text', 'email', 'Email', array('size' => 50, 'maxlength' => 50));
$form->addRule('email', 'Please enter an email', 'required', null, 'client');

$form->addElement('text', 'url', 'Website', array('size' => 50, 'maxlength' => 50));

$form->addElement('textarea', 'body', 'Comment:', array('rows'=>10,'cols'=>50));
$form->addRule('body', 'Please enter a comment', 'required', null, 'client');

$form->addElement('submit', null, 'Submit');

$form->display();

?>

It automagically does client side javascript to do first level validation and makes the form look quite nice. You can just run php file.php on the command line to scrape out the plain HTML.

Here's how I setup my wireless on Debian.

Firstly, create a script in /usr/local/bin called wireless-mapping or something similar. Make sure the dialog package is installed.

#!/bin/bash

if [ -f /etc/default/wireless ] ; then
    . /etc/default/wireless
else
    echo Please setup /etc/default/wireless
fi

for profile in $WIRELESS_PROFILES
do
  LOCATION_NAME=$profile\_NAME
  LOCATION_DESCR=$profile\_DESCR

  DIALOG_ARGS="$DIALOG_ARGS \"${!LOCATION_NAME}\" \"${!LOCATION_DESCR}\""
done

LOCATION=`eval dialog --stdout --menu \"Select your wireless location\" 10 50 5 $DIALOG_ARGS`

echo eth2-$LOCATION

Then create a file /etc/default/wireless where you put descriptions of your wireless networks. Put each of your networks in WIRELESS_PROFILES and then setup a name and a description, like below.

#WIRELESS OPTIONS

WIRELESS_PROFILES="home keg nicta"

home_NAME="home"
home_DESCR="At home"

keg_NAME="keg"
keg_DESCR="keg private"

nicta_NAME="nicta"
nicta_DESCR="nicta (hack)"

Finally, you need to make the mapping in /etc/network/interfaces for each network. It should look something like this.

mapping eth2
    script /usr/local/bin/wireless-mapping

iface eth2-keg inet dhcp
      wireless-essid keg
      wireless-key [key]

iface eth2-home inet dhcp
      wireless-essid wienand
      wireless-key [key]

iface eth2-nicta inet dhcp
      wireless-essid nicta_wireless

Notice how the mapping for your ethernet card is the script, and then you have a bunch of interfaces defined as interface-name, where name is the name you chose in the /etc/defaults/wireless script.

All going well, next time you ifup eth2 you should see something like this

CTD posts a question from a school exam, which appears to come down to a syntax error (I didn't pick it, someone in the blog comments did).

Apart from illustrating that not much has changed since I did computer science at school in 1997, it is an example of everything that is wrong with teaching computer science.

You'll think I'm crazy, but maybe we should rename computer science computer art-economics. Firstly, you'll notice that their is a fair bit of maths and science behind both of those fields, but it is not the primary focus of either.

Both artistry and programming are about plucking something out of your head and representing in some tangible form. Just as we can look at a piece of art and decide if it is a good or bad representation of what the artist had conceived, we can look at an algorithm represented in code and decide if it is an elegant solution to a problem.

The senior English department does not teach you to write by presenting you with grammatical errors and marking you on how many mis-placed apostrophes you find. The music department doesn't teach you to listen for the slip of a finger in a concerto and the art department doesn't make you study the five rough drafts of the Mona Lisa. In all of these departments their goal is to open your mind to the cornerstones of their fields and give you a foothold and the skills to hang on, from which you can climb as high as you want.

Standard algorithms and data structures are the cornerstones of computer science. The skills to hang on are teaching you a language with which to express these ideas. Binary logic is the basis of everything that gets built on top; the way 'and', 'not' and 'or' can be made to conspire and build most anything imaginable should be your first stop.

In other ways, however, computer science is much more like economics. Anyone who has studied economics will very quickly realise that playing around with the economy comes down to two things -- you either do something more efficiently (get more output from the same input) or accept a trade off (get less of one thing for more of something else).

A computer only has so many cycles per second to crunch through data. It only has so much RAM, cache, TLB slots, memory bandwidth, disk space, network bandwidth. When you write your algorithm, you either need to find a way to somehow be more efficient with your resources, or take a trade off.

Understanding where you can get efficiencies starts by learning about algorithms. We formalise this with big-O notation, but you don't need to know about that to realise a quick sort gets the job done faster than a bubble sort. When you get really smart, you start coming up with your own ideas that are better than anyone has ever thought of before.

Understanding tradeoffs is what makes you a programmer. You need to understand what is happening from what you write down to the way the instructions get issued into the processor. You need to understand what the operating system is doing between your program and the hardware, and any of the myriad of other variables that happen on a modern computer. Think of all the others things you understand to make good decisions; networking, databases, electronics, mathematics. How to make a good interface is as much about psychology as anything else.

This is an absolute gold mine of material, and exposes you to everything that modern computer science is about. There is an infinite number of exams without one stupid "find the syntax error" question.

Our goal should be striving to open the eyes of the next generation of hackers to the amazing world that lives beneath their keyboard. If things are anything like when I was at school, the only wonderment was wondering what the hell I was doing sitting in this class when it looked so nice outside!

A fantastic site I've stumbled upon lately is the Airmen of Note Archive. You don't get traditional big bands sounding consistently better than them.

They have an extensive audio archive for download with a small fee to support the bandwidth of the site. It seems a typically governmental thing to do to create amazing recordings and leave them to languish, and thankfully this site has dug them all up.

Clicking on the links to download all those MP3's isn't a very Linux user type thing to do. In that vein I've put a directory hierarchy filled with links to the albums and the album cover in airmen-download.tar.gz. Pay on the site for a user name, write a few scripts and you should be ready to go (feel free to mail me if you have no idea what to do). The original Python scripts I used to extract it all are available there too.

If you like Jazz, spend the $20 and get this fantastic collection. Although it's not all my taste, mostly because at times it feels a bit cheesy, it's a mine worth exploring for the fairly fairly frequent nuggets of solid gold.

Chatting with Hal, one of our summer students, we came across a bevy of interesting things to do with inlining code.

• C99 6.7.4 tells us that inline can only be considered a hint, by the standard. gcc may choose not to inline things marked inline for a number of reasons.

• The gcc attribute `always_inline <http://gcc.gnu.org/onlinedocs/gcc-4.0.2/gcc/Function-Attributes.html#Function-Attributes>`_ only applies to functions that are already declared with the inline function specifier.

• always_inline will inline even with optimisation turned off. The kernel wants this on all the time so has

  #define inline                  inline          __attribute__((always_inline))
  

• Without optimisation turned on (-O) -finline-functions does nothing. This is because gcc doesn't have enough information to analyse the functions and decide whether to put things inline or not.

• Code bloat is an obvious issue with inlining large amounts of code; C++ can be particularly bad with excessive inlining (and is one reason why gcc might choose to ignore inline directives).

• Particularly relevant to the kernel is stack bloat -- if you join two functions together that separately use half the available stack when inlined, gcc may not be able to figure out the scope of variables is different, and they will all get separate stack space. For example

  static inline void stack_user1(void)
  {
      int blah[1000];
  }
  
  static inline void stack_user2(void)
  {
      int blah[1000];
  }
  
  /* we use a lot of stack without realising it */
  int caller(void)
  {
      stack_user1();
      stack_user2();
  }
  

• Documenation on using inline as a macro with the advantage of type checking.