You can use cgroups without systemd.

Them being released at similar times does not mean systemd implemented them, they exist completely separately to systemd.

Literally:

   mkdir /sys/fs/cgroup/memory/<groupname>;
   echo 100000000 > /sys/fs/cgroup/memory/<groupname>/memory.limit_in_bytes

is all you need for cgroups.

The grandparents comment was targeted at cgroups in general. You can’t use cgroups without cgroups. To add on that: IMHO, both systemd and docker made cgroups much more accessible to joe sysadmin and while they’re not a bulletproof security feature, having them (and capabilities, another kernel feature exposed by systemd) in wider use is generally a good thing.

> cgroups without cgroups.

I've been charring my brain to understand what you mean by this.

You don't need to have cgroups for all applications in order to use them.

And they don't need to be implemented by systemd specifically for them to be in use by other init's or tools.

SystemD existing (and being pushed so heavily) stymies the rise of such init systems.

The post I was referring to criticizes cgroups in general, regardless of how they are managed or used.

Sure, then you need to write scripts to monitor your daemons and their dependencies, and you may end up writing something likely worse than systemd that just suffers from the 'NIH' syndrome.

Adjusting to systemd took me a while, but I believe it was worth the effort, and I also believe most people who dislike systemd are just set in their old ways

Other way around there were daemons that previously managed cgroups and system NIHed a new implementation.