Category: Technical

Thumbs Down on Red Hat 9

I spent a good part of today trying to setup mail server on my remote Red Hat 9 machine.  It came with sendmail which everyone agrees is a bloated sloth so I replaced it with Postfix using the instruction given in this document which probably represents the daily life of a Linux user.  No problem there.  I have heard that Maildrop and Courier IMAP combo was a good match for Postfix, so I looked for the RPMs via Red Hat's up2date.  Nothing.

I managed to find the source for Maildrop and tried to configure the build.  Nope.  cpp, C preprocessor, was not installed.  Again, not available via up2date.  Got it via rpmfind.com and installed OK.  Back to configuring Maildrop.  OK again.  Now build fails because g++ is missing.

Earlier, I had to install gcc-compat package because my server came without gcc installed.  Funny.  Apparently, that gcc-compat package didn't include g++.  Latest gcc-compat available on RH9 was an old version of gcc also.  So I considered whether to replace gcc-compat with the latest gcc package from gnu.org.  gcc-compat is an ominous name.  It implies that regular version of gcc is not compatible for some reason.  I punted and rigged Postfix to forward mail to my personal e-mail account with my ISP [1].  Urgh.  I didn't even get to Courier IMAP.

Red Hat distributions seems to have, in general, oddities that cause problems with many packages out there despite being the most popular Linux distribution.  Versions of packages bundled in Red Hat distributions or available for download via up2date are often much older than the latest.  Sometimes this can be dangerous.  For example, latest OpenSSL package available by up2date was 0.9.7a which has serious bus including the ASN.1 bug.  Red Hat 9, in particular, is a bundle of trouble because it uses NPTL library unlike other versions and distributions.

Stay away from Red Hat 9 everyone.  If possible, stay away from other versions as well.  Whatever performance NPTL brings, I can make it up more than enough by getting another cheap Linux box.

PS: Only bright spot in all this is the joy of using Webmin.  It really is great although documentation sucks.  There are so many great Webmin modules out there that one can only smile with satisfaction.

[1] One stupid Linux trick I learned was that in order for 'luser_relay' setting to work, you have to define 'local_recipient_maps' to be nothing.  Leaving it commented out is not the same.  What kind of talented idiots write sh*t like this?

Open Source Java Projects

I visit Carlos E. Perez's Manageability blog about once a week because he occasionally posts useful list of open source Java projects along with terse yet revealing comments.  I thought it might be useful to list the lists.

Carlos is a bit heavy on the Java cheerleading, but these gems are worth the visit.

Eolas Legacy

The picture of post-Eolas era has become clearer with Microsoft's Changes to Default Handling of ActiveX Controls by Internet Explorer and it's not pretty.

To avoid violating the disputed Eolas patent, web developers have three options:

  1. Generate <OBJECT> tag using JavaScript.
  2. Add a special (read non-standard) attribute.
  3. Require users to click OK on a dialog.

It's like some jerk patenting bottled beer and forcing everyone to either pour canned beer into a bottle or stop calling it beer.  Otherwise, the bottled beer will ask "Are you sure you want to drink me?".  Sheesh.  By the way, the jerk's name is Mike Doyle.

Here is a beer-belly's salute to Your-Ol'-Ass, er, Eolas.  *Burp*

RSS-Data Clarified

It seems that RSS-Data is confusing to some people (hello Matt ;-p) so I'll attempt to clarify.

RSS-Data is a proposal to create an RSS 2.0 extention that allows arbitrary instances of generic data to be embedded in RSS 2.0 feeds without requiring introducing new elements with their own micro-schema and namespace.

It is just a proposal at this stage meaning there is no concrete format yet.  Examples out there are just sketchs of what it might look like.

It is an RSS 2.0 extension that adds a new way to extend RSS 2.0, an extension extension, if you will.

A typical way to extend RSS 2.0 involves adding a set of new elements belonging to a namespace like this:

<item>
  <link>blah</link>
  <description>blah</link>
 <my:element xmlns:my="http://...">value</my:element>
 <your:element xmlns:your="http://...">value</your:element>
 <Signature xmlns="http://www.w3.org/...">...</Signature>
</item>

Note that 'my:element' has it's own schema and a namespace, knowledge of which leaks to the application layer even if RSS parsers pushed up all unknown elements up to the application layer.  At application level, these new elements and attributes have to be fetched and navigated somehow.  Unfortunately this is cumbersome for most languages.  Think about having to compare URL to distinguish elements and how one could differentiate attributes from child elements.  XPath could be used, but there are performance and readability penalties.

An extension by RSS-Data might look like this:

<item>
  <link>blah</link>
  <description>blah</link>
  <data xmlns="http://rss-data.org/..."
 name="signature" type="structure">
 <data name="value" type="binary">Akjdfaiwjfqeesdah=</data>
  <data name="cert" type="binary" transform="base64, asn.1">
 askjdfa;kljalkjweqasdf
 </data>






 </data>


</item>

With just one legal RSS 2.0 extension that adds one new element plus a set of attributes, I can add arbitrary data into RSS 2.0 feed.  While this rendition of RSS-Data removes the need to define new elements and associated namespace for each type of data, there are two problems:

  • Language bindings are still problematic.  'Name', value, and 'type' can be mapped fairly well to language specific features, but mapping 'transform' is difficult.  I suppose 'transform' can be removed, but it is nice to have.
     
  • Existing XML standards like XML-Signature are not being used.

Solving the first problem involves turning all attributes into child elements and mapping and pushing child elements down another level.  This is essentially what XML-RPC and SOAP has done.  A nice bonus is that this approach works very well with modern scripting languages (i.e. item.signature.cert[0].name).

The second problem is harder to solve and RSS-Data proposal is silent on the problem.

Obvious use of RSS-Data is shoveling data with dynamic structure (i.e. database query result) out through RSS 2.0 feeds and having the data be displayed in a scrollable grid or a nice chart by RSS clients without them really understanding what the data is.

Given that RSS-Data is ultimately just an extension of RSS 2.0 and does not prevent other extensions, I think RSS-Data is a Good Thing.  Let people vote with their feet.

RSS-Data

What I like about Jeremy Allaire's RSS-Data proposal:

  1. Reduced need to change RSS schema, binding, and parser to support new payloads.
     
  2. Possibility of reusing XML-RPC code and SOAP code.
     
  3. Arguably faster to parse.
     
    In my experience, element-rich XML documents are faster to parse than attribute-rich XML documents.  But this is not important given readily available processing power at the consuming end.

What I dislike:

  1. Ugly and harder to read although not as bad as RDF.
     
  2. Increased need to change RSS application to support new payloads.
     
  3. Contextually inconsistent and verbose.

    <name>
      <name>value</name>  <!– implicit style –>
      <name>
        <name>name</name> <!– explicit style –>
        <value>value</value>
      </name>
    </name>     

With RSS-Data, developer's attention will shift from RSS parsers to RSS application frameworks capable of supporting new payload types and routing mechanics via plugins.  Despite irksome cosmetic downsides of RSS-Data, I like that.

Only problem is that one can make the same arguments for RDF which makes me a hypocrite.  No news there, but I find it ironic to see RDF folks attacking RSS-Data.

Update #1 – 2003/10/08 10:21AM PST

Text moved to RSS-Data Clarified because it was too long.

Red Hat 9 and IBM JVM 1.4.1

For an hour, I tried to install IBM JVM 1.4.1 on my Red Hat 9 server without success.  Uploading 61Meg RPM file took a while via SFTP, hopefully because I haven't tweaked the bandwidth throttling on SFTP daemon and not due to some bandwidth congestion at the server end.

The trouble started when I gave the file to RPM.  It was my first invokation of RPM.  That was fast, I said.  Output said the package was installed but nothing about where it installed to.  After stumbling around the file system and books, I found the command to get information from the package.  Apparently, the file was relocated to /opt/ directory.  That's strange, I said.

I thought maybe I am supposed to run a script there to install for real.  Nope.  I browsed the docs and read the readme file which basically said IBM JVM 1.4.1 is not compatible with Red Hat 9 due to thread library change in Red Hat 9.  Great, isn't it?  I decided to post this info here because I couldn't find it on the web.  I hope it helps someone out later.

Linux is for geeks with very high tolerance level in all things except Microsoft.

Update #1 – 2003/10/06 1:49AM PST

I don't know exactly how it happened, but both IBM and Sun's JVMs runs just fine on my Red Hat 9 server now.  Weird.  I ran Tomcat on all three JVMs (IBM 1.4.1, Sun 1.4.2, Blackdown 1.4.1) without a glitch.

BTW, Tomcat 5.0.12 has been solid so far even though it's a beta.  Cool admin consoles are nice and JSPs are snappy.  Reading through Tomcat developer list and bug database, there are no serious bugs remaining.  In fact, Tomcat team is talking about whether to release 5.0.14 now or wait until JSP 2.0 and Servlet 2.4 API are approved by Sun.  They are not expecting any more changes in the spec and wants more people to bang on Tomcat 5.0.

I recommend that you try it now so the poor team can have some bugs to fix.  Boy, I wish Sun had this sort of problem.

Glut of Workflow Engines

A good measure of hype is the number of open source projects.  Light attracts moths.  Hype attracts open source developers.  From this perspective, it is disturbing to see how many open source workflow projects there are.  According to Carlos Perez's Open Source Workflow Engines Written in Java post, there are at least 14 in Java alone.

While some are just component-level projects, there are some starting to approach commercial level quality by providing user-friendly workflow design tools.  Regardless of their quality, I believe the noise they project into the workflow software market is substantial enough to affect commercial workflow software vendors like the way sea-level affects civilization.