Cry Babies Cry. Programmers Code.

A schism of sorts is forming in the Debian developer community as one developer has gone on record to formally criticize Debian's decision to adopt systemd in an Open Letter to the Linux World.

Here's what I have to say to Mr. Christopher Barry and others who may agree with his viewpoint.  Accept it.  Systemd is a done deal.  It's here for good reasons whether you realize it or not.  But I hope you eventually grasp why it was written, as it does solve many inherent 'known' problems with aged sysvinit.

And, as expected, a chorus of cry babies has been awoken, like sleeping dogs, taking aim (again) at systemd.

Those who complain in this instance, I am afraid, have a simple agenda.  

They are lazy.

As such and with much creativity they will persist lodging complaints so as to avoid doing some difficult, but not insurmountable, work.  Yes, there are many pain points in addressing merging systemd PID 1 code that are due to its 'middleware' central/critical role, which result in dependency changes and in some cases some major code rewrites that must be done to conform with this new technology standard.

Ah, standard.  There's the rub.  There are legions of arrogant, swaggering Open Source code jockeys who like to strut their stuff by spinning off their 'me too' Distro with their own branding overnight.  Have you taken a count of how many Linux Distributions there are now?

Standardization strengthens the power of Linux.  Distro sprawl does not.

The planned integration of systemd is now officially deployed to Debian Jessie Beta 1. This means that all the 'foot dragger' derivatives must follow suit with doing what is needed to align with this major system design change.

So, while we see some dig in their heels by organizing a boycott, others choose to simply whine, as the din gets louder and louder.  Soon, though, the cry babies will run out of tears, pick up their toys, and go home whilst the real-world Programmers continue to keep their heads down, doing the grunt work with little fanfare and nary a complaint.

Cry Babies cry.  Programmers code.  -- Dietrich

Related articles

• The Debian Init System Deba{te|cle}
• Systemd: Got Choice?
• Developer Dissatisfaction Looms with Systemd

Read More

The Debian Init System Deba{te|cle}

by Dietrich Schmitz

Debian Linux has had a long-standing reputation of being staid and pragmatic in their decision-making.  Even their software release management policy is on the long side when compared with other Distros.  A typical 2-year software cycle just doesn't cut it in today's Internet World operating at the 'speed of light'.

So, it would appear, the time has come for Debian's maintainers to make a decision as to which init system to adopt going forward.

While Debian 7 Squeeze includes systemd as an installable option, the default init system is sysvinit.

The debate currently being conducted at Debian is whether they should move to Upstart (used by Canonical Ltd.'s Ubuntu Linux), or, to systemd instead, going forward and as such a position statement has just been drafted on the Debian wiki site.

Sysvinit Disadvantages

The Debian Team has had many years of good results using sysvinit, but recognize it's limits are now beginning to show strain.  And with a feature freeze for Debian 8 nearing, they must determine which init system will become the new default replacement for the aged sysvinit.  

Here is their list of disadvantages for using sysvinit going forward:

• Sysvinit lacks service supervision. While /etc/inittab provides this capability, management of /etc/inittab is quite restrictive. Upstart eliminates the need for complicated PID file handling for all services. There are bolt-ons that allow you to do service supervision on top of sysvinit, such as runit, but it's clear that these are bolt-ons.
• Sysvinit does not track dependencies between services. Insserv/startpar provides this on top of sysvinit, but this is again very much a bolt-on, and only handles dependencies at boot/shutdown time (i.e., during runlevel changes) and can't handle any complicated service interdependencies at runtime. Upstart expresses this information in the native service configuration format, clearly and concisely.
• Sysvinit requires complex shell scripts for each service. While some of the complexity has been abstracted out into common helpers (lsb-functions; start-stop-daemon), having to represent each service's start/stop handling as a program is a severe handicap. Upstart jobs are simple, declarative, easy to maintain, and easy to modify locally as needed. They also eliminate the longstanding nuisance of update-rc.d reactivating services behind the administrator's back on upgrade.
• Sysvinit is linear. It stopped being a good fit for boot management on Debian the moment Debian adopted udev. There are many race conditions that persist in Debian today when booting with sysvinit, and although these may be fixable, the complexity for fixing them with sysvinit is very high. We're better off switching to an init system that's designed to work together with the event-based kernel and udev.

Upstart vs. SystemD

Clearly, Debian developers recognize that the time has come to make a change.  

In the opinion of the author(s) of the position statement, it would seem to place both init systems on equal footing insofar as features are concerned: 

"In terms of overall feature uplift of the init system itself, there is really rather little to distinguish upstart from systemd. Both would represent a huge step forward for Debian over sysvinit. If Debian did not adopt upstart, systemd would certainly be my second choice."

Looking further for some substantive information in the position statement, the author(s) go on to make some subjective comparisons:

But despite the init systems being comparable at the feature level, there are reasons that I think upstart is a better fit for Debian than systemd.

• SystemD is Linux-specific. Upstream has been very clear that they are not interested in accepting porting patches to enable systemd to be used with kernels other than the Linux kernel. If Debian wishes to continue to support non-Linux ports, this significantly reduces the benefit that maintainers would gain from having a simpler init format to support.

• SystemD is hasty. Debian is late to the party when it comes to adopting a better init system, but systemd is evolving rapidly and does not have a long track record of backwards-compatibility that it can point to. While systemd is unlikely to break any interfaces that upstream has promised to maintain, I think there is a risk that newer dependencies will be driven by the version requirements in Fedora and RHEL, leaving Debian to fend for itself with respect to sorting out rocky transitions on upgrade - not unlike the problematic udev transitions of the past. Upstart is committed to maintaining compatibility across stable releases of Debian, just as it currently does between Ubuntu LTS releases. While upstart seeks to leverage newer kernel features where this makes sense, we are committed to having sane upgrade paths and not depend on such kernel features prematurely.

• SystemD is "greedy". Most of the recent arguments about why it's dangerous to adopt upstart instead of systemd center around features that are being built into systemd in a manner that can't be separated out (e.g., cgroup management in PID 1). There is an advantage to the implementor to put these features in-process in init, because it ensures early availability with no concerns about startup ordering at boot, but it commits downstreams to a monolithic design with respect to parts of the system architecture which are not settled questions in the wider ecosystem. Debian should take a principled position regarding its future architecture, and not find itself at the mercy of other parties who wish to dictate design to us.

So, it is apparent the author(s) are in favor of Upstart but would 'consider' systemd, yet, go on to reinforce with additional reasons why Upstart should be considered over systemd.

As though that were not enough, Google Plus user and Intel employee/Gnome community member +Sriram Ramkrishna  threw his opinion into the mix characterizing the whole subject as having morphed from its original purpose.  Ramkrishna writes:

"...the whole debian systemd discussion has turned into a referendum on GNOME being the default DE for Debian with those who want to switch advocating switching to XFCE as I would imagine that it works closest to what GNOME 2. Why they didn't pick Mate, I don't understand if they want the GNOME 2 experience.

The discussion seems to miss the fact that they would miss out on Wayland and moving to a new display server? They can of course do what they want as that is their prerogative. But it seems that long simmering resentment against GNOME and the change in UI has risen to the fore with the small dependency that GNOME has on systemd. They are using that as an excuse to drive a change in DE.
There are a lot of good reason to use systemd, all that has been rehashed. But the biggest nonsense I've read (as an IT guy) is the fact that we should have a choice in init systems. What the fuck? Essentially people just want to make every part of the OS to be hot swappable. Who would want to support such a system? Who will QA all these combinations? It's madness!..."

However valid the reasons set forth in the Upstart vs. systemd position statement may be, the level of emotion rises whenever a discussion is had concerning moving to +Lennart Poettering's  systemd.  Personally, I believe in the long-term systemd will become the best option receiving full support from the Linux Foundation's kernel.org developers insofar as plans to merge udev and systemd into the kernel are concerned.

The concern is that Debian's pragmatism may work against them and cause a backlog queue of software development issues.  So, acting in a timely fashion in today's world is vital to remaining competitive for any Linux Distribution.  

Hopefully, the Debian Team have recognized this and will respond by making adjustments to how their organizational structure and decision making process works to result in overall efficiency improvements.

As for the Debian init system issue, my money is on Debian going with Upstart, since that was the system chosen by Canonical Ltd. for Ubuntu and Mark Shuttleworth has no intention in making a change any time soon.  This would put both Distros and their derivatives in alignment with each other going forward and efficiencies would obtain.

Here's hoping Debian reaches a decision which best serves their future needs.

-- Dietrich

Related articles

• Debian To Replace SysVinit, Switch To Systemd Or Upstart
• Debian 8.0 To Be Frozen, Features Announced
• Debian To Switch To Systemd Or Upstart

Read More

Systemd: Got Choice?

by Dietrich Schmitz

I've been thinking over the whole systemd issue and have written several stories about it.

It seems to me that somehow a major tenet of Linux has been overlooked:

CHOICE

When exactly did choice go out the window?

I want to know why systemd is not an 'opt-in' configurable option?

Did I miss something?  No, I am afraid I didn't.

No, the whole situation has really been simmering in my mind and as I did more research on systemd, the only conclusion I can reach is that systemd is being foist upon us without a shred of consideration being given to 'choice'.

There is no recognition of or respect given to choice when a Distro simply removes sysvinit or any of the other fine initialization schemes in favor of systemd.

This represents a violation of a major tenet of Linux that I cherish and don't appreciate having simply taken away from me.  Choice is mine.  I can let someone else make a decision for me, or, I can seize control and decide for myself what is best for me.  Someone else has decided that systemd is best for everyone.  Well, guess what?  It isn't.  And you don't have to accept it.  There are still Distros which don't use systemd and some that actually do give you the option to use it.

As far as I am concerned, this is a grievous error and every user should protect their given right to choose what is best for their situation.

Making systemd an opt-in configurable choice should have been given top priority.

If you don't protect your right to choice, who else will?

Today, as a matter of principle, I am taking action on this issue and resolve to do something about it.  Taking choice away is wrong and elitist at best.

I will fill you in later in a follow up story.

-- Dietrich

Related articles

• Gentoo Team Isolates Udev from Systemd (eudev)
• Slackware: Is Systemd Inevitable?
• Systemd: An Accident Waiting to Happen

Read More