Blogospheric Refraction

Atomic MPC forum user, freakonaleash, asked an interesting question regarding sending faxes over IP. This got me thinking.

We’ve got solutions for an internal LAN such as Hylafax for an intranet-based fax-over-IP solution. But nothing exists that could be considered similar to Voice-over-IP. I can’t use the internet for instance, to send a fax overseas — and sometimes just like the telephone, one needs to fax a document.

There’s also the situation of inexperienced people. People like my grandparents, wouldn’t have a clue how to use a computer to send an email, or maintain a PC. Linux distributions have gotten to the point where I’d be quite comfortable setting up a minimalist Gentoo or Ubuntu installation on an old PIII box — to allow basic email and web browsing, but I still need to be around to keep it updated and maintained. Even if I were to go throw Windows XP on the same machine — I’d still have to maintain it.

Email offers some very useful options for such people — e.g. the ability to send letters and other correspondence and have it arrive at the other end within a day or so. (and that’s if the mail servers are having a bad day!) These days, one can buy a hardware device that provides VoIP capability, one can purchase devices that offer limited web-browsing capability without the need of a full-blown desktop computer, why not an internet appliance for sending and receiving email?

Well, I don’t see the need for a whole new protocol. SMTP and POP3/IMAP will do just fine for the actual FoIP capability. The issue is the interface to these protocols. I’m thinking an internet facimile would offer the following:

• Ethernet interface for connection to the internet via a router.
• Internal ADSL and/or PSTN modem for stand-alone internet access without other hardware, and standard fax capability
• LCD Display and keyboard for reading/composing mail and user interface (touchscreen)
• Onboard scanner and printer
• Handset/headset jack for voice communications (either VoIP or standard land-line)

The idea, is that someone who doesn’t have a proper understanding of computers, could send a message over the internet using this device. They would simply hit the “Compose” button, fill in the recipient’s fax number (standard fax) or email address (FoIP), a subject for the message and cover letter, then scan in whatever attached pages they wish to add (these would appear as PDF, JPEG or PNG attachments). Some models may include USB ports and card readers, to allow attaching arbitrary files from USB drives and flash cards. Once they’re happy, they get the option of either sending it right then and there, or storing it to send in a batch run.

For privacy, perhaps something like PGP could be incorporated, thus allowing messages to be encrypted. There’s scope for this device to act as an internet router, networked printer/scanner, and VoIP ATA box too, which could be add-on features.

In essence though, the box could just sit in the corner… and say, overnight, connect to the internet, download any new messages, send any unsent messages out.

I might look into something like this, as it seems in the open source world, we have pretty much all the necessary pieces — just a matter of piling the right software on a standard PC and we’ll have a proof-of-concept prototype.

Update: Seems I should have read this page first… we were thinking on the same wavelength afterall. I’ll leave the post here, since I think my (and Brian Lozier’s) argument is still valid with respect to the overheads in various templating engines…

---

It has always fascinated me, with large-scale PHP projects, how people seem to flock to overly complicated templating engines. I’ve worked on a couple of such projects, and it got me thinking about why we do it.

My first real contact with a site that uses templating engines was the Asperger Services Australia site. Originally, it was a static-HTML site done in FrontPage, but after looking at a number of CMS systems, we finally chose TikiWiki to run the site. TikiWiki utilises the Smarty templating engine — a behemoth weighing in at just over 1MB.

Smarty wields a lot of power, able to do numerous transformations with strings — but it’s a big package, and takes quite a while to master. It also seems to occupy a lot of memory, and requires write access to directories to store “compiled” templates.

This year, we built a web application called Teamworker. Our implementation was written in PHP using MySQL, and basically it was a ground-up re-write of an internal QUT webapp of the same name (many QUT students probably know it well). For this project, we wound up using the bTemplate engine, a far simpler engine than Smarty, it uses simple string replacement of XML-like tags. It has quite a few limitations however — for instance, one cannot have two loops of the same name — it’ll substitute one, but not the other. It isn’t difficult to pick up, but some aspects of its syntax are … awkward.

I dare say if I look hard enough, there’s probably some poor sadistic sod trying to do it with XML and XSLTs. Yes, they have their place, but they’re massive overkill. If your data is already in XML to begin with (i.e. Gentoo’s site) then sure, go for it, but otherwise it seems to be (to me anyway) a really messy way to do things.

PHP, believe it or not, actually is a templating engine. It has all the features one needs. All the code I need goes inside tags like this: <?php ?>, and outside of these, I can have just about anything I want. I can also use conditional statements inside PHP tags, to control what gets displayed outside… e.g. suppose I define the variable $logged_in, a boolean, and the string $user… a webapp might have:

... random HTML code...
<?php if ($logged_in) { ?>
Hello <?= htmlentities($user) ?>.
<a href="profile.php">Profile</a>
<a href="logout.php">Logout</a>
<?php } else { ?>
Hello guest. Please <a href="login.php">log in</a>
<?php } ?>
... more code ...


Voila… done. To whistle up this template, a script only needs to initialise $logged_in and $user, then include("template_file.php");, and it’ll appear as they expect.

However, this requires that your templates be structured a particular way. You’re more-or-less generating things on-the-fly, rather than constructing everything in a buffer, then sending it later. This can lead to display code getting mixed up with computation code, which isn’t terrific. So in these situations, PHP needs a little helping hand. Enter, the 8-line templating engine.

PHP since version 4 supports output buffering. These allow the programmer to control when and how, data is released to the browser. In addition, it is also possible to fetch the rendered output from the buffer as a string then clear the slate. This gives us great power to create a very simple but flexible templating engine, in 8 lines of PHP code:

function doTemplate($templateFile, $data) {
extract($data);
ob_start();
include($templateFile);
$_out = ob_get_contents();
ob_end_clean();
return $_out;
}

It’s crude, but it works. A site can then be easily put together using this method. No files need to get written at runtime, there’s no special syntax required. The idea is the template files are just very trivial PHP scripts — one uses as few functions as possible to achieve the desired page output. So built-in functions such as if, foreach and similar constructs, and maybe the odd include(). A site might use an overall template like the following:

<html>
<head>
<title><?= htmlentities($page_title) ?></title>
</head>
<body>
<h1><?= htmlentities($page_title) ?></h1>
<hr />
Navigation: <?php foreach($navlinks as $link) { ?>
<a href="<= $link["target"]; ?>"><?= htmlentities($link["title"]) ?></a>
<?php } ?>
... other header stuff ...
<?= $content ?>
... rest of page

They may, for instance, have some form widgets. Suppose they wanted all these boolean values to use radio buttons with some sort of tick/cross image beside them? They can define the HTML code for them in one place…

<input type="radio" value="no" name="<?= $name ?>" id="<?= $name ?>_no" /><label for="<?= $name ?>_no"><img src="/images/cross.png" alt="No" /></label>
<input type="radio" value="yes" name="<?= $name ?>" id="<?= $name ?>_yes" /><label for="<?= $name ?>_yes"><img src="/images/tick.png" alt="Yes" /></label>

Then use that widget repeatedly in a document by simply defining some place holders (using <?= $placeholder_name >) and generating the page…

$my_page["show_email"] = doTemplate("templates/yesno.tpl.php",array( "name" => "show_email" ));
$my_page["subscribe_annouce"] = doTemplate("templates/yesno.tpl.php",array( "name" => "subscribe_announce" ));
//
// ... other definitions ...
//
$page_content = doTemplate("templates/register.tpl.php", $my_page);
echo doTemplate("templates/overall.tpl.php", array(
"page_title" => "Register for our forum!",
"content" => $page_content,
"navlinks" => $navigation // <-- This may be a global array that's manipulated in various places as needed.
));

Already, that works in much the way bTemplate does, but doesn’t have nearly as many limitations. There are some manipulations that it can’t do as easily as Smarty does them, such as inline manipulations of text, but then again, it’s a heck of a lot more lightweight. Sure, RAM is cheap these days… but still, why waste the resources if you don’t have to? What I’ve done above, could be viewed as wasteful — even the very act of using PHP in the eyes of some, but sometimes we don’t get a say in that matter, we work with the tools we have at hand. (Heck, I’ve been known to use C and Busybox ash to construct webapps — which works surprisingly well too.) But even in this age of cheap computing power, I think striving for minimalism is still worthwhile.

This is an idea I’ve had for some time now, but only recently started doing anything about it. Anyway…

The problem:

As many of you may know, I study at university. Often the lectures and tutorials are on late at night. Thus, I frequently find myself making my way from or two university in the dark. Many of the areas I walk through are dimly lit, with sparse street lighting and quite a few road crossings. Often the footpath is an uneven surface, and therefore one needs a torch of some kind to see any hazards underfoot. The same torch does improve one’s visibility — but only for those in the torch’s beam.

Headlamps are really nifty torches… freeing both hands. The problem one has though, is that the small compact ones aren’t much good for distance vision, and the big bulky ones chew batteries like they’re going out of fashion. Then there’s the fussing over whether they’re pointed up or down, adjusting head straps…etc. They’re great when camping, and even for walking home of an evening, but the balance between light intensity and battery drain is a big problem, especially when only a limited supply of batteries is on hand. Seldom does one need a high-power beam all the time, but they’re useful to have.

Bike tail-lights are useful for improving one’s visibility to vehicles coming from behind, but they aren’t much help if they’re approaching side-on. And none of these lights will turn themselves off if there’s sufficient ambient light.

My idea:

These problems got me thinking about how I could solve the problem. Does it really need to be solved? Well, it isn’t a big one, so I guess not… but for the sake of it, I’ll try and solve it anyway. LED technology has vastly improved in the last few years, to the point now where they’re talking of using them in street lighting and car headlights (PDF; IEEE Explore subscription required). The big advantage is the high efficiency and low heat of LEDs. A few high-power LEDs should last as long, if not, longer than the incandescent bulb that my present headlamp uses.

My idea revolves around mounting 3 sets of LEDs on a hard hat of some description. Why a hard hat? Well, they’re a rigid structure that I can easily drill holes into and mount components on. Using a full-brim hard hat (rare in Brisbane), it’ll also keep the sun off during the day, thus serving a fourth purpose.

This headlamp would use 3 different LED banks:

• High-Beam LED: Single 1W high-power White LED — mounted above the rim facing forward in the distance.
• Low-Beam LEDs: Three high-intensity 5mm White LEDs — mounted under the rim facing downward.
• Rim LEDs: Twelve high-intensity 5mm Red or Yellow LEDs — mounted around the rim of the hard hat facing outwards.

The high-beam LED would provide the distance lamp… acting like any high-power torch. It’d be focussed slightly below the horizon. The low-beam LEDs would be directed downwards so that they light up an area just in front of the wearer, allowing them to see what they’re doing. The Rim LEDs would be divided into two groups of 6 that flash alternately to warn approaching vehicles at any angle.

Mounted on the top of the hard hat, would be a light-dependant resistor (cadmium-sulfide cell) that detects ambient light, and just underneath, a PCB containing the controller logic for the automatic switching. Then down the side under the rim, would be the switches and threshold pot for controlling the whole circuit.

Each of the functions can be in one of three states, controlled by the user: on, automatic, or off

Controller Circuit:

The key to this headlamp design is the controller circuit. I ended up trying three different circuits before settling on this design. By far, the most simple circuit was based on a IRF630B N-channel power MOSFET.

In this configuration, the CdS cell and potentiometer were wired in a resistor-divider configuration, such that the voltage rose as the light level dropped. This drove the MOSFET’s gate pin, causing it to sink current whenever the light levels were low.

I soon discovered this circuit was no good for high-current devices such as my existing incandescent headlamp. Because the bulb was such a heavy load, it put a heavy strain on the batteries, causing the voltage potential to drop significantly. This in turn, shifted the threshold point on the voltage divider, causing the MOSFET to turn off again, causing the batteries to rise up again… ad nauseum, until the batteries were flat or the user got frustrated and switched to manual modes.
Addition of a relay helped… the ciruit was slightly more stable, increasingly so as large amounts of capacitance were added across the relay, slowing response times. It still was possible to get the whole system into a battery-guzzling oscillating state.

In the end, I turned to the humble 74HC14 Hex Inverting Schmitt Trigger. By turning my voltage divider up-side-down (so voltage rose with light level) I found I could gain the effect I needed. Due to the hysteresis provided by the Schmitt Triggers, the light doesn’t turn off until it gets significantly lighter than the threshold point, and doesn’t turn off until it gets significantly darker. This provided the stability I needed.

The final design (click image on right, or see SVG or Kicad .sch versions) works as follows. The CdS cell and pot provide the means for detecting the light level. Adjusting the pot will make the circuit more or less sensitive to light. This drives the first Schmitt-Triggered inverter.

The output of this inverter is passed through a BC547C NPN transistor which in turn, drives a small reed relay. This relay is the main switching workhorse, providing a switched 6v rail which hooks to small toggle switches for the low and high-beam LEDs.

For the Rim LEDs, the same schmitt trigger IC could be used to make the oscillators. The Phillips 74HC14 datasheet describes how. I didn’t care much about frequency, so long as it flickered just fast enough to be noticable. To get the alternate flashing action — I set one inverter up as an oscillator, and used it to drive a second inverter. The outputs of both drive individual BC547C transistors, which act as current sinks from the Rim LEDs.

The following two photos show my testing of the circuit on a breadboard.

Bill of Materials

The following is the list of parts for this headlamp, and where I purchased them. Some components can be exchanged to suit one’s needs. At the moment, I haven’t yet bought the 1W LED and power supply which would form the high-beam LED.

Quantity	Part Desc	Supplier.	Part No.	Approx. Price each (at time of post)
1	Hard Hat	Blackwoods	05339960	$22.00
1	74HC14 Hex Inverting Schmitt Trigger	Jaycar	ZC4821	$1.30
3	BC547C NPN Transistor (or similar)	Jaycar	ZT2152	$0.20
1	5V SPST Reed Relay	Jaycar	SY4036	$2.95
3	1kOhm Resistor	Dick Smith Electronics	R1074	$0.04
1	10kOhm Resistor	Dick Smith Electronics	R1098	$0.04
1	33Ohm Resistor (for low-beam LEDs)	Dick Smith Electronics	R1038	$0.04
1	10Ohm Resistor (for rim LEDs)	Dick Smith Electronics	R1026	$0.04
1	33µF Capacitor (electrolytic)	Dick Smith Electronics	R4340	$0.25
1	Veroboard PCB 95mm×76mm	Jaycar	HP9540	$3.80
1	1MOhm Potentiometer	Jaycar	RP8524	$2.50
1	Photoresistor (CdS Cell)	Jaycar	RD3480	$2.50
1	4×AA battery holder	Jaycar	PH9282	$2.25
1	1W Constant Current Supply	Jaycar	AA0582	$19.95
1	1W High-power White LED	Jaycar	ZD0508	$9.95
3	18000mcd White 5mm LED	Jaycar	ZD0195	$4.95
12	4000mcd Red 5mm LED	Jaycar	ZD0154	$0.80
1	Packet of Nylon bolts 12×3mm	Jaycar	HP0140	$2.65
1	Packet of Nylon bolts 25×3mm	Jaycar	HP0142	$3.00
1	Packet of Nylon nuts 3mm	Jaycar	HP0146	$2.50
3	DP3T Switch	Dick Smith Electronics	R7614	$0.98

Assembly

Construction of this headlamp will require drilling holes into the shell of the hard hat. So once complete, I wouldn’t go using it on a construction site. To mount the rim LEDs, I found the best way to do it was to use a 3mm drill to make the hole, then use a screwdriver to widen the hole so it was just big enough to accomodate the LED. The LED was then forced into the hole, plugging it — friction holds it in place.

The switches were small enough to mount using double-sided tape just inside the hard hat. A small piece of PCB was used to mount the potentiometer, allowing it to be fastened to the underside of the rim using a nylon nut & bolt.

The low-beam LEDs were mounted onto a small PCB with the current-limiting resistor, and fixed to the front of the hard hat using masking tape (yeah, dodgy I know) — some cardboard prevents the light from shining into the wearer’s eyes.

The main PCB and battery pack were fitted inside the shell of the hard hat — two 25mm long bolts hold the battery pack in place, while one 12mm bolt holds the PCB in place. The actual components are placed on the PCB according to the PCB board design shown to the right (click for larger image).

Final Product (almost)

Well, I haven’t bought the high-beam LED yet, that’s for later. The end result however, works great. I first used it at Riverfire 2007 and found it very convenient. At the time I had lost the LDR, so had to buy one yesterday, which I fitted last night. The unit now automatically switches off if the light levels are sufficient. As far as appearance, it doesn’t look that different to an ordinary hard hat, until you switch the LEDs on. These show the hard hat, before modifications, after, and what it looks like in action.

Safety & commercial considerations

It’s worth noting that although this hard hat would’ve been manufactured to meet AS/NZS 1801. I’ve destroyed this rating by drilling holes and inserting electronics. This project might still survive the double impact tests needed — but it’s never been tested, and isn’t intended to. I just wanted a hat that shaded me by day, and lit my path by night.

If this idea prooves popular, I could see it being adapted into a removable brim that sits over a hard hat/cap. The actual electronics cost over $60 … so embedding it into a hard hat on a commercial basis is not economic, since hard hats have a limited lifespan and need to be replaced every few years. So the headlamp would need to be detachable.

Update: 22nd November

Well, having used it now for two months, the idea has worked great. One set of 4×AA batteries lasts about 2 months, with moderate usage — and even then everything still worked, just the light was getting a little dim. I’ve since added the high-beam 1W LED (the supply for it wound up costing about $40, but anyway) and extended the brim so that it provides additional shade during the day.

The photo on the left shows what it looks like now. There has been one minor technical problem, in that the relay occasionally sticks — I’m investigating whether I replace this with something solid-state such as a P-channel power MOSFET which should do the job nicely. The only other one is the odd social problem — of people asking if you’re expecting a disaster, but once they’re used to seeing me wear it, this usually isn’t an issue.

---

Update 2009-06-05: I did get around to making a P-MOSFET version. See the schematic in PDF or gschem.  The circuit can theoretically use any P-MOSFET rated at 1A current for Q1… this one uses the IRF9540N available from Jaycar (which is overkill).  I use BC547Cs for Q2 and Q3.  CONN1 connects to the adjustment pot (use a 2M? one), CONN2 connects to the LDR.  R1 and R2 may be omitted, but are present to allow the circuit to operate if either the pot or LDR connections are broken.  CONN3 and CONN4 connect to your low and high beam LED banks.  CONN5 connect to the two warning LED banks.  R4 and C1 control the rate of oscillation… any value can be used, see the NXP 74HC14 datasheet for details on how to calculate these.

Well, right now I’m lying back, listening to the fruits of my labours.

When it comes to time-shifting, there are quite a few solutions that allows a user to time-shift television. MythTV, Tivo, Foxtel IQ… just to name three. However, I’ve looked around, and found very little for radio.

My needs are basic… I have an old stereo FM tuner plugged into the line-in socket of an old laptop. It’s in a spot where it can get good reception. The machine has a 20GB HDD, Apache web server, and enough CPU grunt to push the data. I thought it’d be nice if I could stream my radio around the house, in a manner that allowed me to time shift backwards up to a few hours or so. Therefore… if I wanted to hear a radio programme, but missed the first 15 minutes — no problem, just tell it to start playing from 15 mins ago. Done.

It’d also be nice if it could be in lossless form. I’m on a 100Mbit LAN — I don’t need compression, but some extra CPU cycles could be nice.

Icecast did the basic need of streaming radio quite well… but there were a few problems:

1. It couldn’t timeshift
2. I found it would frequently drop the feed mysteriously
3. It used Vorbis — not so much a problem, but for my needs, lossless was better

So seeing few alternatives, I set about designing my own system. The concept is simple:

• Create a capture programme, that records audio to a series of 1sec raw blockfiles, stored in a stream directory.
• Make a CGI application that scoops up a number of these blockfiles, concatenates them, adds an appropriate header and pushes them out to the client
• Construct a shell script that can clean up old files (to keep the disk from getting full)

After looking around at a suitable capture API, I settled on Portaudio v19. I had done some apps with v18… thus I had some familiarity with it. Doing this allowed my app to be cross-platform, should I decide to develop it further.

It was simply a case of writing a program that would write blockfiles, one for each second, identified by a Unix timestamp. As time ticks forward, it closes one block file and opens the next. My capture app is basically 137 lines of pure C code. Very tight and efficient.

For the CGI app, I again did it in pure C. It picks up its parameters from the PATH_INFO environment variable, allowing nice clean URLs, and parsing is as simple as calling getenv. I ended up writing two versions of this app.

The first version used sox in a child process, to convert the raw audio to a RIFF stream. My problem was that I used popen to execute sox. It worked well, except that disconnecting the player left loads of sox instances running, hogging the CPU. I started looking at writing my own RIFF header library, only to discover how complicated it was.

Looking around, I stumbled across the humble Sun Audio format. Apart from the minor inconvenience of having to pass everything through atonl/atons… everything works fine. I specify a URL like http://blackbox.local/cgi-bin/stream/linein/2 (the laptop, an IBM T20 is called blackbox), which gives me the stream “linein” from 2 seconds ago. I find it’s a bit glitchy any closer than that… but for maybe 6 hours coding, I’m quite happy with the result.

The problem has been clients… Amarok seems to know what to do with the stream. mplayer tries despairately to seek in the stream (why?) then drops out. And don’t even ask what Audacious does — I’m at a loss there. That said, good ol’e sox and wget or curl works fine, and is lightweight — just the interface is a tad annoying.

I’ll probably wind up writing my own client anyway — so I can time-shift somewhat more conveniently (using a slider to set the offset).

Still on the TODO list, is to make the capture app daemonise itself (it runs in the foreground for now), and to write an app that can be run from cron, and will record a radio programme for later listening (e.g. on a portable music player for instance) — perhaps optionally encoding it in a compressed format.

I’m tossing up whether to release the sources or not… if there’s demand for such a project, I’ll look into cleaning things up and releasing it. That said, if anyone knows of something that does similar to the above… I’d be interested to hear about it.

I’ve been doing little bits and pieces to help with our current global warming crisis.

Okay, I know not everyone thinks there is such a problem, and indeed, they could have a point, but I’d argue cutting back on emissions is still a good idea, regardless what the weather is doing.

A few months ago, I posted about a pump-shower that I was using to reduce my water consumption. Since then… especially as winter set in, I’ve been looking at other ways to cut down my power consumption and reduce my impact.

In our household, our major contributors would be:

• Transport: getting to/from uni/work
• Computers
• My bad habits (leaving lights/appliances turned on)

The transport situation is an interesting problem. Seeing as I don’t have my own driver’s license, I usually hitch a ride to the railway station of a morning when heading to uni. My father drives right past Mitchelton railway station on his way to work (in Enoggera). Until recently, we were using a 1982-model Subaru stationwagon to get us there. This car was getting quite old, and whilst running reasonably well, chews about 9~10L of petrol per 100km — quite a lot for a car of this size. Luckily we managed to score a 2007-model Holden Rodeo. Indeed, such a vehicle is overkill for most of the day-to-day trips we do, we got it with camping trips in mind. Around the city, it chews about 8~9L of diesel per 100km, so still quite a bit better than the Subaru considering the size difference.

I could ride my bike to uni, however there’s a catch. Brisbane traffic, particularly around the CBD, is not a nice place to be when you’re on two wheels and pedal-powered. This is ignoring the hilly terrain between The Gap (where I live) and the CBD. Thus it’s public transport for me until the traffic settles down a bit. (and I get a bit more fit)

The real challenge though, for reducing our resource consumption, has been the computers. In this house, there are 30 computers. Not all of them run all the time, in fact, typically the following must run 24/7:

• Web server: IBM Netfinity 5000 server running Gentoo 2007.0 on an Intel PIII 550MHz CPU ~300W PS
• Wireless Network server: Recycled desktop PC running Gentoo 2007.0 on an Intel Pentium MMX 166MHz CPU … ~200W PSU

So okay, worst-case scenario, we’re burning about 500W/hr just with those computers. I also like to run my desktop PC 24/7, since even if I’m not home, I can shell into it from uni/whereever and grab files/execute tasks. My desktop PC is almost 6 years old now… and has been upgraded a little bit since then. Its specs:

• CPU: 2×Intel Pentium III 1GHz
• RAM: 1GB PC133 SDRAM
• HDD: 3×18.2GB and 1×9GB SCSI disks
• Power Supply Rating: 400W

I have no idea whether it would actually hit 400W peak usage… but it could get close to that in some cases. In addition, there’s my file server (Cobalt Qube2) which runs on a 200W PSU. Add to this my bad habit of leaving the SGI boxes turned on, idling for days on end, we can be easily looking at 2kW every hour. It’s little wonder that we have been known to cop some astronomical figures on the power bill — as much as over $400/quarter.

This got me thinking about what I actually use my desktop PC for. I’m not a gamer, so high-end 3D performance is not a requirement, just accelerated 2D is sufficient. My desktop PC is normally an integral part of my sound system; plugged into the amp as a second tape deck. This allows me to record from tape, radio and vinyl records. I also like listening to my music on the computer (I have about 1200 songs in Vorbis format) and sometimes watch some TV shows (e.g. The Chaser vodcasts — note these aren’t available outside Australia). Then there’s the more mundane tasks: wordprocessing, spreadsheeting, presentations, software development…etc.

Back in February, Lemote donated two Fulong minicomputers to Gentoo so we could do a port of Gentoo to them. It didn’t take me long to get X, KDE, Firefox, Thunderbird and all the other typical luxuries one has on a standard Intel PC, fully operational. I soon came to a realisation however: these machines do just about everything I do for day-to-day tasks, and come with power supplies rated at 12v 4.1A. 50W is excellent for a machine that runs at 660MHz. The Wikipedia article about them claims that they’d rival a P4 CPU, which I’d dispute, but this aside, they’re one of the most responsive MIPS-compatible machines I’ve ever used. About the only things I can’t do:

• Run Java applications — Presently, there’s no Java environment for Linux/MIPS. I’m yet to figure out OpenJDK, and there’s also one rather interesting project on Lemote’s project site that seems to promise a JVM… but for now, I just use my x86-based laptop to work with the few Java apps that I need to use.
• Play Flash media reliably — Gnash can play some videos, but it can’t play them all. I have Gnash 0.7.2 installed at the moment (I just tried 0.8… it failed to compile) which can do some, but anything involving video is a no-go. But I so rarely come into contact with Flash, it’s enough to stop Firefox bitching about missing plugins — if I really need Flash, again, I’ve got my laptop.
• .NET apps — Now, I did see some MIPS-related code put in the recent versions of Mono. I think this is more targetted at IRIX, but still might be interesting to look into — especially for things like ikvm — but at present, I don’t use any .NET stuff. So this is a very low priority.

So I sacrifice these things, for a significantly smaller power bill. How much of a difference it makes, will be interesting. I’ve turned off and unplugged my desktop PC… it’s sitting on the floor under a table, silent. I’m using the 20″ CRT monitor and other peripherals from that box for one of the Lemote boxes, and thus use it as a primary desktop. The machine handles the job extremely well, especially since I upgraded it to 512MB RAM, and should do just fine when other devs want to shell in and test apps. Presently, I’m fiddling around with a n32 chroot environment, updating that (sys-libs/db-4.2.52_p4-r2 is in the test phase), and the desktop is still rather responsive.

As I sit back and listen to the Live Earth concert currently playing in Sydney (Triple M Brisbane has been playing highlights all day), this got me thinking about the impact the IT industry has on our power usage. Particularly in the Wintel community (Windows/Intel). Over the last 10 years, we’ve seen processing clock speeds multiply 20× and power consumption multiply about 2~3×. 10 years ago, we were looking at (what is now) the mid-range PII systems, between 300~400MHz, and requiring power supplies rated about 200~300W. We now talk of 2-3GHz CPUs, requiring 400~600W PSUs. Microsoft and co have been slowly upping the requirements of their latest operating systems — and at the same time, have been slowly forcing people to upgrade.

Windows Vista pretty much needs a state-of-the-art desktop PC at the moment before it runs properly. The same PC, which might be relatively responsive under Vista, often flies by comparison under Linux. Add to this the requirements of anti-malware packages, things soon balloon up. Also, Microsoft seems to assume we run our PCs 24/7… Notice how they default to updating at 3:00AM? Just how many home users do that?

Now, if turning Google black could possibly save 3GW/year, what would happen if either (1) Microsoft stripped some bloat out of their OS products, or (2) a sizeable portion of the IT industry were to move to more power-friendly alternatives? A more lightweight operating system and applications, could mean we could use more low-end computers to achieve our day-to-day tasks. In my case, I’ve switched to a machine that draws slightly over 10% of what my x86 desktop chews, and so far, has done everything I need to do.

The bonus, these Lemote machines are small enough to carry in my backpack to uni .. simply “borrow” a monitor and keyboard from a non-working university workstation, and bang, I’ve got a very convenient desktop that lets me get my uni work done — and simultaneously allows me to do any MIPS-development work on-the-run, whilst drawing less power than my laptop or any of the university workstations. It’s also amusing to watch IT students, many of whom have only ever known IBM clones or Apple computers, see the box, think it’s a USB HDD, then do a double take when they notice the monitor, network and peripherals plugged into this apparent “HDD”. Despite having a much slower CPU than the university workstations, the machine boots up faster, and gets the job done sooner, than many of the university machines, making me much more productive.

Surely if people’s workstations in the workplace ran with this sort of efficiency, productivity would go up. And if the PCs aren’t working as hard, this has got to have some kind of effect on a company’s power bill. I wouldn’t like to speculate, but I’d imagine that a company that recycles its old PCs using Linux … even to run them as thin clients off a much more powerful server (Windows or Linux) could save huge amounts of power, and conversely reduce a significant amount of CO₂ emissions as a result.

I think the IT industry as a whole, truly needs to start looking into how to use the computing power we have more wisely, rather than producing operating systems that spend loads of CPU cycles DMA-loading fancy textures into video RAM so the power-hungry GPU can render some completely pointless and time-consuming flashy eye-candy effect, or make some pesky metal fiend jump about the screen whilst one is trying to write a letter (Yes machine, I am writing a letter, now sod off and let me get on with it).

Thankfully, I don’t have to put up with this… but it amazes me how many people do.   To them, I ask: why?  It’s about time big corporations realise how frivolous this whole counter-productive “beautification” project is, and start looking at making their software work better on the hardware we have now, rather than lumping these needless hardware upgrades on us and causing this excessive waste of our power resources.

(Update 20080211: During an upgrade of my blogging software, I accidentally lost the photos of the shower… I’ve since taken new ones, of the portable shower, and the new in-house installation.  Click any photo for a larger image.)

Those of you in this part of the world, will probably know about the massive water shortages brought on by the drought. Particularly in Brisbane, where the problem is that dire, that we’re moving to level-5 water restrictions, which means luxuries like washing cars and watering lawns are largely things of the past.

Residents have been asked to keep their showers to 4 minutes or less — but is there a better solution? Well, when camping, we often have to face working with a limited supply of water. Often we have two supplies, drinking water that we bring with us, and washing water that we collect from the campsite. Lugging buckets of water around is no fun, thus it pays for us to be efficient in our water usage.

Camping showers often are overglorified bags with shower nozzles attached to the bottom. Usually there are two types, one is usually is made of black plastic, and is designed to absorb heat from the sun. The other is a bag you just fill with heated water. They need to be suspended overhead, often quite high to be useful. They’re heavy when fully loaded, making hoisting them a challenge, and don’t offer that much pressure. You can also get showers that are powered from a 12v supply, which overcome this issue, but then one must have a car or small SLA battery nearby. None of these are all that useful when not camping either.

Kym Schluter, however, came up with a rather novel idea. Hardware stores sell pressurised weed sprayers which can carry several litres of water. By attaching a suitable hose and nozzle to these, you can build a camp shower which is portable, doesn’t need to be hoisted up high, and provides decent water pressure without electricity. He’s been using this shower for a number of years now, and over time, a number of us have made replicas of it. None of the camping stores seem to be selling these showers — but thankfully, your local hardware store will carry most, if not, all the components you’ll need to build one of your own.

The shower consists of three main parts, the pump pack itself, the hose and the nozzle. The lot connects together using standard hose fittings, allowing you to theoretically use any off-the-shelf trigger hose nozzle. The unit pictured on the left is a 6L pressure pack. A short length of clear 12.5mm tubing connects the bottle to a hose fitting. On the bottle side, plumbing tape is wrapped over the screw thread to seal the gaps. The hose was fitted by heating the end up (place it in hot water for a few secs) then pushing it over the end of the thread. It was then clamped to keep it from slipping off. You’ll find the other end of the tube will neatly fit inside the hose fitting, making a secure fit.

To make the hose, we used some 10mm clear tubing, with a screw-in adaptor fitting on one end, and a standard hose fitting on the other. The thread on the screw-in fitting is wrapped up with plumbing tape and clamped much like the pressure pack, and the other end will generally fit quite securely.

The whole assembly is completed with a standard off-the-shelf trigger nozzle. You can use almost any fitting here, bearing in mind that soaker nozzles tend to loose pressure quickly (<2 seconds). Ideally you’re looking for something with a fine spray. The nozzle pictured here has several settings, the ones that are useful are “centre” (uses a small 2cm ring in the centre of the nozzle), “jet” (produces a 2mm jet of water), “flat” (produces a 5mm×1mm rectangular jet) and “mist”. Your mileage will vary.

I haven’t produced any diagrams of the system, since it’s a pretty simple concept, but I figured I’d pass this idea on. We’re thinking of building one for one of my uncles: my cousin and his girlfriend both see nothing wrong with half-hour showers. This system, you can take as long as you like… you still won’t use any more than 6L water. I’ve found using this unit, I’m able to get everything done with water to spare. Couple this with one of the solar showers mentioned earlier, and you’ve got a green way to keep clean.

Installing an in-house trigger shower

Since posting the above entry… we’ve actually installed a similar shower arrangement in our house.  Using typical washing machine adaptor fittings that you can obtain from any hardware store, you can achieve much the same thing.  You don’t have the 6L limit, which is both a positive, and negative, and you don’t have to pump it.  The photos here show the installation (left), and a close-up of the fittings in use (right).  To use this on a mains supply, you’ll need a water hammer arrester, like the one pictured in the photo — otherwise the water hammer generated when releasing the trigger will push the hose off the end of the fitting.

Hi All…

I know many of you are in the web development and security arenas… I figured I’d throw this idea up for everyone to have a look at.

Authenticating users on a website can be quite a challenge at times.  Sometimes, HTTP Basic authentication is all that’s required, re-sending the password with each request.  But the problem with this; is that someone can intercept the username and password, thus knows everything needed to establish a new session.

HTTP Digest authentication is good; but MD5 isn’t as strong as other hashing algorithms available, and more importantly, it assumes the server knows the exact password.  But what if you’re hashing the password?  Also, this doesn’t necessarily solve the issue of session hijacking.

Thus what I have come up with, is “Challenge-Response Digest Authentication”.  My rationale for this method of authentication and session management is as follows:

1. Remove the need for the cleartext password to be stored or transmitted.  Using CRDA, only the hash of the password needs to be stored.
2. The remote user still needs to demonstrate knowledge of the password (or rather, its hash)
3. Various aspects of the client, such as the IP address and user agent, are used when generating the hash, making session hijacking more difficult.

So, how does this actually work?  Well, in a web application scenario, it requires JavaScript on the client side to implement the hashing algorithm (in my case, I’ve settled on SHA1).  The initial authentication phase works as follows:

1. Remote client makes a request to log in by requesting the login form.
2. The server generates a session ID, which is the hash of the following (in this order):
   • IP Address of client (from the server’s perspective)
   • Client User Agent
   • A random salt string
3. The server responds by sending back the requested form; Included on the page in the JavaScript code, are values for a random salt and the IP address of the client.  A cookie containing the session ID could also be included — or on more advanced clients, could be determined by the client.
4. On submitting the form, client side JavaScript takes the information provided, and generates a hash of the following data (in this order):
   • IP Address of client
   • User Agent in use
   • The random salt given
   • The username
   • The hash of the password

   The cookie generated earlier is passed back to the server as well so it can look up the salt value.

5. The server receives the session ID (via cookie) as well as the username and response (via HTTP POST), looks up the salt for that session ID, then checks the following:
   • The session ID is valid for the given IP and user agent
   • The response is valid

If successful, the server generates a random nonce value, and passes this back to the client.  The session key to be used from this point forward, is the hash of the following information:

• IP Address
• User Agent
• Random Salt
• Nonce value

The nonce is then updated at regular intervals.  On an intelligent client, the raw nonce value could be passed back right at the start, and stored — the client incrementing it when told by the server.  On a simpler client, the key may get passed back and forward.

For each request after this initial authentication step, a cookie should be passed to the server containing the following string: “SessionID:SessionKey”.

Anyways… those are my ideas.  I know there are problems with this; most notably, is the effectiveness of hashing when you hash something twice.  I know that SHA1 is less effective in this instance — but the question is, how much less effective?  I figure it’s not really enough to be worried about, but then again, I know there are people who work in this field, and thus will know more about it than me.

I’m still tinkering at this stage, I’ve got a small proof-of-concept webapp going that utilises this scheme at a basic level, and I’ll keep poking at it for now, but I’d be interested in hearing other people’s thoughts on whether this would be effective against preventing session hijacking and keeping a site secure.

Hi All…

Some of you may recall a proposed patch to block the use of proprietary kernel modules in the Linux kernel.  This seemed like a good idea, and it’s one I’d support — however, I do realise there are some shortcomings in the plan.  Looking at the thread tonight, I happened to see a post by David Schwartz which suggested a trademark that could be used by the manufacturer if decent specifications were made available.

I did some thinking about this… and the idea of a small (perhaps non-profit) organisation, could be appointed, to devise Linux-compatibility standards, which companies must meet before they can claim their device is “Linux-Friendly”.  If this organisation agreed that, indeed, the device met the specs, the manufacturer would be given a license to use an appropriate logo when advertising their device to consumers, and they’d be allowed to call their device “Linux-Friendly”.  Otherwise, they’d be told how they can rectify the situation.

I’m thinking something like a 3-level system, which indicates the level of support provided by a device for Linux: (The following is obviously a rough draft)
Bronze-Level Compatibility:

1. Complete Hardware specifications must be made available to those implementing open-source device drivers
2. Technical people responsible must be willing to answer questions relating to the implementation of such drivers
3. Drivers and utilities for the device must be released under the GNU General Public License (may be dual-licensed) and should allow a user to utilise all the device’s features.

Silver-Level Compatibility:

In addition to the requirements of Bronze level, a manufacturer must offer technical support (at minimum, by email) for users running Linux.  Such support should apply to the mainstream Linux distributions (Red Hat/Fedora/CentOS, SuSE, Debian, Gentoo, Ubuntu), but may include other distributions too.
Gold-Level Compatibility:

In addition to the requirements for Silver level, a manufacturer must be actively involved in the development of the open-source driver.  Examples would include the Intel PRO/Wireless devices, WACOM tablets, HP printers…etc — all of these companies run open-source projects that develop drivers for their products.

The above is obviously a work-in-progress, and should not be considered official.  I use the Gold/Silver/Bronze system here, because many people are familiar with how it works.  If you’re new to Linux, obviously Silver or Gold level is best, but things may JustWork with Bronze-rated hardware… if you have contact with Linux-savvy people, or are Linux-savvy yourself, then Bronze will suffice.  If you don’t see any rating at all, it’s a matter of buyer-beware.
What would the logo look like?  Well… I’ve got an idea for that too:

The penguin was hand-traced from a photograph of a King Penguin uploaded to the WikiMedia Commons.  The thought is, perhaps the blue ring there could be coloured to indicate the level of support.  I have a SVG version of that image here.  Note: I ask people, to not use this logo for commercial use until proper guidelines are worked out.
Anyways… what are people’s thoughts?  I personally think it’ll make life easier for the typical Linux user, in determining what hardware to buy.  If there’s support for the concept, then it encourages through peer pressure, companies to participate, hopefully leading to better quality drivers.

Hi All… Somewhat in the spirit of this festive season, I found myself thinking about a problem last night — whilst trying to get to sleep.

We’ve all heard the stories of Santa covering the globe in a sled pulled by reindeer… Now, I’m not particularly interested in what the method of transportation is, or any other details for that matter. Rather, I was more interested in whether it was feasable, for a single individual to visit each point on the globe once in a single night.

In order to visit each point on the planet within the same “night”, one would have to exploit the phenominon of timezones. Legend has it, this mythical character does his business under the cover of night. Thus, it would be logical to assume this would be between the hours of 22:00 (10PM) and 04:00 (4AM).

The natural place to start and end such a journey would be at the International Date Line, heading westward. That is, visiting New Zealand (UTC+12), the various south pacific islands, then Australia, SE Asia..etc, scanning from pole to pole following the longitudinal lines.

Assuming this is the case, one would have to be at the international date line by 22:00, local time. The time zone west of the IDL is UTC+12. The sweep would then proceed, winding around the earth to eventually finish at the other side of the IDL at 04:00 the morning, local time (UTC-12).

Thus, we have the start and end times of our journey:

Start:	22:00, 24th December	UTC+12
End:	04:00, 25th December	UTC-12

If we convert these back to UTC…

Start:	10:00, 23rd December	UTC
End:	16:00, 25th December	UTC

The total number of hours for the journey thus works out to be:

23rd Dec:	10:00 to 00:00	14 hours
24th Dec:	00:00 to 00:00	24 hours
25th Dec:	00:00 to 16:00	16 hours

Thus, 360 degrees of longitude must be covered in 54 hours. Division of these figures gives us the exact length of time one can spend at any degree of longitude. It works out that an individual has 9 minutes to cover each degree of longitude. There are 180 degrees of latitude that must be covered in that 9 minutes, thus one could spend no longer than 3 seconds at any given point on the globe.

There is some optimisation that could be done to the route… for instance, you wouldn’t be delivering goods to every point on the planet, only those inhabited by people. Thus you could skip oceans and deserts, saving valuable time. The amount of optimisation though, looks limited. It would seem unlikely that a single individual could accomplish such a feat. Needless to say, it would be an interesting exercise for someone more adventurous than myself to attempt.

Anyway, not to sound like a grinch… that was my thoughts late last night. Those looking at a way to dispell the myth for youngsters who are getting a little old, this little piece could be useful.

At the moment, I’m not home, but I’m popping in occasionally to check on things (the joys of dialup mean I’m not able to remain online). I should be home tomorrow afternoon (Boxing day) and will be getting right back into the swing of things.

My thoughts especially go out to those working throughout Christmas Day. While many of us are sitting with family, eating a christmas lunch, or just veging out (like me), there are people out there who are still stuck at work. People like the firefighters in Victoria and Tasmania, who have been battling flames for much of the last few weeks. People keeping the various hospitals running. Those in law enforcement, and other facilities we all take for granted. It’s these people that deserve the day off more than most, but choose to keep working regardless. To you, I thank you.

So to all, whether you’re relaxing or hard at work, have a Merry Christmas… and let us all hope that 2007 turns out to be a better year than 2006 has been.

PS: Ohh, and those travelling interstate this year, if you happen to be wandering through the Jet Star screening points at the Brisbane Airport — keep in mind they are people too, stuck working on Christmas day… there’s no need to give them a hard time, they, like you, want to get home too.

I’m sure we’ve all seen it. IRC network spam, trolling, cracking… all kinds of abuse. However, unless I’ve been living under a rock lately, there doesn’t seem to be a co-ordinated approach at dealing with it.

I’m a regular user of both Freenode and AustNET IRC networks, and over the years, I’ve witnessed a number of network abuses, and I’ve seen how both networks here, handle such issues. But the issue is this, if a user abuses people on one network, what’s to stop them going and abusing another? Or even abusing people by other means, such as email?

Thus, I’m thinking… a cross-network black list would help here. It’d require co-operation between the various IRC network operators… but the idea is this. I’ll use a couple of actual examples here.

Example 1: This cretin, plonks bots on a number of AustNET channels, including #atomiclinux. Alledgidly he runs off with victim’s money and doesn’t deliver.  Nonetheless, it’s a nuisance we can do without.  Address information has been removed here:

--> itsmew (itsmew@xxx.xxx.xx.xxxxx) has joined #atomiclinux
hey people i have 2 portble notbook i need to sell immediately.  message me if interested on msn at this is just mike @ DOMAIN WITHELD
< -- itsmew has quit (Banned from AustNet: Must go now, one stolen laptop spammer)

Now, in this case it was pretty quickly dealt with.  We have had this chap go on unchallenged for hours.  I don't know if he spams other networks too.

Since this was on one network, it would be reported and would go into the blacklist, with the report comming from one network.  Owners of other networks may decide to act on the blacklist based on this first report, or they may wait for a couple of independant reporters to complain, depending on the severity of the inconvenience. They may also decide to block access to other services in order to prevent abuse via email or IM protocols.

Example 2: This troll, first spammed us on #atomiclinux.  Unfortunately though, none of us were awake, and thus he soon left...

Jul 26 00:41:55 --> l33t_h4x0r (l33t_h4x0r@vw-18983.as9105.com) has joined
#atomiclinux
Jul 26 00:41:57  i kno more about computas than u all im da best
hacker eva

A few days later, he turns up in #mipslinux on Freenode.  The log is rather long, so you can find it here instead, here he got booted out by Ralf Bächle.  The next day, he also pestered the people in #edev on the same network — unfortunately his lack of understanding of Australian fauna sent him packing.
In this situation, we now have 3 reports from 2 independant groups.  The chap would be blacklisted right then and there, and banned for an appropriate length of time.

How long would you ban someone?  Well, I guess it should depend on the number and type of past offences, as well as the number of reports regarding the current offence.  This could be based on a decaying figure that gets bumped up with each report, something like the demerit points system that driver’s licenses here in Australia have.  Thus various offences would be given a weighting, and it’d be the sum of points from each type of offence, that determines the final score.  Network admins could then decide how long to ban offenders, on a per-point basis.

This blacklist could work for other protocols too.  Why does email need a special blacklist database…?  This could be shared across a number of services.  The idea: a spammer may not be bothered about being banned on one IRC network.  But they won’t like it if every host on the internet now refuses to speak to them.  This would work well in Example 2 above, where the idiot decided to use the exact same host to do his trolling from.  The first example actually looks like a comprimised host — which is still a serious issue.  Even on IRC networks that don’t implement this… it is possible for IRC clients and bots to have such filters installed, allowing per-user or per-channel filtering, the bot only needs channel operator privileges to work.
It seems to me, that the nuisance problem won’t go away unless we actually become proactive and do something about it.  I might post more on this topic. There’s a lot of logistical issues to sort out (e.g. how do the reports get filed, how to deal with false alarms…etc.), but I do believe there is a need for some system like this.