Comment by mikekchar | Hacker News Reader

Comment by mikekchar | Hacker News Reader

Parent Full thread

You're getting down voted mainly because you are wrong. I'm actually not well versed in this, so hopefully somebody will correct my wrong version -- but at least I think it will steer you in the right direction ;-)

Systemd solves real problems that have to do with virtualisation and/or containerisation. Red Hat is the company that wrote Systemd and they did it for commercial reasons (i.e. they needed these facilities in order to fulfil contracts with paying customers). Red Hat contributes greatly to Gnome. I haven't checked, but I believe they are far and away the biggest contributor. They have financial reasons for doing so, but I don't really understand what they are.

The connection between Systemd and Gnome is real, but not quite what you think. Systemd does make some stuff in Gnome easier to do, but it isn't really necessary at all. Systemd was not developed for Gnome -- it was adopted by Gnome. It's a bit of a dog food problem. Most Gnome developers (i.e. Red Hat developers) have a vested interest in Systemd being successful. They want to make sure they are using it where they can. They saw no particular reason to make Gnome 3 compatible with any other init system because: 1. It would be more work and why should they pay for work that isn't in their interest 2. They want more people to adopt Systemd because that puts Red Hat in a good position to sell more contracts.

It's totally understandable and not really underhanded. I personally hate it with a passion, but things I hate are not always evil :-)

Systemd solves real problems that have to do with virtualisation and/or containerisation.

systemd predates the industry love affair with containerization and virtualization for workload management, although work on containerization within systemd may have helped increase awareness of containerization's value. I don't remember early reasons to use systemd mentioning either; the rationales trotted out in favor of systemd in its early days were reducing boot time and replacing shell scripts used during boot, shell scripts labeled things like "old" and "fragile", despite multiple decades of shell scripts being successfully used to reliably manage the boot process on open source and proprietary Unixes, alike.

systemd does not predate the industry's love affair.

According to wikipedia, the initial release was in March 2010. The industry started courting virtualization (as it is practiced today) with the appearance of EC2, in August 2006, and the love affair came shortly afterwards.

"Reducing boot time" is of great importance for short-lived containers - if it takes 60 seconds to boot a server, and you only run it for 120 seconds, then you have 50% overhead. If it takes 6 seconds, you're down to 5% overhead; If it takes 150ms (e.g. Intel Clear Container project), it's completely negligible.

Those scripts, are, in fact, old and fragile, and while they did manage the boot process, "reliable" is a stretch. I've personally filed 2 bugs against the horrible hodge-podge of isc-dhcp that, in rare occasions, randomly failed (which is a bit of a problem if your DHCPd box is unattended and a few hours drive).

Through the years, many systems much better than init scripts have been proposed and implemented - personally I like the daemontools family, which I think is inherently better thought out.

although it definitely helped to have red hat backing, systemd won on for technical reasons: it's much better than the init scripts; it's not inferior to any other system; and it comes with simple integration with network/resolvers/etc (by virtue of including those services) -- something that saves distributions a lot of work integrating various parts.

> "Reducing boot time" is of great importance for short-lived containers

Containers don't tend to run an init.

While true, i think the notion here is to treat containers like VMs in the cloud. Thus a container is spun up or down depending on the load on the service.

Then again, that notion brings to mind a certain comic about a self-ddos...

http://www.commitstrip.com/en/2015/07/08/true-story-fixing-a...

Systemd as a project has developed a history of moving goalposts. Their initial talk was about boot speed by using dependency trees and parallel execution.

But when containerization caught the zeitgeist, they were quick to trot out nspawn as an alternative to, say, Docker (never mind that Docker and RH devs had a bit of a spat around the same time).

Since then they have been shifting the goalposts towards whole system management, perhaps best likened to Windows Active Directory, by adding more and more sub-systems that frankly has crap all to do with booting.

On top of all this it seems the people involved regularly end up pulling grsec style "fixing" of systems that work in real life but are "broken" according to some spec or other (sometimes ignoring decades of hard earned experience in the process, as was the case with their DNS reimplementation).

Gnome 3 has a hard dependency at this point on logind. There are patches produced to allow it to work with consolekit but they got denied. What I hate systemd for is the fact that Redhat is making it a dependency on more and more of their projects. So much for making small tools that do one job.

This containerization and virtualization thing is repeated without evidence. There is nothing systemd specific to running containers. Containers and VMs work perfectly well on Alpine, Gentoo and any distribution.

Namespaces and cgroups are provided by the kernel. Any init system can use them. Cgroups are mounted at /sys/fs/cgroups and while there continues to be some friction on how these are mounted and used with systemd going its own way, other init systems like openrc manage them perfectly well.

The rest of it is standard networking, mounts and autostart services started by the container managers like LXC, Docker, libvirt for VMs and these can be done by any init system.

Reply on news.ycombinator.com