Kenneth Porter wrote:
It's funny how the discussion gets lost in a focus on speed, and the
other benefits that are more important to servers seem to get ignored
(at least for discussion).
To me the big wins are explicit expression of dependencies instead of
numbered start/stop order, and better integration with hot-plugging.
The speed is nice, but to me it's the ability of the system to
describe the desired relationships clearly that makes the admin's life
more bearable.
I'd like to see a system that's smart about dependencies, but I've
got some fear that the cure could be worse than the disease. I'd want
the ability to break the rules if I want to.
Another problem is that dependencies aren't always so clear: does
Apache depend upon Tomcat or does Tomcat depend on Apache?
* Apache can't handle .jsp files w/o Tomcat, but
* A Java application runs just fine in Tomcat, except that you need
Apache for the outside world to see it.
Tomcat gets wedged often, and needs a kick. I don't need to
restart the web server in this case. I often kick Apache because I
changed the configuration files... I don't need to trash the
application state in Tomcat when I do this. Although I want these
services to start together, things would go smoother if I could kick
them independently.
On the other hand, if you're using Oracle from PHP, you'll lose
your connection to the Listener if you kick Oracle and don't kick Apache.
I'm not completely happy with dependencies being represented in the
'init file' (or generalization thereof) because a dependency is a
function of two software systems, not a product of one. For instance,
imagine that I'm running the Apache that comes with Fedora/RH, and I'm
using it in a 'web services' or 'application server' mode where it
depends on some other daemons such as Tomcat, mcached, etc that I've
installed myself. Well, if I hacked the init script for Apache to add
the new dependencies, that may cause problems for rpm management.
(I've got this problem with the .desktop file system for creating
the Gnome menu -- I might want to attach my own categories such as
"Favorite" or "Available in Kiosk Mode", but hacking 100 .desktop files
would be a disaster)
It might be easy to create 'virtual' services that are a bundle of
other services, and this might even be a replacement for numbered
runlevels... A 'desktop' service, for instance, brings up X Windows,
Xft, input method daemons and all that.
----
I think it's good that we're having a free-wheeling discussion of
all aspects of a new init system because it's important that it has a
design that embraces all of the things we're going to want to do with
it. A new init system ought to facilitate fast boot and it ought to be
flexible enough to support software suspend -- if we pick bad data
structures, we'll have a system that we'll be cursing for years to come.
I'm particularly concerned about customizability. Different shops
have different ideas about the 'right' way to manage systems, and there
are many questions that have no conclusive answer. It's one thing for
Gnome to be tough to customize (if I hate the panel, I can install a
different panel) but I'd hate to have to do surgery on initd for every
FC5 or RHEL 5 box I maintain.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
