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.'"
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.
It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail. - Abraham Maslow
I don't think you've heard some of the non fanboi mac users rant..
They are brutal
Especially about the OS X finder which while working isn't where it needs to be yet.
Don't get them started on the Dock.
I hear lots of negative criticism about Linux. Mostly from uneducated haters, but there's no lack of it.
My problem is the opposite, uneducated Linux developers. I'll submit a bug asking for feature parity with Windows or OS X and get a response back that clearly misunderstands how those OS's work. I then spend a week educating the person and explaining to them why (from and end user perspective) the way Linux does things now really isn't better and what the other OS in question does. In the the end they usually agree, it would be cool to improve Linux to work that way, but too much work or would be incompatible with other distros, so they ignore it.
Alternately, I submit a usability bug (I have worked as a UI/usability expert in the past) and then spend hours trying to explain to a server engineer working on making a desktop, why their design ignores all the research in the field and (if they did testing) is going to be a huge problem when they test it.
Don't get me wrong. I like and use Linux. In many ways it has leapt ahead of other OS's and provides a model for them to follow. It just does have some serious flaws and problems that have gone unaddressed for a long time and don't seem likely to be fixed anytime soon.
Oh, and in lots of cases, it IS ready for the desktop. Either in a managed environment with a guru at the top, for those who know what they're doing, and for locked down spoon fed distros.
I agree it can work and save money in certain uses.
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:
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'.
I am TheRaven on Soylent News
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.
Palm trees and 8