Gentoo Archives: gentoo-user

From: "Steven J. Long" <slong@××××××××××××××××××.uk>
To: gentoo-user@l.g.o
Subject: [gentoo-user] Re: systemd and kernel developers cooperating to turn it into a global cgroup manager?
Date: Wed, 23 Oct 2013 22:44:27
Message-Id: 20131023225137.GB7442@rathaus.eclipse.co.uk
In Reply to: Re: [gentoo-user] systemd and kernel developers cooperating to turn it into a global cgroup manager? by Daniel Campbell
1 Daniel Campbell wrote:
2 > Do you know the design consequences of opt-in versus opt-out? I'll keep
3 > this short: When evolving a codebase, new behavior for core parts of the
4 > system should not be pushed or forced on users. If you must, keep the
5 > old behavior around as a default and allow users to try the new thing by
6 > explicitly opting in. The new naming in whichever udev started the mess
7 > did it the exact opposite (and wrong) way.
8
9 Good luck with that argument; you have to bear in mind Gentoo devs are
10 mostly fresh out of Uni (or still in it.) They're not very experienced iow,
11 as a rule, apart from in Gentoo ebuilds and making the tree work together,
12 which is all we ask of them. Oh and usually Java from Uni; they typically
13 have a snobbery about shell as well (and doesn't it show) which is quite
14 amusing when one considers their implementation language.
15
16 (No this is not to the topic per se: it's a wider point that I had to
17 repeat to someone recently, who apparently found the insight very useful.
18 So I put it out there for other users, or those to come.
19
20 I have zero interest in arguing the toss with anyone: you're welcome to
21 your opinion, that's mine. You ain't gonna change it, so don't bother
22 trying. Feel free to rant amongst yourselves. ;)
23
24 The point is that this is actually why Gentoo is a very good place for a
25 "developer" to cut hir teeth: they learn from the other users when they
26 install, and usually come up through the forums, where if you've ever
27 been to OTW, the difference between a personal attack and criticism of
28 someone's work is blatantly obvious. Further they have to run any major
29 design ideas past that same experienced user-base, who had the rough
30 edges knocked off ages ago, and simply want it to work for everyone.
31
32 They don't always see it like that, ofc, but I for one remember thinking
33 much dumber things. [1]
34
35 > The way the new behavior was introduced may have led users of single-NIC
36 > systems to believe that the old way was broken, when as demonstrated
37 > through past use, works *just fine* for single-NIC machines. It was
38 > *multi-NIC* use that wasn't as predictive and needed the fix, not
39 > *single*. It's basically using poor design/defaults decisions to smear
40 > existing technology dishonestly. Technical propaganda, so to speak.
41
42 Even more amusing when you consider that the original race that was so
43 terrible it justified breaking the machines of those it was supposedly
44 in aid of, as well as those of people who had zero use for it, yet were
45 apparently the target market, was in fact implemented by the same set
46 of "early userspace experts" who put themselves forward as such 5 years
47 previously.
48
49 I personally have no words to describe such a situation beyond "idiocy".
50
51 > Getting back to the original topic, cgroups sound like a pretty neat
52 > idea that other init systems could benefit from. If the systemd guys are
53 > willing to work on that subsystem for themselves, are they also
54 > interested in seeing what other init systems would want from cgroups?
55
56 This is actually what I posted about: I know qnikst already implemented
57 a large chunk of functionality in openrc and was concerned about the
58 "proposed changes" mainly because as usual it was a grand statement of
59 intent, with little in the way of coherent content. But we're spitting in
60 the wind: you can't expect amateurs who've backed themselves into a
61 corner, full of ego-attachment to their "work", to ever admit it's crap,
62 or that they fscked-up. Certainly not based on the record of this team.
63
64 > Certainly there's more room for development and/or standardization on an
65 > API instead of a single project having all the influence. I think their
66 > presence and activity with cgroups could be beneficial if policed by
67 > another init system project that's not trying to infect every Linux
68 > distro.
69
70 Yes one would think before embarking on such a venture they'd at least
71 take a look at other things that also run on Linux in the same domain, such
72 as s6, runit or openrc. But no, systemd is allowed to take them over, but
73 no consideration can be given to those use-cases, because "this is only
74 about cgroups." It's orthogonal, maan.
75
76 You're not alone; careful though as you just get labelled a "hater" even
77 when you've tried your damndest to collaborate with the "other side" (who
78 are the only ones even interested in "sides") only to come up against
79 groupthink, double-speak, and monkeys flinging poo.
80
81 "You're not with us so you *must* be against us!"
82
83 "No. We just do not care."
84
85 "Ah you is haterz."
86
87 "Bye then; enjoy the kool-aid."
88
89 [1] http://www.iusedtobelieve.com/
90 --
91 #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Replies