Gentoo Archives: gentoo-user

From: "Steven J. Long" <slong@××××××××××××××××××.uk>
To: gentoo-user@l.g.o
Subject: [gentoo-user] Re: Removing pulseaudio
Date: Thu, 25 Apr 2013 20:00:25
Message-Id: 20130425202634.GA1479@rathaus.eclipse.co.uk
In Reply to: Re: [gentoo-user] Removing pulseaudio by "Yuri K. Shatroff"
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 ;-)