Thanks to all who chimed in...
On 2014-02-16 3:27 PM, Canek Peláez Valdés <[email protected]> wrote:
On Sun, Feb 16, 2014 at 1:26 PM, Mick <[email protected]> wrote:
[snip]
You may have lost it in the link that Volker posted (thanks Volker), but this
comment from HaakonKL probably sums it up:
"... I will give Upstart this though: Should something better come along, you
could replace upstart. I guess this holds true for OpenRC as well.
You can't say that about systemd."
I had read that blog entry before. Is full of errors, like believing
that everything that systemd does is inside PID 1.
Maybe it is 'full of errors', but is the primary point true?
There is actually little code inside PID 1;
The quoted text said nothing about this, so please stay on point.
As to the point raised:
Can you surgically remove systemd in the future without reverse engineering
half of what the LSB would look at the time, or will its developers ensure
that this is a one time choice only?
You guys talk about software like if it was a big bad black magical
box with inexplicable powers.
If someone is willing and able, *everything* can be "surgically
remove[d]". We got rid of devfs, remember? We got rid of OSS (thank
the FSM for ALSA). We got rid of HAL (yuck!). GNOME got rid of bonobo,
and ESD. KDE got rid of aRts (and who knows what more).
I think you are being a little disingenuous here.
The obvious unspoken meaning behind the 'can you surgically remove' was:
Can you do it *easily*? I'm sure you would not suggest that getting rid
of the above were 'easy'?
It simply doesn't matter if systemd boils down to one monolithic binary,
or 600, if they are tied together in such a way that they can not
*individually* be replaced *easily and simply* (ie, without having to
rewrite the whole of systemd).
That said, it seems to me that, for now at least, it isn't that big a
deal to switch back and forth between systemd and, for example, OpenRC.
So my main concern is - will it still be possible - *and* easy - in a
year? Three years? Five? If the answer to *any* of those is no, then I
think the best solution - for gentoo at least - is to make whether or
not systemd is to be used more like a *profile* choice - a decision that
you can make at install time, similar to choosing between hardened or
not (not easy/simple to switch to/from after a system is up and running).
In fact, it seems to me that, since (from what I've read) the primary
reason that systemd was written in the first place was to provide
extremely fast boots *in virtualized environments*, having it be a
choice made by selecting a corresponding *profile* is the *ideal*
solution - at least for gentoo. At least this way everything could be
documented, and switching between a systemd and non-systemd profile can
be supported for as long as possible, understanding that at some point
in time it may have to become an install time choice - kind of like
choosing between hardened or not is mostly an install time choice now.
