Last weekend I was sick with a fever and was dreaming crazy dreams in
the middle of the night. For some reason I kept noodling in my brain
about Hugh Hewitt and Salem Communications. Hewitt is a writer,
blogger and popular conservative talk-show host. Salem is a large
broadcast group owner with a Christian mission. It also owns the
Salem Radio Network, which syndicates Hewitt, Michael Medved and
I had no idea why this stuff was happening in my dreams, but I blabbed
about it in my blog anyway, because I was still sick and lacked the
energy to blab about anything else.
So a couple days of later I heard from a reader in Ireland who said
maybe I was dreaming about Salem for a pretty good reason. Seems that
Salem Radio Labs develops and distributes GPLed open-source
applications for operating radio stations. The writer was especially
turned on by Rivendell, described this way on its index page:
Rivendell aims to be a complete radio broadcast automation solution,
with facilities for the acquisition, management, scheduling and
playout of audio content. As a robust, functionally complete digital
audio system for broadcast radio applications, Rivendell uses
industry standard components like the GNU/Linux Operating System, the
AudioScience HPI Driver Architecture and the MySQL Database Engine.
Rivendell is being developed under the GNU Public License.
Radio is a subject that has been dear to my heart and brain ever
since I was a kid. Longtime Linux Journal readers know I'll find any
excuse to go off on a radio tangent. Well, now I have a real good
As soon as I looked through Salem Labs' site, I got in touch with Fred
Gleason, Director of Broadcast Software Development for Salem Radio
Labs, and told him I'd like to do a Q&A with him. He got back (and
forth) almost immediately. Here's a selection from the dialog:
Doc Searls: Whose idea was this? (The company's? A station's?)
Fred Gleason: It basically arose as a sort of synergy between John Ehde
(Salem's Senior VP of Engineering) and myself (at the time, Chief
Engineer of WAVA in Washington DC). John had been wanting to "adopt"
and standardize an automation system for a couple of years, and I
wanted something Linux-based, as all of the existing proprietary
systems ran only on Windows and had all of the problems inherent in
DS: How did it get rolling?
FG: The whole thing jelled at a company-wide meeting of engineer and
programming types at Spring NAB in 2002. We did what amounted to a
big focus group to determine what an automation system needed to do
to optimally handle the sort of programming Salem often does
(long-form talk programming). The original Rivendell design arose
directly from those discussions. A few months later, I was
transferred from WAVA to the corporate payroll and started work on
the project full-time.
DS: I assume you and John were into Linux already. What were your
backgrounds there? Did you come from other Unix platforms or what?
(Everybody's story is different.)
FG: I had been running it since late 1994, when I came across a book
called Running Linux at the local MicroCenter store. Back then, I
was your classic CE [chief engineer]--a hardware guy, looking after
transmitters and cart decks. I had taught myself C programming as a
teenager (on a Commodore 128) but had never really done anything
with it professionally. Linux revived my interest in the software
side of things, to the point where I eventually ended up teaching
myself C++ and Qt. So, when the time came, it was just sort of
natural that I'd undertake something like Rivendell.
John, on the other hand, has no *nix background at all. He just
knew it as an OS that had a great reputation for stability and
reliability, something the Windows systems we were using at the time
were notably lacking (this was the NT 4.0 era). John is a good
friend, and it says something about him as a person that he was
willing to trust me (someone with no academic qualifications in
computing whatever) to pull off a project like this.
Somewhere in his writings, Eric Raymond talks about this sort of
thing as a more general phenomenon: a "subject expert" in a
particular industry that ends up morphing into a programmer in the
process of implementing a FOSS solution for that industry, rather
than coming from a traditional academically-trained computer science
background. Rivendell is a classic case of this.
DS: How much are your stations using it? How about other stations,
including stations on the Net?
FG: Salem currently has eleven stations (out of about 100 total) on
the air with it. By the end of this year, that number should be close
to 50. The plan is eventually to move all Salem stations to it, as
their current (proprietary) systems wear out and need replacement,
while all newly acquired stations get it from Day One. We are also in
the middle of installing it at our network head end (Salem Radio
Network, where Hugh Hewitt and others are originated), where it
should be on-air by the middle of this year. You can get a sense of
what a typical installation looks like from this
of our Seattle facility.
As for other stations, I don't have an accurate count, but I know
it's on the air (both web stream and terrestrial radio) because I get
feedback from those users all the time on the project mailing lists.
My impression is that it is particularly popular in Europe and the UK.
DS: Does it address the complex Internet broadcast music reporting
requirements of SoundExchange in the U.S.?
FG: Yes. It is capable of generating music reports for SoundExchange
directly from the database of aired songs.
DS: Do many Internet-only stations use it? Can you say which ones?
FG: Do a search of the
You'll find lots of references.
DS: The guy who wrote to tell me about Rivendell said he saw it as a
replacement for RCS.
FG: That's a fair assessment. It's in the same class as many of the
radio automation products--ENCO, ScottStudio, Prophet Systems, just
to name a few.
DS: He added, "All we need now is a decent scheduler (like an OSS
analogue for Selector) and the whole radio business gets much more
FG: Yes, this is the point of critical need in the toolchain right
now. I see folks looking for a scheduler on the project lists
regularly. Part of the problem is that music scheduling, when done
correctly, is as much about the *data*--song titles,
beats-per-minute, album art, etc.--as it is about scheduling logic.
A FOSS app can provide the logic, but for the data you're still going
to end up either licensing an existing database (big $$) or compiling
one yourself (big-time labor-intensive). There has been some recent
discussion on the project lists about undertaking some of this under
some sort of CC license--it'll be interesting to see where it goes.
DS: Any guess at how much money it saves stations?
FG: The figures I've seen indicate an up-front savings of 50-75% over
comparable "proprietary" (in this case, ENCO DADPro32) systems. This
is with both hardware and software costs factored in. Support savings
are even greater, as ENCO support involves a hefty annual fee. And,
of course, no license tracking, malware or patching costs to worry
DS: Are Salem stations generally using Linux and open source? Got
some examples? (We love success stories.)
FG: It varies widely by site. Some use it for their entire server
infrastructure (Samba, Sendmail, Apache), while others are only just
now getting their feet wet. A significant development has been in the
small but crucial (for us) area of talk show call management, where
is being used extensively.
DS: Is there support for tie-ins to Web pages? (Listing, for example,
programs or music being played.)
FG: Yes. Rivendell has a feature called
"Now & Next" that is capable
of sending data about current and upcoming events to external devices
(such as web servers and RDS encoders). I know of at least one site
(non-Salem) that is using this to update player messages via Icecast.
DS: How about for podcasting, using RSS and enclosures?
FG: Rivendell is capable of generating and uploading the MP3s
automatically. Direct generation of RSS data is currently not
supported but is under discussion and will probably be added
So there you go.
There are more and more stations every day, on the Net as well as the
air, that need to get more done on less money and with less hassle.
Add to that the growing zillions of podcasters, and I'll bet there's
a lot of fun to be done with Rivendell and other projects like it.
Salem Radio Labs
and check out Call Commander (call screening), SoundPanel (swift access
to an array of audio sources) and Linux Audio Backstop (automated
scheduling of audio recording and playback). Plus the other good
Hey, if you're doing radio, maybe one or more of these can work with
your dreams, too.
Doc Searls is Senior Editor of Linux
Journal. He writes the Linux for Suits column for Linux
Journal. He also presides over
Doc Searls' IT Garage,
which is published by SSC, the publisher of Linux
Doc Searls is Senior Editor of Linux Journal
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Tech Tip: Really Simple HTTP Server with Python
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide