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