computer hardware co-op launches
Richmond High School student Jonathan Ulrich helped to set up and test a thin client lab.

This is an open letter to the Richmond, Indiana Community School system. There is a school board meeting coming up to discuss how to fund technology upgrades with a dwindling budget. I strongly suggest the school system consider Linux thin client labs as part of the solution. Thin client labs are made with low-cost, low-power, low-maintenance stations and have many advantages.

A Linux thin client lab is already being used successfully in the area. Four years ago in Brookville, Indiana a thirty-seat thin client lab was set up at St. Michael’s School. Initial costs were kept low through low hardware requirements and the use of free, open source software. The lab is still in use four years later. Minimal maintenance has been required, including zero virus/spyware/malware infections due to the use of Linux.

Thin clients don’t need a hard drive, which are at the top of the list of the common parts to fail in a computer. Instead, every workstation pulls all the software it needs from a single server, meaning there is a one computer to maintain software on in the lab, not thirty. So St. Michael’s unplugged the hard drives in their machines, cutting down on noise in the lab, and well as reducing the energy consumed by the lab.

I recommend checking for yourself on this success story. For the administrator perspective, contact the Principal, Ken Saxon at (765) 647-4961. For the IT perspective, contact Mike Heins, who set up the system and maintains it: (765) 328 4479, (also at

The use of Linux in Indiana schools is not new, either. In 2005 the state of Indiana launched a state-wide initiative to put Linux on the the desktop of 300,000 Indiana high school students. Locally, Northeastern High School has made significant use of Linux.

I’ve already hinted that thin clients have lower power requirements and can be lower maintenance. The hardware needed for thin client workstations is not special. In fact, old desktop hardware that would otherwise be discarded for being slow is ideal. In a thin client system, the performance is determined by the server, and the workstation needs just a minimal amount of resources to connect to it.

With these principles, I built a four-seat demonstration lab at my church, using three computers so old that a local computer store gave them to me. I paid only $50 for a memory upgrade for the server. As a thin client lab, these old computers came back to life and performed like modern desktops, although they ran Windows 98 in their former lives.

Because a school lab setting is ideal place to deploy a thin client network, there are several projects that focus on exactly this, and give away the required software. These include K12Linux and Edubuntu. Both are exceptionally easy to try out and install, from personal experience.

Pursuing thin client now is a strategic move that works towards the goal of the City’s Comprehensive Plan to be a “Sustainable City”. The plan is fiscally conservative and technologically advanced, with low impact on the environment and energy bills.

unshoveled sidewalk in Richmond, Indiana I support Richmond, Indiana’s official to plan to become a sustainable city and I hope you do, too. Part of this vision includes better support for walking and biking around town. With 10 inches of snow on the ground, clearing our sidewalks is simple way that we can promote walkability in our town.

City ordinance requires that we have our own sidewalk shoveled by 10 AM– and keep it clean– or risk a $50 fine. Today I went further than that– I made sure this side of my block was walkable from end to end, not just from my property line. I challenge others to do the same: insure the that the sidewalk is sufficiently shoveled on your block to walk from end-to-end.

It could mean a little more exercise for you, possibly a pleasant surprise for a neighbor, a definite gift for our postal workers, and a welcoming sight for anyone who might walk by.

Free Geek Richmond?
panorama of our hardware coop, January, 2009

The Richmond Church of the Brethren provides free space for me and some other volunteers to operate this "Hardware Coop". We take in computer hardware that people are ready to get rid of. As our resources permit, we test it, spec it, label and inventory it, install Linux and provide "hardware grants" to those who need cheap or free hardware. What we can’t re-use, we recycle.

We also learn a lot in the process. Jonathan Ulrich helped us put DD-WRT on a wireless router so it would function as a repeater, providing internet access to the room.

I built a four-seat thin-client computer lab with good performance using LTSP and Edubuntu. The thin client approach allowed us to bring 366Mhz/64Mb systems back to life by connecting them a reasonably powerful server. (Which was just an XP desktop that had been slow for lack of a memory upgrade). When the lab setup is stable again, perhaps we’ll be able to grant the entire 4-seat lab to a non-profit.

With our new reliable internet access, we are able to be much more productive with our troubleshooting, research and general organization.

Soon I hope to be organized enough to take on more volunteers to share the fun and satisfaction of hardware recycling. (Not to mention preferred access to the latest hardware donations!). Also, our current resources prevent us from accepting donations from the general public. So far, the congregation and our friends have provided enough e-waste to keep us busy!

We could use help getting the valuable parts of our inventory into a spreadsheet, so we can publish what we have give out as hardware grants.

Soon I hope to organize a field trip to Free Geek Columbus. They are a model of what our future could be. I expect the visit could be inspirational as well as educational.

Derrek on the EZ-Sport recumbent Titanium 1.01 was released recently. The new release include includes a README with clearer instructions on how to install Titanium if you are not already familiar with installing modules from CPAN.

Initial feedback on Titanium has been positive. A couple recent quotes from users: “Titanium is much, much simpler [than Catalyst] and has the advantages that entails.” 1, “CGI::Appplication and Titanium (including modules like HTML::Template and HTML::FillInForm) are simple to use, work with all of the authentication stuff that I interface with, and scale perfectly for the number of users that I typically have.” 2. Simplicity is a goal of Titanium and our feedback confirms our success with it.

Jaldhar Vyas has also made important contributions to making it easier to get going with Titanium. He has packaged Titanium for Ubuntu, appearing first in the upcoming Jaunty Jackalope release. He also released a new version of Module::Starter::Plugin::CGIApp, which includes a “titanium-starter” script used to start Titanium projects. This modules comes as a part of installing Titanium and its dependencies.

To test the performance of Titanium, I made a simple benchmark to compare it with some other Perl systems in vanilla CGI. It confirmed what I already knew:Titanium runs fine in vanilla CGI as well as scaling up persistent environments like FastCGI and mod_perl.

When the results first came out, HTTP::Engine had by far the worst results– unacceptable performance for vanilla CGI. But soon afterwards the developers embarked on a successful effort to improve the performance in vanilla CGI. In just a few days time, they had a version that benchmarked nearly 10x faster, while still keeping all the essential features. This is the philosophy that CGI::Application and Titanium have always had– we provide the essential features you need with low overhead.

To help out new users get started with this kind of web development, Mark Rajcok created a CGI::Application Tutorial and Jumpstart Application. He used CGI::Application and some plugins to create a solution much like Titanium that performs well in a typical shared hosting environments. He includes a demp, so you can see test the performance for yourself. Mark is another person who appreciates the benefits of vanilla CGI.

With this positive initial feedback I plan to continue my work on making Titanium even easier to install by shipping all of its dependencies with it.

This weekend I spent some quality time with HTTP Cookie Specs ( RFC 2109 and RFC 2695 ), and looked closely how at the cookie parsing and handling is done in three Perl frameworks: Titanium, Catalyst and Mojo. Titanium uses CGI::Cookie by default, while Catalyst uses CGI::Simple::Cookie and Mojo uses built-in modules including Mojo::Cookie::Request.

I’ll look at these solutions through the filters of Standards, Security, and Convenience.

Standards: Max-Age, Set-Cookie2 and commas

Max-Age is cookie attribute which gives the expiration time as a relative value. This is considered a more secure replacement for the “Expires” header, which gives the time as an absolute value, making it vulnerable to clock skew on the user’s systems. and Mojo support it, but CGI::Simple does not. This is potentially an issue for Catalyst users, if they believe they have Max-Age support because the documentation refers them to CGI::Cookie, but they actually don’t because they are using CGI::Simple::Cookie.

Set-Cookie2 is a standard from 2000 to replace Set-Cookie, which became a standard in 1997. Mojo is the only of the three that supports it. However, Set-Cookie2 never caught on. Firefox 3 doesn’t even support it, and neither does IE 6. Still, I like the idea of deciding for myself about supporting new standards, rather than having tools that only support older standards. Mojo wins here.

The RFCs say that servers should accept a comma as well as semicolon between cookie values. and Mojo comply here, CGI::Simple does not. (I’ve submitted a patch to address this, along with a few other places I felt CGI::Simple cookie parsing lagged


CGI::Simple cookies are potentially less secure because they lack “Max-Age” support. Mojo’s cookie implementation appears to be vulnerable to an injection attack where untrusted data in a cookie value can write a new HTTP body. I have notified the developers of my findings there. and CGI::Simple both avoid the injection attack by URI-encoding the cookie values, (a spec-compliant solution).

Convenience and CGI::Simple share several convenient user interface features which Mojo currently lacks. They allow you to set multiple-values for a single cookie, including setting a hashref. They also provide a convenient shorthand for giving expiration times, like “+10m” for “10 months in the future”. Mojo lacks these features. If you have a Catalyst app that uses the multiple-values features, a port to Mojo could mean a painful cookie transition, since Mojo does not have a built-in understanding of the format uses to store cookie values. (This detail is not dictated by the cookie spec so both value formats are “spec compliant”).


Sebastian Riedel, the Mojo author, promotes Mojo as being focused on standards. From my findings here, I have to say that I agree that Mojo is a leader here, currently at the expense of a potentially serious security issue, and lacking some usability features that the others offer.

CGI::Simple has a reputation but being a lighter and better engineered version of Certainly the overall the design and focus of CGI::Simple is an improvement. But the reality is that CGI::Simple was forked from in

  1. has received many improvements since then including improved cookie handling, like adding support for “Max-Age”. However, CGI::Simple doesn’t seem to make a point of tracking and merging improvements that originate in CGI::Simple is perhaps more like a lighter, tighter alternative to as it existed several years ago.

The mature-but-maligned comes out fairing the best for cooking handling in my opinion. It did not have any of the potential security issues I found with the other two, and it has a range of convenient methods for cookie access.

But as a final note, I encourage to you check with the specific projects for the most current information, as some of the deficiencies I found here may already be addressed.