Gentoo Archives: gentoo-user

From: "Canek Peláez Valdés" <caneko@×××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Removing pulseaudio
Date: Fri, 26 Apr 2013 22:14:20
Message-Id: CADPrc82+BcdRjsP7vWDJH-SDmRZFnwwGYEPsYV2MoHuNqWodkQ@mail.gmail.com
In Reply to: Re: [gentoo-user] Removing pulseaudio by Alan Mackenzie
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