Palm: 1992-2006?

I got dragged onto the Palm bandwagon in 2000, but the sad fact is that its main advantages over a Filofax are the following in descending order of importance:

• fits in my pocket
• holds tons of data without getting larger
• can beep at me to remind me of something
• synchronizes with my desktop computer
• runs software

There isn't one of these that doesn't apply to smartphones, and Apple forsaking Newton for iSync was the writing on the wall. While a programmer posting anonymously at OSnews is correct that PalmOS development is pretty much "compile once, deploy everywhere," he's also evading the other truth: that in order to make PalmOS small and fast, the firmware sacrifices enough characteristics of a conventional platform to make porting apps a chore.

Platform historians are going to have a hard time resisting the impulse to paint Palm's history as a flawed copy of the Macintosh. As a former Apple employee, Jeff Hawkins never objected to the comparisons made by the press.

It's an apt parallel to what happened with the original Macintosh, beyond the obvious Motorola 68K/monochrome screen. Design decisions made 10 years before held back the platform, and it took dumping nearly everything that differentiated it in favor of a more standardized OS and hardware to sustain the product name, while carefully maintaining five years' worth of compatibility to make the transition palatable. A faster CPU replaced a 68K and the OS shipping for it was essentially a recompile for the new architecture with a bytecode translator.

Unfortunately they followed Apple's mistakes as well. Spinning off software divisions, releasing too many new models with incompatible hardware and not enough improvements, and taking their momentum over Microsoft for granted.

Ultimately PalmSource made the critical mistake Apple avoided: they thought their future lay in BeOS, wasting a year trying to shoehorn its features into PalmOS before realizing they had zero clout with Palm or its hardware licensees. Cobalt died on the vine. Partners like Handera, Symbol and Tapwave either folded or switched alliances to Windows as laptops got cheaper and smaller and SCO's legal troubles made it relatively clear that Linux was a viable alternative for smartphones.

And Linux is where PalmSource claims PalmOS' future lies, with a new kernel but the same API. Unlike the OS X transition that supplied every Mac user with a fully fledged instance of BSD Unix, the Linux PalmOS won't be a Zaurus running Linux with a recognizable file structure. It's merely an architecture change to make PalmOS easier to port to as-yet-unknown smartphone platforms.

Nevertheless rumors abound that PalmSource's corporate masters have no use for PalmOS.

When everyone got on Wifi, Palm lagged until well after every one of their competitors made it a stock feature. The Windows portable platform rides Microsoft's coattails; iPods feed off iTunes' ubiquity. PalmOS lacks an equivalent lifeline, and Palm's decision to stop supporting MacOS cuts the philosophical tie that founded the company.

The LifeDrive is a solution looking for a problem, and a rushed one at that: a cold restart reformats the hard drive -- and it still can't run any OS except the one burned into it.

The most important lesson geeks and nerds need to take away from the 90s if they didn't cut their teeth in the 80s is this: the commercial computer business is not a meritocracy and it never was.

• Better products will be steamrolled by cheaper ones.
• Cheaper equal quality products will be ignored in favor of ones with dumbed down interfaces, European designers and flashy ad campaigns.
• Businesses will choose the bigger company over price, quality or dependable standards, every time.

If you're an idealist, stick with BSD or Linux.

There's no such thing as an HTML comment, and why that's important

If a comment contains 2 consecutive dashes and its document has an XHTML doctype declaration, Gecko-based browsers like NS 7 and Firefox will show the content after the double dashes. The reason is convoluted but understandable:

• In the SGML spec, <!--this is a comment--> is actually two nested sets of delimiters:

• The <! and > are SGML declaration delimiters. Declarations are usually self-enclosed structural definitions meant for a parser, not content meant for a viewer, and do not look or behave like HTML tags:
  <!ELEMENT gallery (imagebase*,image+) --an imagebase child element is optional, but there must be at least one image-- >
  Declarations abound in other kinds of SGML documents (such as DTDs), but HTML only demonstrates one in action, the doctype:
  <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
• Inside declarations, double-dashes are the actual comment delimiters (see the example with ELEMENT above).
  

• Because HTML comes from SGML, its creators saw no reason to reinvent the wheel. Instead of creating an HTML comment tag, they reused an empty SGML declaration with SGML's own declaration comment syntax. There is, in fact, no such thing as an HTML comment tag. When the W3C released the HTML spec, they only reiterated this fine grained point in a separate document comparing SGML and HTML, because they figured everyone was familiar enough with SGML's 15-year-old standard to understand this already. Double-dashes are comment delimiters in several programming languages, and "dash-dash-space-endofline" is the delimiter used by mail programs to separate your message from your sig.
  

The authors of NCSA Mosaic, the first browser, likely reasoned that in the absence of any other SGML declaration types besides doctype, there was no need to parse "HTML comments" beyond the predictable <!-- and --> start/end pair. Newcomers to the browser-writing scene unfamiliar with SGML assumed this pair was one set of delimiters, not two. The distinction is almost academic.

Doctypes change the rules. Remember, doctypes are declarations, and declarations define a parser's behavior. In their absence (or in the presence of an HTML 4.0 doctype), browsers typically revert to "quirks mode," which often means they parse HTML using the parser they had in 1999. Add an XHTML doctype, however, and the document will be parsed to stricter guidelines more tightly conforming to XML spec...

...in theory. Gecko browsers (Mozilla/Firefox/Netscape) currently enforce SGML comment syntax in the presence of an XHTML doctype, IE and Opera do not. For now, there isn't much more incentive than there was in 1999; however, as browser based XML/XSLT web apps take off, parsing the XML datasets' custom DTDs will become more necessary, and as hinted before DTDs are just a laundry list of SGML declarations. Given their common heritage and syntax, it's conceivable that a browser's DTD parser and the XHTML/XML/XSLT parser will merge enough to use the same rule for SGML comments in all contexts.

You'll see more SGML in web pages in the future, especially when web servers start using XHTML's correct MIMEtype and stop using HTML's "text/html". This change in MIMEtype triggers even stricter XML parsing in Gecko and Opera, which means that XML-nonconformant content such as JavaScript and CSS inside web pages have to be escaped with <![[CDATA]]> blocks. (If you're using external .css/.js files none of this is an issue.)

Unlike SGML comments, CDATA doesn't hide content but tells the XML parser to ignore it as raw character-based data (similar to how the PRE tag works) and thereby allow JavaScript/CSS operators like < > -- to exist without triggering the error that started this article. Remember, this is 2005 and the number of browsers today which still attempt to render the contents of style/script blocks as text is practically nil, even counting microbrowsers, Lynx, and Netscape 4.7. SGML comment hiding of style/script blocks is unnecessary and deprecated.

Fun with SLAX

OK, I've been dropping off enough copies of Knoppix to earn my Geek Scout badge for the last year. Since I'm running Debian this isn't too surprising; it's a hardcore live demo of Debian Sarge, a quick way to get Linux under your fingernails without commitments.

For a change I thought I'd try the latest SLAX live miniCD image. Slax 5.0.6 is a lot more impressive than the last SLAX distro I checked, 4.2.0. Firstly, the 5.x.y releases are based off the 2.6 kernel, so autoconfiguring your sound is easier. I was impressed to see a good selection of basic Internet apps on it... except the newsreader.

Thunderbird's a great email program. It replaced Eudora on my work desktop months ago and I've never looked back. As a newsgroup reader, it's pretty unimpressive. I never tested it much at work because my employer disabled NNTP access a few years ago so as to keep the servers from melting. At home, it's a different story. Mac users are largely stuck with MT-NewsWatcher, which is adequate but not stupendous and not updated often. Windows users are familiar with a collection of shareware and commercial newsreaders, Forte FreeAgent being a popular choice.

Where Thunderbird lags as a newsreader, ironically, is the concept "modern standards." Binaries newsgroups in the late 80s relied on something called UUencoding for attaching binaries to posts, due to the fact that like email, this method of communication was typically a 7-bit medium attempting to carry 8-bit data. One of its better features is the ability to spread one file out across successive posts. Unfortunately, UUencode lacks native file compression. Enter yEnc. Newsreaders started handling yEnc encoding as early as the mid90s, but the Mozilla group seems to have ignored it as a standard. Moreover, Mozilla's newsreaders can't handle multipart binaries.

Enter Pan. Pan is an open source newsreader whose best features are familiar to users of FreeAgent. Because it's OSS, it's available for most Linux distros. It's not in SLAX, though, and a "carry all your tools in your pocket" CD is incomplete without it.

Before this morning, I never customized a liveCD. Knoppix has a method, but it's unpleasant on resources and speed. SLAX, on the other hand, is designed to be modular and comes with both Windows and Linux tools for rebuilding new ISO images once you've tweaked it.

Pan isn't available as a SLAX 5 module (supposedly SLAX 4 modules are incompatible). However, the SLAX CD comes with a command line utility for converting Slackware .tgz installation files into SLAX .mo modules. The Pan package was converted within a minute, added live to the CD and...

Poop. Turns out it has a GNOME library dependency (gnet). Well, no prob with "Bob," I got the library .tgz, ran it through the same converter, and added it live to the CD, entered pan at a shell prompt and BAM! Pan was up and running. The two .mo files were moved to my PC's hard drive, I restarted the PC, and followed the SLAX instructions for rebuilding the SLAX ISO using the modules. Instead of reburning it I tried to put it through Bochs for testing.

Bochs suchs. I'd been told before to get QEMU and I wasn't disappointed. Far fewer configuration options required, network emulation automatic, and lo and behold, SLAX 5.0.6 with Pan installed. Only downside was, it wasn't part of the KDE Internet submenu. I added Pan to the submenu and the icon bar, then opened a shell and executed a one-line command to export all updates and changes to another .mo module, saved it to the HD, and rebuilt the image once more. (The ISO compress/build process itself is less than five minutes.)

This time, the image booted with Pan in the tray and on the menu. For kicks I added it to the equivalent menus in Fluxbox and cooked the image a third time, burning it to a CD/RW I keep around for this kind of last testing.

Getting a pocket-sized liveCD with basic tools is cool. Getting to customize it without recompiling a kernel is sweet. SLAX takes it one step farther by maintaining a webserver you can log into to save your state to, in case you aren't able to burn customized copies. This pimpslaps Windows "profiles" into last week, folks.

MCPAN is for wimps, OR libexpat and I

Hi. If you're like me, you spend most of your time trying to do neat things in Perl.

OK, so no you're not. And frankly, neither am I. However, if you're trying to do XML stuff in Perl, like slurping it into a DOM object and/or doing XSLT transformations, you need XML::XSLT. Unfortunately, it isn't that simple. XML::XSLT depends on XML::Parser, which depends on other modules. XML::XSLT also depends on XML::Parser::Expat, which isn't actually installed by XML::Parser, but libxml. Now, MCPAN will pretend it handles all the dependencies behind the one you're trying to install, but there's a hitch. Two, really.

One, MCPAN is unavailable to non-root users, because it can't do local installs of Perl modules. At home on a Debian Sarge box or my dual G5, this is not a problem. At work, where I'm using my employer's Solaris box, I don't have the privileges to run MCPAN, so I have to manually discover all the dependencies and perl Makefile.PL install each module in turn, by hand from source, being sure to point the installation at a local location.

Two, MCPAN is excellent at handling dependencies -- so long as what it needs are other Perl modules. The heart of XML work in Perl (and Python, for that matter) is a little tiny non-Perl library called Expat. It's a C library which is usually located under /usr/local.

Except that it isn't really a default installation on *nixes. Debian Sarge, yes. OS X/BSD, no. Solaris, yes but not necessarily in /usr/local where XML::Parser expects it, and it certainly isn't part of Windows, either. This is annoying enough that PHP's designers reverse-engineered their own expat-compatible library into PHP.

Moreover, MCPAN ain't apt-get. If it can't handle a dependency, it cries and wets its pants, leaving you to dredge through all its reports in hopes of figuring out what to do. At least apt-get tells you what you might need to do, rather than just suggesting you force the install.

Google "libexpat OS X" to witness the wailing and moaning of the damned (Perl, Python and others) unable to understand how they were left behind. Life is hell.

If you're one of them and you found this blog, here's what you have to do. First off, log in as root on your Mac and open a browser. Go here to get the source code archive for expat. You're going to do this old-school and compile it yourself. Relax, I'll hold your hand through this.

Now that you have the tar.gz file on your desktop, resist the impulse to double-click it. If you have, delete the folder. Open the Terminal:

$ cd ~/Desktop
$ ls
expat-1.95.8.tar.gz
Applications
[yada yada]
$ gunzip expat-1.95.8.tar.gz
$ tar -xvf expat-1.95.8.tar
$ cd expat-1.95.8
$ ./configure
$ make
$ make install

That's it. Go back to MCPAN and install XML::XSLT; the rest should fall into place.

[As nice as the OS X and Stuffit utilities are for decompressing tar.gz, gunzip and tar do what *nixes expect down to the letter, and desktop decompression utilities have been known to do strange things to filenames. WinZip, for example, creates the expat folder seemingly flawlessly, but your shell will insist to high heaven that there's no configure file to ./ even as you see it there.]

Fink's the OS X version of apt-get. The downside to Fink is that like apt-get, you're stuck with what's available in the current repository, and worse, each new release of OS X has unpleasant repercussions for Fink. When Debian has a new release, the repository tends to be ready; when OS X has a new release, there's endless bitching about what's broken in Fink.

FWIW, I ran the MCPAN XML::XSLT installs on Debian Sarge and Tiger simultaneously. Debian handled it flawlessly, only occasionally asking yes/no questions to which the Enter key was sufficient. OS X tried to do the same, but gargled on its own vomit until I manually installed expat and started over. Ironically, when I tried to use perldoc to verify that XML::XSLT was installed on Linux, perldoc wasn't there and had to be installed using apt-get.

It's conceivable that a default install of Debian doesn't have expat, either. Nevertheless, this thing should be integrated into all *nix default installs. MCPAN should be as good as apt-get.