part of me likes to make life difficult for myself, insisting on running old hardware until it won't run anymore, and being a grumpy unix curmudgeon in general. I can relate to the insect-ridden shaman described in the unix-hater's handbook. the brave new web 2.0 world is browser based, and it seems to me like yet another set of buzzing flies and stinky poo to deal with. I've gotten used to the existing ones, thanks.
I was asked to look into content management systems on behalf of one of my club's members, who is interested in redoing our club's website. his suggestions were drupal, joomla!, and plone. most CMS systems are built with mysql as a backend, which would be fine, except that mysql still doesn't run correctly on the alpha architecture. I don't know if x86-64 is any different, but I get a steady stream of unaligned access warnings, and flat-out refusal of mysqld to run on my NetBSD-running alpha. by contrast, postgres just works. I was ready to kill joomla! straight away since it has an exclamation mark built-in to its name. "... because open source matters". obviously portability doesn't matter to joomla!, which only supports mysql according to the minimum requirements posted at http://help.joomla.org/content/view/34/279/ . plone is built around zope. zope so infuriated a friend of mine a while back that he created http://zope-is-evil-666.idyll.org/ . his experience in this arena easily trumps mine, which is enough to give me pause with any project utilizing zobe, but I figured that his objections had been addressed in the last seven years. however, after reading further, it appears that plone has its own idea of how databases should work, and doesn't use a SQL backend out of the box. http://plone.org/documentation/faq/plone-relational-database thanks, zopers, but I have better things to do than wank in python. this left drupal. drupal's installation was fairly painless: create the database; set up some rewrite rules in apache; go to the magic drupal page; tell drupal where the database is; start plugging away. the fact that I had to configure drupal through the web interface was a warning sign. after poking through web configuration, it hit me... drupal is set up for content management entirely through a web interface. <insert wincing here> can't I just edit some templates for layout out of band, post content >from the command line, and have some separation between the input and output stages of my CMS? web input methods are _STILL_ the simplistic hack they always were, and the last thing I want to do is handle content generation WITHIN A WEB BROWSER. I want to view it in a browser, but not generate it there. I'll edit XML, even. drupal does not appear to accomodate. I hate it. I hate all the CMS software I've examined so far. I'd go back to bashing my stones together and dealing with static content, except that I really do want to separate content from presentation and store content in a form which can be indexed in multiple ways. (symlinks in a filesystem are difficult to manage.) I'd love to tag my rants, content, and pictures, see RSS feeds on a single page under my domain, and be able to generate pages based on lookups from a content store. wordpress can bite me too. "drop this tarball in a directory and see what breaks" does not appear to be a good upgrade strategy. (trojanned distributions are also of some concern.) it's almost as if everybody who learns PHP goes through a "let's write a CMS" phase where supplication at the idol of browser is a necessity. fsck the browser. if I actually get around to drafting a requirements list for a CMS, and implementing said system in a compiled language, hell must be a chilly place indeed... -- Aaron J. Grier | "Not your ordinary poofy goof." | agr...@poofygoof.com The United States is the one true country. The US is just. The US is fair. The US respects its citizens. The US loves you. We have always been at war against terrorism.