| 1 |
Alan McKinnon <alan.mckinnon@×××××.com> writes: |
| 2 |
|
| 3 |
> On 18/12/2016 18:47, lee wrote: |
| 4 |
>> Rich Freeman <rich0@g.o> writes: |
| 5 |
>> |
| 6 |
>>> The universe of Linux systems that are running Firefox but not |
| 7 |
>>> Pulseaudio is fairly small at this point. |
| 8 |
>> |
| 9 |
>> Pulseaudio eats away about 10% CPU without any benefit whatsoever, not |
| 10 |
>> to mention that it makes things more complex and less reliable. Why |
| 11 |
>> would anyone use it? |
| 12 |
>> |
| 13 |
>> Developers might try to make their lifes easier by developing software |
| 14 |
>> to the point where nobody wants to use it, except for the few developers |
| 15 |
>> perhaps. With firefox, a policy like that contradicts their claims. |
| 16 |
>> |
| 17 |
>> |
| 18 |
>> This is another issue which comes up quite often with FOSS. Developers |
| 19 |
>> claim to be doing something in the interest of their users and are |
| 20 |
>> asking for support. When you take a closer look, you find that they |
| 21 |
>> don't, and when you offer support, they do not want it. |
| 22 |
>> |
| 23 |
>> Why can't they just say that they are making software for themselves the |
| 24 |
>> way they want it and don't care about what anyone else says or wants? |
| 25 |
>> It only gives reason to distrust someone when you find that they do not |
| 26 |
>> do what they claim to be doing. |
| 27 |
>> |
| 28 |
> |
| 29 |
> I think you are over-simplifying the situation here. Step back and look |
| 30 |
> at the problem from the angle of "it's a bunch of people doing stuff" |
| 31 |
> and not from a tech-centric angle. It's a people problem. |
| 32 |
> |
| 33 |
> You could make a valid case that the Mozilla devs are outright lying - |
| 34 |
> they said they want xvy, and your offer to help provide xyz was |
| 35 |
> rejected. But is it really that simple? I think it's more a case of the |
| 36 |
> devs would like contributions for xyz and they don't mention the |
| 37 |
> "everyone knows" "hidden assumption" of environment abc and general |
| 38 |
> method def. Ahhhh, that's the usual tripping point. |
| 39 |
> |
| 40 |
> I don't know the specifics of your particular case, but my first |
| 41 |
> approximation guess is that there's an abc and def in there which the |
| 42 |
> devs didn't think to mention. Happens all the time, usually with |
| 43 |
> stunningly obvious stuff that "everyone" thought "everyone else" knew |
| 44 |
> about. Things like future roadmaps, planned features, and the individual |
| 45 |
> personal preferences of each dev. |
| 46 |
> |
| 47 |
> I guess I'll saying don't be too quick to shoot from the hip - more |
| 48 |
> looking less assuming is often the better path. |
| 49 |
|
| 50 |
It really is that simple because it is the way it turns out. It doesn't |
| 51 |
matter /why/ it turns out that way. |
| 52 |
|
| 53 |
There is no assuming involved, and I have no reason to try to figure out |
| 54 |
what hidden agenda a bunch of developers might have, or to make |
| 55 |
assumptions about one. It won't change anything. |
| 56 |
|
| 57 |
That doesn't keep me from noticing that what is being said is very |
| 58 |
different from what is being done. If the bunch of people wants to |
| 59 |
change that, /they/ need to do so. |
Archives