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