The Fugue

A current thread on asterisk-dev reminded me that I hate autoconf/automake almost as much as I hate packages that don't use something like autoconf/automake. Yeah, it's a conundrum.

As a system administrator and user, I like packages that adjust themselves to my environment and my preferences. That is, they detect where libfoo's headers are installed and generate an appropriate makefile, and I can specify --prefix=$HOME or --prefix=/usr/local if I want to, and the package won't pollute my /usr/{bin,lib,include} directories. What I don't like as a user/sysadmin about autoconf is the overly-lengthy ./configure sessions that check a million things that you know are not in this code, only to tell you two minutes later that you don't have dependency X. But that is a minor inconvenience compared to the benefits.

As a developer who once upon a time took the plunge and learned autoconf/automake (and promptly swapped it out), I feel the pain of the hordes of developers screaming for release. It's too complicated, too fragile, too undocumented, too overdocumented (I don't understand that either), and just plain ugly. But it does the job better than anything I've seen, and I've given a cursory look at alternatives. Plus the users demand it because they like the things I listed in the above paragraph.

So what is needed? Why has nothing overthrown the beast? We need something portable with essentially no requirements (because sane developers hate adding unnecessary requirements to their requirements list: each requirement is a class of users that will never try your software). We need something that works at least as well from the sysadmin's viewpoint. We need something simple to understand and use from the developer's standpoint.

Portable with no requirements is a two-edged sword. If you try to write it in shell you will end up with something at least as ugly as autoconf, no matter how good your start. Perl without modules might be a good choice. But I think you could write it in whatever language you want with whatever dependencies you wanted, if only the developers are required to have them. Developers don't mind installing a bunch of stuff for a good tool, but they don't want to have to ask their users to install it to use their program. Observe that this is how autoconf works, the generated configure script is portable shell code. This is good, and it obviously works. So the thing could be written in whatever language (you would choose ruby, of course) and output shell and makefiles.

Works at least as well from a sysadmin's viewpoint means simply that it's easy to tell it where libfoo headers are, and where you want things installed. Get in touch with your inner sysadmin. Familiarize yourself with their pet peeves. Google should help there, or feel free to email me for a piece of my mind.

Simple and easy means several things, but more than anything it means KISS. It should be dead-simple in the common case. It should allow you to make custom tests. Telling the user what to do about failures should be easy. Getting configuration information (e.g. big-endian or little-endian?) should be easy (config.h-like should be fine). If you're going to implement this, you're a developer right? So just think through it and you should be ok. What's that? Autoconf developers are developers too and look how they messed up? Well, remember that they wrote this thing back in the era of sendmail.cf. I forgive them because autoconf is a product of its age.

I wrote a program with a serious memory leak, and filled up my 512MB RAM and 1GB swap. My computer, falcon, was in serious thrashing mode. The red led was on solid, X was completely unresponsive (characters I typed in my xterm showed up about 10 minutes later). Even my laptop's network connection was unresponsive (because falcon is my router here)

While I was debating as to why the Out-Of-Memory killer hadn't reaped my runaway process yet, I got curious as to whether JACK would work at all. So I reached over and pressed some keys on my MIDI keyboard (ZynAddSubFX was running, as it usually is), and sure enough Zyn came sounding through loud and clear. In fact, I couldn't hear a single XRUN. It was as if the computer was as idle as could be. I was seriously impressed.

Impressed, but not overly surprised. I did ask for this after all. I have 2.6.13 with Ingo Molnar's realtime-preempt patch, and rtlimits configured properly. jackd runs at priority 65, and my sound card at priority 99. I have the realtime-preempt patch configured at PREEMPT_DESKTOP, because I've had stability issues with PREEMPT_RT. PREEMPT_DESKTOP has been solid though, I have a 33-day uptime, and I use falcon heavily.

I won't go into the details again on how to get where I am, because the information in the last paragraph coupled with tapas' excellent instructions for realtime preemption and rtlimits are all you need.

One last statistic, in case you still don't believe me. That thrashing session started about an hour ago and lasted about half an hour. Here's the screenshot from qjackctl:

With many thanks to Jim Weirich for his excellent presentation (which I unfortunately could not experience in person), I present an Asterisk DSL called radp.

Asterisk is incredibly cool and powerful, and until now has been incredibly painful to configure for someone as accostumed to the beauty of ruby as I am. That all ends today.

http://hans.fugal.net/src/radp

I just had a battle with OpenLDAP about TLS, and I lost miserably.

If you search google for this error, you will get a lot of hits and almost no intelligent answers:

ldap_start_tls: Connect error (-11)
        additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

My certificates are perfectly valid certificates, signed by my own CA (not precisely self-signed, but you'd have the same problem with those). OpenLDAP clients apparently default (at least on RHEL, SLES, and Debian) to require that LDAP server certificates be valid, including the "check against my local copy of the CA cert" step.

There's two ways to get it to work, and they are both options that go in your ldap.conf file: TLS_REQCERT and TLS_CACERT. See the OpenLDAP Administrator's Guide for more information.

And a word to the wise: don't set your RHEL system that is authenticating with LDAP to require TLS and then log out, until you've verified that it actually is working. Why RHEL won't let root log in if LDAP isn't working is a bug I still have to chase down, but it's sure made my afternoon stressful.

I got QtRuby working perfectly on my iBook. It wasn't easy, but it's reproduceable. I wrote up the instructions on ruby-talk, go read them and let me know if it doesn't work for you.

GnuCash has some pretty nifty features for small business these days. Herman Oosthuysen has a good writeup, although it is a bit dated. I wouldn't follow it step-for-step since many of the details have changed and GnuCash has a good set of basic business accounts, and I'm not in Canada. But it's a good read.

One thing I had a hard time with was figuring out how to pay myself and how to account for things I bought for the business with personal funds. The magic word here is Equity. Paying yourself is debit equity, credit asset. Paying for a business expense out of a personal account is essentially a form of investing in your business, so it is debit expense, credit equity. I use GnuCash's Equity:Retained Earnings account for taking owner draws, and created an Equity:Owner Contributions account for investments.

With the announcement of the first Friday from the Pragmatic Programmers, which is Rapid GUI Development with QtRuby, I got really excited. I used QtRuby a little bit back when it was brand-spanking new, because I've used Qt more than once in the past (C++) and I think it is an excellent toolkit. I figured that this PDF book signalled that QtRuby was finally ready for prime time.

It is with great sadness that I report it is not so, at least not for me. It may well be solid enough for serious work. Since it is in Debian now, it may well be the easiest toolkit path on Debian-based Linux. It may have better documentation and a really cool PDF book from the Pragmatic Bookshelf. But it is nigh unto impossible to install on OS X. It claims to be able to, but the extremely complicated instructions fail to tell you what to do when this strange smoke thing fails to compile.

On the other hand, FxRuby is now much easier to get on OS X (and Linux) than it has been in the past. Install Fox (with DarwinPorts on OS X or apt-get on Debian), have rubygems (you do, don't you?), and type gem install fxruby. Nice. It's not native OS X, but it's installable. I managed to get some semblance of OS X nativity with Tk, but I seem to gravitate away from Tk for some reason. I haven't tried ruby/gnome2 yet on OS X. I hear good things about wxRuby, but I have found it also is impossible for mere mortals to install it on OS X.

If I write a GUI app, I want it to have minimal requirements of installation by users. Right now I'd be happy to rely on DarwinPorts/Fink and gems to do the heavy lifting, but asking users to go through an excruciating manual compilation process that fails inexplicably just won't cut it.

Ruby on Rails is really nifty. That's a huge understatement, but it's late and I don't have time to evangelize.

One nifty thing about rails with an un-nifty name is the has_and_belongs_to_many keyword. It is long and awkward, and it is also mentally awkward. For example:

class Recipe < ActionRecord::Base
  has_many :ingredients
  has_and_belongs_to_many :cookbooks
end

Since when did a recipe have a cookbook, or a cookbook belong to a recipe? No, sorry, this is a terrible name. I appreciate the desire to make it read in a natural language sort of way, but trying to english-ize complex relations like this is the sort of thing that gets you in trouble in AI classes and other places where relations are important. Like, say, relational databases. Anyone who has the ability to consciously create a many-to-many database table (as opposed to unconsciously cut-and-pasting one) will know what many_to_many means, and his brain will happily fill in the gaps to read out "Recipe has a many-to-many relationship with cookbooks."

I like that I have very few things in Rails to rant about, but I have never been known to hold back my rants. ;-)

Oh, I almost forgot the solution, which was the whole reason I decided to blog it! Thanks to Jamis for figuring out just what the best way to do this is. Append this to the end of config/environment.rb:

class ActionRecord::Base
  class << self
    alias :habtm :has_and_belongs_to_many
    alias :many_to_many :has_and_belongs_to_many
  end
end