On Fri, Oct 4, 2013 at 7:53 AM, Nico Kadel-Garcia <[log in to unmask]> wrote:
> On Fri, Oct 4, 2013 at 3:25 AM, James Rogers <[log in to unmask]>
> wrote:
> We're basically going to be stuck with systemd for release 7. It's wedged
> into all the upstream Fedora daemons, sometimes with a crowbar and a can of
> Jiffy Lube. There are some serious problems that it resolves (such as demons
> dying off, and requiring some sort of master daemon to make sure they get
> restarted as needed). If you want to affect choices like that, then you need
> to get into the developer cycles with Fedora and affect changes upstream.
Given how fully-fleshed out systemd is and the momentum that it has, I
don't see how getting involved in Fedora or further upstream could
change the basic thrust of systemd.
I'd add journalctl to the good things that systemd brings to Linux...
> It's basically a rewrite of an old approach used by Dan Bernstein in his old
> "daemontools" project, which died off for various other reasons (such as
> Dan's weird copyright policies and insisting that his tools all go in "/",
> instead of /etc, /var, /usr, etc.) I'm frankly surprised that our friends
> upstream in Fedora burned cycles writing it: daemontools worked well, was
> well understood, and just needed some re-arrangement to actually follow the
> "File System hierearchy", and Dan Bernstein finally got tired of his weird
> licensing practices and made it public domain. (I've been publishing RPM
> build wrappers for that software, for *years*).
I was only vaguely aware of daemontools until systemd was released and
there were some upstart v/s systemd comparisons. I was surprised that
there were also daemontools and runit, and at least two daemontools
derivatives, in addition to Apple's launchd (Apache-licensed for a few
years). Except for the latter (and I'd rather not even think of the
outcry had a distribution decided to adopt it!), I'm pretty much
ignorant about these supervisors, but if they aren't socket-activated
and their init files aren't declarative and aren't dependency-based, I
dount that RH would've been interested in adopting one of them. I may
be completely wrong, but, quite frankly, none of these projects are
new so the fact that no distribution ever chose to adopt one of them
by default makes me wonder how good they really are. It might just be
inertia.
I suspect that Lennart/RH would've chosen to start from scratch (and
openly cherry-pick good ideas from others like launchd and Sun's smf)
in order to be in complete control, in the same way that Canonical has
chosen to do its own thing with Unity and Mir.
> What's going to be awkward is forward porting and back porting software
> between SL 6 and SL 7. I'm running into this now with Subversion (which I
> try to publish github updates for, for SL 6 especially) and up-to-date samba
> releases (whicih I also publish updates for, use them from github if you
> like them). Either the same source spec file and SRPM has a lot of debris
> wrapped in '%if" statements to manage both startup systems separately, and
> pick among them, or we'll be reliant for SL 7 maintaining some SysV init
> script architecture and keep it simple and backwards compatible by using
> SysV.
>
> We could maintain two source trees, one with .spec files and init scripts
> for systemd and the other for init scripts. I *don't* recommend that, it
> gets nasty.
Or you could not ship a systemd file until EL-6 is retired since
systemd can launch and supervise sysvinit scripts.
|
