[RDD] Rivendell "should just work"

Marcos Romero mromero at hcjb.org
Sat Mar 1 01:43:17 EST 2008

Great response.  Thank you Fred.

marcos e

-----Original Message-----
From: rivendell-dev-bounces at techweb.rfa.org on behalf of Fred Gleason
Sent: Fri 2/29/2008 5:26 PM
To: User discussion about the Rivendell Radio Automation System
Subject: Re: [RDD] Rivendell "should just work"
On Friday 29 February 2008 05:10:14 pm Bill Smith wrote:
> The point of this discussion is to contrast the installation of a printer
> driver.  Installation of a printer driver should be straightforward,
> painless and only take a few minutes.  It should "just work".

Well, that certainly is a worthy goal.  Sometimes we achieve it, and sometimes 
not.  As one who has that very same model color printer and has had 
the "pleasure" of installing that same driver, I can relate to your 
frustration there.  I've also set up dozens of printers under Linux that do 
indeed 'just work'.  I've also had my share of successes, and of horror 
stories, installing printers under Windows.  I suspect that many on this list 
could say the same.

> "Professional" software has to be simple
> and work reliably in the toughest environments.

Can't argue about the reliability part of your statement.  I strongly disagree 
with the 'simple' part though.  'Simple' is in fact what characterizes 
*consumer* software.  The very nature of 'professional' environments mandates 
complexity.  If this were not so, we'd all be running Windows Media Player on 
the air, and companies like Prophet, MediaTouch, *et. al.* would all be out 
of business. 

> With respect to Rivendell, there are many program configurations which are
> not yet set by default and/or handled by scripts.  Automatic download of
> needed support libraries, mysql activation of the backup feature, default
> entry of report names in RDAdmin, assignment of basic sound-card channels
> and ports in RDAdmin, activation of the time clock are just the tip of the
> iceberg.  If Rivendell is to be a professional package and widely adopted,
> it should "just work" out of the box, based on a specified, reasonable,
> minimum hardware platform.

As someone who has installed many of the 'big name' commercial automation 
systems on a blank system from scratch, I can truthfully state that *none* of 
them "just work out of the box" -- *all* require some degree of configuration 
and tuning before they become even minimally useful in any professional 
environment.  Indeed, some of them require significantly *more* effort than 
that typically required to get a new RD installation functional.

None of this is to say that RD couldn't do better, of course.  Putting some 
sane defaults in for audio assignments, for example, is probably a good idea.  
However, many of the items you highlight as being 'problems' are in fact 
*intentional* aspects of the design.  A newly created database, for example, 
defaults so that it is accessible only from the local machine -- 
configuration is required to make it available over the network.  This might 
seem awkward and inconvenient at first, but would it really be a better idea 
to default everything to wide open?  That's the M$ way.  They do it to try to 
ensure a good default "user experience", but the resulting security 
vulnerabilities often lead to ugly situations.  Likewise with driver 
versions.  There are those who reflexively "upgrade" to the latest version of 
<name-your-favorite-package> the instant the new version becomes available.  
I am not one of their number, precisely because RD is designed to work in 
the "professional" environment, meaning places where there is real money 
riding on the reliable and consistent operation of the system.  In such a 
setting, one cannot afford to shoot from the hip with untried components.  
The current driver has been carefully tested and found to work reliably.  
When the current version has likewise passed it's tests, we'll start building 
against that.  (And, if for some reason someone *must* have the latest 
driver, full source is available to enable that.  In what other automatin 
system is that true?)  In the meantime, the system works.

> If Jack is needed to interface Banshee and Audacity,
> then it should be a recognized part of the installation package, but
> Rivendell shouldn't break the Linux sound system, whatever it is.

'Break' it how?  I'm not following your point here.

> I would hope that this issue, that of developing a comprehensive and
> complete installation would be addressed in full before considering the
> release of 1.0.  I have attempted to address and positively contribute to
> resolving this issue, but even after a concerted, perhaps extraordinary,
> effort to install Rivendell, I for one am still facing  installation
> activities just to deliver a working system.  The user is yearning for a
> Windows solution after watching months of this activity.

I'm sorry that you've had problems, Bill.  I think Jay put it best though -- a 
significant part of the problem may indeed be one of 'Expectation 
Management'.  We're not talking about software for Aunt Millie's e-mail 
machine here.  As a full-bore, no-compromises automation system, installing 
and maintaining RD is an inherently complex task.  As developers, we do our 
best to ease those tasks, but at the end of the day it is unavoidable that 
some degree of expertise on the part of those tasked with deployment will be 


| Frederick F. Gleason, Jr. |               Chief Developer               |
|                           |               Paravel Systems               |
|       A good plan today is better than a perfect plan tomorrow.         |
|                                        -- General George Patton         |
Rivendell-dev mailing list
Rivendell-dev at techweb.rfa.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://techweb.rfa.org/pipermail/rivendell-dev/attachments/20080229/92f55507/attachment.htm

More information about the Rivendell-dev mailing list