
Spotify position in support of systemd in the default init debate - possibilistic
https://lists.debian.org/debian-ctte/2014/01/msg00287.html
======
forgottenpass
Out of all the people commenting on #727708, The Spotify post is a rep from an
organization with systems to administrate. Just like almost every other not-
ctte, not-init maintainer person on that list, so it makes sense for Spotify
to comment, but not really worth giving undue weight to their post in the
larger debate currently happening on debian-ctte.

If you want a better picture of debian's init decision, the bug got punted to
ctte to decide on, so check out the ctte ml archives for December [0] and
January [1]. Russ Allbery and Ian Jackson are the most vocal CTTE members on
the list and support systemd and upstart respectively. The thread "Bug#727708:
init system other points, and conclusion" is where Ian [2] Russ [3] start
making the case for their preliminary conclusions.

Edit: If there are other things worth pointing out on the list put 'em here.
I've really only been skimming the posts for the last few weeks. They're also
considering openRC, but it appears not to be a real contender. Tollef Fog Heen
is a debian systemd maintainer and has posts worth reading on both what
systemd actually is and what the impact of different decisions.

[0] [https://lists.debian.org/debian-
ctte/2013/12/](https://lists.debian.org/debian-ctte/2013/12/) [1]
[https://lists.debian.org/debian-
ctte/2014/01/](https://lists.debian.org/debian-ctte/2014/01/) [2]
[https://lists.debian.org/debian-
ctte/2013/12/msg00182.html](https://lists.debian.org/debian-
ctte/2013/12/msg00182.html) [3] [https://lists.debian.org/debian-
ctte/2013/12/msg00234.html](https://lists.debian.org/debian-
ctte/2013/12/msg00234.html)

~~~
rohansingh
I should point out that while this is theoretically the official position of
our infrastructure team here at Spotify, we've also got a lot of opinion and
debate internally (like you have on any topic among a large team of
engineers).

One other fun problem Spotify is going to tackle is how we're going to handle
systemd vs. upstart if/when we transition from straight-up Debian to Ubuntu.

~~~
the_mitsuhiko
> One other fun problem Spotify is going to tackle is how we're going to
> handle systemd vs. upstart if/when we transition from straight-up Debian to
> Ubuntu.

After two years of upstart I am wholeheartedly regretting ever touching it.
It's broken by design and currently in such a bad way that you actually might
have to reboot the machine to fix it.

Upstart is the main reason I'm considering dropping ubuntu for something else.

~~~
mixmastamyk
Works for me. What is the problem?

~~~
STRML
For example, there is a long-standing bug [1] where an improperly configured
job using "expect fork" can cause upstart to become completely confused and
unfixable without a reboot (or a really hacky ruby script [2]).

As the comments discuss, it's not really always clear all the time when to use
"expect fork" vs "expect daemon" and the rules change with a `script` block.
So this hits people all the time, including me.

It's these kinds of bugs in upstart that bite people all the time. I could go
on about its obtuse configuration but I can declare unequivocally that upstart
configurations are my least favorite part of system administration, bar none.
`Start-stop-daemon` reduces _some_ of the pain but is also difficult to debug.

1\.
[https://bugs.launchpad.net/upstart/+bug/406397](https://bugs.launchpad.net/upstart/+bug/406397)
2\. [https://github.com/ion1/workaround-upstart-
snafu/](https://github.com/ion1/workaround-upstart-snafu/)

------
zx2c4
So that you don't kill their cgi bug tracker, here's the static archive:

[https://lists.debian.org/debian-
ctte/2014/01/msg00287.html](https://lists.debian.org/debian-
ctte/2014/01/msg00287.html)

------
ForHackernews
Who's responsible for changing the titles on these threads?

You've removed the interesting bit: That it's Spotify's ops people putting in
their two cents.

~~~
thepumpkin1979
I submitted it, the title was changed and so was the author. What's going on
here.

~~~
ricardobeat
If you submit a duplicate URL, HN "accepts" it then redirects you to the
earlier posting.

~~~
thepumpkin1979
That's probably what happened.

------
lamby
This sort of thing actually happens a fair amount, albeit usually without a
"celebrity" company and often without the organisation even being named.

It's actually a difficult email to write (especially if you are disagreeing
with a proposed change) as it can easily come across as a sort of childish
blackmail.

~~~
_delirium
Yeah, it seems like it could range from positive to negative depending on the
precise tone and implications. On the one hand, if a large Debian user
believes that some decisions will make lives easier for them and others
harder, them explaining why they think so gives useful input to Debian that
they can use to better server their users. Of course, one large company's
interests might be outweighed by other considerations (and considerations of
other users), but it's useful input to have either way. On the other hand,
written in slightly the wrong way it can come across as bullying... "as one of
your largest users, we _strongly suggest_ you make this decision or we will
have to pursue alternatives". Even more tricky in cases where the user is also
a significant supporter of a project (whether through staff resources,
donations, etc.).

This one seemed reasonably written to me. It was a little light on the
technical details of why specifically Spotify finds systemd works best for
their use case, but the three bullet points do give some information.

------
Shish2k
Currently using systemd on debian myself, with a few of my own custom .service
files and a lot of falling back to sysvinit compatibility -- would love to see
more upstream packages contain .service files. Things like "automatically
restart if the service dies uncleanly" being handled by the init system are a
godsend compared to managing init.d scripts which try to do that job
themselves (things like "service start" getting into an infinite restart loop,
then "service stop" says "service is not running", because the init script is
stuck in a loop but the service itself hasn't been spawned...)

~~~
peterwwillis
init scripts were originally designed to be "dumb" scripts that only performed
one simple task. other scripts could then be written around them reliably,
without wondering what the script might be doing in the background other than
loading some options and running a program.

with modern service management, a lot of extra "intelligence" has been added
to how programs are executed and managed. this leads to levels of complexity
and uncertainty that eventually lead administrators to hacking the hell out of
the system to be able to use it reliably, usually disabling advanced features
so they can control such features themselves.

on top of that, automation of service restart is a solved problem since...
decades ago? it's trivial to have a service restart if it's killed.
unfortunately, once such a function is added to your init system, people use
it all over the place and don't consider the consequences of services
restarting automatically. eventually they get bitten by an unforeseen problem
and build in limits to the service restart, etc etc. system automation is a
lot harder than most people think.

~~~
krakensden
> it's trivial to have a service restart if it's killed. unfortunately, once
> such a function is added to your init system, people use it all over the
> place and don't consider the consequences of services restarting
> automatically. eventually they get bitten by an unforeseen problem and build
> in limits to the service restart, etc etc. system automation is a lot harder
> than most people think.

All the more reason to solve it once instead of in a billion different and
differently awful addon packages.

Plus, systemd is actually _better_ at this than supervisord, daemontools,
etc., already because of its cgroup usage- it can reliably kill _all_ children
before restarting, even if the process forks.

Finally, I encourage you to read the systemd docs:
[http://www.freedesktop.org/software/systemd/man/systemd.serv...](http://www.freedesktop.org/software/systemd/man/systemd.service.html)

they are quite nice, and show that, in fact, thought has gone into it.

> unfortunately, once such a function is added to your init system, people use
> it all over the place

I'm not super on board with this view- for almost everyone, if apache goes
down, they want something to restart apache because the problem was probably
transient and having apache being down is a Big Problem. Plus, most modern
supervisors know about things like "restart throttling".

~~~
peterwwillis
> All the more reason to solve it

see, this is the problem. people don't seem to understand the paradigm of
system automation fully. okay, let's take driving a car automatically as an
example.

where are you going? let's assume we know that all the time. now how do we get
there? we have to know where we are to figure out how to get there. and on the
way, will we need to stop for gas or a bathroom break? once you figure out
those things (and a few more) you can get to the meat of the "code", which is
how to maneuver the streets without running into anyone. that part is the easy
part, because our variables are based on concrete laws of physics, traffic,
etc.

the hard part is all those other variables that change based on each trip you
take. did we get a flat tire? did someone run into us? is there an unexpected
detour? all of these things and more _may or may not_ happen, and you really
can't account for them all.

so while it's nice to have intelligent tools, the tools should be designed to
make it easy for people to customize their services to their needs, and not
attempt to solve all the problems themselves. in my experience, the simpler
the tool is, the less assumptions there are.

this leads you to build in things like monitoring, trending, alerting, quotas,
resource limits, and generally design your system better to detect, withstand
and prevent fault, instead of just reflexively killing and restarting anything
when the eventual problems happen.

> Plus, systemd is actually better at this [..] because [..] it can reliably
> kill all children before restarting

... so that when the state of your database/index/locking/etc goes wacky
because some job was killed before it could release the lock, you can then
write a lock-cleaner-upper and a post-killing-script-execution add-on to
systemd. i'm sure they already thought of that (or encountered it on a running
system) so it's probably already a feature, but if not: yikes.

(side note: i did investigate systemd initially and found tons of things they
either didn't think of, or hadn't released as features yet. i wouldn't have
been able to use systemd as a replacement for my current system without some
of them!)

~~~
Shish2k
> [simple shell scripts lead] you to build in things like monitoring,
> trending, alerting, quotas, resource limits, and generally design your
> system better to detect, withstand and prevent fault

Simple shell scripts might lead people in that direction, but in practise, few
people actually _go_ in that direction, and those that do don't go all the
way. Systemd might not have all of those features, but it has _most_ of them
(which is a massive improvement for most services), and it doesn't stop you
from adding the rest yourself (which is fine for services who care about going
all the way).

------
cakeface
I highly recommend that anyone interested in systemd who doesn't know much
about it read Lennart Poettering's initial descriptions of it. I knew very
little about Linux init systems and I found this incredibly interesting and
informative.
[http://0pointer.de/blog/projects/systemd.html](http://0pointer.de/blog/projects/systemd.html)

~~~
pingswept
Thanks for that. Very interesting read.

------
colanderman
Glad I'm not the only person who thinks upstart is back-assward. I've never
understood how its model of "start a service iff all its dependencies are
running" makes any sense: it (a) starts random other services I don't care
about, just because their dependencies are met, and (b) forces me to manually
track down and start all of a service's dependencies in order to start it.

Though I'd be glad if someone could explain to me how it _does_ make sense.

~~~
CameronNemo
(a) makes sense because it is assumed that if you have the job enabled, you
want it to be started. If you do not care about those services, just disable
them.

(b) is indeed a PITA.

------
_delirium
Tangent, but the 2nd point is intriguing. How does one use cgroups to set up
resource limitations? Is there any kind of decent front-end? I've seen the
kernel documentation
([https://www.kernel.org/doc/Documentation/cgroups/cgroups.txt](https://www.kernel.org/doc/Documentation/cgroups/cgroups.txt)),
but how do I use it? For example, if I wanted to give some shell users limited
accounts where they can't use more than 512 RAM and some CPU quota each, I
gather cgroups can do this, but I haven't been able to figure out how to set
something like that up. (Yes, I know you could handle that use-case by giving
each user their own virtual machine and let VMWare or Xen or Virtualbox handle
the RAM/CPU quotas, but that's often not what I want.)

~~~
sandGorgon
I have been investigating this over the past couple of days for a pet project
of mine (a local college needs to setup a programming competition - need to
resource limit compile jobs).

The way that systemd handles it is three-fold:

One, in the .service file, you can put in resource constraints [1] - which
will be honored by a service on startup.

The second way is to create a .slice file which is exactly that - a slice in
the cgroup hierarchy and where you can assign some resource limits (where it
is bound by the slices above it in hierarchy). All services that are assigned
to this slice will SHARE that cgroup resource constraints. For your specific
requirement, this is the way to go. Create a user.slice (to affect all user
accounts) or a user-<some uid>.slice to affect on an individual basis (still
will inherit from user.slice).

The third way is to invoke _systemctl set-property_ (with properties defined
in [1]) to affect an already running process.

What I am attempting to use is _systemd-run_ [3] to start transient processes
(not background services) with resource constraints. However, I have filed an
enhancement request on some missing features here [4] . Feel free to star it
up !

[1]
[http://www.freedesktop.org/software/systemd/man/systemd.reso...](http://www.freedesktop.org/software/systemd/man/systemd.resource-
control.html)

[2]
[http://www.freedesktop.org/software/systemd/man/systemd.slic...](http://www.freedesktop.org/software/systemd/man/systemd.slice)

[3] [http://www.freedesktop.org/software/systemd/man/systemd-
run....](http://www.freedesktop.org/software/systemd/man/systemd-run.html)

[4]
[https://bugs.freedesktop.org/show_bug.cgi?id=73685](https://bugs.freedesktop.org/show_bug.cgi?id=73685)

~~~
mrud
There is runguard [1] from the DOMjudge project. It may be able to do what you
are looking for.

[1]
[https://github.com/DOMjudge/domjudge/blob/master/judge/rungu...](https://github.com/DOMjudge/domjudge/blob/master/judge/runguard.c)

~~~
sandGorgon
well yes, and there is "isolate" from the Moe project. But systemd is teh new
shineyyyy.

------
pekk
It's a lot easier for one systemd-loving company to switch to
RHEL/CentOS/Fedora than for everyone else to deal with problems with systemd.

systemd is at least controversial enough in ways that matter to Debian
(portability off Linux, etc.) that I think it's nice not to have a monoculture
here.

~~~
nailer
Really? I've been away from Linux for a few years, but it used to be my
career. I recently checked out systemd to make a service on a CoreOS box.

systemd replaces so much overlapping logic, has config files for services
rather than scripts, and uses an existing known config format. Basically
everything that sucked about SysV init. What's not to like?

Edit: I see you've added portability off Linux. That's a very small concern,
and certainly lower than 'deep Linux integration' for most Linux users.

~~~
justin66
> I see you've added portability off Linux. That's a very small concern, and
> certainly lower than 'deep Linux integration' for most Linux users.

It didn't help systemd's popularity that the people behind it have tried to do
disgusting stuff like convince GNOME to make GNOME dependent on it, which
doesn't just effect "portability off linux" but the portability of GNOME. (I
don't believe they got that one through)

~~~
sandGorgon
this is incorrect. Gnome depends on logind which is one component of systemd
and which has ALREADY been adopted by upstart itself [1]

logind is basically a much better replacement for Consolekit (which is not
actively maintained) and the Gnome devs want to use the other part of systemd
(e.g. "systemd --user" ) to manage user sessions rather than write and
maintain the code. It makes complete technical sense.

[1] [http://phoronix.com/forums/showthread.php?78518-Ubuntu-
Plans...](http://phoronix.com/forums/showthread.php?78518-Ubuntu-Plans-To-
Move-To-Systemd-s-Logind)

~~~
Sanddancer
Unless you're concerned about things with compatibility with other kernels,
which is something that the systemd folks explicitly don't want to do. The
biggest problem with pushing all the systemd baggage into gnome, instead of
working to create actual standards and apis, is that the bsd folks, the
opensolaris folks, etc, who all have their own init systems that have
different pros and cons are being bullied out of any say in gnome.
Unfortunately, Gnome is packed with people from redhat who have no desire for
things like consensus, and would rather chase the flavor of the week.

~~~
sandGorgon
Its less a question of "don't want" than cannot. Systemd leverages core Linux
kernel features like cgroups and soon, kdbus. All of this, mind you is what
upstream kernel wants.

Other OSes - like Hurd and Free BSD - lose out, because they don't have these
features. The systemd developers have invited others from the community to be
maintainers, if they are interested in porting - but nobody has responded.

I want to leverage my Linux box better - already I'm seeing a use case for
groups and systems to build and contain services _for myself_. I don't have
any problems with Hurd, but don't want it to be dictating how I run my
servers.

The only reason the CTTE discussion went on for this long is because of
"greater good" outside of Linux. Else Systemd is the best for people living
off Linux.

~~~
Sanddancer
You're changing the goalposts. The initial discussion was about gnome, and
their desires to ignore the many many other kernels it currently runs on in a
short sighted desire to minimize developer issues. In those cases, it is
absolutely a detriment to the community to force more and more requirements on
systemd, instead of putting out specifications for generic dbus consumers and
producers. In this context, I would definitely argue that it's not in the
project's best interests to depend on another project that has stated they
have no intention to make things work across different kernels.

This is the issue that people who only deal with linux don't understand. Were
I to try to put software in gnome that depended on features only found in ZFS,
I would be rightfully criticized for it. Why should Linux-only features get a
free pass?

~~~
bkor
What you're saying is utterly incorrect, speaking as a GNOME release team
member. Pretty poor to first complain about moving goalposts, yet at the same
time misrepresent what was done.

In the beginning of 2012 (Jan/Feb) I highlighted the various problems. Nobody
stood up to help out. Now it is 2014 and we do NOT rely on systemd.

Further, we DO rely on dbus APIs and can rely on ConsoleKit still.

Get your facts straight please.

~~~
Sanddancer
What was done was certain parties made a one-sided announcement that
ConsoleKit was deprecated without any discussion regarding the people who used
it. Where was the call for new maintainers? Where was the call to see if the
project still was viable? Re-reading the "discussion" thread still feels to
all the world like a decision was made, regardless of the merits of keeping
the project alive, because Lennart et al wanted to move everyone kicking and
screaming to their new toy.

Furthermore, where is the GDM documentation on what it produces/consumes
regarding dbus? Where's the API spec. I can find that it does use
org.gnome.DisplayManager as its root, but what more from there? I have the
feeling that few people are willing to help out here because Gnome feels about
as transparent as a brick regarding these decisions.

------
wpietri
Two things I love about this: ops guys getting involved in the debate, and the
fact that Spotify has somebody who's job is to be open-source ombudsman.

~~~
dima55
The debate moved to the CTTE long ago. Stuff like this is noise at this point.

~~~
girvo
While you're right, don't be such a grump. It's cool that some business try
and stay involved in this :)

------
Patrick_Devine
I have to admit, I was dragged kicking and screaming into the new init world,
and really didn't want to leave SysV init. I haven't used systemd, but I have
been using upstart and it's grown on me.

After reading this post, I did look at:
[https://wiki.debian.org/Debate/initsystem/upstart](https://wiki.debian.org/Debate/initsystem/upstart)

Which does spell out some reasonable pros and cons of both systems. I'd say
the biggest problem with upstart (and possibly the deal breaker) is the
licensing terms. Yes, it's open source, but no, I really don't want to have to
fill out Canonical's contributer license agreement if I want to contribute.
I'm not really sure why Canonical doesn't just GPL like everyone else and
leave it at that.

There are some tools out there for upstart, but one thing which would be
really nice would be a built in command for visualizing the init graph in
ascii. It doesn't have to be fancy, just enough to know where your init script
is going to be called in the boot process.

~~~
hansjorg
> I'm not really sure why Canonical doesn't just GPL like everyone else and
> leave it at that

That is about copyright, not about the license. Organizations who requires
this includes the FSF and Mozilla for example. See:

[http://www.gnu.org/licenses/why-assign.html](http://www.gnu.org/licenses/why-
assign.html)

~~~
bkor
But FSF/GNU contributions are guaranteed to stay under a Free Software
license. Canonical is not similar. Not at all the same situation. Further, IMO
FSF/GNU/Mozilla are also bad for requesting this.

------
agumonkey
From linux conf australia 2014 : the 6 stages of systemd
[http://www.youtube.com/watch?v=-97qqUHwzGM‎](http://www.youtube.com/watch?v=-97qqUHwzGM‎)

~~~
rodgerd
The most remarkable thing about doing this talk was how many people have told
me, either before (on hearing what I was talking about) or after, that they
had various strong opinions on the topic, but hadn't spun up systemd on their
servers.

The most gratifying was the number of people who said they'd give it a try
after the talk.

~~~
agumonkey
Was it based on previous software shipped by L.P (pulseaudio was a difficult
exercise to say the least) ? or just because of change of decades old SystemV
habits that felt heavy and potentially scary ?

~~~
rodgerd
I didn't conduct a scientific survey, but I think more the latter than the
former; also, a lot of peoples' knowledge has been very much based on the
public debate, which tends to the idea systemd offers benefits for desktops.
Which may be true, but I see far more benefits for desktops.

~~~
rodgerd
(That should be "more benefit for servers", of course)

------
codingtheone
I think this is the most important bit "dependency model of systemd is easier
to understand, explain and work with than the event based counterpart of
upstart.". IMO upstart is over-engineered to say the least.

------
bitwize
Systemd is _the_ Linux init system. Using anything else at this point is
folly. This debate is a tempest in a teapot stirred up by whiners and haters
who are resisting what the community overwhelmingly supports as a technically
superior, easier, and designed-for-Linux init system.

~~~
akira2501
It's better than SysV init, but there are a dozen other init's out there, all
with different properties. Not everyone cares about "linux on the desktop,"
and not everyone thinks that freedesktop.org is doing the best job as far as
that goes either.

~~~
bitwize
_It 's better than SysV init, but there are a dozen other init's out there,
all with different properties._

And none of them leverage Linux's features as extensively as systemd. By _the_
Linux init system, I mean the one overwhelmingly supported by most of the
Linux community, and the one which is best designed to work with Linux.

 _Not everyone cares about "linux on the desktop," and not everyone thinks
that freedesktop.org is doing the best job as far as that goes either._

Who's talking about desktops? Systemd is not a freedesktop project, and it was
designed to make server administration easier by offering much finer grained
control and monitoring of system services with a much better interface. Many
of its most controversial features -- such as binary log files -- don't make
sense except in a server context where the tampering-attestation features of
systemd-journald make it a far more secure solution than plain text logs.

You should really read Lennart's essays and blog posts about systemd to get a
clearer picture of its tremendous advantages.

Whatever you do, you'd best get used to systemd. It has all but won.

~~~
akira2501
I'm not trying to be snarky here; but systemd is hosted on freedesktop.org, is
it not? That is its primary place of development as well, no? Admittedly, I've
always associated systemd as a project as part of this nebulous "effort" to
bring linux on the desktop forward. I also assumed that's why they went to the
trouble to integrate systemd into dbus so heavily.

I have read some of Lennart's essays -- but I generally strongly disagree with
his conclusions, so I haven't been paying attention for a while. I think his
solutions are over complicated and rely on too much impenetrable technology to
actually save me any time. The arguments have been made elsewhere, so I won't
go into it that deeply, but I think departure from the "unix way" is folly and
will only make administration more difficult.

As far as getting used to it goes; this is still unix. I can still install
whatever initd I like after the fact. Which I do. Yes, this means I have to do
more work than I would have to do if I relied on vendor packages, but we
generally use custom packages for all our critical services anyways. Since
we're going to have to deal with it whether or not we're using systemd, and
we're already rolling out a non-standard initd to our distributions, we don't
feel we have to make any investment in learning systemd.

~~~
bitwize
Freedesktop provides hosting for systemd, but it is not really a project under
their banner.

 _I won 't go into it that deeply, but I think departure from the "unix way"
is folly and will only make administration more difficult._

"There is nothing more gray, stultifying, and dreary than a life lived inside
a theory." \--Jaron Lanier

Unix as a design philosophy is dead, or it is in serious need of a revamp in
order to cope with the realities of modern systems. The complexities of modern
software call for parts that function together as an integrated whole and are
designed to work with each other -- not parts that fulfill one limited task
and abdicate all further responsibility. It's time to let go of the 1970s
conception of the Unix way if we want to build Linux into a modern system.

In fact both the dominant desktop Unix -- Mac OS X -- and the dominant
proprietary server Unix -- Solaris -- employ an advanced init system similar
in many respects to systemd. So there is already established precedent in the
Unix realm for what Lennart is doing for Linux with systemd.

And again, there is overwhelming support for it in the Linux community, so
much so that support for non-systemd configurations is already drying up in a
variety of third-party upstreams. Systemd is the path of least resistance.

~~~
sergiosgc
> Unix as a design philosophy is dead, or it is in serious need of a revamp in
> order to cope with the realities of modern systems.

Oh, you young whippersnapper, there is still so much in the world for you to
learn.

IT is the poster child of the NIH syndrome. No other knowledge area suffers
from it as much as IT does. For a system design paradigm to have survived 50+
years in this environment, it must be quite good.

Settling on dbus for IPC is about as bad as settling with CORBA would have
been ten years ago. Settling with a simp!e Unix socket following the
everything-is-a-file paradigm is just as correct today as it was in the
sixties.

~~~
bitwize
dbus provides useful abstractions -- like broadcast/multicast -- that are
lacking in the traditional Unix IPC mechanisms and are cumbersome and slow to
implement.

That's a big part of why it's superseding almost every other IPC mechanism out
there for critical system messages, and why it's going into the kernel.

------
mmagin
What made me hate upstart was that it still is willing to get the default
runlevel from /etc/inittab, but it doesn't bother to emit warnings to the user
that the rest of /etc/inittab is completely ignored, at least on the version
of CentOS I was using. I think it's particularly user-hostile design for any
program to accept configuration that does nothing (excepting whatever comment
syntax a particular config file uses.)

I would vastly prefer if it either made lots of complaints about the ignored
lines in inittab, or even if it it failed hard -- because then I would have to
fix the problem immediately.

I have used systemd, but never actually poked around at its configuration
(having just run Debian with it as a desktop user), so I can't properly judge
it yet.

------
beefhash
I don't understand how this is still anything to discuss. systemd is the only
option; GNOME is already using it for some parts and will probably not
hesitate to integrate it even more deeply to push Poettering's agenda.

Whether or not the sysadmins want to learn systemd and regardless of whether
it's the technically superior super-init system (you can't really call systemd
an init system anymore), it's going to be forced down our throats anyway.
What's with the holdup?

~~~
Nursie
GNOME is far from the only FOSS desktop these days. A desktop that demands you
have a specific init system is not onw I care to use.

------
runjake
I'm confused about debian stable vs testing vs unstable. Is there a branch
that keeps relatively recent versions of packages and is reasonably usable as
a daily driver?

~~~
dfox
Yes there it is, it is exactly what unstable is. Packages in there are
reasonably recent and generally match upstream in functionally. There are
occasional compatibility problems between packages but that is something that
you cannot avoid if you want to have "relatively recent versions".

~~~
sampo
So unstable is reasonably stable?

~~~
jhaywood
Except for experimental, which isn't even a coherent system, all of debian's
branches are relatively stable. For personal desktop use I find unstable (Sid)
to be just fine. I know it sounds bad but my rule of thumb for avoiding major
problems is this: If synaptic wants to delete a bunch of important looking
packages during an update - hold off a few days for things to settle down.

------
latchkey
The bigger question here for me is why Spotify needs 5000 physical servers.

~~~
brokenparser
Not only that, but why with that many servers pages (playlist top,
artist/album details, etc) are often very slow to load.

------
possibilistic
Debian.org's server seems to be having trouble. This is getting traffic from
both HN and /r/linux.

Cache: [http://bugs.debian.org.nyud.net/cgi-
bin/bugreport.cgi?msg=35...](http://bugs.debian.org.nyud.net/cgi-
bin/bugreport.cgi?msg=3546;bug=727708)

------
mwcampbell
Just saw this interesting post by Noa at Spotify (speaking on his own behalf)
later in the thread, about the trade-off between monoculture on the one
extreme, and effort spread too thin between competing solutions on the other:

[https://lists.debian.org/debian-
ctte/2014/01/msg00306.html](https://lists.debian.org/debian-
ctte/2014/01/msg00306.html)

------
trump
Keep in mind, this is coming from the same company that gives their devs root:
[https://www.youtube.com/watch?v=pts6F00GFuU#t=169](https://www.youtube.com/watch?v=pts6F00GFuU#t=169)

Otherwise, I agree with their endorsement of systemd.

------
myrandomcomment
Both systemd and upstart have added a level of complexity I would prefer to
avoid. The simplistically of sysvinit is greatly missed.

But then again I am an old fuck so..

~~~
bkor
The complexity is there, you just don't see it. Systemd handles _all_ types of
services. Sysvinit does not. Systemd abstracts a lot, making it easier per
service (by putting more in systemd). In sysvinit a lot is copy/pasted across
services. IMO making everything more error prone.

------
dinkumthinkum
The person that wrote is a "Free Software ombudsman" ... Pretty serious stuff
we got going in software now. :)

