Greetings,
I seldom post, but read a LOT. Have to say, I completely agree with
Cowboy here.
Fred, I understand your reasoning for moving to a complete command line
maintenance structure [thats how other DB-based systems do it], but hear
me out here...
It seems quite a few of the members of this list are somewhat, if not
intimately familiar with Linux. I am going to dare to say although most
of this list are, the vast majority of engineers AREN'T. Engineering
these days has become such a daunting task. Not only are we expected to
be experts in transmitter maintenance and repair, we are also expected
to be "experts" in just about every area that encompasses today's modern
broadcast facility: Traffic experts, Desktop Support experts,
Productivity software experts, Firewall/internet security experts,
microwave experts, phone system repair/maintenance experts, email
experts, web design, and on and on and on. In the days of the modern
engineer, simpler is better. While the internet based Wordpress [ive
never heard of Drupal] is used by lots of folks and organizations, isn't
it maintained by them, whereas in most cases our automation systems are
housed and maintained by us [the lowly broadcast engineer]. I know this
is going to rub some folks the wrong way, but as a "computer user" the
last 20 or so years, its 2018 for goodness sake; we shouldn't have to
rely on CLI commands to maintain our in house systems. I know that is
how its "always been done" for maximum efficiency in the *nix world, but
I just think it adds one more layer of complexity that the typical
broadcast engineer doesn't need.
I for one use Linux as my main OS on my home computer [Mint to be
specific]. But my knowledge of its underworkings is severely lacking.
I can USE it no problem. I can even perform basic maintenance on it
[without the need for the CLI], but if something happens to it, I'm up
crap creek. I would love to be able to dig into it and learn more, but
I just don't have the time. Right now, I just want it to "just work"
[and it does wonderfully, otherwise I wouldn't be using it].
Bottom line, Ive been fascinated by Rivendell for YEARS now. Probably
for longer than a decade. But I am just not comfortable enough with my
familiarity of it yet to put it into full production on all our Group's
stations [I have it in use on ONE LP station]. I think the direction it
needs to go is make is EASIER to administrate, not more difficult. I
just CAN'T be the only engineer to feel this way. While on the subject,
I am also disappointed you did away with the appliance install. I
understand how technically the "script" install is better and more
reliable, but again, it took a backwards step in the "ease" department,
but that is the subject for another thread.
Off my soap box,
-Alan
PS Off subject, but since I mentioned it above kind of-Many years ago
[decades?] I ran across a tongue-in-cheek job description of a broadcast
engineer. If anyone has a copy of that, I would LOVE to have it. It
was about 2 pages long and included items something along the lines of
"knowledge of eyeglass repair. knowledge of submarine repair.
knowledge of janitorial procedures." and the very last line was
something like "oh, and some knowledge of broadcast engineering would be
helpful as well".
On 9/27/2018 1:44 PM, Fred Gleason wrote:
On Sep 27, 2018, at 14:22, Cowboy <[email protected]
<mailto:[email protected]>> wrote:
STRONG objection !!
While you and I might be quite comfortable at a command shell interface
( perhaps even more comfortable than with a GUI in many cases )
this is absolutely the wrong direction for the "everything
smartphone" generation.
It’s actually the same approach that most every other FOSS DB-based
system (WordPress, Drupal, etc) takes. Database management (creation,
deletion, backup, restoration) is properly outside the scope of the
application. The typical workflow for creating a new DB goes like this
(I’ll use WordPress’s famous ‘five minute install' as an example):
1) Create an empty database of the appropriate name
2) Create a RDBMS user with appropriate rights to access that database.
3) Enter the values for what you’ve done (DB name, username, password)
into application configuration [‘wp-config.php’].
4) Start the application. When it sees the empty database, it then
initializes a new DB schema in the provided container, ready for user
customization.
And that’s exactly how the Rivendell 3.x codebase does it. Taking this
approach has allowed us to throw out a couple thousand lines of fussy,
bug-prone code in rdadmin(1) that previously attempted to read the
user’s mind and manage the DB ‘automagically’ (and all too often got
it wrong).
Since this is in fact a standard trope for initializing DB-based
applications, hopefully the '“everything smartphone” generation’ won’t
find it too unnerving. :)
And, although it pains me, you and I are mortal !
[shock and dismay!]
Cheers!
|----------------------------------------------------------------------|
| Frederick F. Gleason, Jr. | Chief Developer |
| | Paravel Systems |
|----------------------------------------------------------------------|
| A room without books is like a body without a soul. |
| -- Cicero |
|----------------------------------------------------------------------|
_______________________________________________
Rivendell-dev mailing list
[email protected]
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
_______________________________________________
Rivendell-dev mailing list
[email protected]
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
