[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#727708: On diversity



On Fri, 2014-01-17 at 16:08 +0100, Ihar Filipau wrote:
> Uoti Urpala wrote:
> > Even the upstart proponents do not seem to have significant arguments
> > about upstart having better functionality, and there don't seem to be
> > all that many people who would have a reasonably informed opinion that
> > upstart would be technically better even for just their particular use.
> 
> I followed the discussion from the beginning and I'd like to comment on that.
> My own comparison of systemd vs. upstart (Fedora 20 vs. Ubuntu 13.10) is still
> fresh in my memory.

Your comparison does not look very informed, see below.


> 1. "upstart" is a highly configurable init system, while "systemd" hardcodes
> most of the nuts and bolts in the 32 shipped executables. I spent one days

Your "hardcodes" is wrong: systemd ships with helper executables and a
default boot setup which uses those, but they're not hardcoded and you
can use something else if you have a reason to.

> So here you go. The advantage of the upstart, is that if you need to tweak the
> boot of your system, you can do it right there, with the text editor, by
> changing the .conf files or the shell scripts. While with the systemd, you have

I strongly disagree that using shell more as an implementation language
would be a good thing. But out of the things in your post I think this
is the closest to a not-factually-incorrect personal preference someone
could have for upstart: some people could prefer working in shell only.
However, this isn't really a comparison of the init systems themselves
so much as a comparison of the default boot setups shipped with the
inits. Even if you decide that almost every program running on your
system should be implemented in shell only, you could still use systemd
to start those programs, though you'd need to change more of the default
configuration if you wanted to avoid starting anything non-shell at
boot.


> 2. "upstart" was not designed or intended to be a SMF (service management
> facility), while "systemd" was.
> 
> I think it is insincere of upstart proponents to even advertise it as such. On

> On the other side of the fence. As I see it, it is only a coincidence that
> "systemd" is also an init system. To me it was clearly designed from ground up
> as SMF: boot and initialization were only afterthought. That's why the magic
> binaries, because the initialization, an event driven process, simply doesn't
> fit into the systemd "everything is a service" model.

This is nonsense. Technically, the choice of implementation language for
the binaries/scripts and the event/dependency model are completely
orthogonal. This means your last sentence is completely wrong. It's also
not plausible as a historical fact that boot would have been an
"afterthought".


> 3. Boot times. Though systemd was supposed to improve the boot time, Fedora 20
> VM on my rig needs 1m5s-1m15s to start - while Ubuntu 13.10 VM always timed
> flat 0m35s. That was pretty dumbfounding realization, especially after finding

Other people have Fedora booting a lot faster. There are lots of reasons
that could make boot slow other than inherent problems with the init
system, so if you haven't done any analysis of the causes of the
slowness, this does not really tell anything.


Reply to: