Mark Stosberg

Today Melody was announced as a fork of the perl-based Movable Type platform. I helped the Melody project as it prepared to launch, in part advising on how to best to relate to the Perl community.  One of the stated interests of Melody is to refactor the project to use CGI::Application, which I maintain. Tim Appnel has already spelled out  a vision of what a "CPANization" of Movable Type might look like, and I've looked in depth at what the initial steps towards using CGI::Application could be.

My own vision for Melody is a code base that's very focused on publishing and content management, with all the infrastructure outsourced to CPAN modules that are well-written, well-documented, and well-tested.  The collaboration between Melody and CPAN would be a two-way code flow. While there are more CPAN modules that Melody could make use of, there are number of pieces of Melody which should be packaged as independent modules on their own and released to CPAN. One example is the great "dirification" that already exists in Movable Type. This is the functionality that turns any given string of words into a reasonable representation in URLs. It seems like an easy problem on the surface, but Movable Type has a sophisticated solution that takes into account what it means to do this well across many different languages. I also couldn't find any existing CPAN module which already takes on this problem space, so I started to extract this out of Movable Type myself and published a draft of String::Dirify. For that initial release, I ripped out all the fancy multi-language support, and there is still more significant work to be done to untangle this layer from from Movable Type. ( If you want to pick up that project and work on it, there's also some discussion of testing String::Dirify).

While Movable Type already had an open source release, I expect Melody to have  a more adventerous evolution, and I look forward to it becoming a shining star in the Perl community, not just for the exterior functionality, but also because internals have an opportunity to become an example of best practices.

I have a goal of distributing Titanium along with all of its dependencies. The vision is to have a pure perl stack, so it’s easy to unpack and start using the distribution, without worrying about binaries tied to a specific platform.

One stumbling block with this has been HTML::Parser, which requires XS and is dependency of HTML::FillInForm, which is used by CGI::Application::Plugin::ValidateRM.

I’ve been working with Ron Savage on a Pure Perl replacement for HTML::Parser, and I made good progress over the weekend based on his foundation. He created HTML::Parser::Simple, which is really is two major parts in a one. First, it provides a pure-perl HTML parser. Secondly, it also provides a specific use of the parser, which is store a representation of a HTML documentation as a Tree::Simple data structure.

In a future version, I’d like to see the Tree::Simple part split into it’s own module to clarify the parts, and to eliminate this dependency for people who don’t use it. For example, in the new sub-class I created, I don’t use the Tree::Simple object at all.

I made a short-term goal of getting all the tests for HTML::FillInForm to pass when we modify one line in HTML::FillInForm to say that it “isa” HTML::Parser::Simple::Compat” rather than being a sub-class of HTML::Parser. Then I run the HTML::FillInForm test suite and see how many tests pass and file. Currently our parser emulates enough of HTML::Parser to pass 61 percent of the tests.

The idea with “HTML::Parser::Simple::Compat” is provide an API that is compatible (enough) with the HTML::Parser 2.x API. I think the approach seems promising, but there is still more to do:

• I have a focused on getting tests to pass, so the documentation is still poor
• Perhaps my “Compat” sub-class should really be merged into the parent class. I’ll discuss this with Ron
• There are few of our own tests, as I’ve been focusing on getting HTML::FillInForm tests to pass. Perhaps more of those tests could be “ported” into own test suite.
• Performance and memory consumption have not been benchmarked.

If this project interests you, feel free to fork the project on github and start contributing code or other feedback.

Hardware recycling in Richmond took a leap forward last weekend. A small group of Richmond volunteers toured Free Geek Columbus. We learned much from visit. One valuable detail I’ll focus on today is that they run their organization on web-based, database-driven software system called “fgdb.rb”. The software is available on their intranet, allowing several volunteers to use and access the system at the same time.

fgdb.rb tracks hardware donations, volunteer time, recycling trips, and hardware distribution. fgdb.rb work with a neat tool called “printme” that takes an automatic snapshot of the all of computer system’s details, and uploads it to the database. This automates tedious data entry and creates a great reference.

I was pleased to find that “fgdb.rb” was available for free as open source software, and is designed to runon Linux. However, the documentation was lacking on details on how to get the system up and running on Ubuntu Hardy Linux, which is what we use on our server at our hardware co-op, and also on my laptop.

Free Geek Portland developed fgdb.rb for their own use and had tested installing the software primarily on Debian Lenny Linux. Now I have managed to install it on Ubuntu Hardy Linux, and have submitted a patch back to the authors to update the documentation to help others do this as well. You can see my current version of the installation instructions, but my changes should be merged into the main fgdb.rb git repository soon, and I recommend checking there for the current version.

I’ve also published a few photos from the Free Geek Columbus field trip.

I just saw a patch I created on github attributed to “mark@freekbox.(none)”.   That’s nothing like an email I use and it’s annoying that git not only selected this as my identity to use in the commit log, but then didn’t even run it by me for a reality check. Now that I’ve committed that patch and pushed it to github, there’s no real way to alter that. Extra annoying.

By contrast, the first time you record a patch in a darcs repo, you are prompted for your e-mail address in a friendly way:

$ darcs record
Darcs needs to know what name (conventionally an email address)
to use as the patch author, e.g. 'Fred Bloggs <fred@bloggs.invalid>'.
If you provide one now it will be stored in the file 
'_darcs/prefs/author' and used as a default in the future.  
To change your preferred author address, simply delete or edit
this file.

What is your email address?

Easy and pleasant.

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 mikeh@perusion.net).

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.

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.

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.

Here some more notes from testing my zn5 phone. Photos I’ve taken with it are sprinkled throughout.

• The built-in e-mail client appears not to be open source, although much of the phone is. One disappointment with the mail client is that it appears that “POP before SMTP authentication” is not implemented. Strangely, it seems to identify itself as “Moto-A760” as part of making SMTP connections.

• Mujmail is a decent, fully open source mail client that runs on the phone. It includes the basic usability touch of having keyboard shortcuts for key functions. But as a Java application, Mujmail is sandboxed, meaning it’s prevented from accessing files that it did not create, like reading or writing e-mail addresses directly back into the central address book that the phone uses. Also, because there is no way to make it the “default mail client” on the phone, the “Simple Sharing” feature to easily email a photo can’t be integrated with it. This is the java mess again.

• There reports that 8 GB microSD cards work with it, although it officially supports a max of 4 GB. Amimu’s review of the ZN5 echos the 8 GB claim, and includes many screenshots.

• I got the ability to telnet into the ZN5 working. That’s documented now on the OpenEZX wiki.

• With telnet access, in theory manually fixing the Java permissions is not particularly hard, bit I keep getting out of memory errors.

• The MidpSSH client doesn’t support ssh tunneling, but it shouldn’t be too hard to add. Any takers?

• jmIRC is tested to work as IRC client.

• I’ve now used it combination with the generic “ES-388” Bluetooth USB adapter, as a way to transfer files to a laptop running Ubuntu Linux 8.04 (Hardy Heron). It was easy enough to send or receive a single file, but I’m not yet able to browse the phone as if it was shared folder.

When trying to install some signed applications like Opera Mini on the ZN5
I get "root certificate missing", and the application fails to install.

This message refers a certificate that is used to confirm that the application is from a legitimate author. Based on confirmation of a legimate author, the
signed application then has the possibility of being allowed to some more
security-sensitive operations, such as reading and reading files that the
application did not correct.

For background on this issue, I recommend this post on Midlet signing on the Javia blog, and the post How MIDlet Signing is Killing J2ME.

These notes concern the unbranded Motorola ZN5 camera phone. The unbranded phone includes the software that Motorola distributes with the phone, rather than the software that T-Mobile puts on the phone when it is branded for T-mobile.

The phone is available with the original software directly from Motorola. I found mine on on eBay. On eBay, you have to be careful to insure that you are getting an unbranded phone, and not just an unlocked T-mobile branded phone.

For more ZN5 details, you may follow my ZN5 bookmarks as I create them.