1 |
On 20/10/13 12:24, Daniel Campbell wrote: |
2 |
> On 10/20/2013 02:37 AM, Samuli Suominen wrote: |
3 |
>> On 20/10/13 09:34, Daniel Campbell wrote: |
4 |
>>> On 10/19/2013 06:35 PM, Volker Armin Hemmann wrote: |
5 |
>>>> Am 19.10.2013 17:02, schrieb Daniel Campbell: |
6 |
>>>>> On 10/17/2013 11:27 PM, Mark David Dumlao wrote: |
7 |
>>>>>> https://www.linux.com/news/featured-blogs/200-libby-clark/733595-all-about-the-linux-kernel-cgroups-redesign |
8 |
>>>>>> |
9 |
>>>>>> Not sure if I read that just right... but since nobody is doing cgroup |
10 |
>>>>>> management besides systemd, in practice the cgroups implementation in |
11 |
>>>>>> Linux wasn't very consistent. So since systemd is doing it, their work |
12 |
>>>>>> is helping shape the kernel's cgroups api? |
13 |
>>>>>> |
14 |
>>>>>> Interesting... |
15 |
>>>>>> |
16 |
>>>>> >From my perspective it looks like systemd developers are trying to push |
17 |
>>>>> their ideas into the kernel, almost like they intend to merge systemd |
18 |
>>>>> *with* the kernel. |
19 |
>>>> from what I read in the article cgroups are a mess and are cleaned up |
20 |
>>>> anyway. The only real user of cgroups at the moment is systemd. |
21 |
>>>> Others are welcome to make use of cgroups too. But in the current state |
22 |
>>>> nobody blames them for not jumping in. |
23 |
>>> No complaints here in improving something, but consider the source is |
24 |
>>> all I'm saying. |
25 |
>>> |
26 |
>>>>> If systemd is the only implementation of cgroups and |
27 |
>>>>> their developers are working on cgroup support in the kernel, it spells |
28 |
>>>>> calamity given their history of evangelism and zealotry. |
29 |
>>>> well, going over some old ml threads on fedora mailing lists all I could |
30 |
>>>> find was that Poettering and Sievers DID listen and DID make changes if |
31 |
>>>> the demand was high enough. |
32 |
>>>> |
33 |
>>>> Sure, I dislike systemd. Sure what happened with udev was a dick move. |
34 |
>>>> But their 'zealotry' is a lot less developed than the zealotry of those |
35 |
>>>> who exploded about using an 'init-thingy' in the future. |
36 |
>>>> |
37 |
>>> I'd say their zealotry is less loud and more persistent. Their way is |
38 |
>>> best, UNIX (and its philosophy) is outmoded, people are thinking 30 |
39 |
>>> years behind where we are, etc etc etc. Those who have separate /usr and |
40 |
>>> blame systemd for pushing them to use an initramfs aren't seeing the |
41 |
>>> real problem (upstreams not putting things where they belong, FHS no |
42 |
>>> longer *really* being worked on, generally just the filesystem being |
43 |
>>> played with like a toy) |
44 |
>>> |
45 |
>>>>> I truly wish I understood why a single userland program and its |
46 |
>>>>> developers are being given the keys to an entire subsystem of the |
47 |
>>>>> kernel. |
48 |
>>>> they aren't. |
49 |
>>> Of the people who have committed to the cgroup subsystem of the kernel, |
50 |
>>> how many are not members of the systemd, GNOME, or Red Hat projects? |
51 |
>>> I'll let that speak for itself. |
52 |
>>> |
53 |
>>>>> Their changes to udev have proven to be a headache for users, |
54 |
>>>> yes? which ones? |
55 |
>>> Persistent NIC naming, for starters. The former maintainer's idea to |
56 |
>>> merge with systemd (which was influenced by Mr. Poettering in the first |
57 |
>>> place) when the two are completely separate pieces of software that do |
58 |
>>> two completely different jobs, and various other troubles with udev > |
59 |
>>> 175 that one can Google for and find tons of results. |
60 |
>> I can't find anything that would be true. Can you point out some? |
61 |
>> A lot of FUD[1] and outright lies coming from people, who, for example, |
62 |
>> don't like systemd. |
63 |
>> |
64 |
>> [1] http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt |
65 |
>> |
66 |
>> I know for a fact udev-208 is a full replacement for udev-171 in terms |
67 |
>> that both work on same kernels, same libcs, and so forth. That's why |
68 |
>> 171 is no longer in Portage, because it's completely useless from users |
69 |
>> (and developers) point of view. |
70 |
>> |
71 |
>> Adjusting some configs and enabling some kernel options that have been |
72 |
>> around for a long time is just part of normal maintenance process, |
73 |
>> that's what we have admins for. |
74 |
>> |
75 |
> Do you know the design consequences of opt-in versus opt-out? I'll keep |
76 |
> this short: When evolving a codebase, new behavior for core parts of the |
77 |
> system should not be pushed or forced on users. If you must, keep the |
78 |
> old behavior around as a default and allow users to try the new thing by |
79 |
> explicitly opting in. The new naming in whichever udev started the mess |
80 |
> did it the exact opposite (and wrong) way. |
81 |
|
82 |
|
83 |
It's not forced upon you. You received a news item that had instructions |
84 |
on howto assign names you want, like lan0, internet1, wireless3, and so |
85 |
forth. |
86 |
And it also described howto turn off udev from completely renaming the |
87 |
devices, to keep kernel assigned names. |
88 |
What they did was they dropped the *broken* feature called 'persistent |
89 |
rule_generator' which never worked correctly, and in |
90 |
race conditions still flipped eth0 <-> eth1 around -- that was a |
91 |
*security* flaw that *needed* to go. |
92 |
It would have gone even without providing the alternative of providing |
93 |
biosdevname -like new name optionality to the users. |
94 |
Kernel and kernel drivers are designed in a way it's not supported to |
95 |
flip in-place kernel names and udev tried to workaround that. |
96 |
|
97 |
https://www.kernel.org/doc/htmldocs/device-drivers/API-device-rename.html |
98 |
|
99 |
> |
100 |
> While editing and updating configs is a normal part of system |
101 |
> maintenance, turning a system on its head and screwing it out of network |
102 |
> accessibility until the new default is reversed (by means of a `kernel` |
103 |
> line in GRUB, requiring a reboot) is straight-up wrong design. |
104 |
|
105 |
Again, that's why you received a warning beforehand in form of portage |
106 |
news item, portage news postinst message, |
107 |
and a updated gentoo handbook plus gentoo wiki. There was no such |
108 |
breakage as you described, unless you were |
109 |
stupid enough (sorry, no offense intended) to upgrade something related |
110 |
in the boot process without reading the relavent |
111 |
information. |
112 |
|
113 |
> Conversely, keeping old behavior, even for systems that *do* have |
114 |
> multiple NICs, will at least be functional (for one of the NICs, anyway) |
115 |
> until they set the option to get their expected behavior sorted out. |
116 |
> Multi-NIC systems are less common than single-NIC systems, and that |
117 |
> alone should've been enough motivation to leave old behavior as default, |
118 |
> with the new behavior a simple config switch away. |
119 |
> |
120 |
> The way the new behavior was introduced may have led users of single-NIC |
121 |
> systems to believe that the old way was broken, when as demonstrated |
122 |
> through past use, works *just fine* for single-NIC machines. It was |
123 |
|
124 |
And when those single network adapter users enable one of many virtual |
125 |
drivers that create eth*, or attach removable |
126 |
network device that creates eth* the bug would have been brought up. |
127 |
So no, it was never safe to use in-place in-kernel renaming even on |
128 |
single NIC systems. |
129 |
|
130 |
> *multi-NIC* use that wasn't as predictive and needed the fix, not |
131 |
> *single*. It's basically using poor design/defaults decisions to smear |
132 |
> existing technology dishonestly. Technical propaganda, so to speak. |
133 |
> |
134 |
> My beef with that decision is separate from my disdain for the decision |
135 |
> to merge it with systemd, which is only mildly related to why I dislike |
136 |
> systemd, but that's irrelevant. |
137 |
> |
138 |
> As for FUD, I see no reason to get personal. If you insist, we can take |
139 |
> a look at which Gentoo package(s) you maintain that are related to the |
140 |
> topic and ask ourselves if you are any less biased. |
141 |
> |
142 |
|
143 |
If you are hinting I'm someway favouring systemd, or udev for that |
144 |
matter, you couldn't be more wrong. I use OpenRC, and I maintain |
145 |
ConsoleKit/udev |
146 |
out of necessity (because someone has to). I deal with facts, I have no |
147 |
favouritism to any direction. |
148 |
In contrast, I also maintain a bunch of software that allows people to |
149 |
*skip* whole freedesktop.org stack (ConsoleKit, PolicyKit and so forth) |
150 |
like pmount, |
151 |
pmount-gui and such for minimal systems. |
152 |
|
153 |
> --- |
154 |
> |
155 |
> Getting back to the original topic, cgroups sound like a pretty neat |
156 |
> idea that other init systems could benefit from. If the systemd guys are |
157 |
> willing to work on that subsystem for themselves, are they also |
158 |
> interested in seeing what other init systems would want from cgroups? |
159 |
> Certainly there's more room for development and/or standardization on an |
160 |
> API instead of a single project having all the influence. I think their |
161 |
> presence and activity with cgroups could be beneficial if policed by |
162 |
> another init system project that's not trying to infect every Linux distro. |
163 |
> |
164 |
> tldr version: opt-out design is bad, the accusation of FUD is moot since |
165 |
> you maintain udev for Gentoo, and I think work on cgroups (by systemd |
166 |
> people) could be good if they're not the only people working on it and |
167 |
> calling the shots. |
168 |
> |
169 |
|
170 |
There is nothing stopping from sane patches entering the Linux tree that |
171 |
would go in favour of OpenRC cgroups support, it's just that there are |
172 |
almost no people working on it. |
173 |
Like I said, code matters, complaining doesn't. |