On Tue, 8 Aug 2017 11:11:20 +0200
Jaromil <jaro...@dyne.org> wrote:
> what I bring home after reading this is the idea of a supervisor that
> manages cgroups and LXC containers in a simple way and, to inherit
> some standardised work being done in systemd, supports its service
Be careful recommending cgroups.
I've never used them, and know little about them, but I know they were
one of the main excuses for systemd.
Look on Wikipedia's cgroups page. In the beginning, Google needed a way
to throttle and account for resources of whole groups of processes, so
Paul Menage and Rohit Seth wrote cgroups and got it into the kernel in
January 2008, at which time it was a feature invisible to all but those
engaging in Google-scale useages.
In 2013 a Red Hat guy named Tejun Heo began rewriting and
redesigning cgroups. The diagram on the cgroups Wikipedia page
sports diagrams just like systemd diagrams, and notes that
FreeDesktop.Org is involved in this kernel feature. Then there's this:
Under former Red Hat Linux kernel developer and a principal software
engineer Tejun Heo’s stewardship, cgroups underwent a massive redesign,
replacing multiple, per-controller cgroup hierarchies with a “single
kernel cgroup hierarchy… [that] allow[s] controllers to be
individually enabled for each cgroup” and is the “private property of
systemd.” These changes, especially when combined with functionality
in systemd, increased the consistency and manageability of cgroups.
"Especially when combined with the functionality in systemd."
Did Heo et-al make cgroups harder to use without systemd? I don't know.
But I look at the timing, the complete rewrite throwing away the old
code, the involvement of Redhat and FreeDesktop.Org, and I can't help
thinking I've seen this movie before.
At this point we might be doing ourselves a disservice by thinking an
interaction with cgroups is an advantage of a given init.
July 2017 featured book: Quit Joblessness: Start Your Own Business
Dng mailing list