Linux Needs Critics

An anonymous reader writes "Keir Thomas berates the fact that the world of Linux almost entirely lacks critics. In fact, he says, Linux people tend to see genuine critical evaluation as a bad thing. FTA: 'The problem with this anti-criticism approach is that it's damning Linux to an eternity of navel gazing. Nothing can ever get any better. The best hope we have are the instances where a few bright sparks, with their heads screwed on the right way, get together and make something cool (as happened with, say, Firefox back in the day). But that's rare and can't be relied upon.'"

Comments

Re:Nonsense

[Ami Ganguli]

Indeed. What a strange article.

I would even go so far as to say that Linux (and the Free Software ecosystem that surrounds it) has a lot more critics than closed software - or at least more effective critics.

Large software companies pay PR departments to generate positive coverage. Most Open Source projects have no PR effort behind them at all. So criticism of the software is less likely to be drowned out by astroturf.

Re:You should look into linuxhaters

[TheRaven64]

The state of audio on Linux never ceases to amaze me. Linux used to have OSS. It worked. Then the developer decided to make the next version non-Free. At this point, the Linux community had two choices:

1. Fork the old version, keep it in the kernel, keep adding drivers to it, and just ignore the existence of the non-Free version.
2. Make something new, from scratch, which is completely incompatible with the original, and may eventually be better at some distant point in the future.

For some reason which I have yet to understand, they picked option 2 and ALSA was born. Meanwhile, FreeBSD just kept OSS in the tree and kept up to date with (backwards-compatible) improvements to the API (and ABI). To play a sound on FreeBSD I (as a developer) open /dev/dsp, issue ioctls to set the sample rate, number of channels, and so on, and then write the data there. In total, it's around five lines of code (less if you want the default sample rate and number of channels) and uses the standard UNIX system calls so I don't need to link (and worry about the existence of) any libraries. Starting with FreeBSD 4, the kernel did mixing in software if the sound card didn't support it. Starting with FreeBSD 5 (around 2003), the kernel would automatically assign new virtual channels whenever a new app opened /dev/dsp. With FreeBSD 8 (7 if you add some out-of-tree patches) each vchan gets its own volume control and the mixing performance is improved with a new fixed-point algorithm.

Now let's compare this to Linux. On Linux, the OSS APIs may work. For some value of 'work,' because there are four different ways in which OSS may be implemented on Linux:

1. It may be the old OSS 3 version, that stayed in the kernel for a long time but wasn't really maintained after ALSA became new and exciting.
2. It may be the commercial OSS 3 implementation, if someone has paid for it (this was the only way of getting support for some sound cards for a while, and possibly still is).
3. It may be the new OSS 4 implementation, which is now GPL'd on Linux (CDDL and BSDL for Solaris and *BSD), but not included by default with many implementations. This supports all of the features I described for FreeBSD and a few more.
4. It may be OSS emulation in ALSA.

In some of these cases, only one program can be using the OSS device at once. In others, you get proper sound mixing. In the OSS 4 configuration, you get per-vchan volume controls. Most Linux systems, however, ship with ALSA. Unlike OSS, which is supported on *BSD, Solaris, HP-UX, and so on, ALSA is Linux-only. It is also very poorly documented. Because ALSA isn't ubiquitous (and for a long time didn't handle mixing), a lot of systems started shipping with userspace sound daemons, which did this mixing. These all came with their own APIs, their own client libraries, and a complete inability to work together.

The Linux solution to this mess? Add another userspace sound daemon, but this time call it 'standard'.

We are not magicians

[betterunixthanunix]

Sometimes you cannot just *make* a driver. Some hardware is overwhelmingly complicated, and if the hardware manufacturer cannot or will not release the source for their driver or technical documents for the hardware, then you are SOL. My laptop's integrated modem has no free drivers, and the only Linux driver available is from a team that is under an NDA. The attempts to write a free driver were nothing even close to something useful, and those attempts have been undertaken for 10 years.