
Debian: Transition plan to systemd by default - mkesper
https://lists.debian.org/debian-devel-announce/2015/02/msg00013.html
======
bhouston
It is a herculean task to replace such a core piece of the Linux system
architecture and it is amazing that this has been generally a success.

This will lead to a lot more efficient and maintainability of the Linux OS for
a long time to come once we get past the near term hurdles of reduced
stability and various regressions (and obvious design issues to be resolved)
that come from such a huge change.

I'll be honest, I didn't think this was possible.

~~~
falcolas
> This will lead to a lot more efficient and maintainability of the Linux OS

How does consolidating functionality and control into one piece of software
increase efficiency _and_ maintainability? In my past experience, monolithic
software efforts can be more efficient in the beginning, but they quickly
become a maintenance nightmare as fewer and fewer people understand all of the
moving parts.

You don't have to look far to see the effects of this: the Linux kernel is
filled with small "I'm not sure we can remove this but I don't think it does
anything" comments. You can also see it in the SaaS market as they move
towards microservices, away from the monoliths of yesterday. You can see it in
the giant corporate structures who take 6 months to requisition a smartphone
for testing which will be obsolete in another 6 months.

The init system has the flaw of being too distributed to offer intelligent
coordination between processes, but I'm not sure that following the pendulum
swing to the complete opposite end of the spectrum was the best choice either.

~~~
zanny
Systemd is not a big blob, it is actually fairly well structured in its source
repository. Each part has its own disable flags on compilation and makes
independent binaries. You should think of systemd less as a "program" and more
as a software compilation for the core system.

Yes, there is a chance that components of systemd could suffer bitrot, but I'd
argue its less likely that a project under the tutelage of Red Hat in the
interests of its enterprise crowd will see the rot that other projects like
xinetd have in recent years, where major contributors just stop, the whole
project grinds to a halt, but because its not part of some broader software
project nobody notices to pick up the slack (note, my example has gone through
periods of rot and revival when someone notices its become a problem). If one
component starts rotting the bugs will pile up on the systemd bug trackers and
the broader project will notice and respond more efficiently since everything
in systemd uses the same semantics and code formatting and the developers will
be more comfortable changing their working directory than their repository.

~~~
vezzy-fnord
_Each part has its own disable flags on compilation and makes independent
binaries._

Except for generators, certain auxiliaries like rfkill, journald, udevd and
others. It's rather inconsistent, as is the specific libraries that can be
disabled.

~~~
digi_owl
Never mind that all the "independent" binaries depends on a certain init
binary sitting as pid1...

------
bndr
There's a fork of Debian without systemd [1]

[1] [https://devuan.org/](https://devuan.org/)

~~~
acjohnson55
Why is this downvoted? Knowing very little about the debate, just seeing this
comment grayed out doesn't help inform me. If the comment is not helpful, I
wish someone would reply with information to explain why that's so. Is Devuan
a bad project for some reason? Is this spam? Or is someone just dismissive of
the need for an alternative?

~~~
qznc
Many people consider it an overreaction to fork Debian for its choice of some
defaults. Instead of creating this website and community, they could help
Debian support its non-defaults. It's the same work anyways.

~~~
falcolas
I believe the problem here is that systemd can be introduced to a "non
default" Debian system via package requirements, whereas they hope to prevent
that in Devuan.

~~~
leni536
You can avoid installing systemd with apt-pinning it to negative priority if
you really want to.

~~~
falcolas
Which won't allow you to install certain core pieces of Debian software which
have decided to rely on systemd.

If I understand Devuian correctly, they will port releases of core software
off of systemd and back to init, giving you the option of still using core
software packages without systemd.

> Devuan will derive its own installer and package repositories from Debian,
> modifying them where necessary, with the first goal of removing systemd

~~~
EmanueleAina
> Which won't allow you to install certain core pieces of Debian software
> which have decided to rely on systemd.

Debian is committed to support sysvinit for the next release at least. I
really doubt anyone in Debian will add dependencies on systemd "just because":
if they do so they may have compelling reasons (eg. ConsoleKit is unmaintained
and broken) and the correct reaction would be to fix the issue (eg. like the
ConsoleKit2 people are trying to do) rather than forking Debian just to ignore
the issue.

Not that forking Debian is bad and people should not do it for whatever
irrational reason if they want: it's just that in this case there's no
rational reason the same task couldn't have been carried over in Debian itself
other than the fact that in your own fork you may accept lower quality
contributions more easily.

------
smhenderson
I know this has been discussed all over the place to the point of exhaustion
but I am still somewhat shocked that Debian adopted systemd so quickly. For a
distribution that is known for it's stability and conservative approach to new
software I just think this happened way too fast.

I've been a happy Debian user for many years but lately I've fallen back to
using *BSD (particularly OpenBSD). I guess that puts me in the "old and afraid
of change" camp but for me it's nice to be back using something that looks
and, more importantly, _works_ like Unix.

Debian will remain my goto distribution when I want/need Linux but it's no
longer my first choice...

~~~
Aardwolf
I don't really understand the force that makes so many distros adopt systemd
either.

Who/what is driving this despite all the controverse?

~~~
jjoonathan
The fact that it did many things easily and correctly that init/cron/monit
only did after navigating a minefield of gotchas, reinventing the wheel, and
employing obnoxious hacks to do things that ought to be simple (parallel
init). Init scripts are easier to tweak, no doubt about it, but I'm equally
sure that if I was actually throwing together a distro I would want a modern
init system.

Also, remember that launchd on OSX has been around for a decade. People from
the linux world who encountered it tended to think "hey, this is kinda nice, I
wish we had something like it." Perhaps launchd itself had a predecessor
somewhere, I dunno. But the point is that people had seen these systems in the
wild, so when someone showed up who was serious about seeing the project
through there were a bunch of maintainers whose reaction was "about damn time"
rather than "what is this?"

~~~
XorNot
I've found service files _much_ easier to tweak then init scripts. When 90% of
all init scripts become a single line exec command, there's not a lot to go
wrong.

------
SoMuchToGrok
Personally, I'm excited for the change. Waiting any longer to adopt systemd
could have had serious repercussions on the entire community (across distros).
Big players are already using it; RHEL7 and CoreOS. It's time for a paradigm
shift with our approach on managing infrastructure.

Both the sysvinit and systemd crowds have brought up great points - issues
that needed to be addressed. The strong willed nature of the *nix communities
is what makes them great. Strength in numbers. "Fighting" is a natural
process; whether it's a team or a family.

Incredibly excited to see what kind of impact this has on computing as a
whole. Time to learn something new.

------
JoshTriplett
This announcement isn't as significant as it seems. As mentioned in the mail,
Debian has already transitioned to using systemd by default for the upcoming
jessie release, for both new installs and upgrades, with a carefully
orchestrated transition coordinated between the sysvinit, upstart, and systemd
maintainers. (That transition includes the ability for sysvinit and systemd to
co-exist on the same system, choosing which one to boot at boot time with
init= or a GRUB menu option, rather than having the packages conflict at
installation time.)

This announcement only occurred because, after that transition, someone
formerly on the technical committee (now resigned, but a member at the time)
attempted to use the technical committee to force a revert of that transition.
This announcement is effectively the current technical committee saying "nope,
the other teams in Debian have done a fine job arranging this transition, and
we're not going to overrule anyone".

(I helped draft this proposal, and spent a fair bit of time trying to make
sure it would not be taken as changing the current state of affairs in any
way, only affirming the work others had already done.)

------
Nursie
I thought this was already the case? My systems that run jessie seem to have
made the switch some time ago.

I'm not a fan, it has caused a variety of problems (which may be teething
trouble or not), I'm not a fan of its logging and I don't like that when I
make changes to 'legacy' stuff in /etc/init.d systemd tells me I need to issue
more commands to get it to re-read the startup scripts rather than just use
them... feh.

------
tomswartz07
I seem to remember that SystemD caused quite a stir for Debian a while back,
but I don't remember exatly why.

Can anyone give a (brief) explanation as to the background of the controversy?

~~~
tinco
Some people claim SystemD is not in line with unix philosophy. Some think it
is bug ridden. Some just feel its adoption was strong armed by political heavy
weights. Some feel other solutions might be better. And others believe there
was never a problem with the current solution to begin with.

(I don't agree btw, just giving some info on opinions that others have)

~~~
falcolas
> Some people claim SystemD is not in line with unix philosophy

One example of this interpretation - we can no longer reliably use `netstat
-nlp` to determine what process is responding to requests a particular socket.
In certain configurations, `netstat -nlp` will show systemd owning the socket,
not the process who receives and responds to the process.

e.g. Systemd will own port 80, and feed it back to Apache who listens over
8080.

To determine who will truly respond, you need to know the proper systemctl
incantation, or find the configuration file (there are 8 locations across 3
folder hierarchies where these can live[0]).

[0] [http://man7.org/linux/man-pages/man5/systemd-
user.conf.5.htm...](http://man7.org/linux/man-pages/man5/systemd-
user.conf.5.html)

~~~
feld
So systemd is doing a reverse proxy for Apache in that configuration? Or is it
launching Apache on demand like some sort of advanced inetd?

Either way, netstat -nlp isn't lying about who owns the port 80 socket. It's a
terrible idea, but the data returned is not incorrect.

~~~
falcolas
Well, it depends. In some cases, it's opening the file descriptor for a port
then giving it to the daemon after the daemon has finished starting up. The
service ends up maintaining the socket, but Systemd opened it.

In other cases, Systemd acts as an advanced xinitd and start services on
demand, which means that Systemd listens and starts a service, but the service
does the accept and responds.

So... it's hard to say without digging into the systemd configs.

------
jkot
I think Jessie already uses Systemd on new installations. This is just upgrade
path, which makes sense, since other init systems are unsupported (nobody is
doing the work).

------
jwarren
If anyone else is looking for a legible and noob-friendly explanation of this
controversy, I found a decent reddit thread:
[http://www.reddit.com/r/explainlikeimfive/comments/2jormj/el...](http://www.reddit.com/r/explainlikeimfive/comments/2jormj/eli5_the_difference_between_systemv_and_systemd/)

~~~
digi_owl
Sadly at this point in time the sysv vs systemd debate is a distraction, as
systemd has grown to encompass so much more than sysv ever did. Damn it, it
can be a full blown docker replacement now.

~~~
jwarren
That's pretty astonishing. Are you referring to this kind of workflow:
[https://goldmann.pl/blog/2014/07/30/running-docker-
container...](https://goldmann.pl/blog/2014/07/30/running-docker-containers-
as-systemd-services/)

I clearly have tons left to learn as a Sysadmin

~~~
digi_owl
Nope, you can now import docker containers into systemd-nspawn.

------
eleitl
This was the final straw that broke the camel's back and the reason why I'm
transitioning to the *BSD ecosystem.

------
ausjke
This hurts though I know it's coming. Debian failed me after so many years'
trusts. Sadly the other options are quite limited, which is the worst part.
*BSDs are not really on par for what I want(Desktop, Server and Embedded),
Windows is a totally different ecosystem, what should I do?

~~~
stringy
The resolution does mention there will be documentation on switching to sysv
after an installation, so I assume this option will have to be officially
supported; it sounds to me as though systemd is simply a default, not a
requirement.

~~~
EmanueleAina
Yes, it will be officially supported as systemd is simply a default, not a
requirement, as defined by previous CTTE deliberations and as implemented even
before them by the Debian systemd team, which has gone to great extents to
make sure you can happily switch back and forth with almost no issues.

------
anh79
before: update-rc.d foobar enable (or service foobar enable) after: systemctl
enable foobar

It's the position of the verb that makes war. ^^

------
striking
At least they include sysvinit support. That's far nicer than any other
distro.

------
jbb555
I'm pretty much abandoning linux due to systemd and the fact that a tiny group
of people have basically forced it on everyone despite few people wanting it
and huge objections.

This might not be the end of linux but it's really really harming it.

~~~
cssmoo
I'm not abandoning it because of systemd specifically but the whole Linux
boot/init stuff is hell and the platform is death by a thousand papercuts when
something goes snap. That's reason enough on its own. I recently had to rescue
a CentOS 7 box with failed mdadm RAID1. Between grub, md, initrd, LVM and
systemd it was three hours of hell. This was due to an md failure causing
corruption on a mirror disk rather than a physical disk failure as well.

Windows and FreeBSD with ZFS are beautiful in comparison. I've come to
recommend those over Linux these days.

~~~
digi_owl
Recommending Windows ahead of Linux says something...

------
SpaceInvader
I have to say I am surprised. From where I sit migrating to systemd doesn't
look like the best solution. But, said that, I'm gonna get some popcorn and
watch another holy war starting.

