> It went from I would think about using
> it to I wouldn't. Ruby? RoR? What bad
> choices you have made.
I know sysadmins tend to avoid shiny and new (generally for good reason), but neither Ruby nor Rails is particularly new at this point and Ruby at least has good potential for system administration tools. Perl was my language of choice for 15 years. Ruby shares a lot of syntax with Perl, but has a functional object-oriented programming model. I'm tired of waiting for Perl 6. :) The tradeoff is that the library of 3rd-party Ruby libraries is nowhere near as well-developed as CPAN. Having ported around 5000 lines of Perl to Ruby I find that the resulting code is generally shorter and easier to read, except where you run into a shortcoming or lack of a 3rd-party library.
It does mean that as an etch user you have to write bits of Ruby for your etch configuration scripts, but plenty of non-Perl developers managed to get what they needed with the previous versions because the configuration scripts tend to be short and simple and easily built up by cut-n-paste from other scripts.
I understand that Rails seems out of place in this context, it wasn't the first thing I considered. But after looking around at XML-RPC and other web service libraries I decided that using Rails as a simple CGI layer made the most sense, given that I develop etch alongside nVentory (an asset and configuration database), which is a heavy user of Rails. Developing etch on a separate web service platform didn't make sense. Etch does not make heavy use of the Rails platform, nearly all of the server code is in a generic Ruby library with just a minimal hook into Rails.
It went from I would think about using it to I wouldn't. Ruby? RoR? What bad choices you have made.
An open, cross-platform journaling program.
A scientific plotting package.