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 19:10:01
Message-Id: CADPrc832EN5QxgxX3quvMiGrkAoZQ5PhPL-uwkLnqtqp7T+Bmg@mail.gmail.com
In Reply to: Re: [gentoo-user] Removing pulseaudio by Alan Mackenzie
1 On Fri, Apr 26, 2013 at 1:38 PM, Alan Mackenzie <acm@×××.de> wrote:
2 > 'afternoon, Canek!
3
4 Hi Alan.
5
6 > On Fri, Apr 26, 2013 at 12:02:38PM -0500, Canek Peláez Valdés wrote:
7 >> On Fri, Apr 26, 2013 at 11:29 AM, Alan Mackenzie <acm@×××.de> wrote:
8 >> [snip]
9 >> > Somebody reported that pulseaudio is an absolute requirement for Gnome
10 >> >>=3.8. That may not be 100% of users, but the "forced" is certainly
11 >> > there.
12 >
13 >> No one is forcing nothing on anyone, since nobody is forcing no one to
14 >> use GNOME, Gentoo, or Linux for that matter.
15 >
16 > That's a strawman argument. Anytime a free software project drops
17 > support for something, it forces its users to make choices. Yes, force.
18
19 I don't think that's true, since we are not paying anyone to do the
20 work (well, at least for sure I'm not paying anyone to do anything).
21 They (the developers) don't own us *anything*.
22
23 >> The developers of any project can always decide the dependencies of a
24 >> project. If you are not a developer, you simply have no vote in the
25 >> matter, although you certainly always have voice... that they can
26 >> choose to ignore.
27 >
28 > Free software developers, having got people to commit to using their
29 > software, have responsibilities, albeit moral ones.
30
31 If you want to get into morals, this will become a religious argument,
32 and sorry but I'm not interested in that.
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 > You'll surely have noticed that what gets up the
43 > noses of people on this mailing list most is when support for reasonable
44 > configurations gets dropped. Witness all the recent trouble over eth0,
45 > for example.
46
47 What problem? I use NetworkManager in desktop and laptop; there is no
48 problem there. I read the instructions in my media center and servers:
49 no problems there. I don't particularly like the new funny names, but
50 I don't write the code, and the fruits from it I get for free, so I
51 don't complain about it.
52
53 >> > There's a difference between a "default choice" and an absolute
54 >> > requirement.
55 >
56 >> Yeah; and the decision is for the developers to make.
57 >
58 >> >> Basically there's a bunch of vague criticisms of unnamed systems where
59 >> >> "they" force stuff on "all users" for "no good reason". Nevermind that
60 >> >> we can actually state what the reasons are. Fingers in the ears.
61 >> >> neener neener.
62 >
63 >> > Please feel free to state those reasons, which as far as I can see,
64 >> > nobody has done yet in this thread; "they" being the gnome team, and the
65 >> > reasons being for the forcing, not for a non-existent "default choice".
66 >
67 >> If GNOME has to support PA and non-pa systems, they need to code,
68 >> test, support and bug-fix 2 different sets of of systems. If they need
69 >> to support ConsoleKit and logind, the number grows to 4 (PA/ck,
70 >> PA/logind, non-PA/ck, non-PA/logind). With 3 different optional
71 >> requirements, it's 8 sets of systems. With 4, is 16. With n, it's 2^n.
72 >
73 >> That's exponential growth, which in CS is always no-no.
74 >
75 > WADR, that is simply false. With features which interact chaotically
76 > with eachother, yes, you have exponential growth. With distinct,
77 > self-contained features, each one is merely an incremental test effort.
78 > ALSA and pulseaudio are self-contained, and are also well tested in their
79 > own right. Only integration needs testing.
80
81 OK, I exaggerated a bit; but who is going to do the integration
82 testing? You? Because the GNOME developers have no interest in doing
83 that, and I support their decision.
84
85 > If you were serious about this exponential growth, how on earth could,
86 > e.g., the Linux kernel or Emacs, both with thousands of options[*],
87 > possibly get tested anywhere near acceptably?
88 >
89 > [*] 12,666 in Linux 3.7.10, 7,510 in vanilla Emacs 24.3.
90
91 Because they have enough integration testers. They have enough
92 interested users to do the required testing; the kernel and Emacs is
93 oriented towards technical apt users. The stated goal of the GNOME
94 project is that even my grandmother could use it.
95
96 >> Who is going to code, test, support and bug fix all those possible
97 >> configurations? You?
98 >
99 > No. The gnome developers.
100
101 Why? Because you say so? Do you pay them?
102
103 > I test and support all reasonable (and many
104 > unreasonable) combinations on my own free software project.
105
106 Good for you: that's your call. It's not your call to say what the
107 GNOME developers should use.
108
109 >> The GNOME developers simply cannot support all different sets of
110 >> possible configurations, and PA covers the sound needs of *ALL* users
111 >> (doesn't matter if you like it or not), even the simple cases.
112 >
113 > What about the needs of those high-end audio users, for example, who need
114 > jack?
115
116 There are several success stories about mixing PA with Jack; you can
117 Google them. I don't see the problem.
118
119 > What about those, like me, with audio problems, where the need exists to
120 > strip a system down so as to isolate those problems?
121
122 As I said below: if PA has problems, they need to be fixed. Did you
123 report the bugs?
124
125 >> If PA has bugs in some configuration, those bugs need to be fixed; the
126 >> solution (in the GNOME developers view) is not to "remove PA", since
127 >> the goal of the project is to cover *ALL* use cases.
128 >
129 > pulseaudio is a server component - gnome is an application. They are at
130 > different levels of the system hierarchy, just as a mail transport agent
131 > and mail user agent are. The maintainers of mutt don't force the use of,
132 > say, postfix. By long tradition on *nix, sysadmins configure their own
133 > systems, selecting those components which best fit their needs. gnome's
134 > decision to mandate pulseaudio interferes with this tradition. IMAO,
135 > this is a Bad Thing.
136
137 GNOME is a desktop environment, and it wants (from some years now) a
138 vertical integration from kernel to the last userspace application. I
139 root for that.
140
141 And I have been using Unix since 1996, and I don't care about what
142 *nix "long traditions" are. I want a Linux system that works from my
143 cellphone to my big iron server, and everything in between. I don't
144 even care about *BSD; I don't wish them any ill, but I don't care
145 about them.
146
147 If you don't agree with that, that's fine; but if a big enough set of
148 developers thinks similarly, several projects will move in that
149 direction. It's already happening.
150
151 >> But hey, the source is there; feel free to patch whatever needs to be
152 >> patched in GNOME (and probably GStreamer) so it doesn't require PA.
153 >> Just be certain that those patches will be rejected by upstream, for
154 >> the reasons stated above.
155 >
156 > Making minor changes to free software is impracticable on a casual basis.
157 > Only forking a project can do this. You know this full well.
158
159 Well, fork away then. It's in your freedoms when it comes to free
160 software. Look at the success stories from MATE, Cinnamon, the Trinity
161 Desktop Environment and eudev.
162
163 >> And by the way, this is also true for Gentoo: it cannot support all
164 >> different sets of possible configurations, no matter how hard they/we
165 >> try.
166 >
167 > It come pretty close. :-)
168
169 http://article.gmane.org/gmane.linux.gentoo.devel/85223
170
171 "I'm not sure about the future of the core of OpenRC:
172
173 Upstart & systemd have some clear architectural benefits, despite their
174 implementation shortcomings (either upstream or per-distro).
175 The /usr merge is inevitable, as is the integration of other components
176 into the init system (udev, dbus, ...). What has become dis-integrated instead
177 is the configuration: lots of hardware ships specific udev rules with few
178 problems."
179
180 That's a Gentoo developer talking. Many of them think like that; many
181 of them oppose them. But the truth is, Linux distributions are moving
182 to a vertical, tightly integrated OS. There will always be niche
183 distros for the people that don't like this (and hey, that's the
184 beauty of using Free Software), but the big distros are going that
185 way. It's possible that Gentoo will follow (as did Arch, as
186 Debian-based Tanglu and Gentoo-based Sabayon are doing).
187
188 Greg Korah-Hartman will integrate an incarnation of dbus (or something
189 really similar) into the kernel:
190
191 https://plus.google.com/u/0/111049168280159033135/posts/BDgg5DKVjkX
192
193 and then the only required dependency for systemd will be Linux.
194
195 Man, that will be a nice day.
196
197 Regards.
198 --
199 Canek Peláez Valdés
200 Posgrado en Ciencia e Ingeniería de la Computación
201 Universidad Nacional Autónoma de México

Replies

Subject Author
Re: [gentoo-user] Removing pulseaudio Alan Mackenzie <acm@×××.de>