1 |
On Fri, Apr 26, 2013 at 1:38 PM, Alan Mackenzie <acm@×××.de> wrote: |
2 |
> 'afternoon, Canek! |
3 |
|
4 |
Hi Alan. |
5 |
|
6 |
> On Fri, Apr 26, 2013 at 12:02:38PM -0500, Canek Peláez Valdés wrote: |
7 |
>> On Fri, Apr 26, 2013 at 11:29 AM, Alan Mackenzie <acm@×××.de> wrote: |
8 |
>> [snip] |
9 |
>> > Somebody reported that pulseaudio is an absolute requirement for Gnome |
10 |
>> >>=3.8. That may not be 100% of users, but the "forced" is certainly |
11 |
>> > there. |
12 |
> |
13 |
>> No one is forcing nothing on anyone, since nobody is forcing no one to |
14 |
>> use GNOME, Gentoo, or Linux for that matter. |
15 |
> |
16 |
> That's a strawman argument. Anytime a free software project drops |
17 |
> support for something, it forces its users to make choices. Yes, force. |
18 |
|
19 |
I don't think that's true, since we are not paying anyone to do the |
20 |
work (well, at least for sure I'm not paying anyone to do anything). |
21 |
They (the developers) don't own us *anything*. |
22 |
|
23 |
>> The developers of any project can always decide the dependencies of a |
24 |
>> project. If you are not a developer, you simply have no vote in the |
25 |
>> matter, although you certainly always have voice... that they can |
26 |
>> choose to ignore. |
27 |
> |
28 |
> Free software developers, having got people to commit to using their |
29 |
> software, have responsibilities, albeit moral ones. |
30 |
|
31 |
If you want to get into morals, this will become a religious argument, |
32 |
and sorry but I'm not interested in that. |
33 |
|
34 |
> The prime one is to support their users. |
35 |
|
36 |
No; the prime one is to do their jobs. Most of them are employed by |
37 |
several of the available Open Source supporting companies; their |
38 |
responsibilities is to do the job they are being paid to do. If they |
39 |
are hobbyist, then their prime "responsibility" is to do whatever the |
40 |
hell they want to (and gets accepted in a community project). |
41 |
|
42 |
> You'll surely have noticed that what gets up the |
43 |
> noses of people on this mailing list most is when support for reasonable |
44 |
> configurations gets dropped. Witness all the recent trouble over eth0, |
45 |
> for example. |
46 |
|
47 |
What problem? I use NetworkManager in desktop and laptop; there is no |
48 |
problem there. I read the instructions in my media center and servers: |
49 |
no problems there. I don't particularly like the new funny names, but |
50 |
I don't write the code, and the fruits from it I get for free, so I |
51 |
don't complain about it. |
52 |
|
53 |
>> > There's a difference between a "default choice" and an absolute |
54 |
>> > requirement. |
55 |
> |
56 |
>> Yeah; and the decision is for the developers to make. |
57 |
> |
58 |
>> >> Basically there's a bunch of vague criticisms of unnamed systems where |
59 |
>> >> "they" force stuff on "all users" for "no good reason". Nevermind that |
60 |
>> >> we can actually state what the reasons are. Fingers in the ears. |
61 |
>> >> neener neener. |
62 |
> |
63 |
>> > Please feel free to state those reasons, which as far as I can see, |
64 |
>> > nobody has done yet in this thread; "they" being the gnome team, and the |
65 |
>> > reasons being for the forcing, not for a non-existent "default choice". |
66 |
> |
67 |
>> If GNOME has to support PA and non-pa systems, they need to code, |
68 |
>> test, support and bug-fix 2 different sets of of systems. If they need |
69 |
>> to support ConsoleKit and logind, the number grows to 4 (PA/ck, |
70 |
>> PA/logind, non-PA/ck, non-PA/logind). With 3 different optional |
71 |
>> requirements, it's 8 sets of systems. With 4, is 16. With n, it's 2^n. |
72 |
> |
73 |
>> That's exponential growth, which in CS is always no-no. |
74 |
> |
75 |
> WADR, that is simply false. With features which interact chaotically |
76 |
> with eachother, yes, you have exponential growth. With distinct, |
77 |
> self-contained features, each one is merely an incremental test effort. |
78 |
> ALSA and pulseaudio are self-contained, and are also well tested in their |
79 |
> own right. Only integration needs testing. |
80 |
|
81 |
OK, I exaggerated a bit; but who is going to do the integration |
82 |
testing? You? Because the GNOME developers have no interest in doing |
83 |
that, and I support their decision. |
84 |
|
85 |
> If you were serious about this exponential growth, how on earth could, |
86 |
> e.g., the Linux kernel or Emacs, both with thousands of options[*], |
87 |
> possibly get tested anywhere near acceptably? |
88 |
> |
89 |
> [*] 12,666 in Linux 3.7.10, 7,510 in vanilla Emacs 24.3. |
90 |
|
91 |
Because they have enough integration testers. They have enough |
92 |
interested users to do the required testing; the kernel and Emacs is |
93 |
oriented towards technical apt users. The stated goal of the GNOME |
94 |
project is that even my grandmother could use it. |
95 |
|
96 |
>> Who is going to code, test, support and bug fix all those possible |
97 |
>> configurations? You? |
98 |
> |
99 |
> No. The gnome developers. |
100 |
|
101 |
Why? Because you say so? Do you pay them? |
102 |
|
103 |
> I test and support all reasonable (and many |
104 |
> unreasonable) combinations on my own free software project. |
105 |
|
106 |
Good for you: that's your call. It's not your call to say what the |
107 |
GNOME developers should use. |
108 |
|
109 |
>> The GNOME developers simply cannot support all different sets of |
110 |
>> possible configurations, and PA covers the sound needs of *ALL* users |
111 |
>> (doesn't matter if you like it or not), even the simple cases. |
112 |
> |
113 |
> What about the needs of those high-end audio users, for example, who need |
114 |
> jack? |
115 |
|
116 |
There are several success stories about mixing PA with Jack; you can |
117 |
Google them. I don't see the problem. |
118 |
|
119 |
> What about those, like me, with audio problems, where the need exists to |
120 |
> strip a system down so as to isolate those problems? |
121 |
|
122 |
As I said below: if PA has problems, they need to be fixed. Did you |
123 |
report the bugs? |
124 |
|
125 |
>> If PA has bugs in some configuration, those bugs need to be fixed; the |
126 |
>> solution (in the GNOME developers view) is not to "remove PA", since |
127 |
>> the goal of the project is to cover *ALL* use cases. |
128 |
> |
129 |
> pulseaudio is a server component - gnome is an application. They are at |
130 |
> different levels of the system hierarchy, just as a mail transport agent |
131 |
> and mail user agent are. The maintainers of mutt don't force the use of, |
132 |
> say, postfix. By long tradition on *nix, sysadmins configure their own |
133 |
> systems, selecting those components which best fit their needs. gnome's |
134 |
> decision to mandate pulseaudio interferes with this tradition. IMAO, |
135 |
> this is a Bad Thing. |
136 |
|
137 |
GNOME is a desktop environment, and it wants (from some years now) a |
138 |
vertical integration from kernel to the last userspace application. I |
139 |
root for that. |
140 |
|
141 |
And I have been using Unix since 1996, and I don't care about what |
142 |
*nix "long traditions" are. I want a Linux system that works from my |
143 |
cellphone to my big iron server, and everything in between. I don't |
144 |
even care about *BSD; I don't wish them any ill, but I don't care |
145 |
about them. |
146 |
|
147 |
If you don't agree with that, that's fine; but if a big enough set of |
148 |
developers thinks similarly, several projects will move in that |
149 |
direction. It's already happening. |
150 |
|
151 |
>> But hey, the source is there; feel free to patch whatever needs to be |
152 |
>> patched in GNOME (and probably GStreamer) so it doesn't require PA. |
153 |
>> Just be certain that those patches will be rejected by upstream, for |
154 |
>> the reasons stated above. |
155 |
> |
156 |
> Making minor changes to free software is impracticable on a casual basis. |
157 |
> Only forking a project can do this. You know this full well. |
158 |
|
159 |
Well, fork away then. It's in your freedoms when it comes to free |
160 |
software. Look at the success stories from MATE, Cinnamon, the Trinity |
161 |
Desktop Environment and eudev. |
162 |
|
163 |
>> And by the way, this is also true for Gentoo: it cannot support all |
164 |
>> different sets of possible configurations, no matter how hard they/we |
165 |
>> try. |
166 |
> |
167 |
> It come pretty close. :-) |
168 |
|
169 |
http://article.gmane.org/gmane.linux.gentoo.devel/85223 |
170 |
|
171 |
"I'm not sure about the future of the core of OpenRC: |
172 |
|
173 |
Upstart & systemd have some clear architectural benefits, despite their |
174 |
implementation shortcomings (either upstream or per-distro). |
175 |
The /usr merge is inevitable, as is the integration of other components |
176 |
into the init system (udev, dbus, ...). What has become dis-integrated instead |
177 |
is the configuration: lots of hardware ships specific udev rules with few |
178 |
problems." |
179 |
|
180 |
That's a Gentoo developer talking. Many of them think like that; many |
181 |
of them oppose them. But the truth is, Linux distributions are moving |
182 |
to a vertical, tightly integrated OS. There will always be niche |
183 |
distros for the people that don't like this (and hey, that's the |
184 |
beauty of using Free Software), but the big distros are going that |
185 |
way. It's possible that Gentoo will follow (as did Arch, as |
186 |
Debian-based Tanglu and Gentoo-based Sabayon are doing). |
187 |
|
188 |
Greg Korah-Hartman will integrate an incarnation of dbus (or something |
189 |
really similar) into the kernel: |
190 |
|
191 |
https://plus.google.com/u/0/111049168280159033135/posts/BDgg5DKVjkX |
192 |
|
193 |
and then the only required dependency for systemd will be Linux. |
194 |
|
195 |
Man, that will be a nice day. |
196 |
|
197 |
Regards. |
198 |
-- |
199 |
Canek Peláez Valdés |
200 |
Posgrado en Ciencia e Ingeniería de la Computación |
201 |
Universidad Nacional Autónoma de México |