Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager?

[Samuli Suominen]

On 20/10/13 09:34, Daniel Campbell wrote:
> On 10/19/2013 06:35 PM, Volker Armin Hemmann wrote:
>> Am 19.10.2013 17:02, schrieb Daniel Campbell:
>>> On 10/17/2013 11:27 PM, Mark David Dumlao wrote:
>>>> https://www.linux.com/news/featured-blogs/200-libby-clark/733595-all-about-the-linux-kernel-cgroups-redesign
>>>>
>>>> Not sure if I read that just right... but since nobody is doing cgroup
>>>> management besides systemd, in practice the cgroups implementation in
>>>> Linux wasn't very consistent. So since systemd is doing it, their work
>>>> is helping shape the kernel's cgroups api?
>>>>
>>>> Interesting...
>>>>
>>> >From my perspective it looks like systemd developers are trying to push
>>> their ideas into the kernel, almost like they intend to merge systemd
>>> *with* the kernel.
>> from what I read in the article cgroups are a mess and are cleaned up
>> anyway. The only real user of cgroups at the moment is systemd.
>> Others are welcome to make use of cgroups too. But in the current state
>> nobody blames them for not jumping in.
> No complaints here in improving something, but consider the source is
> all I'm saying.
>
>>> If systemd is the only implementation of cgroups and
>>> their developers are working on cgroup support in the kernel, it spells
>>> calamity given their history of evangelism and zealotry.
>> well, going over some old ml threads on fedora mailing lists all I could
>> find was that Poettering and Sievers DID listen and DID make changes if
>> the demand was high enough.
>>
>> Sure, I dislike systemd. Sure what happened with udev was a dick move.
>> But their 'zealotry' is a lot less developed than the zealotry of those
>> who exploded about using an 'init-thingy' in the future.
>>
> I'd say their zealotry is less loud and more persistent. Their way is
> best, UNIX (and its philosophy) is outmoded, people are thinking 30
> years behind where we are, etc etc etc. Those who have separate /usr and
> blame systemd for pushing them to use an initramfs aren't seeing the
> real problem (upstreams not putting things where they belong, FHS no
> longer *really* being worked on, generally just the filesystem being
> played with like a toy)
>
>>> I truly wish I understood why a single userland program and its
>>> developers are being given the keys to an entire subsystem of the
>>> kernel.
>> they aren't.
> Of the people who have committed to the cgroup subsystem of the kernel,
> how many are not members of the systemd, GNOME, or Red Hat projects?
> I'll let that speak for itself.
>
>>> Their changes to udev have proven to be a headache for users,
>> yes? which ones?
> Persistent NIC naming, for starters. The former maintainer's idea to
> merge with systemd (which was influenced by Mr. Poettering in the first
> place) when the two are completely separate pieces of software that do
> two completely different jobs, and various other troubles with udev >
> 175 that one can Google for and find tons of results.

I can't find anything that would be true. Can you point out some?
A lot of FUD[1] and outright lies coming from people, who, for example,
don't like systemd.

[1] http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt

I know for a fact udev-208 is a full replacement for udev-171 in terms
that both work on same kernels, same libcs, and so forth. That's why
171 is no longer in Portage, because it's completely useless from users
(and developers) point of view.

Adjusting some configs and enabling some kernel options that have been
around for a long time is just part of normal maintenance process,
that's what we have admins for.