> When Lennart Poettering started thinking about the problem, he first looked at Upstart, which was an event-based system that was still based around scripts, but he concluded that he could do a better job.
I think I'd like systemd more if I had more confidence that he had done a better job.
I never really understood why Upstart didn't get more traction; was it just the Canonical backing made other distros avoid it, or did it have drawbacks I never ran across?
I used upstart deeply around 2012-2014 in a commercial product based on Ubuntu. I remember two problems with it which had me waiting for Ubuntu to switch to systemd (unfortunately my employer ran out of money right when that happened). The first was that Upstart's model is upside-down: where systemd has units that depend on units, Upstart has jobs that are activated as other jobs complete. Whereas you would tell systemd that (say) Apache depends on syslog and ask it to try to start Apache, and therefore systemd would first try to start syslog, you tell Upstart that Apache can be started when syslog starts, and that you should start syslog, and then Apache's dependencies are met and Apache can start too. Instead of having a single target (like sysvinit runlevels or systemd's multi-user.target) that it works towards, Upstart just starts ... stuff ... untill it's done. Upstart did have a runlevel concept, but as I recall it was an event that triggered jobs to start, not a target. See http://upstart.ubuntu.com/cookbook/#critique-of-dependency-b... for Upstart's defense of this approach.
(systemd is hardly unique in being dependency-based instead of event-based - but it is a strike against Upstart in particular. Also, while one of the stronger claims of why Upstart should work this way is it matches the evented mindset of udev, systemd can handle events from udev just fine, by just having it add additional targets - and in the end, systemd consumed udev.)
The other was that it was hard to deal with its bugs. I had a job that wasn't activating. I spent days chasing it, including attaching a debugger to Upstart, and eventually gave up. I've used systemd extensively and have not had "Why isn't this service starting" bugs. (I've certainly had that confusion, but I've always been able to figure it out quickly.) systemd has in my experience been reliable and trustworthy. I'm not going to say that it's bug-free, or that I like its implementation, or that I have no complaints about it. I am going to say I haven't been frustrated by it - even when running very old distro versions with lots of known bug fixes upstream. That's very important for whether I'm happy with it or whether I'm going to switch back to sysvinit and find something else for service monitoring.
The problem is full process management, and in that regard, upstart was pretty much still just scripts. I will say this, systemd tries to solve the problem of tracking all children/grandchildren which is difficult to do with sysvinit or scripts by themselves.
Systemd also solves the problem of unified ways to start services across many distributions. Packaging things is easier. I don't like the systemd ini target format and wish something else had won out instead. With something like upstart, in theory you could rewrite the upstart daemon and use the same scripts, since the format/standard was much simpler.
I feel like there must have been a lot of bullying to get systemd across so many systems. It just seems weird to see so many major distros all decide to accept something so complex if it wasn't for Redhat cramming it into everything they maintained and helped fund.
You know, he didn't say that. He said Red Hat adopted a complex system that solves some problems - implying that they may have some other motivations. If anything, the point seems to be that it is a very complex and unwelcome way to solve some problems - and perhaps unworthy of Linux.
> I feel like there must have been a lot of bullying to get systemd across so many systems.
I followed the Debian discussions when they debated init changing.
It was not pretty, there was a lot of things, but I don't remember any bullying. It was simply a very long uphill battle from a sort of loose group against the majority of maintainers that wished to stop worrying about 99% of init script problems.
Systemd is not perfect, never was, but it gets shit done, whereas no other project does in this regard. (A lot of people wanted to tackle some parts of what systemd does, but that was late and insufficient.)
And, all in all, there is always room for a systemd2 in Rust, distros would switch to it in a heartbeat, if it would be better.
I think it largely was Canonical that was the issue. Every time they've pushed something that they designed/developed it always seemed to me that they were more attempting to solve their business model problem rather than a Linux architectural problem. (i.e. get people dependent on them rather than just providing a solution)
Even though Red Hat is a much larger organization, their contributions have never felt like power plays in the same way that Canonical's have. Perhaps it's just the way that Canonical tries to shove their stuff through while Red Hat seems to get more organic buy-in. For example, as controversial as Systemd was (mainly from sys admins and power users), it did have a level buy-in from distro maintainers and developers which Upstart never really did. Canonical just tried to say 'we're doing this.'
Sure, many things have been contentious... changes in general meet with resistance. That's not a uniquely Red Hat, or even Canonical, thing. But in the end, and this is just my impression as I'm no longer a major user of either company's distro, Red Hat seems more interested in working with (with the notable exception of one specific prolific individual) other developers and distros while Canonical doesn't. It shows in the results: most of Canonical's major initiatives don't even survive in their own distro for too long either because of user revolt or the other distros go in a different direction. (they lost me as a user because of a couple of them)
(If there are distro maintainers / package developers who disagree, I'd be interested to hear about it. Again, this is just my impression)
Scott James Remnant
+
4
1
2
1
Reply
+Michael Hasselmann at the point that Kay, Lennart and
I sat down and discussed all this stuff, I don't think
Upstart was perceived as "shitty" at all. We'd had
on/off discussions for ages, but the big one I remember
was the LF Collab Summit in SF in April 2010.
Hindsight certainly lends a different perspective, and
I'd be the first person to say that Upstart doesn't
work as intended. +Lennart Poettering makes a great
point about mountall in a recent post, it was written
because Upstart couldn't do the complex filesystem
cases it was designed to be able to do; and I was very
aware even at the time that was a failure that would
need to be addressed.
Had the CLA not been in place, the result of the LF
Collab discussions would have almost certainly been
contributions of patches from +Kay Sievers and Lennart
(after all, we'd all worked together on things like
udev, and got along) that would have fixed all those
design issues, etc.
But the CLA prevented them from doing that (I won't
sign the CLA myself, which is one reason I don't
contribute since leaving Canonical - so I hold no
grudges here), so history happened differently. After
our April 2010 meeting, Lennart went away and wrote
systemd, which was released in July 2010 if memory
serves.
So I don't think I can claim that the perceived
shittiness of Upstart spawned systemd, because at the
time it wasn't seen that way. I don't think I can even
claim that it provoked Lennart in any way, init was an
area all distributions were fiddling with, so it was
inevitable anyway.
I entirely agree with Kay and +Greg Kroah-Hartman that
it was the CLA that caused systemd to be written
instead of Upstart.
But I don't need that self-affirmation anyway :) I
wrote Upstart, I got paid for it, I moved on to do
other things, something else came along and replaced
it. If Upstart hadn't been under the CLA, and systemd
hadn't've happened, all my code would have long since
been rewritten by now anyway.
That's the nature of the software world, there's no
point getting precious over things. Do your bit, have
fun doing it, move on and let others do their bit,
etc.
Can’t speak to the parent but I have a similar feeling.
Personally I’ve been using openbsd quite heavily for personal projects, for work my team transitioned from RHEL6 to FreeBSD- and while it has quirks (mostly on installation of software) it is incredibly stable.
It’s a shame my chosen cloud provider doesn’t treat it like a first class citizen, but that’s fine since the community projects seem to work on making good images.
I still use Linux on my desktop and laptop; since I feel like the design of systemd is more suited to those roles (systemd’s design in general feels like windows service activation) but I’ve been having issues that seem to be related to systemd. So it’s not winning me over.
Not the person you replied to but systemd was the last straw that made me switch all my servers to FreeBSD.
FreeBSD is much better at just not screwing everything up (particularly on OS updates). Sometimes I have to manually configure a new piece of hardware, but once I configure it it stays configured, and the way to configure it doesn't change from version to version.
On my new laptop I just didn't bother replacing windows. With "Bash on Windows" I can run all the unix programs I wanted to, but windows is handling all the session-management type stuff that systemd would do. I've found the system more reliable and better at responding to hardware changes. As much as there are horror stories of windows update breaking everything, I haven't experienced that myself (whereas I have had systemd updates leave systems non-booting).
I think I'd like systemd more if I had more confidence that he had done a better job.
I never really understood why Upstart didn't get more traction; was it just the Canonical backing made other distros avoid it, or did it have drawbacks I never ran across?