Let me elaborate. Good Programmers write Portable Code. This means checking for supported features and using them if they exist, falling back to less desirable methods otherwise. So either the systemd guys are too lazy to do this (and therefore I probably don't want to run their code even if my OS is supported) or there is something linux has exclusively, that is so damn awesome that systemd would suck if it didn't have it. To my knowledge, group scheduling is not that awesome. In fact, as far as I know, freebsd's kernel and userland apis are superior to linux's in many ways, and if this is false, I would like very much to know why.
I was tempted to call gnome and systemd lazy, but thought I should learn more first.
Full disclosure: I don't run gnome (apart from gtk) and probably never will, but only as a matter of personal preference, not philosophy.
Writing portable code slows you down. With every change you have to think "hey is this available on all the other OSes too, and if not, how do I fallback?". This distracts you from your main goal, especially if that main goal can be better implemented with platform-specific APIs. I can very much understand not trying to bother and instead relying on contributors to port things to other OSes.
Is there anything wrong with lazy? Remember that people have limited time and man power.
There's a very good reason for using cgroups: to completely clean up a service's process tree even in the face of abusive behavior. A service can spawn a child process that calls setsid(). By using cgroups systemd can kill that child process too. Traditional POSIX APIs like killpg() do not allow that and give processes the ability to escape supervision.
You say FreeBSD's kernel APIs are superior. It makes me wonder why you think that. There are only two things that I think are better on FreeBSD than on Linux: kqueue is better than epoll, and the OpenBSD firewall is easier to learn than iptables. As for everything else I've yet to see hard evidence that FreeBSD beats Linux.
Answering "is this available on other OSes and how do I fall back?" is a good way to think through your algorithm and ensure that it makes sense.
Didn't know that about cgroups. Has anyone tried to kill a process tree on bsd or solaris and failed?
I don't know a lot about freebsd, most is just hearsay. I have been happier with their libc though, it seemed like it had fewer gotchas and unimplemented features.
"Good Programmers write Portable Code" seems a bit of a hasty generalization. Good programmers write portable code if portability is a goal of the project. Portability, as you define it, comes at a direct cost of maintainability, and potentially the ability to add new function in a reasonable manner.
A large portion of "good programming" is about making tradeoffs, and making the correct decision. Prioritizing portability is a decision that can be made, but that the decision is made one way or the other within the scope of one project does not mean that the decision-maker is a "good" or "bad" programmer.
Ad hominem is not a good counter argument. I haven't had as bad of an experience with PulseAudio as apparently many other people do but surely he has learned from whatever mistakes he made. Surely you weren't a rock star programmer the day you were born?
Let me elaborate. Good Programmers write Portable Code. This means checking for supported features and using them if they exist, falling back to less desirable methods otherwise. So either the systemd guys are too lazy to do this (and therefore I probably don't want to run their code even if my OS is supported) or there is something linux has exclusively, that is so damn awesome that systemd would suck if it didn't have it. To my knowledge, group scheduling is not that awesome. In fact, as far as I know, freebsd's kernel and userland apis are superior to linux's in many ways, and if this is false, I would like very much to know why.
I was tempted to call gnome and systemd lazy, but thought I should learn more first.
Full disclosure: I don't run gnome (apart from gtk) and probably never will, but only as a matter of personal preference, not philosophy.