eric
eric Some features are more important
Obviously. No comments on that. But in your free time plz let me know what exactly events are.
eric before implementing new features i try to be "free of bugs"
Good initiative. THIS is one of systemd's major downfalls.
eric absolutely not. This is one of the mistake of systemd that will not appear with 66. Cgroups is not and was never designed to track processes. This is an horrible hack make by systemd dev.
I meant to put services into slices ad sub-cgroups, for resource management. [Eg. boot.slice/boot-services-like-acpid-and-cpupower-or-thermald system.slice/cups.slice/cupsd-and-all network.slice/networkmanager-and-samba-and-all] each slice has collective options for it's services.
No, I am not pro-systemd. Just an opinion:
CGroups aren't for tracking processes, they are for grouping processes at the resource-usage level.
If a service forks off 13 processes, it will get 13 times the priority of another service which has only 1 process... This won't happen when each of the services are in their own cgroups...
And when they are already grouped, it's the easiest way to track processes...
Yes, BSDs have implemented CGrpFS just for process tracking.
Again, I am not pro-systemd-nonsense or against your opinion. Just saying that CGroups are infact fine for process tracking, and it's systemd doing things the wrong way.
libcgroup provides tools and commands for cgroup management, along with useful libraries...
You might want to see it if you plan to implement cgroups...
