1 |
On Fri, Apr 26, 2013 at 3:34 PM, Alan Mackenzie <acm@×××.de> wrote: |
2 |
> Hi, Canek. |
3 |
> |
4 |
> On Fri, Apr 26, 2013 at 02:09:46PM -0500, Canek Peláez Valdés wrote: |
5 |
>> On Fri, Apr 26, 2013 at 1:38 PM, Alan Mackenzie <acm@×××.de> wrote: |
6 |
> |
7 |
>> Hi Alan. |
8 |
> |
9 |
>> > On Fri, Apr 26, 2013 at 12:02:38PM -0500, Canek Peláez Valdés wrote: |
10 |
>> >> On Fri, Apr 26, 2013 at 11:29 AM, Alan Mackenzie <acm@×××.de> wrote: |
11 |
>> >> [snip] |
12 |
> |
13 |
>> > Anytime a free software project drops support for something, it |
14 |
>> > forces its users to make choices. Yes, force. |
15 |
> |
16 |
>> I don't think that's true, since we are not paying anyone to do the |
17 |
>> work (well, at least for sure I'm not paying anyone to do anything). |
18 |
>> They (the developers) don't owe us *anything*. |
19 |
> |
20 |
> In a sense, no. But in another very important sense, yes. Without that |
21 |
> sense of duty, of obligation, on the part of developers over the last few |
22 |
> decades, GNU, Linux, X, BSD, ... would scarcely rate as more than toys. |
23 |
|
24 |
That's your subjective analysis. I would say the reason is because the |
25 |
developers took the technically correct decisions. |
26 |
|
27 |
> [ ..... ] |
28 |
> |
29 |
>> If you want to get into morals, this will become a religious argument, |
30 |
>> and sorry but I'm not interested in that. |
31 |
> |
32 |
> Fair enough! |
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 |
> Again, fair enough. But that's just as "religious" a viewpoint as my |
43 |
> own. |
44 |
|
45 |
O yeah? Ask the ones that need to pay the rent. |
46 |
|
47 |
>> > You'll surely have noticed that what gets up the |
48 |
>> > noses of people on this mailing list most is when support for reasonable |
49 |
>> > configurations gets dropped. Witness all the recent trouble over eth0, |
50 |
>> > for example. |
51 |
> |
52 |
>> What problem? I use NetworkManager in desktop and laptop; there is no |
53 |
>> problem there. I read the instructions in my media center and servers: |
54 |
>> no problems there. I don't particularly like the new funny names, but |
55 |
>> I don't write the code, and the fruits from it I get for free, so I |
56 |
>> don't complain about it. |
57 |
> |
58 |
> Some Gentooers had problems over this change. I didn't have "problems" |
59 |
> as such, but the time spent not having these problems could, I feel, have |
60 |
> been better spent. |
61 |
> |
62 |
>> > If you were serious about this exponential growth, how on earth could, |
63 |
>> > e.g., the Linux kernel or Emacs, both with thousands of options[*], |
64 |
>> > possibly get tested anywhere near acceptably? |
65 |
> |
66 |
>> > [*] 12,666 in Linux 3.7.10, 7,510 in vanilla Emacs 24.3. |
67 |
> |
68 |
>> Because they have enough integration testers. They have enough |
69 |
>> interested users to do the required testing; the kernel and Emacs is |
70 |
>> oriented towards technical apt users. The stated goal of the GNOME |
71 |
>> project is that even my grandmother could use it. |
72 |
> |
73 |
> I understand what you're saying. In the limit, this tight integration |
74 |
> will lead to a system barely capable of being customised. It will be as |
75 |
> inflexible as MS Windows always has been. Will your GM want to use such |
76 |
> a system? |
77 |
|
78 |
I sure hope so. I don't see"inflexibility". I see "set a stack where |
79 |
the best option is chosen by the ones writing the code". |
80 |
|
81 |
> [ .... ] |
82 |
> |
83 |
>> > What about the needs of those high-end audio users, for example, who need |
84 |
>> > jack? |
85 |
> |
86 |
>> There are several success stories about mixing PA with Jack; you can |
87 |
>> Google them. I don't see the problem. |
88 |
> |
89 |
> I'm not an expert on jack, but I gather it's high-endedness implies very |
90 |
> low latency, for example. Feeding a signal through pulseaudio as well |
91 |
> would negate the whole purpose of jack. Maybe. |
92 |
|
93 |
I think (I could be wrong) that you can piggyback PA from JACK (so |
94 |
JACK has the control). That was what I understood. |
95 |
|
96 |
>> > What about those, like me, with audio problems, where the need exists to |
97 |
>> > strip a system down so as to isolate those problems? |
98 |
> |
99 |
>> As I said below: if PA has problems, they need to be fixed. Did you |
100 |
>> report the bugs? |
101 |
> |
102 |
> I don't even know where the bug is. It's somewhere in my audio. It |
103 |
> might be in Firefox 17.0.5. It might be in pulseaudio, though having |
104 |
> been able to remove it, I doubt it. It might be in ALSA. My point is, |
105 |
> in a tightly integrated system, my chances of fixing the problem would be |
106 |
> that much slimmer. I don't experience the problem in my fossilised mdev |
107 |
> system from last summer. |
108 |
|
109 |
Well, that helps. And that the problem: with loose integrated systems, |
110 |
a lot of people tend to "fix" things by actually workarounding them, |
111 |
so the real problem (a bug in ALSA, PA, or the aps) gets unfixed. We |
112 |
need to zero in the real bugs and *fix them*. It's not your |
113 |
responsibility to fix the problem; but (and specially if you believe |
114 |
in "moral obligations") reporting the bugs is. |
115 |
|
116 |
>> >> If PA has bugs in some configuration, those bugs need to be fixed; the |
117 |
>> >> solution (in the GNOME developers view) is not to "remove PA", since |
118 |
>> >> the goal of the project is to cover *ALL* use cases. |
119 |
> |
120 |
>> > pulseaudio is a server component - gnome is an application. They are at |
121 |
>> > different levels of the system hierarchy, just as a mail transport agent |
122 |
>> > and mail user agent are. The maintainers of mutt don't force the use of, |
123 |
>> > say, postfix. By long tradition on *nix, sysadmins configure their own |
124 |
>> > systems, selecting those components which best fit their needs. gnome's |
125 |
>> > decision to mandate pulseaudio interferes with this tradition. IMAO, |
126 |
>> > this is a Bad Thing. |
127 |
> |
128 |
>> GNOME is a desktop environment, and it wants (from some years now) a |
129 |
>> vertical integration from kernel to the last userspace application. I |
130 |
>> root for that. |
131 |
> |
132 |
> That would probably be an environment I couldn't configure to work the |
133 |
> way I want. Gnome and I will likely be parting company in the coming |
134 |
> years. |
135 |
|
136 |
That's your prerogative, of course. |
137 |
|
138 |
>> And I have been using Unix since 1996, and I don't care about what |
139 |
>> *nix "long traditions" are. I want a Linux system that works from my |
140 |
>> cellphone to my big iron server, and everything in between. I don't |
141 |
>> even care about *BSD; I don't wish them any ill, but I don't care |
142 |
>> about them. |
143 |
> |
144 |
> You can't have a single Linux which works equally well on all these |
145 |
> disparate systems. Equally badly, perhaps. Look at the problems which |
146 |
> MS Windows-8 is having, and it only tries desktops/laptops and 'phones. |
147 |
|
148 |
I don't think that way; I think an unified system can run in all the |
149 |
hardware spectrum. We will know in a few years. |
150 |
|
151 |
>> If you don't agree with that, that's fine; but if a big enough set of |
152 |
>> developers thinks similarly, several projects will move in that |
153 |
>> direction. It's already happening. |
154 |
> |
155 |
> Yes. I doubt it will end prettily. |
156 |
|
157 |
I'm sure it will be awesome. |
158 |
|
159 |
> [ .... ] |
160 |
> |
161 |
>> and then the only required dependency for systemd will be Linux. |
162 |
> |
163 |
>> Man, that will be a nice day. |
164 |
> |
165 |
> Will you still be able to configure your system as you wish, though? |
166 |
|
167 |
As long as *you* do the customization, and don't expect that your |
168 |
distro do it for you, yeah sure. That will be always possible. |
169 |
|
170 |
The code is out there. |
171 |
|
172 |
Regards. |
173 |
-- |
174 |
Canek Peláez Valdés |
175 |
Posgrado en Ciencia e Ingeniería de la Computación |
176 |
Universidad Nacional Autónoma de México |