Positions forming in the Debian init system discussion

Posted Jan 5, 2014 20:36 UTC (Sun) by khim (subscriber, #9252)
In reply to: Positions forming in the Debian init system discussion by raven667
Parent article: Positions forming in the Debian init system discussion

Actually skimming that is funny, it's an article from 2011 about Debian debating the finer points of systemd.

Indeed. That's for pointing out that piece which was written in 2011 and claims that “cgroups can eat your dog” and that “that's one hell of a badly written lump of code”.

Note that it also includes this piece: If you want kernel/cgroup.c code review, I can probably post it a bit after -rc1. Well, it's 2014 and we still have no explanations for what's so bad with it.

Note that it's not the first time code was rejected or ever ripped out because it was badly written: devfs and reiser4 come to mind. But there criticism was in the form “if you'll do this and that then you can cause kernel oops” or “if you'll do this and that then normal user can exhaust all the kernel memory and ulimits will not help” or “if you'll do this or that then kernel will lock down… hard”. That's understandable, valid criticism: if code in kernel (or proposed for inclusion in kernel) breaks said kernel in certain circumstances, then it's objectively bad and must be ripped out. One can discuss if it's fixable or not and if it's not fixable it's not included and/or ripped out.

Unfortunately cgroups criticism does not look like that. Instead it's bunch of hot words and little substance. The most objective criticism is “the maintainer in the kernel doesn't think that the current delegation model is safe or well implemented, is running screaming from it and doesn't want to support it”.

If, indeed, this is the gist of the problem then it makes it a social problem and not a technical one. The natural response to this is: we need a new maintainer. Today's code was written by someone, perhaps that person can be a maintainer? If not then why not? If author of the code does not want to support it then it certainly puts him (or her) in bad light and if noone else want to support it then it may be a valid justification for removal of the code because this essentially makes code orphan, but if the justification is not that code is objectively bad (== can break kernel) but that current maintainer does not like it then the natural question is: have other venues been tried? Who was contacted WRT maintainance of said code and why such discussions never surface when cgroups are discussed?