1 |
On Thu, Apr 25, 2013 at 09:31:43PM +0400, Yuri K. Shatroff wrote: |
2 |
> On 25.04.2013 19:48, Mark David Dumlao wrote: |
3 |
> > On Sat, Apr 20, 2013 at 5:34 PM, Walter Dnes <waltdnes@××××××××.org> |
4 |
> > wrote: |
5 |
> >> I think you've hit the nail on the head. Complex setups require |
6 |
> >> complex software... deal with it. An analogy is that an |
7 |
> >> 18-wheeler semi-tractor trailer with a 17-speed manual transmission |
8 |
> >> (plus air brakes that require months of training to manage/use) is |
9 |
> >> much more powerful than a Chevy Sonic hatchback when it comes to |
10 |
> >> hauling huge loads. But for someoneone who merely wants to zip out |
11 |
> >> to the supermarket and buy a week's groceries, the hatchback is |
12 |
> >> much more appropriate. |
13 |
> >> |
14 |
> >> Similarly, PulseAudio may be better at handling complex situations |
15 |
> >> like you describe. The yelling and screaming you're hearing are |
16 |
> >> from the 99% of people whose setups are not complex enough to |
17 |
> >> justify PulseAudio. Making 100% of setups more complex in order to |
18 |
> >> handle the 1% of edge cases is simply wrong. |
19 |
|
20 |
Exactly. If you think you have to make 100% of cases more complex just |
21 |
to handle an edge 1%, YDIW. No ifs nor buts about it. |
22 |
|
23 |
> > The "complexity" overhead of pulseaudio is vaaastly overstated here. |
24 |
> > |
25 |
> > Yes, as a general principle, adding unneeded complexity is bad. But |
26 |
> > that takes into account general ideas on the relative tradeoffs of |
27 |
> > having it there or not. But listen to the happy PA users here who |
28 |
> > don't feel any problem with their setup. The complexity doesn't bite |
29 |
> > them. |
30 |
|
31 |
> As for the complexity of PA, one must distinguish the PA architecture |
32 |
> complexity, its installation complexity and the complexity of managing |
33 |
> this stuff for the user (not mentioning usage complexity which is |
34 |
> probably negligible). |
35 |
> |
36 |
> I wouldn't care for the architecture complexity (although I assume it to |
37 |
> be too complex) but what I do care about is its bad manageability. |
38 |
> If it were to install just a package, or just remove one package, then |
39 |
> everyone would be satisfied, including those who need the functionality. |
40 |
> But apparently it isn't so; either all audio software is to use PA, or |
41 |
> none at all. |
42 |
> |
43 |
> > Analogy: 99% of people aren't going to need a11y. But the whole point |
44 |
> > of installing it by default on most desktop systems is that you can't |
45 |
> > predict who will need it, and _it does not harm_ (or very little |
46 |
> > harm) to the people who don't. |
47 |
> > |
48 |
> > So your tradeoffs are: A) no a11y unless elected by user: - for the |
49 |
> > 1%: a11y is a pain to install because the user might not even be able |
50 |
> > to see the screen (very big pain) - for the 99% use a few megabytes |
51 |
> > less on their disk. (very small gain) |
52 |
> > |
53 |
> > B) a11y for everyone unless elected removed: - for the 1%: they can |
54 |
> > use the system properly (no pain) - for the 99%: use a few megabytes |
55 |
> > more on their disk (very small pain) |
56 |
> |
57 |
> > Obviously (B) is a better default choice. Ditto pulseaudio. |
58 |
|
59 |
That's assuming it were simply a case of a few megabytes of disk space. |
60 |
But as pointed out, it's also a case of upstream wanting everyone to |
61 |
change the way they do things across the board, in the name of |
62 |
"convenience". It doesn't seem like these "convenience" layers really |
63 |
make anyone's life easier in the longer-term. |
64 |
|
65 |
Instead of working behind the scenes so that existing methods function |
66 |
more capably, everyone has to change their code to a new API, whose |
67 |
developers wouldn't know an ABI-promise if it smacked them on the head, |
68 |
and all users have to change their setups. Hardly making everyone's |
69 |
life easier, and "breaking userspace" as if it were lucrative. |
70 |
|
71 |
Further, they appear to have a tendency to break when you want to do |
72 |
something "unusual", or as most people think of it, use your machine as |
73 |
you see fit. That's a problem common to all idiot-box software, when |
74 |
they try to guess and don't listen. |
75 |
|
76 |
If I wanted that, I wouldn't have fled Windows development over a decade |
77 |
ago. |
78 |
|
79 |
> Well if PA is that great then why really not do like you suggest? |
80 |
> Probably, the problem is not "a few megabytes more on their disk" but |
81 |
> that PA is just not a good alternative? |
82 |
> |
83 |
> And eventually is there a real big unsolvable problem for one to |
84 |
> *install* PA when he needs? Does one really end up with "black screen" |
85 |
> or another kinda PITA without PA? If not, then it's not a good analogy? |
86 |
|
87 |
Precisely. |
88 |
|
89 |
> But as I feel it, the talk is about choice, not PA nor complexity. I |
90 |
> just *don't want* it. I probably don't see any harm with various |
91 |
> akonadis and nepomuks in KDE (actually, I did see much harm, but that's |
92 |
> another story) but I simply don't want'em. As a result (of all those |
93 |
> useless-for-me pieces of great code removed) I have Gentoo running KDE |
94 |
> times faster than e.g. OpenSUSE, but even without that, it's my choice |
95 |
> and if I don't perceive or measure these "times faster" I believe in |
96 |
> them. |
97 |
|
98 |
I'm with you there: after I removed semantic-craptop, my KDE came back to |
99 |
me :-) I went a bit further and removed the nubkit stuff, and things |
100 |
actually work a lot better. It was hard giving up kmail[1] but once I'd |
101 |
overcome that barrier, losing nubkit was a trivial thing to do, after I |
102 |
read Dominique's wonderful write-up[2]. |
103 |
|
104 |
The other thing I did was switch my /bin/sh symlink to point to busybox, |
105 |
ie /bin/bb which I'd used as SHELL when working with mutt, where it was |
106 |
noticeably quicker (I had to test procmail setup quite a bit, before I |
107 |
got it running nicely.) There were a couple of initscripts that needed |
108 |
patching, though everything still worked. But the difference is amazing. |
109 |
|
110 |
Boot time, which has never been a concern to me, sped up by orders of |
111 |
magnitude in terms of user perception: I used to get time to read all |
112 |
the initscript messages. Now I glance away, and they're gone. More |
113 |
importantly, the _rest_ of my system sped up as well. |
114 |
|
115 |
It's important to note that this is only feasible because of the modular |
116 |
design of Unix. And frankly it makes me laugh at the dead-end One True |
117 |
Inturgrated Way being touted so much. |
118 |
|
119 |
> Why should I care that there is a 99% majority of users who say |
120 |
> that some stuff are harmless or they need them on their PCs, if *I* |
121 |
> don't need it on *my* PC? -- Here "I" means "one". |
122 |
|
123 |
> If free software is going to be really free, then it is not expected to |
124 |
> make assumptions about what I need or what 99% users need, nor to make |
125 |
> its use unavoidable. It is expected to provide a means to use it, as |
126 |
> well a means to not use it. |
127 |
|
128 |
That is one of my favourite quotes this year: I hope you don't mind if |
129 |
I repeat it? It sums up exactly what we should be aiming for, and what |
130 |
we're not getting. |
131 |
|
132 |
Regards, |
133 |
steveL. |
134 |
|
135 |
[1] http://forums.gentoo.org/viewtopic-t-945868.html |
136 |
[2] http://forums.gentoo.org/viewtopic-t-938680.html |
137 |
-- |
138 |
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-) |