Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
On Sat 15 Nov 2014 at 11:37:14 -0500, Miles Fidelman wrote:
> Brian wrote:
> >On Sat 15 Nov 2014 at 13:49:18 +0200, Andrei POPESCU wrote:
> >
> >>On Vi, 14 nov 14, 08:04:00, Marty wrote:
> >>>By the same token systemd is a major waste with no real gain. It duplicates
> >>>equivalent modular alternatives, and also requires unnecessary effort to
> >>>repair damage from excessive coupling.
> >>I challenge you to come up with a configuration that duplicates
> >>systemd's features with a combination of other software.
>
> That assumes that one needs or wants systemd's features.
I rather think Andrei might not regard this as answering his challenge.
(You also didn't say whether the link's picture made you chuckle :) ).
> For some (many?) of us, systemd represents no gain, and significant
> operational impact (time required to deal with changes).
Fair enough, but working within the realities of a situation is also
part of the deal. The deal for Jessie is systemd. This is not on a take
it or leave basis; quite a lot of work has been put into ensuring the
alternatives you want are there.
We have been here before, so some of what follows is repetition. For
users who feel the same as you it is (AFAIK) the way to get basically
what you want. It cannot be definitive because changes between now and
the release of Jessie are likely to alter the advice.
Upgrading
---------
After changing sources.list and an 'apt-get update' do
apt-get install sysvinit-core systemd-shim
Then proceed with an upgrade and dist-upgrade.
New Install
-----------
Use the apt-get command above immediately after installation or
preseed the installation of sysvinit-core and systemd-shim.
Both of these may or may not have an operational impact in individual
cases but (as an outline) they are (AKAIK) the only ways to avoid
systemd-sysv being installed. After that you are on your own, leaving
aside bugs.
I appreciate any major change to a way of working can be stressful but
(without wishing to teach anyone how to do their job) there are ways of
testing which can increase confidence in the provided methods. The
testing also has the added benefit (should there be problems) of
improving on the already large amount of work done within Debian. The
BTS would be the appropriate place to put one's experiences.
Reply to: