Thanks, MATE!

Posted Jun 16, 2015 17:34 UTC (Tue) by drag (guest, #31333)
In reply to: Thanks, MATE! by ncm
Parent article: MATE 1.10 released

A large part of Pulseaudio's early nastiness can be contributed to Ubuntu's implementation of Pulseaudio was poorly executed and Alsa drivers themselves were in a really bad state.

In the bad old days any system I had I know I would have to work around alsa bugs. Usually this meant, minimally, setting up a asoundrc file and setting the PCM format, rate, and buffer sizes because the drivers themselves choose poor defaults. Unless I did this then poor sound quality, stuttering video playback, and other things was the normal consequence. Pulseaudio devs refused to implement work arounds and 'tweak' configuration knobs to work around broken drivers and this forced a lot of good fixes to happen... unfortunately for end users the turn around time for driver enhancements in Linux is about 1-2 years. So they were plagued with continuous problems until Distros picked up more modern kernels.

And by the time Pulseaudio came out I was already switching away from Ubuntu. I didn't understand at the time why people had so many issues using Pulseaudio. When I went back to trying to use Ubuntu and Debian on my desktop I found out that they really just did a bad job. Debian required a significant amount of effort to get Pulseaudio running since it wasn't the default... just installing the deb package without putting a lot of effort in reconfiguration the system manually would yield a almost completely broken audio system. Ubuntu tried to integrate it, but some of the configuration choices they made were bad and caused problems for end users.

Nowadays it seems most of these issues have been resolved and, generally speaking, the issues people run into are either actual Pulseaudio issues (probably most of them) or related to the fact that they have been hamfisted with their system and are doing things like insisting on using alsamixer (which was fundamentally broken prior to Pulseaudio, would regularly configure hardware is terrible ways without any fault on the end user, and hasn't gotten any better) or are trying to use 'minimalistic' desktops that require a great deal of configuration to work correctly and they have missed something important audio-related.

Thanks, MATE!

Posted Jun 16, 2015 20:53 UTC (Tue) by paulj (subscriber, #341) [Link] (6 responses)

These rationalisations of "The users must suffer so the code can be redeemed" have almost religious parallels. It's not good user-experience engineering though, is it? I personally don't think it has helped further the reach of the Linux desktop at all. At least, amongst my peer group, the mid-90s and early 00s Linux enthusiasts, many have abandoned it on the desktop.

Thanks, MATE!

Posted Jun 17, 2015 0:46 UTC (Wed) by raven667 (subscriber, #5198) [Link] (1 responses)

That's true, this wasn't the best user experience but the ultimate responsibility falls on the distributor otherwise what are they for? No one had to ship PA if they didn't want to, they could have kept ESD or patched PA to make the experience anything they wanted, it's Free software. Of course no one had then or has now a test environment sufficient to discover all these integration issues, even on common hardware and not every distribution has the best experts capable of integrating every software adequately.

Thanks, MATE!

Posted Jun 17, 2015 7:27 UTC (Wed) by paulj (subscriber, #341) [Link]

This is Linux. Responsibility is distributed and diffuse. The distributors are not always well resourced, it may not be possible to do major integration work, and it may not be possible to swim against upstream tides. Upstreams set the tone and have responsibilities too, in addition to the distributors. This seems a collective failure.

Thanks, MATE!

Posted Jun 17, 2015 1:49 UTC (Wed) by rwhogg (guest, #103069) [Link] (3 responses)

They're not the only ones: <http://tirania.org/blog/archive/2013/Mar-05.html>.

What's more important, the code or its users? I'd argue it's the users. Programs exist to support users, not the other way around.

We haven't always sacrificed users for the sake of code though. We still maintain X11 and make sure it works nicely with different hardware, for example. That's the right choice, even if it causes us some pain, because otherwise we'd break every graphical application ever. I'll cheer when Wayland fixes everything, but forcing a buggy Wayland onto the world would be a disaster. Let's wait until it's ready. It sounds like with ALSA/PulseAudio we made the wrong choice. Ditto with GTK+ 3.

Transitioning takes time; Python 2/3, Perl 5/6, and IPv4/6 proved that. In the meantime, the best experience we can muster comes from helping users make the most of the imperfect software they have. If Microsoft can do it, so can we - it might just mean reallocating some developers away from the next exciting rewrite.

Thanks, MATE!

Posted Jun 17, 2015 12:06 UTC (Wed) by pizza (subscriber, #46) [Link] (2 responses)

> If Microsoft can do it, so can we - it might just mean reallocating some developers away from the next exciting rewrite.

Microsoft has the advantage of (literally) multi-billion R&D budgets and many thousands of developers that can be explicitly told what to do, in a top-down manner.

And even with that huge advantage, Microsoft can't do it most of the time.

Thanks, MATE!

Posted Jun 17, 2015 13:29 UTC (Wed) by rwhogg (guest, #103069) [Link]

> Microsoft has the advantage of (literally) multi-billion R&D budgets and many thousands of developers that can be explicitly told what to do, in a top-down manner.

It's true that we can't pay everyone to do exactly what we want, but we can change the incentive structures of open source so that huge rewrites and unnecessary new projects are less rewarded than maintaining existing widely used software. You don't have to employ someone to influence their actions. (You're right that it certainly helps though!)

I'm not saying it's going to be easy. But all sorts of techniques can make this easier:

* Large organizations like Intel, Red Hat, etc. could shift from funding GNOME to funding MATE (for example)
* Promote the less prominent but nonetheless productive and important developers in existing projects more heavily than they are currently. Social capital goes a long way in the volunteer case. This would discourage starting unnecessary brand-new projects just to get the desired attention.
* Make it easier to package software for different distributions so there's less incentive to go it alone. This will also make integration issues and the upstream/packager divide less problematic.
* In the case of people who ARE employed in open source, the Microsoft tactic works quite nicely.

We don't have to, and can't, support every piece of software this way. But we should be able to support enough to have a viable desktop environment.

Thanks, MATE!

Posted Jun 24, 2015 12:50 UTC (Wed) by epa (subscriber, #39769) [Link]

I think the point is more that Microsoft *don't* have developers who can be told what to do, top-down. There are, even today, hundreds of thousands of developers writing for the Windows desktop, far more than the total employees of Microsoft. And the existing applications that work today must continue to work tomorrow. The Linux approach of moving on to a new version of the desktop libraries and stranding older applications is simply not an option. This forces Microsoft to be disciplined about compatibility, whether they like it or not. Sure, things do go away in the end: Win16 applications don't run on 64-bit Windows, but that is at least a decade after Win32 became common. And of course there are the anecdotes about my beloved application which worked fine on Windows 95 but won't run on Windows 7. But on the whole, their record of not breaking stuff is enviable, and so far away from current Linux practice it's not even funny.

If distributions put their foot down and said: all binary applications which currently work must continue to work in future releases, then upstreams would have to start taking compatibility seriously. Of course this will never happen, and I am not even seriously advocating it. But perhaps there is some middle ground.