Mark Stosberg

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.

Joining several others, I'm moving my Perl blogging off of use.perl.org. My personal Perl blog posts will be here.

I sometimes write about Perl on my company blog here.

On my own site, I'll be able to see my own traffic stats, control the SEO, and provide a unique design. I think having a plurality of blogs promoting and discussing Perl is a good thing.

My perl feed also appears as one of the feeds on Perl Sphere.

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.

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.

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. CGI.pm 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. CGI.pm 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.pm)

Security

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. CGI.pm and CGI::Simple both avoid the injection attack by URI-encoding the cookie values, (a spec-compliant solution).

Convenience

CGI.pm 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 CGI.pm uses to store cookie values. (This detail is not dictated by the cookie spec so both value formats are “spec compliant”).

Conclusions

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 enigeneered version of CGI.pm. Certainly the overall the design and focus of CGI::Simple is an improvement. But the reality is that CGI::Simple was forked from CGI.pm in 2001. CGI.pm 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.pm. CGI::Simple is perhaps more like a lighter, tighter alternative to CGI.pm as it existed several years ago.

The mature-but-maligned CGI.pm 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.

Today the first HTTP::Engine release appeared that replaces Moose with Shika. Shika provides the essential class-building tools that HTTP::Engine needs with a Moose-compatible syntax, and strips out the rest of the magic.

The performance improvement was dramatic. The "Hello World" time dropped to 0.19seconds on the same hardware (almost 10 times as fast!) and the memory usage dropped to 6.6 Megs.

Catalyst is currently slated to use Moose in the next major version. Now that HTTP::Engine has switched away from Moose for better performance and memory savings, will other projects follow suit?

With darcs, it’s easy to push a limited number of patches, instead of everything in the branch. There are several ways to do this:

The default is interactively:

$ darcs push 

Tue Jan  1 22:33:33 EST 2008  Mark Stosberg <mark@stosberg.com>
  * RT#1234: new subsystem
Shall I push this patch? (1/1)  [ynWsfvpxdaqjk], or ? for help:

Even if you’ve never used darcs, before it’s easy to figure what to do. You might press “?” for help:

How to use push:
y: push this patch
n: don't push it
w: wait and decide later, defaulting to no

s: don't push the rest of the changes to this file
f: push the rest of the changes to this file

v: view this patch in full
p: view this patch in full with pager
x: view a summary of this patch

d: push selected patches, skipping all the remaining patches
a: push all the remaining patches
q: cancel push

j: skip to next patch
k: back up to previous patch

?: show this help

I like to use “x” to review which files I’m about to push, or “p” to review the patch in a pager. I haven’t yet found that git has this kind of review possibility built into the workflow. Also with darcs, it’s easy to push just one patch:

$ darcs push -p 'new subsystem'

It’s also very useful to push all the patches related to a specific ticket or project:

$ darcs push -p 'RT#1234'

In darcs we call that spontaneous branches because you get some benefits of a branch, without actually doing anything to create one.

The related user experience with git push is worse in a couple significant ways. First, I don’t see a way to use the human readable patch name. A separate step is required to review ‘git log’ to find the SHA1 hash, which must be copy/pasted, because there’s no way you remember it like a human-friendly word or phrase like darcs allows.

Armed with that, you ready to start the four step process that git requires to push specific patches, by creating a new branch, ‘cherry-picking’ to it, doing the push, and then deleting the new branch

$ git checkout --track -b <tmp local branch> origin/<remote branch>
$ git cherry-pick -x <sha1 refspec of commit from other (local or remote) branch>
$ git push origin <tmp local branch>
$ git branch -D <tmp local branch>

It’s because of a number of annoyances like this that I continue to use darcs whenever I can, and git when I have to.

There’s a lot of trash talk among professional web programmers regarding using vanilla CGI, like Stevan Little’s recent comment “There is no excuse to still use vanilla CGI as it is simply just a waste of resources”.

As an experienced professional website developer myself, I find that CGI has its place. First, let’s recap what we’re talking about.

Many of the key organizations I deal with in my daily life now run Linux on the desktop. First, let’s taken as given that I run it home and work and my wife runs it, too. Many other organizations in Richmond, Indiana have switched over to Linux on the desktop as well:

• My church has three computers, one for the pastor, one for the office manager and one for the hardware recycling program. They all independently chose to run Linux. It’s a popular choice in the congregation as well, as with more than a dozen systems in use by members ranging from 4 years old past 64 years old.
• My doctor, Kurt Ritchie, runs his business exclusively on Linux
• My lawyer, Thomas Kemp, runs his law practice primary on a Linux-based groupware solution now, and travels with a Linux laptop
• My grocery store, The Clear Creek Coop, runs exclusively Linux on the desktop. They bought a Dell laptop with Ubuntu pre-installed.
• My bike shop, Ike’s Bikes, now runs exclusively Linux on the desktop.
• A local high school, North Eastern, runs primary Linux on the desktop, as part of trend of over 20,000 Indiana students running Linux.
• A local college, Earlham, features Linux labs
• Local graduate schools, Earlham School of Religion and Bethany Seminary, also use and promote Linux on the desktop
• A local computer store, System Solutions, has had a stack of Linux install disks to give out, and pledges interest to support Linux more in the future, citing frustrations with Windows Vista and Windows malware problems in general.

Those are the commercial desktop Linux desktop uses I can think of off the top of my head. Among home users, I’ve found that a number of people are installing Linux themselves now, from farmers to bloggers.

Microsoft may still have majority share on the desktop here, but in my world they are losing ground fast to the benefits of open source software.

Who has switched in your world?