1 |
On 20/10/13 13:47, Daniel Campbell wrote: |
2 |
> On 10/20/2013 04:55 AM, Samuli Suominen wrote: |
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 |
>> It's not forced upon you. You received a news item that had instructions |
85 |
>> on howto assign names you want, like lan0, internet1, wireless3, and so |
86 |
>> forth. |
87 |
>> And it also described howto turn off udev from completely renaming the |
88 |
>> devices, to keep kernel assigned names. |
89 |
>> What they did was they dropped the *broken* feature called 'persistent |
90 |
>> rule_generator' which never worked correctly, and in |
91 |
>> race conditions still flipped eth0 <-> eth1 around -- that was a |
92 |
>> *security* flaw that *needed* to go. |
93 |
>> It would have gone even without providing the alternative of providing |
94 |
>> biosdevname -like new name optionality to the users. |
95 |
>> Kernel and kernel drivers are designed in a way it's not supported to |
96 |
>> flip in-place kernel names and udev tried to workaround that. |
97 |
>> |
98 |
>> https://www.kernel.org/doc/htmldocs/device-drivers/API-device-rename.html |
99 |
>> |
100 |
> Like I mentioned in a prior e-mail, the change didn't affect me when it |
101 |
> was pushed, and doesn't affect me now. I did recently have to reinstall |
102 |
> Gentoo, however (note, going from testing to stable isn't fun ;p), and |
103 |
> noticed it when I found Gentoo ships with systemd-udev instead of eudev. |
104 |
|
105 |
Yep, no plans on changing the default sys-fs/udev to anything else, no |
106 |
reason to. |
107 |
|
108 |
> I got the new naming and had to do some work to go back to what should |
109 |
> be normal behavior. My `kernel` line remains with that switch in effect, |
110 |
> but I'm not sure if eudev requires that flag to keep default behavior. |
111 |
> Had udev's defaults been left alone, I wouldn't have had to go through |
112 |
> any trouble to migrate back to eudev beyond the unmerge and emerge |
113 |
> that's expected as part of a switch. That's where the design flaw rears |
114 |
> its ugly head. I could see opposition to my view if I was trying to do |
115 |
> something that the software simply wasn't designed to do, like cook my |
116 |
> breakfast for me. Regardless, I was speaking purely from a design |
117 |
> perspective; I succeeded in solving the problem (mostly) on my own, so |
118 |
> no issues there. |
119 |
> |
120 |
> Perhaps the next time I need to install Gentoo, I'll find a way to get |
121 |
> eudev on there before even the first proper boot and avoid the problem |
122 |
> altogether. |
123 |
|
124 |
It's true that sys-fs/eudev restored the *broken* rule_generator from |
125 |
old sys-fs/udev, you can get it by USE="rule-generator". |
126 |
But it's lot saner to keep using sys-fs/udev and just write custom rules |
127 |
to rename interfaces based on MACs to like lan*, internet* |
128 |
so all in all, currently, using sys-fs/eudev doesn't make sense unless |
129 |
you are experimenting/developing for it. |
130 |
For single NIC system, as you mentioned, you can just keep using |
131 |
sys-fs/udev and use the kernel net.ifnames=0 parameter to keep |
132 |
the interface at eth0. |
133 |
Maybe there will be some differences in future that makes eudev |
134 |
worthwhile, but that remains to be seen. |
135 |
|
136 |
>>> *multi-NIC* use that wasn't as predictive and needed the fix, not |
137 |
>>> *single*. It's basically using poor design/defaults decisions to smear |
138 |
>>> existing technology dishonestly. Technical propaganda, so to speak. |
139 |
>>> |
140 |
>>> My beef with that decision is separate from my disdain for the decision |
141 |
>>> to merge it with systemd, which is only mildly related to why I dislike |
142 |
>>> systemd, but that's irrelevant. |
143 |
>>> |
144 |
>>> As for FUD, I see no reason to get personal. If you insist, we can take |
145 |
>>> a look at which Gentoo package(s) you maintain that are related to the |
146 |
>>> topic and ask ourselves if you are any less biased. |
147 |
>>> |
148 |
>> If you are hinting I'm someway favouring systemd, or udev for that |
149 |
>> matter, you couldn't be more wrong. I use OpenRC, and I maintain |
150 |
>> ConsoleKit/udev |
151 |
>> out of necessity (because someone has to). I deal with facts, I have no |
152 |
>> favouritism to any direction. |
153 |
>> In contrast, I also maintain a bunch of software that allows people to |
154 |
>> *skip* whole freedesktop.org stack (ConsoleKit, PolicyKit and so forth) |
155 |
>> like pmount, |
156 |
>> pmount-gui and such for minimal systems. |
157 |
>> |
158 |
> So you maintain them, but don't necessarily follow or agree with their |
159 |
> goals/sentiments/designs? Does that ever create problems for you when |
160 |
> trying to test systemd/udev on revbumps and whatnot? Do systemd |
161 |
> proponents wonder why you don't use what you maintain? Honestly curious; |
162 |
> I assumed that if you maintain something, you use it. Perhaps I was wrong. |
163 |
|
164 |
Well, there is also the difference of liking something and using it for |
165 |
myself at home and then using something |
166 |
at work because it's just the quickest and cleanest way of achieving |
167 |
something. |
168 |
But of course I test everything boot related before committing them to |
169 |
users. ;-) |
170 |
There is really no conflict, I'm luckily in a position where I have |
171 |
access to hundreds of systems. |
172 |
But also that, what you said, it's possible to maintain something |
173 |
without using it, that is to be determined package-by-package basis. |