
Shall we fork Debian? - kissgyorgy
http://debianfork.org/
======
StevePerkins
From the source:

.....

> Why don't you do that [i.e. vote against systemd] yourselves?

>

> We are excluded from voting on the issue: only few of us

> have the time and patience to interact with Debian on a

> voluntary basis.

.....

In that case, you don't have the time and patience to operate and maintain a
worthwhile and ongoing Debian fork.

In that case, there is no substance to the "question" you're raising, because
you wouldn't actually do what you're calling for.

In that case, you're just a handful of guys (or maybe even just one guy) who
spent $10 on a domain name... to get more attention for your
Slashdot/Reddit/HN post than it otherwise would have had if posted straight to
Slashdot/Reddit/HN directly.

~~~
IgorPartola
I came here to say exactly that. "We don't have time to work with the Debian
folks on a solution, but have time to create our own distro." Right. Then
again, they should go for it. If nobody but them uses it, that's that. If it
gains traction, cool.

On another point: why the hell would you have a choice in init systems? As a
user of the OS, I care that the proceses start, stop, and keep running. I
don't care how. A purist in me might care, but I am not going to futz with
installing different init systems for no good reason.

~~~
feld
Nobody said you had to futz with it. Ideally packages would ship with the
correct init scripts and things would work exactly as you expect them to, or
as they did. Unlike with systemd.

Why the hell would you have a choice in kernels?

Why the hell would you have a choice in filesystems?

Why the hell would you have a choice in sound systems?

Why the hell would you have a choice in desktop environments?

~~~
zanny
There needs to be a distinction between Linux distros for us, and Linux
distros for everyone else.

For us, we care about all that stuff, because we are engrossed in it daily.
For everyone else, they will never touch or understand and / or should _never
need to understand_ what a kernel, filesystem, sound system, or desktop
environment is. To them, the computer is a tool, not an environment, and to
use it is to press buttons to get some tangible result you want from it, and
the buttons you have are not buttons you are going to know how to change.

So _I_ want a choice in kernel, filesystem, etc because I care about the
semantics, performance, ethics, and implementation of these things because I
interact with, code for, and code against, them on a near daily basis.
Everyone else does not know they exist, and thus don't care, so choice is
irrelevant to them, in the same way the existence of Linux as an OS "choice"
does not matter to them - if it is not on the notebook on the shelf at Best
Buy, it might as well not exist.

~~~
nullymcnull
Thing is, Debian is already effectively (since Ubuntu) a Linux distro that's
supposed to be for us. People who want a nice desktop experience go with
Ubuntu, people who want a server reach for Debian.

If the higher ups at Debian really think they're going to be a player in
desktop and are making decisions along those lines, then they must be
seriously oblivious to the niche that Debian has _actually_ settled into post-
Ubuntu.

~~~
Daviey
Your distinction is both wrong and too simplistic. Debian has a perfectly
respectable Desktop, and Ubuntu has more than a good server product.

Choosing between them depends more on technical and project requirements.

Whilst I am not a fan of SystemD, it is important to remember that it came
from RedHat.. you know, the people famous for servers.

SystemD will be a good init for Server, as it will be for Desktop. i am pretty
critical of SystemD, but _something_ is better than Sysvinit. I'd have
favoured Upstart, but that doesn't matter... SystemD won, people need to deal
with it. This is a good evolution for Linux.

------
pmontra
I'm a devop, not a system administrator. I setup and administered a number of
single machine web services for my customers along the years, almost all of
them with Debian plus some Ubuntus recently. Database, application server, web
server. Nothing fancy. I also use Ubuntu as my primary desktop (some sort of
gnome fallback DE) after I removed a lot of cruft if comes with by default.

From my experience what I need on a desktop is very different from what I need
on a server. On a server I don't care about displays, keyboards, backlighting,
sound, USB disks, mics, scanners etc. On my desktop they are very important.
There are a number of companies offering Linux VPSes with 512 MB RAM and they
can be good to host a low traffic web service. Good luck running a modern
Linux DE on a 512 MB machine. Not impossibile but not very productive.

So I can imagine having very different init systems for desktops and servers
if this means that the server won't be encumbered by a number subsystems which
are of no use to it. Furthermore binaries instead of scripts and opaque log
files leave a bad taste in my mouth. They make me figure a future with a
Windows like event viewer to browse the log files, over a terminal based ssh
connection. I'm quite concerned about it. It will waive one of the biggest
advantages of a Linux server over a Windows one.

A fork, or an alternative init system, could be a good solution. We should run
this experiment, pick what we like and don't harass the people on the other
side. We will see the results after some years. The satisfaction of the admins
will decree the winner.

~~~
grifferz
systemd has a number of features which are of interest to server operators,
especially those who use containers, which may well be many of us before long.

Running systemd as pid 1 does not imply running a desktop environment.

I have plenty of VPS customers running systemd as pid 1 in 512MiB RAM.

Running systemd as pid 1 doesn't imply having every single binary and
subsystem of systemd running.

I would encourage you to try it before deciding it's something you won't find
useful.

Avoiding it looks like it's going to be significant effort and you'd want to
know for sure that you're justified in that before embarking on that course of
action.

~~~
m45t3r
Yep, this is true. The only thing I concluded from this page is "I am an old
time Debian admin, I don't want to learn another way to configure my system
that is not a bunch of shell scripts, so I am gonna bitch about this decision
and create a fork".

Actually, I find it's funny how anti-systemd people nowadays claim that
"systemd is a init for desktop systems" since Gnome adopt something unrelated
to the _init_ part of systemd that is the systemd-logind (that actually is a
substitute of ConsoleKit that was deprecated god knows how many years ago).
systemd has lots of features that makes sense on servers too. You may or may
not need these features on your server, but systemd (as a init system) is
still a better init system than sysvinit.

~~~
LeonidasXIV
Actually, systemd is pretty awesome for servers. I wrote a simple program that
outputs to stdout and ran it under systemd.

    
    
      * it automatically cares about starting it
      * it automatically puts the programs stdout into the journal (from which I can filter the output of my specific program without having to syslog() everything)
      * it allows me to run the program as user with one line in the INI unit file
      * it allows to make the users home directory read-only (or even inaccessible), so in case someone takes over, there is only so much they can break
      * it can create a private /tmp for my program
    

Actually, for desktops I don't care but for servers systemd is pretty awesome.

~~~
Zancarius
You hit on some of the points that won me over when I first started using
systemd. Writing services is easy and logging their output is a breeze. Not
having to fret with supervisor processes or daemonizing code shifts some of
the complexity out of the application and into the init process[1] where I'd
argue process management _ought_ to live.

Given that targeting sysvinit for all the various sysvinit-compatible systems
out there can be an exercise in frustration (OpenRC, Debian, the *BSDs, all of
whom have subtly different flavors for starting and stopping processes) better
left to individual maintainers, it's nice that I can write a unit file and
pretty much have it work on any system that's running systemd.

[1] I'm aware that some people might argue additional complexity doesn't
belong in an init. That's fine. You're probably right.

------
ancarda
Am I the only person who prefers systemd? Maybe because it's the only init
system I've managed to get my head around. Other init systems seem so
complicated. A config file vs a bash script is far easier and they all seem to
require forking.

I only use Linux for servers so I may be unaware of a sane init system that
works like systemd but isn't systemd. Until something like that appears, I'll
stick to systemd.

~~~
IshKebab
I don't think you're wrong. I imagine all these people saying systemd is so
awful are just worried that their hard-earned sysvinit knowledge will become
obsolete and that new users won't have to go through silly bash scripts (that
are totally secure of course - no chance of security vulnerabilities in
something as ancient and wtf-free as bash). Instead they'll have something
sane like this:

    
    
        [Unit]
        Description=Apache 2 HTTP Web Server
        After=network.target
    
        [Service]
        Type=forking
        EnvironmentFile=/etc/conf.d/apache2
        ExecStartPre=/bin/echo performing: /usr/sbin/apache2 -k start $APACHE2_OPTS
        ExecStart=/usr/sbin/apache2 -k start $APACHE2_OPTS
        ExecStop=/usr/sbin/apache2 -k graceful-stop $APACHE2_OPTS
        ExecReload=/usr/sbin/apache2 -k graceful $APACHE2_OPTS
        PIDFile=/var/run/apache2.pid
        StandardOutput=syslog
        StandardError=syslog
        Restart=always
    
        [Install]
        WantedBy=multi-user.target
        WantedBy=http-daemon.target
    

This is the sysvinit file for apache from debian.

    
    
        #!/bin/sh
        ### BEGIN INIT INFO
        # Provides:          apache2
        # Required-Start:    $local_fs $remote_fs $network $syslog $named
        # Required-Stop:     $local_fs $remote_fs $network $syslog $named
        # Default-Start:     2 3 4 5
        # Default-Stop:      0 1 6
        # X-Interactive:     true
        # Short-Description: Start/stop apache2 web server
        ### END INIT INFO
    
        set -e
    
        SCRIPTNAME="${0##*/}"
        SCRIPTNAME="${SCRIPTNAME##[KS][0-9][0-9]}"
        if [ -n "$APACHE_CONFDIR" ] ; then
            if [ "${APACHE_CONFDIR##/etc/apache2-}" != "${APACHE_CONFDIR}" ] ; then
                DIR_SUFFIX="${APACHE_CONFDIR##/etc/apache2-}"
            else
                DIR_SUFFIX=
            fi
        elif [ "${SCRIPTNAME##apache2-}" != "$SCRIPTNAME" ] ; then
            DIR_SUFFIX="-${SCRIPTNAME##apache2-}"
            APACHE_CONFDIR=/etc/apache2$DIR_SUFFIX
        else
            DIR_SUFFIX=
            APACHE_CONFDIR=/etc/apache2
        fi
        if [ -z "$APACHE_ENVVARS" ] ; then
            APACHE_ENVVARS=$APACHE_CONFDIR/envvars
        fi
        export APACHE_CONFDIR APACHE_ENVVARS
    
        ENV="env -i LANG=C PATH=/usr/local/bin:/usr/bin:/bin"
        if [ "$APACHE_CONFDIR" != /etc/apache2 ] ; then
            ENV="$ENV APACHE_CONFDIR=$APACHE_CONFDIR"
        fi
        if [ "$APACHE_ENVVARS" != "$APACHE_CONFDIR/envvars" ] ; then
            ENV="$ENV APACHE_ENVVARS=$APACHE_ENVVARS"
        fi
    
    
    

And so on...

~~~
vezzy-fnord
I think this Debian fork talk is a bunch of nonsense, but so is your comment.
It's the classic "systemd or sysvinit" false dichotomy, as evidently a ton of
Linux users have never stepped out of their cage to ever look at anything
else.

Besides all the sysvinit alternatives (like depinit) that have popped up
throughout the years, fixed most of its deficiencies and were promptly
ignored, even having a shell-based boot doesn't mean you need to resort to the
antipatterns that Linux distros have been doing - look at what the BSDs do
with /etc/rc.subr and rcorder(8). Though, to some extent, this can be blamed
on sysvinit's flawed abstractions.

If anything, making a "systemd or sysvinit" dichotomy only tells me you're
unknowledgeable.

~~~
EmanueleAina
You're totally right about the false dichotomy, but I don't see why you think
other init system were ignored.

Debian used a really open process to decide the new default init system where
every developer could propose any init system provided that someone offered to
maintain it.

Since SysVinit, systemd and Upstart where the only ones with a credible
maintainership (OpenRC didn't work on Debian until a few week _after_ the
discussion started) the discussion was centered on those three.

So it's not like other init system were ignored, it's just that noone bothered
to do the actual work to make them suitable replacements.

My hypothesis is that systemd was the first to provide enough benefits to
motivate people to implement the switch in Debian.

From a distribution maintainer the fact that systemd tackles many loosely
related problems is an actual benefit, since now said maintainer just need to
coordinate with an upstream project instead of having to maintain dozens of
special snowflake systems (eg. to set the hostname). This is what most systemd
critics fail to accept.

Oh, and the shell is nice but it's one of the worst languages to implement
anything non-trivial, [http://www.dwheeler.com/essays/filenames-in-
shell.html](http://www.dwheeler.com/essays/filenames-in-shell.html) is enough
for me welcome the idea of getting rid of it in the boot process. :)

------
martin_
From the article: We are excluded from voting on the issue: only few of us
have the time and patience to interact with Debian on a voluntary basis.

Using the same argument, forking would seem like a horrible idea if there
isn't active maintainers.

~~~
snogglethorpe
The anti-systemd-brigade only seems to be a small minority of Debian devs
(though they're very loud, and very persistent), so I'm not sure it would have
much effect on the project as a whole.

If a fork would reduce the time spent arguing about the init system (which 99%
of users don't care about), it could even prove _beneficial_ for Debian.

[It seems unlikely the _fork_ would attract the critical mass of devs/users to
succeed on its own though.]

~~~
csirac2
I'm not even "anti-systemd". I'm actually in the process of implementing
systemd for the firmware of an embedded target in $dayjob because socket
activation is actually a good idea and happened to work well when I played
with it.

But a switch to a different init system shouldn't break your system so badly
that it no longer boots. And yet that's what happens if you rely on keyscript
to unlock your drives in /etc/crypttab.

Apparently the answer is to write a different custom C program for every
possible permutation of obtaining key material to feed to cryptsetup:
[http://lists.freedesktop.org/archives/systemd-
devel/2014-Aug...](http://lists.freedesktop.org/archives/systemd-
devel/2014-August/022024.html)

... which is somehow more clean than a 4 line keyscript.

... and certainly lends credence to the idea that systemd just isn't unixy.

~~~
cbsmith
Using shell scripts to do decryption seems dicey at best...

~~~
csirac2
During boot - before the rootfs is even mounted, what kinds of exposure are
you thinking of that's worse than the shell scripts which already make up
cryptmount labyrinth? Some sort of `() { :;};` response from the smartcard I'm
querying? If I can control the smartcard response, wouldn't I also be able to
crash a similarly badly-coded custom C program which does the same?

~~~
XorNot
Conversely a well-coded C program isn't pulling in a huge amount of
additional, irrelevant functionality to the task.

~~~
csirac2
Yet it seems installing systemd drags dbus and bunch of other dependencies in
with it... tomato, potato.

~~~
cbsmith
dbus was already there. How do you think udev works?

~~~
EmanueleAina
To be fair, udev communicates over netlink. :)

Only in the future it may use kdbus for _some_ purposes (eg. uploading
firmware blobs), but this will only affect internal interfaces.

On the other hand, systemd does _not_ require the D-Bus daemon when you're
launching systemctl it as root, the D-Bus daemon is only needed to route the
call when used by unprivileged users. When used as root, systemctl connects to
the PID1 socket directly and D-Bus is basically just a serialization protocol
(and systemd does not depend on libdbus either).

~~~
cbsmith
> To be fair, udev communicates over netlink. :)

To be fair, udev communicates with the _kernel_ via netlink. All the userspace
notifications are done via dbus. So dbus was already part of the equation
whether people realize it or not.

[http://blogas.sysadmin.lt/?p=141](http://blogas.sysadmin.lt/?p=141)

~~~
EmanueleAina
Are you sure? IIRC it was HAL that picked the kernel events and converted to
D-Bus signals, but it has been deprecated a long time ago.

I gave a cursory glance to the systemd/src/udev files and found no mention of
dbus.

------
brute
The website could be replaced by a much shorter version simply stating "I dont
like SystemD. -anonymous".

The author is essentially making a threat, that there will be a fork of Debian
if the project does not give in to his demands. Then he states that he is
totally not just speaking for himself, but for a much larger group, and in
fact claims to have the majority on his side. I have a hard time evaluating
the seriousness of these claims, as there is no intend to back up any of this.

As far as the arguments go, there is nothing new here. The concerns have been
stated before, and have been heard, too.

------
LukaD
Go ahead and fork. Just leave me alone while I enjoy using systemd. I think
some people are taking this way too personal and overreact. Forking is
probably the best way to stop all the whining.

~~~
keithpeter
A fork would also mean that Debian (systemd edition) would not have to keep
legacy init script support. You could have a 'clean' systemd in around
Jessie+1 I imagine.

~~~
dredmorbius
Debian already supports non-Linux kernels on which systemd won't function. So
the legacy init support (or a compatible alternative) will still be required.

~~~
asdfaoeu
It remains to be seen if the kFreeBSD ports will part of the official release
[https://lists.debian.org/debian-devel-
announce/2014/09/msg00...](https://lists.debian.org/debian-devel-
announce/2014/09/msg00002.html) .

------
chias
Please fork Debian.

I find it very difficult to get behind a movement whose primary complains are
that the status quo is "a slap in the face to the _____ philosophy" and
"betrays the _____ philosophy" and so on. If you want to sway me, you have to
tell me why your way is better. The alternative is "offensive" to you? I
cannot begin to describe how much I don't care. You can tell a lot about a
movement by those they stand with, and you've listed your them as "Harbinger
of the Linux Apocalypse", a boycott, and finally something that does nothing
but mock those it disagrees with. I mean you may be bringing up valid points
but curb the drama, eh?

So I'm all for a fork. That is the point of open source, no? Go on and make a
fork and if it's awesome people will use it, otherwise people won't. And maybe
then we can curtail the endless arguments about this in Debian. But in spite
of the title this article, it really didn't read like it was asking if we
should fork Debian. It read like it was asking people to pressure Debian to
follow the authors' agendas, with a threat (?) of making a fork if it didn't.

~~~
VLM
The problem is most of us are just quietly moving to freebsd.

------
jermo
The main reason for forking seems to be opposition to SystemD. Initially I was
unconvinced but then I remembered the recent story of Lennart Poettering (one
of the authors of SystemD) on The State Of Open Source Communities where he
describes the hostility towards him personally
[https://news.ycombinator.com/item?id=8414859](https://news.ycombinator.com/item?id=8414859)

In light of that, forking is a more civilised approach than bullying and
threatening the author.

~~~
_ak
Lennart Poettering is a bully himself, with a well-documented instance where
he continuously interruped a talk at the 27th Chaos Communication Congress,
even going as far as taking over the stage while insulting the presenter.
Lennart Poettering is a toxic person, toxic to the OSS community, and he's the
last person that can complain about bullying.

~~~
dnlrn
[https://www.youtube.com/watch?v=ZTdUmlGxVo0](https://www.youtube.com/watch?v=ZTdUmlGxVo0)

This is the talk you mean right? Have you actually seen the talk? Yes, Lennart
interrupts the talk but everything he says is correct, while the presenter
just spreads random FUD.

The presenter clearly shows that he doesn’t understand most of the stuff he
talks about, talks about 3 year old bugs that already got fixed, etc.

Yes, it’s not the nicest way to interrupt a talk, but the presenter should
have expected some kind of reaction, given the controversial headline.

People like Lennart put their heart into their software. If you shit all over
it and spread random FUD, you can expect some response. What would you have
done?

Also he doesn’t “take over the stage”. He comes up after the talk has ended,
because people on IRC asked him to.

~~~
enneff
The way Lennart interacted with the speaker during that talk was extremely
inappropriate. If he had corrections to make he could have arranged a short
talk afterwards or a written blog post. It is very poor form to be so
disruptive to a speaker, no matter how much you disagree with them.

~~~
tinco
No it isn't.. being on a soap box doesn't give you some special permission to
just spread false information without being interrupted. I heard this argument
before, there was an article about book reviews, and that authors who
interacted with reviewers (by writing on their own blogs about them or on
twitter) would be labeled Bad Behaving Author and be shunned by the review
community. What's up with that?

If someone talks shit, he should be challenged as soon as possible, preferably
in front of the same crowd they are talking shit in front of. If you take the
opportunity to talk in front of a lot of people, you should also take the
responsibility to be properly prepared, and be ready to face the consequence
of not performing adequately.

~~~
enneff
> being on a soap box

Let's get this straight: he's not on a soap box (a term that refers to people
who shout at passers by on the street), but rather at a conference at which he
was invited to speak. The audience came into the room to hear him give his
talk. Lennart rudely interrupted this.

> I heard this argument before, there was an article about book reviews, and
> that authors who interacted with reviewers (by writing on their own blogs
> about them or on twitter) would be labeled Bad Behaving Author and be
> shunned by the review community.

That's not my argument at all. I specifically suggested he _should_ respond
with a blog post. Don't put me in the same group as those people. I encourage
anyone to share their views on their own blogs, in comment sections, and on
Twitter.

> If someone talks shit, he should be challenged as soon as possible,
> preferably in front of the same crowd they are talking shit in front of.

I disagree that it is appropriate to interrupt and shout someone down just
because you think they are "talking shit". The definition of "talking shit" is
subjective. If someone is interrupted before they can make their point, then
the observer does not have the ability to judge whether they are right or
wrong. It instead becomes a matter of whoever has the best rhetorical tactics.
(Or who can shout the loudest.)

My job involves giving a lot of talks, and if someone were to engage with me
like this I _would_ be prepared: I'd be prepared to tell them to wait until I
have finished my talk and address their comments afterward. This has happened
many times, and it worked out fine for all involved. It's called civility.

~~~
LeonidasXIV
> Let's get this straight: he's not on a soap box (a term that refers to
> people who shout at passers by on the street), but rather at a conference at
> which he was invited to speak. The audience came into the room to hear him
> give his talk. Lennart rudely interrupted this.

I was actually there and the talk was so much better for this. Also, I don't
think the Chaos Communication Congress is that much like a business
conference. It is hackers and people who care about software, not so much for
proper manners.

If I remember correctly, Lennart specifically came to the congress because
there were rumors before that this talk will be bashing Lennarts software, so
it was no surprise to see him show up.

~~~
enneff
> It is hackers and people who care about software, not so much for proper
> manners.

IMO this is the attitude that encourages toxic behaviour in the open source
community. Hackers should not be exempt from standards of civil discourse.

------
mappu
_> SystemD betrays the UNIX Philosophy_

Not so convinced by this. "Those days are dead and gone and the eulogy was
delivered by Perl." \-- Rob Pike

Systemd in debian would have an easier time making friends if it didn't usurp
PID1 for roles that are currently outside PID1, and if it didn't encourage
software which is currently init-system agnostic to grow a dependency on a
specific init-system implementation.

~~~
the_mitsuhiko
> Systemd in debian would have an easier time making friends if it didn't
> usurp PID1 for roles that are currently outside PID1

Like what exactly? This is a non issue. systemd has very little actually
running in PID1.

~~~
jude-
All of systemd's other components _require_ systemd-PID-1. So yes, systemd
does usurp PID 1.

------
buster
Or just shut up and put your efforts into maintaining
[https://packages.debian.org/jessie/systemd-
shim](https://packages.debian.org/jessie/systemd-shim)

Also, critique starts with "We like controlling the startup of the system with
shell scripts that are readable".. How on earth is a systemd service file less
readable then a hundreds of lines bash script?

Also relevant: [http://www.itwire.com/business-it-news/open-
source/65684-deb...](http://www.itwire.com/business-it-news/open-
source/65684-debian-leader-says-users-can-continue-with-sysvinit)

~~~
TheSwordsman
And if that service file screws up how do you troubleshoot it? You end up
diving in to the source code of systemd, versus fixing a bug in your script.

And don't get me started on binary log files.

As was said before, buster, your attitude is the problem. It's the same as the
systemd developers and those within the community.

SysVInit has served me thus far with no issues.

~~~
0x006A
Just curious, have you ever used systemd and ran into a problem where your
service file screwed up and you had yo read systemd's source code or are you
making this up?

~~~
dijit
xl2tpd, still doesn't work.

I actually had to try to figure out why, turns out systemd supercedes
lsmod/modprobe etc; causing those programs to return 1 when invoked, there's
no debug or anything so I was seriously weirded out.

took me some time to figure out it was systemd.

the firewall wrapper for iptables gives you an insecure default config and is
hard to fix via config management "add a service that means port 3128 TCP, now
allow incoming connections"

My config management system creates files and pushes them out, I'm not in the
habit of running idempotent commands repeatedly.. I'd rather check if
something is correct before correcting it.

~~~
Twirrim
> I actually had to try to figure out why, turns out systemd supercedes
> lsmod/modprobe etc; causing those programs to return 1 when invoked, there's
> no debug or anything so I was seriously weirded out.

Why on earth does it need to do that?

------
pantalaimon
> Thanks for doing this. How can I help?

> […] it can be helpful to monitor and update the Wikipedia page about
> SystemD.

So they are basically suggesting to manipulate Wikipedia in order to paint a
worse picture of systemd?

------
thu
Something's wrong with this thread. Being for or against systemd is one thing.
Bashing the people who are ready to do some hard work to bring more choices to
the table is another.

If someone wants to write another Ruby (or whatever programming language)
implementation, would you bash her/him ? Would you say "leave me alone, I'm
very happy with MRI" ?

------
bryanlarsen
I think this is a great idea.

\- I think they're wrong about systemd, but if they're right, Debian can merge
their fork back in, they can say "I told you so", and we can move on.

\- It gives us a place to point the anti-systemd people. Rather than spending
their energy trying to fight the system, they can spend their energy
productively on this fork.

\- This puts the burden of maintaining the SysV scripts on the fork, rather
than the package maintainers, as it would be for Ian Jackson's proposal to
maintain freedom of choice[1] Maintaining the scripts probably isn't hard for
most; testing them probably would be. It would require maintainers to keep a
SysV init system up and running on their machines.

1: [https://lists.debian.org/debian-
vote/2014/10/msg00001.html](https://lists.debian.org/debian-
vote/2014/10/msg00001.html)

~~~
justinsb
Exactly; this reminds me of the quote "I do not agree with what you have to
say, but I'll defend to the death your right to say it." A key axiom of free
software is that if you don't like something, you can fork it. If your fork is
better, it will win (in theory).

It isn't necessarily an efficient allocation of resources, but open-source
does not seek to achieve that: it values choice instead.

------
zokier
Sure, feel free to fork Debian. Just don't call your fork Debian or "Pure
Debian" or anything silly like that. Debian is a registered trademark of
Software in the Public Interest, Inc., and as we saw with the Standard
Markdown debacle, people do not like when names of established stuff is
hijacked.

------
keithpeter
Looks like the Squeeze LTS project[1] could use some help[2] and the team
proposing a fork are server type folk reading between the lines. Good fit of
skill sets and a way of generating positive outcomes quickly to build
confidence? So fork _from squeeze forward_ updating strategic packages?

PS: I love the 'how long are your beards?' line. Obviously, I'd rather Debian
didn't fork and that we kept choice for _server_ people in one of the larger
Linux distros just on an 'ecological diversity' basis.

You _can_ do a window manager on top of X with systemv right now in Jessie
[3], the '\--no-install-recommends' option to apt-get is helpful. But the
result will be seriously old-school. Its rather fun for surfing in cafes and
wasting time on forums but for my day to day work (not programming) I prefer a
full fat desktop like KDE/Gnome.

[1] [https://lists.debian.org/debian-security-
announce/2014/msg00...](https://lists.debian.org/debian-security-
announce/2014/msg00082.html)

[2]
[http://www.phoronix.com/scan.php?page=news_item&px=MTc4NTE](http://www.phoronix.com/scan.php?page=news_item&px=MTc4NTE)

[3] [http://sohcahtoa.org.uk/osd.html](http://sohcahtoa.org.uk/osd.html)

------
CrLf
As much as I dislike the idea of systemd, I'm starting to think it's pointless
to fight it. There's still a large chunk of people that think the desktop is
important for Linux's future and will keep pushing for turning it into a
brittle mess of opaque components, unaware of what's really important to
maintain and troubleshoot servers on a daily basis, and unaware of what has
made Linux so successful in this area.

It may happen that systemd ends up being a good thing, or it may happen that
something else takes the place that Debian and Red Hat currently occupy in the
server space. That thing may very well be something other than Linux, and I
don't care if it is anymore.

~~~
XorNot
Since when have init.d scripts been _anything_ but brittle?

~~~
CrLf
SysV init is brittle only for desktop scenarios, where many things can change
between reboots. On servers I've always found it to be very predictable. Once
you fix an issue, it usually stays fixed. I haven't ran into many startup race
conditions in servers.

SysV init has many problems and can be improved upon, but solutions that
increase complexity exponentially and are impossible to reason about when
problems arise aren't the solution.

It worries me to see people justifying increased complexity pretenfing it
matters for servers. Two examples:

1\. I don't care how long my servers take to boot, that doesn't happen very
often and when it does, who cares about cutting 30 seconds on the operating
system side when the POST itself takes twice as long?

2\. I don't care about too much hardware detection magic. Once a server is
installed, at most it will get a memory upgrade sometime along the way, and
replacement disks coming in and out of it will be transparently handled by the
RAID controller. Most often it will just get scrapped in the exact same
configuration it had on day one.

The systemd approach is not unlike the Windows approach. I've managed Windows
servers for may years and I've also had to deal with at least an order of
magnitude more boot issues that with SysV-like init systems.

~~~
digi_owl
How many things can really change between reboots on desktop? That i yank one
GPU and install another? VGA is still VGA as a fallback, no?

Frankly the only bus i can see being much of a issue on desktop is USB. And
that is mostly if you are relying on a ethernet dongle or similar that ended
up moving from port 1 to port 2 between boots.

Yes, this means your desktop may not get connection until you sort out the new
name of the port. But that is a niggle, not a world ending scenario that
require the full replacement of everything between the kernel and the desktop
environment.

All in all, systemd looks like a solution in search of a problem. And if it
has remained Poettering's personal project and distro variant i don't think
many would have raised a stink (and those that found it interesting would have
adopted it on their own time).

~~~
XorNot
At which point why bother with desktop computing or user customizability or
ease of use at all! I mean, who _really_ needed Plug and Play?

Or even multi-user desktops. Or removable storage.

In Linux, everything got a lot better when we added udev - which gave us event
driven mounts. And then we wrote a bunch of hacks to make sysV init minimally
event driven enough to properly wait for it to finish it's work.

systemd simply dispenses with the fiction that SysV init is in anyway actually
suitable for bringing up a modern computer, and replaces it with
centralization of what we now know are the actual, useful services pretty much
all modern computers need to provide. Even embedded systems are likely to be
using network mounted and accessible storage.

------
zorked
Can we as a community move on from this? If someone feels like forking a
distro "because systemd", let them, and it's only newsworthy if it's
successful.

We could also move on from the accusations of "betraying the Unix philosophy".
You know what else is the Unix philosophy? User-based security model. Fixed-
length strings without overflow checks. World-readable passwords, badly
hashed. Unencrypted remote shell with host-based trust. Maybe systemd is good,
maybe systemd is bad, but accusing it of merely changing things is not a valid
argument.

~~~
linuxlizard
Thank you!

------
byuu
Debian has always seemed to be about choice. You can even run it (for now, at
least) on the FreeBSD kernel if you so choose. Obviously they are going to
have to require systemd for Gnome 3.14+, but I see no reason not to allow
installing a different init system for people managing headless LAMP servers
via SSH, if there is an appropriate amount of developers willing to maintain
the necessary packages for this.

Onto debianfork.org ... if history is any indication, naming it Pure Debian is
only going to cause a world of pain for everyone. Forkers really need to stop
trying to name their projects $superiorAdjective $projectName. That's never
going to go over well with $projectName.

And if they do fork Debian, I sure hope they don't set the default UI font to
Georgia 40. (I know it adapts to browser width. I don't like setting my
browser to 200px width to read a webpage comfortably.)

~~~
adekok
> Debian has always seemed to be about choice. ... Obviously they are going to
> have to require systemd

And that's the issue. See my earlier comments:

[https://news.ycombinator.com/item?id=8415564](https://news.ycombinator.com/item?id=8415564)

------
lifeisstillgood
No. Even the pro-fork advocates (even the above article) see the Jackson /
Vernon proposal as a much better idea (choice of init systems with a systemd
default)

No. IMHO Debian is less a distro than a democratic experiment - and systemd
shows it is working. If you don't like systemd (and I vastly prefer my FreeBSD
world) get on board with the democratic process - it is always messy,
frustrating, driving you insane slow. That's how you can tell it is working

Don't fork.

Edit: Matthew Vaughn is an actor not a Dev.

~~~
justincormack
But isnt that proposal kind of too late, the process has already chosen
systemd?

~~~
icebraining
systemd has been chosen as the default, but there's a proposal to keep Debian
open to other init systems: [https://lists.debian.org/debian-
vote/2014/10/msg00001.html](https://lists.debian.org/debian-
vote/2014/10/msg00001.html)

------
legulere
What a joke.

They can't even spell things correctly. It's System V instead of SystemV and
systemd instead of SystemD

> only few of us have the time and patience to interact with Debian on a
> voluntary basis.

But a fork is less work I guess?

> Pure Debian by Veteran Unix Admins

Pretty funny thing to say as GNU and Linux are pretty un-unixy to begin with.

They link to mobile wikipedia

------
ThinkBeat
The person(s) who wrote up this little hissy fit, does not seem able to, nor
want to, invest the effort to create and maintain a fork.

"Unless you meet our demands, we shall fork".

More like

"You gotta do what I say, or I am going to scream shout and bang my hands
against the wall for a while".

or

"Please someone, fork Debian in the way we want it, and spend your time and
energy maintaining it, because we cant be bothered to".

Also, disagreeing with the direction of Debian is not a risky move. Why not
sign your names to it? Is this again because you wish to avoid any personal
responsibility and work?. If you are well known in the Unix/Linux/Oss
community signing your name would give weight to the hissyfit.

------
qznc
How does forking Debian solve anything?

The issue is that Gnome, KDE, and other software requires systemd. You need to
fix/maintain their compatibility with other init systems. Then it is easy for
Debian user to switch init systems.

~~~
captainmuon
> The issue is that Gnome, KDE, and other software requires systemd.

This I can't wrap my head around, why does Gnome for example need systemd?
There are standard ways on GNU/Linux to do everything it needs in a unix
fashion (by deferring to small specialized tools):

    
    
        shutdown
        reboot
        whoami
        uname
        mount
        ...
    

These and similar tools (or libc functions) give you all information you need
(username, etc.) and system functions a desktop environment needs (reboot,
hibernate). You then only need something like udev for plug-and-play (which is
available without systemd, and as a part of it), and interfaces to the
X/Wayland server and the audio system (which are both not a part of systemd).
This seems to be all stuff that can easily be abstracted away in one module
per OS. I don't see why you have to tightly couple your DE to systemd.
(Unless, you are using your DE as a vehicle to push systemd, which I hope is
not the case...)

~~~
nslqqq
Modern DE's also depend on logind. Which could be replaced with non systemd
implementation that has same interface on dbus.

~~~
makomk
To give people some idea of how practical a non-systemd implementation of
logind's dbus API is, here's the documentation for it:
[http://www.freedesktop.org/wiki/Software/systemd/logind/](http://www.freedesktop.org/wiki/Software/systemd/logind/)

It's big, gnarly, essentially undocumented, and contains a bunch of features
to support tricky cases like multiseat machines (systems with two or more sets
of keyboard, mouse and monitor, each with a different user) that are rarely
used but still need to be supported because the API's designed around them.
Even the systemd developers don't think a reimplementation is feasible.

------
click170
So, all I've really heard about Systemd are arguments from proponents and
complaints from opponents, and based on that alone it's difficult to get an
idea of the true merits of one vs the other because rarely does any one
comment lay out all the Pros and Cons for the different init systems.

So I went searching, and found this Page. It probably isn't complete, and
probably comes at this from a single perspective though.
[http://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems](http://wiki.gentoo.org/wiki/Talk:Comparison_of_init_systems)

I am interested in any other comparisons that you believe is a good
representation of both sides. I just want to fully understand the two before
making a choice.

Edit: Removed references to there only being 2 options, there are multiple
init systems.

Edit: Additional comparison from the perspective of someone involved with
Systemd -
[http://0pointer.de/blog/projects/why.html](http://0pointer.de/blog/projects/why.html)

and

A Unix.StackExchange question asking the same thing with a variety of answers.
[http://unix.stackexchange.com/questions/5877/what-are-the-
pr...](http://unix.stackexchange.com/questions/5877/what-are-the-pros-cons-of-
upstart-and-systemd)

------
broodbucket
I know this is just a nitpick, but calling it "SystemD" everywhere on this
page when everything written about systemd asks you very nicely to call it
"systemd" shows these guys are either not as familiar with systemd as you
should probably be if it's that much of an issue for you, or they're
deliberately trying to be edgy. Neither of which inspires confidence in their
ability to maintain a potential fork.

------
perlpimp
I am not sure why debian needs to force replace sysvinit, can't they have
systemd-debian distro that will have all the shiny stuff in it? and maybe have
it grow and if it won't go down with their userbase then they can discontinue
it? Everyone moving to systemd seems a bit fishy. C is very insecure for
daemon coding with all other options why no use go for example? There might be
some influence on behalf interested governmental parties giving a push to
systemd. I don't have a problem with systemd its just I think it should have
been an option not a default for server setups. C programs if they are not
really carefully coded can be easily hacked by stack smashers, race condition
inducers etc.

[https://www.youtube.com/watch?v=fwcl17Q0bpk](https://www.youtube.com/watch?v=fwcl17Q0bpk)

~~~
icebraining
_I am not sure why debian needs to force replace sysvinit, can 't they have
systemd-debian distro that will have all the shiny stuff in it? and maybe have
it grow and if it won't go down with their userbase then they can discontinue
it?_

Go read the arguments, there are many reasons why they decided to switch. A
big part of it is that Gnome/KDE and other upstream software is already
dependent on systemd, so keeping SysV means extra effort to fix that.

 _C is very insecure for daemon coding with all other options why no use go
for example?_

What do you think the current init system is written in? That's not a reason
to keep sysv.

~~~
perlpimp
what does linus say about systemd?

~~~
icebraining
That he doesn't have any strong opinions about it.

------
jeremyjh
Don't threaten a fork. Just do it when the time comes. It sounds like you
don't have a single Debian committer on board and no real influence there so
you are going to have to prove yourselves, just like every other vanity
distribution.

------
cpks
A few points:

* These folks seem clueless. The cite Eric Raymond. Enough said.

* I like classic init. I'm actually not a big fan of systemd, but I clearly recognize something needs to be replaced. The system needs to handle parallelism and dependencies. It's essentially the same problem in a hundred different domains (from luigi, to things like make/ant/paver/rake, to things like supervisord). Each systems seems to solve it worse than the one before it.

Personally, I'd actually go with forking make, since it's the one everyone
knows and the most Unix-y, modify it to:

* Handle long-running task and task restarts

* Handle parallelism

* Clean up some of the issues around modularity

------
fapjacks
Yes. My spidey sense has been tingling about a Debian fork, given the facts
mentioned on the link, consistent problems with at least one of Lennart
Poettering's previous projects (pulseaudio), and the strong likelihood that
politics played a bigger part in the "adoption" of systemd versus technical
merit. If the answer from systemd people is that we have no choice but to use
systemd, then I hope that a fork happens, and I will contribute a lot to that
project, despite the trite downvotes these affirmative comments get.

~~~
cliffbean
One thing I struggle with: how does one calibrate one's spidey sense? Reading
comments in online forums is likely to bias one towards the people talking the
most, which is not a good bet as a representative sample. It's not just
systemd; it's any topic of heated discussion. All we hear from on many topics
are the people with the strongest emotions. How can we compensate?

------
pjmlp
And this is why the only victory for desktop GNU/Linux has actually been
Android/Linux.

I don't care what init system is used. I care about a GUI workstation
experience.

This whole UNIX experience is long lost in GNU/Linux distributions.

Just go out and install an Aix, HP-UX, Solaris, Tru64, DG/UX... system and see
what the real UNIX experience looks like.

------
atmosx
If Ritchie and Thompson knew the damage _fork-ing_ would cause to the open
source community, they would have never implemented the idea, as a system call
in UNIX[1] in 1971.

[1] [http://cm.bell-labs.com/cm/cs/who/dmr/man21.pdf](http://cm.bell-
labs.com/cm/cs/who/dmr/man21.pdf)

~~~
mseepgood
I don't think that they care(d) much about "the open source community". And
why do you think forking causes damage to the open source community? It helps
resolve conflicts of interest.

~~~
atmosx
I know they didnt care (there wasnt any significant OS community at the time)
and even if they did its not reason to remove a core feature of like fork,
because someone might abuse the idea.

It was a kind of pun to state my disaproval to level of fragmentation the
linux community has gotten into.

Okay this SystemD saga might or might be AS important as some people tend to
think. But fragmenting the community so much and having people working to 10
different, unstable solutions instead of 3 stable ones, its a waste of
resources IMHO.

~~~
EmanueleAina
Indeed. Reducing fragmentation is one of the reasons many distribution
maintainers liked systemd, since it replaces tons of special snowflake tooling
that every distro reimplemented differently with one common upstream (eg. set
the hostname, configure binary formats, where to store the OS release name,
etc.)

------
lovelearning
While I agree with the concept of supporting multiple init systems, I don't
quite understand why they'd want to fork it out into an entirely different
distro.

Isn't it possible to do this with patches, similar to how the linux kernel has
RT patches?

------
ownagefool
There's a whole bunch of debian derivatives out there and veteran unix
sysadmins don't necessarily have the skills to deliver this so not sure this
is really all that news worthy until they create something.

------
nslqqq
Apparently 'Veteran Unix Admins' can't even spell systemd right. It not
necessarily correlates with their overall knowledge of systemd, but it's still
very strange

~~~
nslqqq
Ha, they fixed it. It was spelled SystemD before

------
TheLoneWolfling
So: what linux distributions don't use systemd by default?

~~~
cenazoic
Of the major distros, only Slackware and Gentoo.

~~~
fmoralesc
And in Gentoo, it is optional.

------
ck2
Gosh I wish this would happen with CentOS (7 has systemd)

------
AndyKelley
"shell scripts that are readable"

...are they trolling?

------
AdrianRossouw
man. reading up on the systemd mess again, I sure as hell have no desire to
let it anywhere near my servers.

------
ausjke
I'm for this move, choice is _always_ good, be it systemd or anything else.

------
mahouse
Now I'm just waiting for Poettering to post something on Google+ saying he's
being bullied again by this initiative.

------
trapnii
this whole website rather sounds like a blackmail. I'm not a big fan of
systemd (anymore) either. but forking is not a solution to the init-system
problem et al.

------
iptel
Yes

------
23david
Yes we shall...

------
Klasiaster
poor minds, they are just ridiculus. and they make up too many false
statements

------
lubomir
Why is it that so many opponents of systemd can not spell its name properly?

------
awalton
Yes, please.

But I won't be surprised to see them come slinking back in four months with
their tails tucked when nobody's actually maintaining any software for the
fork.

Fork off and die.

p.s.: it's systemd, not SystemD.

------
n0body
Do people not have better things to do with their time? It doesn't make sense.

------
cuillevel3
Yes, more lazy admins. Lifelong learning anyone? They can't vote because
they've been using Debian for free all this time. Oh, the entitlement.

Go ahead fork it.

I'm confident systemd will modernize Linux servers and desktops alike. And if
by next year there is something better, systemd will be replaced.

Just take a look at device filessystems. Anyone remember devfsd? Let me cite
wikipedia:

"While devfs was a step forward, it had several disadvantages of its own.[2]
Since Linux version 2.5 devfs has been succeeded by udev."

~~~
phkamp
The way Linux did DEVFS was so utter moronic that it's no surprise it was
strangled in the crib.

Unfortunately people seem to have confused "this DEVFS implementation" with
"The idea of DEVFS" and thrown the baby out with the bathwater.

For comparison FreeBSD has had DEVFS for 14 years and had a prototype for a
good number of years before that.

And yes, I wrote that DEVFS for FreeBSD :-)

------
DoubleMalt
Just use coreOS and docker on the server and leave the init system discussion
to the desktop people.

There are some fundamentally different and sometimes conflicting requirements
regarding the startup process on a server and on a desktop machine and I think
systemd which is obviously desktop driven will be the catalyst for a split
between server and desktop distros.

I don't think classical desktop environments have much future personally, but
that's just my gut feeling.

Server will definitely move further into modularization of services, and that
will make init systems there less and less interesting.

~~~
justincormack
CoreOS is entirely based on systemd. Fleet is a distributed systemd. It is far
more systemd oriented than any other distro, having built it in as a core
feature form day one.

~~~
TheSwordsman
Which makes using any useful features of the project impossible.

~~~
voltagex_
How? CoreOS has very defined goals of what it does and doesn't do. What have
you been prevented from using?

