Setting up Hudson on port 80 on a Debian or Ubuntu machine

To my delight I discovered there is a debian package of Hudson nowdays.  Installing it was pretty straightfoward, but I wanted to configure hudson to be visible on my server at myserver/hudson, instead of myserver:8080, for a project I'm in.  That turned out to be quite a bit more complicated, but I got it done in the end and documented the process here for others and my own future reference.

My server is running Ubuntu 8.4 Hardy, but the instructions are relatively generic.

Installing Hudson deb package

The Hudson package is not in the default repositories, but that wouldn't be too useful anyway as it would be hard to keep up with the frequent Hudson releases.

Installation instructions for installing the deb package, or see the wiki page for more discussion.

By default the hudson deb package will install hudson in /var/lib/hudson, which also contains a config.xml with some options.  Command line options can be found in /etc/default/hudson.  The hudson log is in /var/log/hudson/hudson.log.  You may want to run

    tail -f /var/log/hudson/hudson.log

while debugging the installation.

You can start Hudson with:

    sudo /etc/init.d/hudson start

Hudson should now be running on port 8080 of your machine.

Remember to register a user and set up access control if you are running the machine on the public internet.

If needed, you can stop Hudson with:

    sudo /etc/init.d/hudson stop

Hudson on port 80

To set up Hudson to run on port 80 (the normal http port) instead of 8080 you could edit /etc/default/hudson and add --httpPort=80 to HUDSON_ARGS.  However, running a service on any port below 1024 requires the service to be run as root on Linux, which is not such a good idea for a compex Java application.  If you try to start hudson with the --httpPort=80 argument in /etc/default/hudson, you'll get a " Permission denied" exception in the log. 

It appears the standard procedure is to run apache (or another webserver), and configure it to hand over processing of a certain path to Hudson.  Mod_proxy seems to be the way to go.

Hudson Prefix

We want to see hudson running on servername/hudson/.  The first step is to change the prefix hudson uses, so we get from servername:8080/ to servername:8080/hudson/.  To do that, add

to the HUDSON_ARGS string in /etc/default/hudson and restart Hudson with e.g.:

    sudo /etc/init.d/hudson force-reload


If you don't have apache installed, use

    sudo apt-get install apache2

to install it.


In many distributions it should be included by default with apache, but you may need to install the mod_proxy module separately:

    sudo apt-get install libapache2-mod-proxy-html

In any case you need to enable it with:

    sudo a2enmod proxy
    sudo a2enmod proxy_http  

By default it is configured to deny all proxying, so edit /etc/apache2/mods enabled/proxy.conf to allow proxying:

    ProxyRequests Off
    <Proxy *>
        Order deny,allow
        Allow from all

[Note that messing up proxy configuration could leave your server as an open proxy, so proceed at your own risk.  I'm just copy pasting code from documentation without fully understanding it...]

In your /etc/apache2/sites-enabled/ directory there should be some file like 000-default or similar, with settings for the site.  Add proxy configurations in it for mapping the /hudson path on the website to localhost:8080/hudson:

    ProxyPass /hudson

You can of course use some other path than /hudson too, in that case remember to also use it with the Hudson --prefix parameter above.

In my case the file looks something like:

    <VirtualHost *> 
        # various stuff ....
        ProxyPass /hudson

You can stop and restart apache to enable the new configuration, or just use:

    /etc/init.d/apache2 force-reload

And you can follow the apache logs for troubleshooting by running

    tail -f /var/log/apache2/error.log

Good luck, and feel free to suggest improvements to this configuration in the comments.

Configuring irssi with UTF-8 and spell checking

I'm switching to using IRC with irssi running in a screen instance on my virtual server. The advantage over running xchat or similar on the desktop is that one can connect from anywhere and disconnect in between without loosing the backlog.

With scripts for irssi it's possible to get most of the comforts of a GUI client, such as nick coloring ( and spell checking (

I had some problems getting nordic characters to work, but the solution was to switch everything to utf-8:

  • The terminal
    • In gnome terminal menu, Terminal->Set character encoding->UTF-8
  • The remote environment
    • Add export LANG en_GB.UTF-8 to the end of ~/.bashrc
  • The screen session when starting irssi
    • screen -SU irc irssi (creates a screen instance named 'irc' using UTF-8 that runs irssi)
  • In irssi
    • /set term_type utf-8
So not really out-of-the-box as in some GUI clients, but hopefully a bit easier to google now.

The script didn't work with UTF-8 out of the box either, aspell needs the --encoding=UTF-8 parameter passed to it to work with non-english characters.

To install for irssi with utf support:

  • Log in to the machine you run irssi on
  • Install aspell:
    • sudo apt-get install aspell libtext-aspell-perl aspell-en aspell-de aspell-fi # and so on for the languages that you want spell check dictionaries installed for
  • cd ~/.irssi/scripts # if the scripts directory doesn't exists, create it
  • wget #downloads the original
  • Edit and find the line
        $speller{$_[0]}->set_option('sug-mode', 'fast') or return undef;
  • Add a new line after it and save:
        $speller{$_[0]}->set_option('encoding', 'utf-8') or return undef;
  • In irssi, write /script load
  • You can specify what language spellchecking should be used in different channels by typing /set spellcheck_languages NetworkName/#channelName/TwoLetterLanguageCode in irssi. Default seems to be english.


Aspeller seems to be a bit more user friendly spellchecker, as it doesn't spam the window with spelling suggestions, just highlights the misspelled words. Unfortunately it doesn't allow specifying channel specific languages. There's also

Boxed Reprap Design 0.3

Here's screenshots of latest version of the boxed RepRap design I've been working on. It has some major differences from the last version, such as a completely mobile toolhead platform, and a fixed bed. The electronics were also moved on top instead of underneath.

First an overview shot:

A 50*50 cm acrylic door covers the front. The upper front panel hides the electronics, and can have holes added for status LEDs and the like.

The top also contains the plastic feedstock, and has room for additions (such as a small dust extraction system for milling for example). The heat generated by the electronics and the ATX power source is fed into the box, to help keep up the ambient temperature to enable warp-free printing.

The above picture shows the Y assembly, sliding back and forth on skateboard bearings running along aluminum L beams.
The X assembly.

And the Z assembly, without mounting holes for the toolhead yet. I was thinking of some kind of automatic head switching system, but decided to just build for manual switching using wingnuts to start with.

In total, the effective work area is around 30*30*15 cm, and the external dimension is around 50*60*60 cm.

I've got the tools and materials (although the Plywood I got is a bit bad quality - don't use class C and D plywood for this kind of projects), so I'll start cutting up and putting together the pieces now.

Flowpaint 0.2 released


Last weekend I released version 0.2 of Flowpaint, my open source paint program project.

Here's the short summary:
Flowpaint version 0.2 is now released! It adds undo, detailed parameters for brushes, a 'recent brushes' - feature, dramatical speedup by dynamically compiling code, and a new set of default brushes. In addition tablets with pressure are now supported also with the Java Webstart version. Flowpaint is still in Beta phase, use with care.
And here's the full release announcement and download links.

I was demonstrating it live at a comics festival in Tampere on the weekend, in between manning the Pirate Party table there. It was a nice event, with a quite good match between the target audience of Flowpaint and the people there (our table was in the room for independent and self-publishing comic artists).

There's several features I'd like to add that I think could be useful for editing comics in Flowpaint. One such is the ability to compose one picture with several frames that show other pictures that are updated when the original pictures are updated. This concept could also be used for things like brush strokes textured with a picture. In addition, tools like procedural brushes or images could be utilized for creating picture components once and re-rendering them with different parameters to quickly create unique detailed backgrounds (simple examples would be a forest or city composed of randomly placed tree / house outline images).

First I have to get more of the basic features implemented and working though. Layers and picture loading are being requested in the poll on the Flowpaint homepage (the results from the previous poll are archived in the wiki). The rendering quality is also lacking, brush strokes look a bit jagged, and there's some artifacts when a brush stroke turns. I'm going to extract the rendering logic into a separate library, Rasterfun. It will allow loading and displaying Flowpaint images also in other (Java/Scala) applications. One other usage for it could be to render fractal / procedural landscape heightmaps for games (such as my Skycastle project) - in this case Flowpaint could be used as a map editor. This requires defining a good file format to represent Flowpaint images in.

Putting a RepRap in a Box with a Mill


I ordered the BitsFromBytes RepRap kit v 2.0 last summer. I put it together just in time for the Alt Party 2008, and even got it to extrude a bit. Above is a picture of it at the Pirate Party booth, nicely illuminated by a 12V RGB LED rail. Thanks to the guys at the party who helped me to wire up the heater and test it!

However, there were multiple problems with it, and I shelved it for half a year and went to work on other projects (the major problem was that I had decided to try using ball-chain with custom drive wheels instead of the standard (but expensive) drive belt)

I took a look at it again recently, but decided to try building an own design from scratch instead of fixing it (yes I know, probably more work, but I'm a designer at heart :) ). Hopefully some useful insights come from this new project.

My goal is to create a simple design that can be easily constructed with a small amount of standard parts from a well sorted hardware store (plus electronics ordered over Internet from e.g. the rrrf store). The design should be relatively modular, with possibility to easily remove the different axis assemblies and toolheads from the box for maintenance and upgrades (the laser cut RepRap designs take a lot of time to put together, and to take apart and put back together if you want to change some part..).

I decided to put the 3D Printer in a box, as it seems that printing in a hot ambient temperature around 50-70 degrees Celsius eliminates the warping of plastics. A box also provides a sturdier frame, which could allow operating a CNC mill with the same positioning system, opening up an additional range of materials, as well as circuit board milling and drilling. The box also neatly contains the unit together with fumes and dust, making it nicer to use in a home.

I made this initial design in SketchUp, which is an excellent tool for this type of work (unfortunately I could only get version 5 to work with Wine under Ubuntu).

The box itself can be made from MDF board or Plywood with 3 cm wide wooden beams to support it. It's a bit small in this design, I'm planning to make it 50 cm wide and 60 cm deep and high in the next design iteration. I placed the stepper motors outside the box, as they are rated for at most 80 degrees celsius.

I use threaded rod to drive all three axes in this design, it's probably ok for milling, but maybe somewhat slow for 3D printing. On the positive side, the wooden box design makes it a bit easier to switch to a belt drive later if needed. Another alternative would be to use larger diameter threaded rod with some gears to speed it up.

The Z motor movement is transmitted through a bevel gear that slides along a rotating square-profile aluminum extrusion. I'm not sure how well that would work, and it would also require a custom-made part, so I will probably change it in later design iterations. This picture should illustrate it:

The stepper motors will be attached directly to the lead screws like this:

A possible improvement could be to add smaller diameter aluminum tubing to the stepper motor end to achieve a tighter fit.

It's not visible in the pictures, but I'm planning to use skateboard bearings attached to an L shaped aluminum extrusion for the linear bearings, as described on

I put the electronics in a drawer underneath the main box, so that they can be easily accessed, and so that heated air can be blown from the power unit and stepper controller cooling fins up through a vent to the main box, to create the preheating required for warp-free plastic extrusion.

I'm currently working on a second version of the design, which rearranges things (changing to a moving x axis and stationary bed to allow automatic tool change, and moving electronics and dust collection to the back of the machine instead of a drawer). I will post more when I get the design finalized and start building.

Edit: Added closeup of z platform.

Representing real resources in a virtual world

In a virtual world with self replicating or easily constructible complex objects, there is a certain conflict of resource usage between the virtual world and the real world. Something that is easy and cheap to construct in the simulated world can bring the real world computer system simulating it to a crawl.

A way to restrict unlimited growth is to introduce environmental resistance in the virtual world. For example, building things could require resources, and running them could require energy, both of which could be in limited supply.

However, if a reasonable approximation of the real world is simulated, the resources and energy requirements will be quite hard to balance so that the simulating computer is not either overburdened or clearly underused.

A solution to this could be to introduce tokens in the virtual world that correspond to real world constraints and resources. For example, to construct a new object would require an object token, which approximately represents the amount of memory used by one object, and the amount of processor power required to simulate its interaction with the environment. To run some scripts / AI routines in the virtual world would require a token that represents the approximate CPU time used by a script (loops and recursion would be either disabled, or done on subsequent execution callbacks, to keep the CPU usage of a single script each world update more or less constant).

The tokens would be initially placed in a free pool. To create a new object / script in the simulated world, free tokens would be needed. Tokens could be requested from the pool and divided randomly between the requesters (or just dropped into random places in the simulated world). Tokens could also be exchanged between objects within the simulated world (for example by destroying an object and taking its tokens, or trading tokens for virtual money, depending on the type of simulation).

The object and CPU tokens could either completely replace other simulated resources (for a Tierra style abstract simulation), or used together with, or embedded in, conventional resources in more complex simulations (e.g. require lumber, metal, and an entity-crystal to craft an item in a fantasy themed gameworld).

The total amount of tokens in the simulation could be kept constant, or the amount adjusted based on memory and CPU load by adding or removing tokens from the free pool.