4 ms·

Systemd solves real problems that have to do with virtualisation and/or containerisation. systemd predates the industry love affair with containerization and v

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.

beagle3 8y ago
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.
- amaccuish 8y ago
  > "Reducing boot time" is of great importance for short-lived containers Containers don't tend to run an init.
  - digi_owl 8y ago
    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-self-ddos/ http://www.commitstrip.com/en/2015/07/08/true-story-fixing-a...
digi_owl 8y ago
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).

beagle3 8y ago

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.

amaccuish 8y ago
> "Reducing boot time" is of great importance for short-lived containers Containers don't tend to run an init.
- digi_owl 8y ago
  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-self-ddos/ http://www.commitstrip.com/en/2015/07/08/true-story-fixing-a...

digi_owl 8y ago

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).