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 ;-) |