Hacker News Reader

Comment by badsock | Hacker News Reader

I almost think there should be a divorce. Call it systemdOS and be done with it. At that point every service it subsumes will be seen as a step closer to the obvious end-goal rather than a point of contention. And the other OS can be something like the Gnome2 fork MATE.

It's not a technical thing, it's cultural. The two sides are playing tug-of-war with the same OS, and systemd's winning, but maybe it would be better to have a positive culture around the changes they're making instead of always having people dragging on the rope. Some forks have been good in the past - EGCS/GCC for example.

View on HN

> Call it systemdOS and be done with it.

Every major Linux distro has chosen systemd as their future. I think that means whoever wants something different needs to change their name, rather than every major Linux distro changing theirs. Just as the Gnome 2 fans chose a new name for their future based on that lineage.

Fair enough. It just seems like it might be useful to have a symbolic split of some kind, where people choose a camp instead of trying to pull in both directions. Naming can do that.

Devuan is, apparently, a fork of Debian without systemd, so there are seemingly reasonable options for going that path. I, personally, won't miss initscripts, but one of our customers has been begging for a Devuan port of our products, so I guess some folks are excited about it.

> as their future

..and here I was thinking they chose it as an init system.

Well, hopefully now you see that it never was just an init system. It is literally the future of Linux in the eyes of its proponents, as it gobbles up more and more crap. And people wonder why there is opposition to systemd!

> Every major Linux distro has chosen systemd as their future

Gentoo is a major Linux distro too.

Correct me if I am wrong here, but I thought Gentoo user had to make active choices when it came to make, compile and configure an installation, and that Gentoo as a distribution had a hands-off approach when it came to make decisions for the user. Is there a "default" init system, where if the user make no decision they end up with a specific one?

https://wiki.gentoo.org/wiki/Comparison_of_init_systems

Gentoo officially uses OpenRC (and eudev), which is what you get if you follow the installation handbook. However, Gentoo also encourages choice and allows many options for init, daemon management, etc, which includes systemd. Other options ( are also available, too, at least unofficially.

> if the user makes no decision

While OpenRC is the official default, the "compile and setup everything yourself" nature of Gentoo makes this kind of statement somewhat irrelevant. One of the major reasons to use Gentoo is the ability to pick the components you want in your OS so it meets your specific needs. So yes, while there is a default, the concept of having a "default" is less important when you are installing everything manually.

I don't really stay on top of popularity of distros, but I'd be surprised if Gentoo is in the top 10, in terms of usage. But, when I say "major Linux distros", I mean, specifically: RHEL/CentOS, Ubuntu and Debian, as those are clear market leaders on the server (I mostly pay attention to the server space). Fedora, Mint, and maybe Arch comes into the picture for desktop, I guess? SuSE seems to be on the rise again. All of those are systemd, I think.

I guess one can argue about what level of popularity makes something a "major Linux distro". I, personally, wouldn't put Gentoo into that category, unless I saw some evidence of dramatic increase in its usage.

If you would tell me "this will just fix & improve init system" then that would a no-brainer. However I feel like the scope of the project has massively changed over time, so people (distros) who agreed with something a year or two ago could have a different opinion nowadays.

> so people (distros) who agreed with something a year or two ago could have a different opinion nowadays.

Do you have an example of a distro that feels that way?

I only follow Fedora and RHEL/CentOS close enough to know, and they're still quite pro-systemd on all fronts, though there's still some hybrid stuff sticking around for backward compatibility and user comfort (so, a lot of stuff people were used to doing in the past still works the same on systemd-based systems).

> Do you have an example of a distro that feels that way?

Void Linux switched from systemd to runit.

Only systemd opponents think it is cultural.

Systemd is just fixing things that have been broken for a very long time.

> Systemd is just fixing things that have been broken for a very long time.

This. I for one don't miss the mess of shell scripts for network management, init, bootloader, cron, etc. I personally think systemd already does 10x better at each of these tasks then the broken scripts have ever done.

Changing the syntax of scripts managing devices and services is hardly an improvement by itself. Yes there are some ideas which have resulted in more useful tools for administrators (systemd-analyze and friends), along with more predictable behaviour which again helps administrators a lot, but apart from those systemd is just "fixing" things which were never an issue for the desktop user.

"Changing the syntax of scripts managing devices and services is hardly an improvement by itself."

That's not what has been done.

systemd unit files are not "scripts". They are declarative configuration files, usually orders of magnitude smaller than the initscripts, network scripts, etc. that they replace. The Apache unit file on RHEL7 is ~17 lines long, and it replaced an initscript that was a couple hundred lines long.

It is a difference of both degree and kind.

There's script & executable invocations inside systemd service files as well. They're simply handled differently. Some setups use dedicated units to just do `modprobe X`, and have "easy" dependency management. Some are replacing udev rulesets with systemd units, none of which are "orders of magnitude smaller".

Just saying, the de facto ways of using systemd are starting to diverge a lot from the intended behaviour. And of course, the de facto usage is what we'll judge each piece of software's merits on...eventually.

I wouldn't call that diverting, but adapting already available scripts to systemd, and eventually they'll get rewritten

Presenting the need to rewrite service scripts as an inevitability is not convincing anybody - and I hate shell scripts more than most.

systemd has an initscript compatibility layer; it works with initscripts, and there is no expiration date on that functionality, to my knowledge. What more do you want?

I never said that they are going to be forcefully rewritten, I meant that whoever maintains initscripts might eventually rewrite them using systemd units more tightly because they are going be simpler and easier to maintain (in general, not because systemd is making anything any harder). You will still run something with systemd, this something can be the plain executable or an initscript, it is not like systemd checks and makes sure it likes whatever it is running...

Except that the more complex unit files still rely on shell scripts - they're just split off into separate files in another directory. systemd simplified init scripts by spraying their content over half a dozen or more different files and then only advertising the size of one them.

Got any examples?

If you're only a desktop user, where do you interact with systemd at all? I am, and I certainly don't.

Precisely. No desktop user ever interacts with the init system.

On the other hand, Linux has a history of _forcing_ desktop users to mess with device management for the simplest of tasks, e.g. making their audio devices work.

> No desktop user ever interacts with the init system.

So you've never restarted a service on your desktop system?

On both Windows & macOS, I've created & managed services, and never had to restart them after they were deployed.

I don't use a Linux desktop (I often retry) because that is unattainable.

You've never changed the configuration of a service?

The claim that systemd doesn't just fix init scripts packs two lies into a very small amount of space.

The parallels between the systemd/anti-systemd "war" and the recent U.S. election are striking. I wonder if a "trumpid1" systemd competitor is in the future...haha...ha...

I don't know about that. I like systemd but I think it has a very different culture from classic Unix. (I never liked Unix culture.) It is probably possible to fix many of Linux's problems while keeping the old culture but no one can be bothered to do it.

> Call it systemdOS and be done with it.

I think of systemd as one component in an attempt to create a good desktop environment based on the Linux kernel. Sort of like how Android is an attempt to create a good phone environment based on the Linux kernel.

Based on that, I think it makes more sense to come up with a separate name for something like a Gnome/Wayland/Weston/systemd/Linux combination. While we are at it we could come up with a separate name for a Linux based system configured primarily by writing scripts. We should stop pretending that there is some sort of generic combination of things called "Linux".

Android is hardly a component. It's a fork. Systemd should also be a fork, that was the GP's opinion too, wasn't it?

I've been tentatively calling the former FDO/Linux or XDG/Linux, FWIW.

>I think of systemd as one component in an attempt to create a good desktop environment based on the Linux kernel.

systemd works on systems as small as embedded systems up to huge hpc systems. It's not just a desktop thing.

...for some value of "works".

...works better than sysvinit, and upstart.

Except when it doesn't or when it's pain in the ass (embedded systems, or so I hear).

You heard right.

Reply on news.ycombinator.com