Discussion of systemd adoption by Debian, openrc, sysvinit

ThunderRd

ThunderRd

Irreverent Query Chairman
Staff member
Edit:
The following posts moved from another hjacked thread here, in the interest of having a place to continue the discussion if there are developments.
-thunderrd

Even the Linux OS devs can't get it together. Lots of lolz here:

http://debianfork.org/

But a more realistic view of the systemd thing here:

http://news.siduction.org/
 
Last edited:
Last post I read regarding systemd was that it killed linux and all distributions. Gotta say it has gotten quite sensational these past few months.
 
Exactly, If it "killed" Linux, then it must have been WAY better than what I'm using now. ;)
 
Their main reason for forking is utter horseshit. I really wonder if it is going to gain real traction.

I use Gentoo, Debian stable, and an unstable Debian derivative regularly, and all of them have a way to remain systemd-free if the user so desires.

Their main arguments are that Debian (and some other distros) has elected (through proper, extensive study and a vote of the devs) to make systemd the default init system. And that it is being 'forced' onto users. And it does too much. And that as an init system it 'doesn't know what it wants to be'. And ...

No one is 'forcing' something on a user simply because it's been made the default. My main machine runs Gentoo. The Gentoo devs have NOT adopted systemd as the default. But many Gentoo users ARE using it. I could, too, if I WANTED to. Is Gentoo 'forcing ' me to use sysvinit? Absolutely not. systemd is supported in Gentoo, just like the default init system, so I have a choice.

Debian, Ubuntu and some others are adopters of systemd. I am not being 'forced' to use it. The unstable Sid machine at my house runs systemd; not because I prefer it (actually, I don't) but because I chose to install it so I can learn it, because it might come in handy to know how it works someday.

Sid rolls, so who cares, anyway? Do what you want.

If you're a first-time installer, installing from the .iso, you are given a choice in the install routine. Use this, or use that: if you make no choice, it installs systemd. It's as simple as that. If you're a novice, you won't know what to choose, so you'll get systemd.

Incidentally, the reason I don't particularly like it is that it DOES do way more than one thing, it's involved in the power management and other stuff, and in some ways doesn't follow the modular Linux philosophy of doing one thing well. Will it become a sore point over time? Maybe. Don't install it if that is your feeling. In my way of thinking, it has far too many other things depending on it, and I think that will make it a 'dependency hog' in the long run, requiring more and more packages to rely on its presence, and making it more and more difficult to remove.

At the end of the day, though, I'll tell you the real, deep meaning of all this mess. In the dev world, it is a resistance to Poettering and Co, and their past record. Just like what happened in the kernel team with Ingo Molnar and Con Kolivas a few years back, there are some folks who simply can't work together.
 
I agree very much with the last part. It's not as much an init system problem, imho, it's the people behind it. Same guys who hates the guts of Miguel de Icaza, it really shocks me sometimes how things are "solved". Plus as far as I know Debian maintainers are still providing sysvinit scripts with applications. I guess eventually if applications integrates part of systemd for whatever reason it'll be harder eventually for them to escape reality.

Agreed on the novice user not noticing, nor he/she should be aware; those things need to be as transparent as possible as not to obstruct the user in any way.

Only problem I had with systemd was with mpd and it was a combination of mpd + dbus + systemd, it seems mpd.service is pretty much isolated and doesn't know that dbus is already running. Quite messy as I'm still not used to systemd as whole, gotta sit down and learn a bit more. Beyond that? I'm super happy with my Debian Jessie installation.

I just hope this fuss over the init system is over soon. Hopefully they'll pick on something else.
 
There are devs 'in the know' who are accusing Poettering of designing systemd with the sole aim of getting as many other packages as possible to depend on it. Ostensibly, this would be to strengthen the need for wider systemd usage.

I don't *really* think that it's coded with that in mind, but I do feel that it might become so. And so do many others who have forgotten much, much more than I've ever known :)
 
Last edited:
I restored Allen's post ;)

If there is a concern about New Linux users installing a process without knowing what it "really" is, I think this is important.
I've read a bit about this conflict and even both of your posts here and still don't fully understand init and systemd
So even as a power user, I would just use the defaults because I wouldn't understand either of them anyways.

You are right that we aren't "forced" to use either one, but 99% of the time beginners and power users just run what comes out-of-the-box. Cause we ain't programmers.

My concern is about Ubuntu, Mint and other distro's that are based on Debian. How will this affect them in the long run?
Will there be a forked Ubuntu and Mint in response to this conflict?
 
If you read the article from siduction guys (I think it was from them). Systemd service scripts are super simple to build, and using journalctl isn't that hard to use (journalctl -u [SERVICE unit]) (although I noticed that if you use it as a non-priviledged user there won't be any logs, gotta be either sudo or root user)

Now like ThunderRd said, there are a lot of people against it just because of the key developer which is Lennart Poettering, he's also behind PulseAudio which as we know it has received a LOT of flak throughout the years.
 
That is still "programmer language" to me :(
It really seems like a developer controversy and since its an open community, people can fork if they want to.
Instead of fighting, just fork it... I guess

Hell, we all have a hard enough time getting along with laws, rules, money, religion, politics
It sucks we have to fight in the digital world as well.

I actually love Pulseaudio! It provides some amazing features that Alsa doesn't support.
The main problems I have is Wine not supporting Pulseaudio... probably for the same reason and this Debian controversy.
 
Err...can you tell me how you restored that post <sigh>
I could not find the secret sauce.
 
Being just a regular user, I personally quite like systemd. I find it easy to both use and manipulate. Also regarding journalctl, you either need root privileges, or your user can be part of the systemd-journal group. The systemd-journal group only have read access to the journal, so for a system with many users it would be ideal to have users part of the systemd-journal group. That way they have full read access to the journal, but you would not need to give them full root privileges through sudo if that is not desirable.

If you want to search through the logs with grep you would need to use a specific argument: --no-pager

Then you can pipe the output to grep. The -b argument is also very useful in case you want to see the log from a specific boot. -b-0 (or just -b) shows last boot (current boot). While -b-1 shows previous boot, -b-2 shows the boot before that, and so on. And for anyone wishing to have all the logs forwarded to a different syslog daemon, that can easly be specified in /etc/systemd/logind.conf

So I have quite a positive view of systemd, I've found it to be easy to work with. However, it should be noted that systemd was already the default init system for Arch when I first started using Arch, so I learned as a part of my learning experience for Arch.
 
Interestingly enough, I was hanging out at #gentoo-chat for a while this evening and followed closely this conversation, which, for once, I was NOT a part of:

millerti18> Back over in #gentoo, before I was politely asked to move the conversation here, we were discussing how only Gentoo could be an objective forum for debating systemd on a purely technical level. Or at least that was my opinion that I was asserting. :)
23* CustosLimen (~CustosLim@unaffiliated/cust0slim3n23) has joined
24* toralf (~toralf@f054055034.adsl.alicedsl.de24) has left ("Konversation terminated!")
18<oniichaNj18> so
18<oniichaNj18> millerti:
18<oniichaNj18> what do you mean
18<oniichaNj18> that only on gentoo can systemd be rolled out at a suitable pace?
24* caveman has quit (Ping timeout: 258 seconds)
18<millerti18> oniichaNj: Only with Gentoo can systemd be rolled out, evaluated, tested, etc. in a way that isn't politically charged.
18<oniichaNj18> I see.
18<oniichaNj18> I think that applies to every distro, as long as it's optional
18<millerti18> oniichaNj: However, by necessity, some distros can't have that many options.
18<millerti18> Whenever I install Ubuntu, it's because I don't WANT choice. I just want to do an install and go.
18<oniichaNj18> Yeah, I understand that. I think that systemd could be available as a package though.
18<millerti18> Or perhaps we could say is that this is the choice I make when I install Ubuntu. :)
18<millerti18> SOME distro has to take the plunge, otherwise systemd won't get all its bugs ironed out. It doesn't seem unreasonable for Debian to put that into its unstable release, because the unstable release is where you put potentially broken things that need to be tested.
18<oniichaNj18> My personal opinion is that they should take the entire thing back to the drawing board and work out their design
18<millerti18> I mean, when I use ~amd64, I expect problems.
18<millerti18> oniichaNj: The thing is, systemd IS a taking back to the drawing board.
18<millerti18> Something like systemd has been tried several times before.
18<oniichaNj18> But why does it keep getting pushed/"forced" if it's broken
18<oniichaNj18> are you saying it's just a fad
18<millerti18> systemd might be the first real chance for a system like this to take hold.
18<millerti18> As for being forced, that is just the opinion of the cons. In fact, LOTS of things get "forced" on people by distro committee. Only this time it's a critical system component that could cause all sorts of problems if it went wrong.
18<millerti18> As for "broken", I would suggest that it's "immature"
18<millerti18> To make it mature, it needs to be thrown into the wild.
18<millerti18> Kicking and screaming. Into unstable distros, where people can find the little corner case bugs.
18<millerti18> I'm not an advocate of systemd in particular. But I am an advocate of many of the things it's designed to do, and I'm an advocate for Linux distros making uncomfortable steps into the future.
18<djdunn-n718> millerti no its quite broken, it needs reengineered badly
18<shingetsu18> morning all
18<pharpend_18> morning
18<iamben18> i like both systemd & openrc
18<pharpend_18> millerti: why don't you have a voice, mate?
18<iamben18> systemd is much more impressive technically, but its take-over-the-world momentum is a bit scary
18<pharpend_18> yeah
18<iamben18> the things you can do with systemd, from a sysadmin standpoint, are awesome
18<millerti18> pharpend_: What do you mean "have a voice"?
18<djdunn-n718> iamben until you look at the kernel side of the systemd
18<millerti18> Even the pro-systemd people will admit that it has some problems.
18<pharpend_18> millerti: The mode for your user is -v . when me, iamben, or most people here talk, you will see a + in front of our nick. yours doesn't have that
18<iamben18> djdunn-n7: "it does cool stuff" is not negated by "there are some ugly parts"
18<pharpend_18> I wish it was more portable
18<pharpend_18> it's non-portability is sort of a good thing, because it means that systemd will never corrupt BSD =p
18<shingetsu18> iamben: I wish they stuck to the *nix philosophy though
18<shingetsu18> they do TOO MANY things
18<iamben18> shingetsu: i think that whole term is loaded BS
18<iamben18> i like stringing together commands with pipes as much as anybody, but not EVERYTHING should be that way
18<pharpend_18> shingetsu: I don't like that argument, merely because of the existence of desktop environments, which most people use. DEs also violate the unix philosophy, but I don't hear many people complain about those.
18<shingetsu18> imo their cron stuff and their journal stuff...
18<djdunn-n718> So its better to hide everything under C?
18<shingetsu18> pharpend_: depends which ones ;3
18<iamben18> the journal is awesome
18<shingetsu18> iamben: from a software architecture standpoint, yes everything should be that way, internally at least
18<iamben18> djdunn-n7: yeah really deeply "hidden" in the obscure C language =)
18<djdunn-n718> If corruption is a feature yeah awesome describe journald nicely
18<djdunn-n718> Cause the corruption's obviously not a bug
18<iamben18> the journal does not corrupt itself, the issues are from FS corruption, and if a block of the journal gets corrupted, yes you DO lose that whole block
18<pharpend_18> shingetsu: although, you usually have an option to choose a different DE, and you can swap them out pretty easily
18<iamben18> that whole issue is much misunderstood, it's not like the journal randomly goes haywire and you have 0 logs
18<pharpend_18> djdunn-n7: also, you can just run another system logger on the side.
18<pharpend_18> djdunn-n7: one that does integrity checks
18<shingetsu18> pharpend_: a DE = a WM + a shell + a bunch of programs ;3
18<millerti18> I dont see what's the big deal about sticking with "unix philosophy" for its own sake.
18<shingetsu18> while several (*cough* KDE *cough* gnome) do violate the phylosophy, some follow it pretty strictly, like XFCE
18<shingetsu18> millerti: because that's how good design works.
18<shingetsu18> I'm in software architecture and every program that doesn't internally follow that idea eventually stagnates to hell and back
18<shingetsu18> that I have seen, anyway
18<pharpend_18> shingetsu: The only DEs I consider worthwhile are Xfce and KDE. KDE is the antithesis of the UNIX philosophy, but they do it very well. Xfce uses the unix philosophy, and they also do it pretty well.
18<millerti18> I mean, "unix philosophy" brought us stupid things like spewing an app's files all over the filesystem (e.g. /usr, /etc, and /var), when it would make sense to just them all in one place.
18<iamben18> shingetsu: also much of this "doesnt' follow unix philosophy" is from people who believe systemd is one big fat binary
18<iamben18> shingetsu: have you seen how many binaries systemd installs? lots
18<iamben18> lots and lots of little modular parts, that RIGHT NOW can't be used externally because no one has tried to write anythign to hook into them
18<shingetsu18> iamben: I realize it isn't, it installs a lot. However, they don't have a specific goal (what I'm mentioning)
18<shingetsu18> systemd on it's own, what is it?
18<millerti18> systemd has perhaps too many goals.
18<shingetsu18> is it a PID(1)?
18<shingetsu18> it does not choose one thing and then does it well
18<shingetsu18> it just does a bunch of different stuff
18<iamben18> millerti: it was meant to replace a huge part of the base-system, that's the whole idea
18<shingetsu18> sure they do it with MODULES...
18<iamben18> shingetsu: ^ you too
18<oniichaNj18> http://a.pomf.se/agsymw.jpg
18<shingetsu18> which huge part, list please :p
18<pharpend_18> oniichaNj: haha
18<shingetsu18> if they do it 100% modularly, and have a specific goal set, it's fine. but they obviously don't
18<iamben18> shingetsu: you already know, i think. lots of the low-level stuff is standardized, which some people hate but that IS their original intent
18<shingetsu18> oh hi oniichaNj ! welcome back
18<oniichaNj18> hi shingetsu
18<shingetsu18> yeah, and the way they moved past it is bad
18<pharpend_18> shingetsu: my other problem is their development practices. they essentially ignore bug reports, and they use git as if it's subversion
18<millerti18> Use "unix phiosophy" when it makes sense and abandon it when it doesn't.
18<shingetsu18> I accept systemd as a PID(1) and a dependency service loader
18<shingetsu18> iamben: ^
18<iamben18> shingetsu: locales, clocks, hostname, dev management, logging, etc. it's all being standardized
18<shingetsu18> I don't accept their other stuff tho :p
18<iamben18> do not expect systemd to be an exact replacement for sysvinit only, that's not its intent
18<djdunn-n718> iamben i cant wait till systemd works with selinux and grsecurity
18<pharpend_18> iamben: yeah, I have to agree with shingetsu, it's doing too many things.
18<iamben18> djdunn-n7: yeah i be that's all that'd holding you back =)
18<pharpend_18> iamben: and standardization doesn't mean "one program does everything"
18<iamben18> pharpend_: it's not one program, it's a whole base system collection
18<pharpend_18> it means "there's a way to do a certain thing, let's make sure everyone does it that way."
18<millerti18> There have been many previous attempts to do what systemd does. Call those protypes. systemd is another prototype that has finally gotten some traction. There's clearly a need.
18<shingetsu18> millerti: ok, so get systemd to write a spec
18<shingetsu18> instead of starting with an implementation
18<millerti18> pharpend_: In some distros, they have to make specific choices. Not all can provide the choices that Gentoo does.
18<iamben18> some people like their base system put together with duct tape and string and cardboard, which is great, but systemd is a pre-welded ready-to-go setup
18<pharpend_18> iamben: so you're saying, "think of systemd as an operating system"
18<Monkeh18> iamben: REstandardized, in new, broken ways, by authors who just don't care how much they break along the way
18<millerti18> shingetsu: I've read tons of systemd manifesto.
18<Monkeh18> Because everyone else can just start over to do things their way
18<shingetsu18> millerti: not a manifesto
18<shingetsu18> a specification
18<millerti18> Think of systemd as a core part of an efficient OS.
18<djdunn-n718> Now if only systemd would stop constantly breaking the welds apart and rewelding it
18<shingetsu18> e.g. read the unix filesystem spec
18<iamben18> Monkeh: let's just say they are very bold =)
18<millerti18> shingetsu: This is not a proper criticism. Most UNIX tools were built without formal specs. They have evolved.
18<Monkeh18> iamben: The line between bold and stupid in their case was worn away by heavy traffic a long time ago
18<shingetsu18> millerti: yeah, and they were bad until former specs appeared
18<pharpend_18> I get really pissy whenever they break their API, which they seem to do every release
18<pharpend_18> I don't like when things break
18<millerti18> Someone will write a spec, sooner or later. Meanwhile, systemd is a prototype system that we have to exercise in order to understand all its implications.
18<djdunn-n718> Kdbus is going to end up being an out of kernel module
18<pharpend_18> if it's a prototype, it shouldn't be in 90% of linux distributions
18<Monkeh18> Please exercise the prototype away from me and my equipment.
18<Monkeh18> And the software I use daily.
18<pharpend_18> millerti: what Monkeh said
18<iamben18> im interested in helping with the prototype
18<djdunn-n718> A constantly evolving prototype shouldnt be production ready
18<pharpend_18> well I think we aren't going to see forced systemd on Gentoo anytime soon, so we're all safe
18<iamben18> djdunn-n7: that's what windows admins say about the linux kernel! =)
24* dhbiker has quit (Quit: Nice Scotty, now beam my clothes up too!)
18<shingetsu18> iamben: linux kernel is a slightly different story. what it should do is clearly specced. they're in feature-adding mode, mostly, nowadays.
18<millerti18> Right now, it's only in Debain unstable, which you don't run on a critical system!
18<pharpend_18> iamben: "actively developed" != "incomplete and broken"
18<millerti18> And for Gentoo, this is a non-issue.
18<millerti18> And you don't have to use Fedora.
23* dhbiker (~dhbiker@APN-123-43-143-gprs.simobil.net23) has joined
18<millerti18> Yeah, the linux kernel is kinda slap-dash. You have to admit that. :)
18<pharpend_18> millerti: yep, I use Debian stable and Gentoo, so not really an issue for me. I like witnessing the drama.
18<millerti18> systemd is where it needs to be: In non-critical systems, in testing.
18<Monkeh18> millerti: The continuing removal of features from other packages to comply with systemd taking over by force, causing developers to have to work around it, is not a non-issue
18<djdunn-n718> Systemd is going to cause the end of sandboxing
23* paulo_ (~paulo@ip90-83-15-186.ct.co.cr23) has joined
18<iamben18> err, systemd has some cool sandboxing features..
18<djdunn-n718> Until kdbus comes and breaks sandboxing completly
18<djdunn-n718> Which needs reengineered to fix
18<millerti18> Growing pains.
18<iamben18> im sure we'll manage =)
18<shingetsu18> still don't see the need for kdbus
18<shingetsu18> (or dbus in general)
18<millerti18> The longer we just complain, the longer systemd will have these problems.
18<shingetsu18> dbus is slightly more justified, since it's a "universal socket"
18<shingetsu18> but remaking it into a kernel module???
18<djdunn-n718> Systemd needs kdbus so they can connect and link non gpl code to the kernel
18<Monkeh18> millerti: Resistance is futile?
18<millerti18> Exactly.
18<Monkeh18> Good luck with that
18<djdunn-n718> Otherwise how can redhat create a premium set of *d's for systemd
18<djdunn-n718> 3 years from now with systemd we will see premium/freemium model for systemd daemons
18<iamben18> i dont understand how that is specific to systemd or kdbus or any of that
18<iamben18> they can already write proprietary services
Click to expand...

I checked the number of binaries installed by systemd. It's 69. Now, I don't know about you all, but having a such huge rewrite of this much of the base system, with 69 binaries all reporting to the same guy, (and coded with glibc in mind, BTW, also belonging to the same guy, which has been highly controversial over the last several years) boggles the mind as to how it will be adequately maintained. It is an absolute MONSTER.

It went on after this, but the main ideas on both sides are fairly expressed here by some knowledgeable folks.

Incidentally, it's basically my fault, reading back, but we are wildly off-topic here; would it be a good for me to open a new thread and move this stuff into it? There might be more people wanting to weigh in on the topic, and this discussion might heat up even more in the near future.
 
Last edited:
While I don't want to scratch off the chat log. I'm going to remain open to see what systemd will provide in the future. Much has been said, chat log is more or less the same of the things I've read from reddit users. What worries me is the no specs part, hopefully someone in their team will fix that once they stabilize systemd, plus it'd be nicer to see what they'll be satisfying on the road. As for the famous "unix philosophy" I'm calling BS, a lot of applications rarely follow unix philosophy suddenly it's one of the complaints.

I don't think I'll add much to the thread if there's a new one for systemd. Much of it will echo what has been said before, concerns about not having "choices". I think we should take everything with a grain of salt and not let our emotions blind us, thus remaining objective.

And yea, we have derailed this so much, hahah.
 
I love OpenRC, it's more verbose, and from personal experience with it and Systemd I think that it's more stable. However, I don't really have anything against Systemd, I just prefer OpenRC.
 
I've contributed some small patches for SELinux to OpenRC. The code is mostly clean and relatively easy to understand, and OpenRC accomplishes pretty much the same goals as systemd without making 3/4s of the universe dependent on it.

IMO, systemd is a good idea, badly implemented. Why RedHat have chosen to go with it baffles me.
 
And this just about sums it all up:

systemd.jpeg
 
So when someone disagrees with you said person is a troll?

Complaining about something you like make said person a troll?

Christopher's writing is not baity enough or aggressive enough for him to be a troll.

I've heard those before, mostly by people trying to silence someone for their opinion.
 
You must log in or register to reply here.
Back
Top