upstart, systemd, Canonical and Debian

[ian-weisser]

Would love to hear what ian-weiser has to say now

-Snort-...huh?
(Blinks blearily)
Why, what happened?
Did the flamethrowers run out of fuel?
EDIT: Oh, I see. Debian chose systemd for init, and SABDFL announced that Ubuntu will match debian by changing to systemd for init.

My position hasn't changed: Debian is blessed with two good, new init alternatives. I wish my problems were deciding among good choices.

I was, of course, wrong when I predicted a slow decision.

I stand by my opinion that Phoronix is a lousy source for good, dispassionate analysis.

[vasa1]

Now there's a website for those not in favor of systemd: http://boycottsystemd.org/

While that link is quite technical, "binary blob" and "SPOF" (single point of failure) aren't comforting.

[rrnbtter]

Greetings,
That site has been up for a while, it is not new. I take it to be just more of the same old high chair banging over the demise of the older Linux OS/Desktop/Tools that fit the low powered systems of yesteryear. I am not personally interested in flag waving only the enjoyment of a forward moving experience. Ubuntu and Unity so far has fit the need. I am updating my Ubunut-next on a daily basis and so far am please with the clumsy results. P.S. SystemD seems to fit the new paradigm just fine!

[vasa1]

Greetings,
That site has been up for a while, it is not new. ....

Okay, I'll remove "Now"

[1clue]

I think there's a lot to the argument. Systemd might become good enough in the future but I don't think it is now. The single point of failure argument is huge IMO, and the complexity of systemd and all its so-called optional components that somehow always need to be loaded anyway.

Linux is built on the premise that an app does exactly one thing, and does it really well. Systemd is slowly taking over the entire system. This is not good, it's not faster and it's not better.

[buzzingrobot]

I think there's a lot to the argument. Systemd might become good enough in the future but I don't think it is now. The single point of failure argument is huge IMO, and the complexity of systemd and all its so-called optional components that somehow always need to be loaded anyway.

An identical argument could be made about the kernel and X.

Linux is built on the premise that an app does exactly one thing, and does it really well. Systemd is slowly taking over the entire system. This is not good, it's not faster and it's not better.

Well, systemd is not an application. It's a replacement for, and an enhancement of, an init system organized rather haphazardly over the years as a long chain of interconnected shell scripts. Neither solution is simple, and can't be.

Linux was created by Torvalds because he was a college kid who wanted, but could not afford, a real Unix, source and all. By that time, Unix was well beyond it's very early one-tool-for-one-task aproach (even then mostly a virture made from necessity: slow, weak hardware.) That approach has merit when users are sophistcated and skilled enough to create scripts to leverage those simple tools, piping output from one into input of another, etc., *and* when graphic displays and mice weren't available. Making GUI tools that "do one thing and one thing well" doesn't really make sense.

As a user who spent a good amount of time in the past dealing with the innards of Linux when that was mandatory if you wanted a usable and functioning desktop, I think the workings of the init system counts as something I -- as a user -- shouldn't -- and don't -- worry about. Systemd has a job to do. If it does it well, I won't know it's there. If it does it poorly and draws attention to itself, I'll go find another distribution.

[cariboo]

I'm currently running Utopic with systemd enabled, and aside from a slight problem with cups, that has been fixed upstream, it works seamlessly. The only difference between upstart and systemd that I can see, is that the system starts a bit faster.

[rrnbtter]

Greetings,
@vasa1, Sorry for my comment regarding your post. I actually wasn't trying to correct your post. I neglected to follow with what was my intention to say, the boycott site was started prior to Ubuntu going to Systemd. Systemd got traction by being picked up by Redhat, Suse and the like that are heavy in the server market. Since it has the big guys behind it, it is strongly maintained. When it started to migrate into Fedora, Debian and the desktops is when the creator of the boycott got a fire burning. I kind of get his point. There has been a consistant segment of the user base that want to keep it simple and they seem to be pretty vocal about their concerns. What I think is that Puppy Linux and quite a few others do a really good job in the "small" segment of Linux. Its obvious to me the Canonical has other asperations. I personally like the way that Systemd works and the general direction of Ubuntu/Unity.

[1clue]

An identical argument could be made about the kernel and X.

Really, about neither. The kernel is an interface between the hardware and a standard API. It really does nothing much else.

X is a windowing interface: An APi for an app to specify drawing things in a rectangle. The specification is handled by the app. On top of X you specify a window manager: A basic API for drawing window frames and controls for them, and handling basic events based on that. And so on.

Well, systemd is not an application. It's a replacement for, and an enhancement of, an init system organized rather haphazardly over the years as a long chain of interconnected shell scripts. Neither solution is simple, and can't be.

I certainly would classify it as an app. Some might call it a daemon, but it's an app which handles startup of system resources. It's what runs the stuff that runs your system. To date it has had a very simple purpose and has performed it well. OpenRC is orders of magnitude simpler than systemd, and systemd offers nothing of interest to me in the first place.

Why should I multiply my system's attack surface by a hundred for no benefit? Why should the boot code insist on changing our filesystem layout? Why should the boot system insist on javascript in the boot process? Javascript is the least secure language ever written for computers, and has no business where they put it.

Linux was created by Torvalds because he was a college kid who wanted, but could not afford, a real Unix, source and all. By that time, Unix was well beyond it's very early one-tool-for-one-task aproach (even then mostly a virture made from necessity: slow, weak hardware.) That approach has merit when users are sophistcated and skilled enough to create scripts to leverage those simple tools, piping output from one into input of another, etc., *and* when graphic displays and mice weren't available. Making GUI tools that "do one thing and one thing well" doesn't really make sense.

When I got into this, X (Xfree86) was a novelty that took days to download over a 1200 baud modem, compile and set up. It was unstable and completely unnecessary. Today, almost all my Linux installations are headless without any sort of GUI. Frankly, I'd say that most current Linux installations in the world are headless without a desktop. Why should these systems use systemd?

The init system has changed dramatically since I started, even if you ignore systemd. But it's always had an elegant, single-purpose structure. Different distros didn't always have the same one, and sometimes offered alternatives.

That's the key here: To date every init system has been an interchangeable part, up until recently. Lennart is trying to insist that all of Linux do things his way: The Microsoft way.

As a user who spent a good amount of time in the past dealing with the innards of Linux when that was mandatory if you wanted a usable and functioning desktop, I think the workings of the init system counts as something I -- as a user -- shouldn't -- and don't -- worry about. Systemd has a job to do. If it does it well, I won't know it's there. If it does it poorly and draws attention to itself, I'll go find another distribution.

Average people should not have to worry about the init system. For years, most Linux users have cared less about it. For those users who DO care, it's important.

Systemd has a lot of flaws. For one thing, they insist on the presence of /usr during boot. That's a terrible idea. Traditional init systems like openrc have /bin and /sbin specifically so the / partition can be small. Only core files needed at boot need to be on /. These core files are rarely updated and as such if you handle your partitions correctly your / partition has very few writes and has much smaller chance of errors. /usr is supposed to get files which are "regular" applications not necessary during boot. These are updated much more frequently, and they take a lot more space, many times more than those in /bin and /sbin. Statistically speaking, the partition with the files normally found in /usr is much more likely to have an error. If you MUST load /usr during boot, and it has an error, then you just don't get to boot.

The list goes on and on and on.

[1clue]

one of the many reasons I just like Debian. Specially "Debian's governance is specifically set up to encourage inaction when there is a lack of consensus."

Actually it's one of the reasons I don't like Debian. I'd rather they be more up-to-date and decisive, and intelligent while they're at it.