[blakesterz]

So he closes with

> Unfortunately, the lock-in they're creating will deprive people of the ability to vote with their feet and switch to better alternatives.

This might sound like a dumb question, and I'm not saying I agree with him, but if I did, I'd vote with my feet by... what? Don't most distros use it now? I'm genuinely curious if this is a practical option for me, though I'm not likely to do it.

[Sanddancer]

FreeBSD, OpenBSD, NetBSD, Illumos, etc. Chances are, you don't even need to tie yourself to the Linux kernel. Lots of OSes out there that don't inflict their users with systemd.

[gribbly]

If you don't like systemd due to it being a lock-in, why on earth would you go with the BSD's who are all lock-in's with their respective implementations of lower-level plumbing which systemd is trying to standardize across Linux ?

[Sanddancer]

The BSDs have far less lock-in with the default components than Linux distributions usually do. For example, I dislike the default syslog daemon, so, I disabled the default, and used my own. This involved adding two lines to /etc/rc.conf --

    syslog_ng_enable="YES"
    syslogd_enable="NO"

and that was it. Unlike systemd's way of doing it, the default syslog facility isn't started at all, doesn't run, period. Pretty much all the other low level services -- crond, dhcpd, ntpd, etc -- are the same way. This is one of the many failings as to how systemd operates. One should have reasonable defaults, but at the same time, if the defaults don't work, it should be easy to change them.

[gribbly]

Well, journald is pretty much the one component of systemd that is very difficult to replace, but even so you can easily forward to another syslog daemon of your choice.

As for the rest, it's very much the same as with the BSD's, they all support their own versions of low level components and only them, and these can be changed by the user with compatible tools of their choice.

[digi_owl]

Forwarding to another process still means that if Journald goes belly up, the logging just died...

[empthought]

I think people don't like systemd because it (in their view) has major flaws, and the lock-in prevents other systems from being tried.

[pmoriarty]

You don't have to use systemd on Gentoo either. I don't.

[digi_owl]

Gentoo has a firm stance towards admin/user choice, and are willing to take action (eudev) to uphold the ability to choose.

This in stark contrast to certain devs over at Fedora and Gnome that hold that choice is bad. Just observe a certain site ebassi maintains...

[mlacks]

Thanks for mentioning illumos, I love running it. I'm having a great time with Joyent running a Ghost instance for my blog

[ktRolster]

Reports are that Devuan works fine. Gentoo reportedly works well, and then there's my favorite distro (for other reasons besides systemd), Slackware.

[LoneWolf]

As a Gentoo user I can confirm it works well without systemd, using openrc, you can use systemd on Gentoo if you want, I personally avoid it.

[jpgvm]

As an upside OpenRC is simpler and even more configurable than systemd whilst being almost as fast, having had dependency based boot since before systemd was conceived.

[LoneWolf]

Wait does it mean other init systems did not have dependency based boot? I have always been a Gentoo user so always used OpenRC, if that's the case it explains why I never understood why systemd was so "revolutionary".

I do find it harder to configure and understand than OpenRC, after I edit some configurations I can just restart the service and it's working, with systemd I have to run more than one command and they are not intuitive at all.

[digi_owl]

There have been quite a few. But until Ubuntu introduced Upstart, and i am sure someone will claim it was not dependency based, few if any reached mainstream usage. Keep in mind that RHEL6 actually use Upstart as pid1, but you would not guess it as Upstart deals with sysv rc "just fine".

Thing is that systemd is lead by some of the most myopic developers in the Linux community. If is not in use by RHEL or Fedora it does not exist. End result is a litany of NIH projects that could have been avoided had they looked around just a little bit.

[jpgvm]

Upstart is not actually dependency based, it's event based. Which is similar but not exactly the same.

It's worth mentioning that the -idea- of systemd if limited to replacing pid 1 with a more reasonable system and something akin to unit files is an excellent one and would be an improvement on OpenRC. Sadly as many have noted systemd come with a lot of very very bad side effects..

[lottin]

The init system is easily replaceable. The problem is things like polkit, which now depend on systemd (logind).

[LoneWolf]

I do have polkit installed, there is an use flag "systemd" that I have disabled and so far I had no problems, it keeps systemd away from my system, and everything works.

[onli]

Another alternative is Funtoo, a (soft) Gentoo fork, with additional integrated means to keep systemd away.

[skywhopper]

I guess that's his point. You don't have many realistic options.

[blakesterz]

Yeah, that's why I'm wondering. As someone above mentioned, I could switch to FreeBSD, OpenBSD, NetBSD, Illumos, etc... but jumping from Ubuntu to those don't seem very realistic given the limits on time.

[anonbanker]

Ubuntu users should switch to Calculate Linux or Slax.

[kinghajj]

Perhaps systemd should be specified as an API, with a test suite, so that there could be multiple independent implementations that compete for mindshare?

[wmf]

The API/architecture is what people object to so giving them more implementations won't help. And there aren't enough people to maintain existing init systems so creating more unmaintained software isn't a good idea.

[mixedCase]

>The API/architecture is what people object to so giving them more implementations won't help.

Not really. The majority of the people I've discussed the subject with and myself agree that the problem is not so much the architecture, as it seems to be somewhat decoupled and merely needs a little push. The problem is the APIs are unstable and writing an implementation is pure hell.

Systemd does some pretty great stuff, it's just that the APIs need to settle down a bit and be tiered into feature sets.

Mind you, I have read very little systemd code, there could be way more tight coupling than what I believe there is. It would be good for a dev to chime in.

[upofadown]

Void

It is interesting for more than just the use of runit...

[semi-extrinsic]

I've gone systemd-free on Arch Linux, no problems so far.

[semi-extrinsic]

Anyone care to explain the downvoting of a simple factual statement? Are the systemd fans angry that other options are viable?

For anyone else wanting to completely purge systemd from an Arch install, here is a good and thorough description; takes less than one hour to switch if you read it thoroughly, about ten minutes if you just do as it says in the code listings.

http://systemd-free.org

[arthulia]

configuring freshly installed packages must be a pain

[semi-extrinsic]

How so?

[arthulia]

because presumably they'd be missing init scripts...

[anonbanker]

> Don't most distros use it now?

I'd submit that, in order to use systemd, you must have to give up the term "distro" to describe yourself.

With that in mind, there are only 5 distributions left:

1) Devuan

2) Slackware (including Slax)

3) Void Linux

4) Gentoo (including Calculate Linux)

5) systemd

If you wanted to vote with your feet, and wanted to keep .deb compatability, you'd move to Devuan. Otherwise, there are four other choices, two of which have LiveCD/LiveUSB install options.

[astrodust]

There's nothing stopping you from writing a drop-in systemd replacement in Rust or something that's easier to write safe code for.

[thinkpad20]

I would love for such a thing (and have thought about doing it myself). But as systemd's capabilities grow more and more expansive, and with its lack of modularity, it becomes harder and harder to write a replacement for it. Of course, even replacing only a piece of systemd's functionality (for example its process manager) would still be beneficial, but systemd would continue to be the only real choice for many.

[astrodust]

The way you overthrow an overlord you no longer like is by knuckling down, working hard, kicking out a replacement. This is how LibreSSL came around (http://libressl.org).

There's nothing especially wrong with the idea of systemd or the way it's been deployed, but if the code-base is suffering from neglect one way to fix that is to either support the core team, or barring that due to hostility, fork and/or make a work-alike.

[anonbanker]

we don't want a work-alike. systemd is not necessary, as all the shims for other platforms will attest.

[astrodust]

You don't. Other people want systemd to work, to be improved, and to move things forward.

[evilDagmar]

I would suggest that simple common sense might prevent such a thing. It's not without reason that the older, wider heads always kept initd simple, in part to prevent it becoming an unnavigable monstrosity. The very idea of the "legacy" init implementations creating files, let alone suid root files, is laughable.

[astrodust]

"Simple" and "systemd" are two things that really don't belong in the same room.

While sysvinit had a lot of short-comings, at least it was simple.