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

[Daniel Campbell]

On 10/23/2013 05:51 PM, Steven J. Long wrote:
> Daniel Campbell wrote:
>> Do you know the design consequences of opt-in versus opt-out? I'll keep
>> this short: When evolving a codebase, new behavior for core parts of the
>> system should not be pushed or forced on users. If you must, keep the
>> old behavior around as a default and allow users to try the new thing by
>> explicitly opting in. The new naming in whichever udev started the mess
>> did it the exact opposite (and wrong) way.
>
> Good luck with that argument; you have to bear in mind Gentoo devs are
> mostly fresh out of Uni (or still in it.) They're not very experienced iow,
> as a rule, apart from in Gentoo ebuilds and making the tree work together,
> which is all we ask of them. Oh and usually Java from Uni; they typically
> have a snobbery about shell as well (and doesn't it show) which is quite
> amusing when one considers their implementation language.
>
> (No this is not to the topic per se: it's a wider point that I had to
> repeat to someone recently, who apparently found the insight very useful.
> So I put it out there for other users, or those to come.
>
> I have zero interest in arguing the toss with anyone: you're welcome to
> your opinion, that's mine. You ain't gonna change it, so don't bother
> trying. Feel free to rant amongst yourselves. ;)
I know you said you won't argue about it, and that's fine. I'm not sure
how fair it is to broadly denigrate the Gentoo devs, though. There are
so many, with varying levels of experience, specialty, and education,
that it would be difficult to put them into a neat label box. Among all
the distributions out there that run Linux as the kernel, I think Gentoo
is probably the most compatible in terms of choices. They do a good job
of making sure OpenRC, sysv, systemd, runit, and others are possible on
Gentoo. Perhaps you know more about some of the devs than I, though. I'm
just a user who aspires to become an official developer to learn more
about it.

>
> The point is that this is actually why Gentoo is a very good place for a
> "developer" to cut hir teeth: they learn from the other users when they
> install, and usually come up through the forums, where if you've ever
> been to OTW, the difference between a personal attack and criticism of
> someone's work is blatantly obvious. Further they have to run any major
> design ideas past that same experienced user-base, who had the rough
> edges knocked off ages ago, and simply want it to work for everyone.
>
> They don't always see it like that, ofc, but I for one remember thinking
> much dumber things. [1]
Well, the udev behavior I was discussing isn't really the fault of
Gentoo devs. It was just the default for udev, as shipped by upstream.
My guess is the devs decided to opt for the default so those who planned
on using the new behavior (and/or GNOME 3.8) wouldn't have to do
additional configuration... at the expense of everyone else having to if
they wanted to retain the net.ifnames behavior. They were screwed no
matter what, really. Had the systemd/udev guys not created the new
behavior, Gentoo's devs wouldn't have had to make a decision that they
knew wouldn't please everyone.

>
>> The way the new behavior was introduced may have led users of single-NIC
>> systems to believe that the old way was broken, when as demonstrated
>> through past use, works *just fine* for single-NIC machines. It was
>> *multi-NIC* use that wasn't as predictive and needed the fix, not
>> *single*. It's basically using poor design/defaults decisions to smear
>> existing technology dishonestly. Technical propaganda, so to speak.
>
> Even more amusing when you consider that the original race that was so
> terrible it justified breaking the machines of those it was supposedly
> in aid of, as well as those of people who had zero use for it, yet were
> apparently the target market, was in fact implemented by the same set
> of "early userspace experts" who put themselves forward as such 5 years
> previously.
>
> I personally have no words to describe such a situation beyond "idiocy".
Pretty much agreed. Self-proclaiming as an expert has such an air of
egotism it's hard to take it seriously.

>
>> Getting back to the original topic, cgroups sound like a pretty neat
>> idea that other init systems could benefit from. If the systemd guys are
>> willing to work on that subsystem for themselves, are they also
>> interested in seeing what other init systems would want from cgroups?
>
> This is actually what I posted about: I know qnikst already implemented
> a large chunk of functionality in openrc and was concerned about the
> "proposed changes" mainly because as usual it was a grand statement of
> intent, with little in the way of coherent content. But we're spitting in
> the wind: you can't expect amateurs who've backed themselves into a
> corner, full of ego-attachment to their "work", to ever admit it's crap,
> or that they fscked-up. Certainly not based on the record of this team.
Agreed. To this day, "PulseAudio" is still synonymous with "my sound
doesn't work" for some people, even though Mr. Poettering no longer
works on it (to my knowledge).

I actually think some of the ideas in both PA and systemd have merit,
but the implementations are so far off base or so ambitious that it
becomes an all-or-nothing decision instead of the usual "micromanaging"
or "piecemeal" package choosing that most of us (I assume) are
accustomed to. So instead of making one decision at a time, choosing a
package of Poettering's means you're committing to more than one
decision. His aren't the only packages like it; one could run the same
argument for other projects that try to do a bit too much for one package.
>
>> Certainly there's more room for development and/or standardization on an
>> API instead of a single project having all the influence. I think their
>> presence and activity with cgroups could be beneficial if policed by
>> another init system project that's not trying to infect every Linux
>> distro.
>
> Yes one would think before embarking on such a venture they'd at least
> take a look at other things that also run on Linux in the same domain, such
> as s6, runit or openrc. But no, systemd is allowed to take them over, but
> no consideration can be given to those use-cases, because "this is only
> about cgroups." It's orthogonal, maan.
>
> You're not alone; careful though as you just get labelled a "hater" even
> when you've tried your damndest to collaborate with the "other side" (who
> are the only ones even interested in "sides") only to come up against
> groupthink, double-speak, and monkeys flinging poo.
>
> "You're not with us so you *must* be against us!"
>
> "No. We just do not care."
>
> "Ah you is haterz."
>
> "Bye then; enjoy the kool-aid."
>
> [1] http://www.iusedtobelieve.com/
>
To be fair, I lack the experience and knowledge in the problem domain to
collaborate with whoever plans on hacking cgroups. I'm just concerned
that other init systems may become locked out of cgroup functionality
until/unless they use an API that requires them to adopt a software
architecture/design similar to systemd's. It's dangerous, to me, to let
ambitious people work on core parts of a large project. They can't be
trusted to remain neutral to all userland software that may depend on it.

Nice link, btw. :)