Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

If it's not technically terrible, it's not technically terrible anymore.

All the initial "ooh and aah" factor of SystemD came from using the kernel's cgroups mechanism, which was a dumpster fire by itself--something dropped by google in the kernel for easier maintenance with the understanding that no one should be stupid enough to use it for something important...enter SystemD.

Apparently cgroups is in better nick these days (as is SystemD), but until the likes of Al Viro come around and give it a clean bill of health, I think I'll pass.



So no docker for you either?


cgroups are essential to properly limit daemons on baremetal servers without the overhead of containers (so more bang for bucks).

For example, you can make sure some poorly written python daemon will never use more than 50pct of the cpu or over 1 Gb of ram - and systemd services will nicely restart the daemon if\when that happens.

By not using systemd you are depriving yourself of essential tools in modern sysadmin (timers alone are worth switching to systems compared to cron anachronistic hacks)


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: