Linux Installation - Simpler than ever

I had my share of Linux installation in the past, starting with floppy disk based 15 years ago, and used various installation methods, including CD, DVD, bootp based network, local file system, and so on. I am used to things breaking, but of course, I enjoy if everything works well.

This week, I stumbled over a package called UNetbootin. Think of it as a Windows setup.exe for installing Linux. It is actually that simple. You may choose between Fedora 8 (as of this writing, less than one week old), OpenSUSE 10.3, Ubuntu 7.10, Debian Etch, and even a simple partition manager. If you do not have Windows installed, you can choose a different host system: There also are .rpm, and .deb files, as well as a simple shell script.

I am definitely impressed. Most possibly, I will use it for my future installations as well. It's worth spreading the news.

Crunchy at the outside and a sweet inlet

This is Anjas and Maries preferred dessert: It's a french treat called Crème Brûlée. It's crunchy at the upper side (due to the burnt sugar). (In the case of Averell Dalton, the crunchy thing would most possibly be the bottom.) Don't ask for the inlet. (Cream, eggs yolk, more sugar)

I definitely prefer a double espresso, but I like the fun to use the burner. :-) If you are in company, it's quite likely that the men will sooner or later be scaffling over its ownership.

Why I am writing this? It reminds me of one of my favourite Gary Larson strips: An igloo and two ice bears, one of them saying "Oh, I like these things. Crunchy at the outside and a sweet inlet."

How to become an Apache committer

I knew there are different possibilities to become an Apache projects committer. In some cases, you've got to earn it hard, in other cases its easier.

Recently I have learned the easiest way, though: You simply have to be the member of the right project. In my case this would be RAT or Plexus. Done nothing, and having two more entries on the profile.

But while we are at it, in it's extremely good that these are joining the ASF. Or should I say "coming home"? I never understood Roberts decision to build RAT at Google. At least, I was unable to see any advantages. Yet another bug tracker to learn, another code repository to maintain, and a completely different way of releasing distributables. Same goes for Plexus at Codehaus. I agree that it makes sense to host the Mojo project at Codehaus: In that case it is most possibly more important that new developers can easily be added.

In both cases, I am personally happy about the decision. In the case of RAT, this will make it much easier to integrate the RAT core and the rat-maven-plugin. And if Plexus will be called Apache Composer, then I'll possibly be able to use it in projects at work as a lightweight alternative to Spring. (It is always easier to ask for use of "Apache Something", compared to "sf.net/projects/foo", or "bar.codehaus.org".

While we are at it: How about moving the Maven issue tracker to issues.apache.org, where it belongs?

A cobbler should stick to his last.

Yesterday I felt really sick and decided to stay in bed. It turned out to be an excellent idea and I could really use some hours of additional sleep below two blankets. (Initially, I had three, but when Hobbesy joined me, she demanded her usual underlay.)

Inevitably, after some hours I felt much better and started to get bored. So I picked up the Digital Fortress by Dan Brown and started to read. I quite liked his previous books. I understand that a novel author has got a poetic license and didn't mind when I found him using his before.

This wasn't the case in the digital fortress. It may be that he was covering an area of my expertise, but my impression is that he simply understands much more of history (Angels & Demons, and the Da Vinci Code), or natural science (Deception Point) than of computer science and mathematics. In fact, the reading was amusing at best. The idea that you can catch the exponential powers of a "million bit key" by a linear increased number of CPU's. The impression that a firewall can be "weakened" by consecutive attacks like a true wall. But the best one was most possibly the "X Eleven transport protocol".

Well, I hope that Mr. Brown returns to his last when the Solomon Key is published. :-)

What a difference ten days make ...

Here they are again: Frodo, Sam, Merry and Pippin are the preliminary names that I prefer. Anja sticks to Nicki, Nacki, Nucki, and Necki. We both agree to consider the other's names as silly. :-)

Initially, they have been as thin as their mothers legs. The length was about the half. Nowadays, the four little mothersuckers have doubled both size and length. Don't ask about the weight. In ten days.

The eyes are now open. Although approximately half of the time is spent for drinking Mama empty (I hope they stick to the milk.) and the other half is left for sleeping, they start to rob, crawl, and tussle with each other. A finger held to their nose is replied with resolute hissing. Quite comparable to Marie, who also tries rather hard to be impressive when she declares herself as a grown up. Of course, she also enjoys to visit and cuddle the cute bunch. Unfortunately, the nest is situated on the attic, quite close to the toys and clothes she had in the past. In other words, any visit is typically ending with a discussion whether or which piece she may bring down. Therefor, fun is a little bit reduced.

If you notice a brown blot at the top of the picture: That's been Gandalf's blood in the birth. Of course, we did not exchange the towel: The babys definitely prefer this one's smell and sense and would possibly be shocked by a completely different environment. Apart from that, the nest is absolutely clean. Better not to enquire how Mama Gandalf achieves this ...

Cat Content

Yesterday we hailed the latest members of the family. The mother's called Gandalf (Ok, that's a males name, but anyways, you can guess why, can't you?), the childs haven't yet got any names. As you can see on the picture, they are neatly ordered from light to dark, so possibly the names should match that order. Suggestions welcome. :-)

History Repeating

In the nineties, I used to work as a freelancer, typically in small one-man projects. At that time, Perl was by far my favourite programming language. Some relicts can still be found. Perl was the proper tool for the job: I had the oversight. I knew any single line of code. If changes were required, then I knew exactly what to do.

When I started to work in larger projects, with two or more members, I felt the weak sides of Perl immediately. Even as the lead developer, I began to lose control. Even if I knew how sources had been, I didn't know exactly, how they were. For example, I could no longer change a methods signature without the risk to break things. The larger the project, the more overwhelming the problem. Java with its type safety and strictness was much more appropriate. I was again able to respond quickly to changed requirements. (Today, I really wonder how large PHP projects are managed and how much time is lost when dealing with these things.)

Of course, that wasn't the end of the story. Code is more than Java, Perl, or any other programming language. I began to become aware of that in my first XML projects, around 1999. The initial version was always based on DOM. The application programmers were fumbling around from node to node, reproducing algorithms again and again. Of course, DOM (or SAX, or pull parsing) was (and still is), the proper tool for generic XML processing. But it is extremely unusable for application programming: As soon as the data model changes, you are lost. Once more, the concept works for small projects. But in a large project, things are quite different: There's absolutely no reliable way to find all locations in the code, that need to be changed.

My reply was the predecessor to JaxMe 1, an early Java/XML binding tool. The binding compiler converts the DTD, or XML schema, into Java beans. By using these beans, the Java compiler controls your use of the data model. If the data model changes, then the compiler tells you exactly what breaks. Ideally, the application programmers will be able to implement about 80% of the projects code by working on the beans and the project becomes manageable again. Of course, the JaxMe predecessor, JaxMe 1, and even JaxMe 2 are very limited tools, compared to modern and full blown Java/XML binding suites like JAXB. But that's not the point, in contrary: It's quite telling, that even my self-made tool could boost a project. The fact, that there have been so many similar projects (Castor, Zeus, XML Beans, to name a few), also goes to show the concepts value.

Two, or three years later, I felt a dejavu: For the first time, I was working in a large SQL/JDBC project. It was the same story again: As soon as we had implemented the first 50 or so queries, some of them quite complex, we felt again, that the growth began to become uncontrolled. An action as simple as changing a column type from boolean to integer could break the project and result in hours of bug tracking. As Hibernate, OJB, and other object-relational mappers (not to mention JDO) weren't available or not really recommendable at the time, I began to implement my own nonsense again. It was sufficient as the base of two large projects. A similar tool, not implemented by me, but by another very capable programmer (Hello, Winfried, should you read this. :-), was the foundation of a third project. The success in relation to the simplicity proves again, how important mapping of loosely coupled entities (tables) to structures controlled by the Java compiler can be.

Well, history's repeating. Nowadays, I am working in a large project again, feeling my own unability to keep the projects parts together: This time the entities are called registry objects, classifications, or associations, they are stored in a registry and accessed via JAXR. The project is getting larger, the pain caused by data model changes is growing. This time, we do not even have a schema language, not to mention a binding compiler, that translates structures into accessors.

But maybe, we can learn from history. I promise that I search for other peoples solution much longer this time. :-)

Poor Mans GForge

I call myself an extremely experienced person, when it comes to software installation, configuration and stuff like that. Having installed server software like Apache httpd, Bugzilla, Perl, Sendmail, MySQL, innd, snmpd, radiusd, to name a few, on Linux and mainstream Unixes (Solaris, AIX, HP/UX) as well as exotic server operating systems like SGI, ConvexOS, Dec, or Windows, there's a rare chance that an installation may surprise me. The most notable example used to be Hylafax, which really wasn't easy to handle in 1996, or around that. (I wonder what it's like today. The project lives, so things might have changed.)

However, there's another example, which can easily driving me crazy: It's GForge, a collaboration server for developers, that basically enables management of a lot of projects via a comfortable web interface. If you have it installed, that is.

It's not, that I am unable to do it. I have running GForge installations. But my first installation required no less than three days of work, until everything was complete and the fun didn't shrink with the second or third such installation. It's simply that I am wondering whether it's worth the effort. In particular, because I find myself missing Bugzilla anyways, when working with the integrated issue tracker.

So when I recently had to setup a new development server, I decided to try something different: If I am installing Bugzilla (which I would end to do anyways), then I have my preferred issue tracker and a comfortable, multitenant user management tool ready. Why not simply attach Subversion, WebDAV (as a Maven repository) to the Bugzilla database?

The result of my attempt can be found at Bugzilla's own Bugzilla in Bug 392482. (Of course, it wasn't an immediate result. There have been a few evolutionary steps.) It consists of two parts: mod_authn_bugzilla is an authentication module for the Apache httpd. Basically, it's simply mod_authn_dbd with some minor changes (setting of environment variables). The Apache module authenticates users against the Bugzilla database. Like its ancestor, it's database agnostic, so you can use it regardless of the type of the Bugzilla database.

The second part enables management of user ID's with Bugzilla. By default, Bugzilla uses email addresses instead of classical user ID's. Which is of course fine within Bugzilla. However, you wouldn't want to use me@foo.com as part of a subversion URL.

I am quite happy with the system, as it is now. I am using standard components, which come with the Linux distro with almost no configuration changes. For example, my Subversion repositories are where CentOS wants them, and not on GForge's preferred location. The webdav directories are below /var/www, as they should be. Ok, I cannot create new projects via the web interface, but project administration is a rare task: User management is what costs the most time and is typically presumed urgent, so that's what matters.

If you are interested in the details, please contact me.