Alsa versus OSS
Last week I read a thread on the mplayer-dev mailinglist. It was about setting the default sound output from Alsa to OSS. It is now OSS for a default compile of the tarball. However OSS is deprecated in linux AND in almost all distributions that ship mplayer (my favorite media player) set the default output to Alsa.
Most in charge mplayer developers are pro OSS and do not want to switch. One of the arguments is that OSS is now GPL and is used other unices as well . There are also arguments about library vs. unix semantics. Alsa has an OSS compatibility mode (actually two, one in-kernel and one in-library). However using this blocks soft-mixing. This means that another program playing sounds can not do this while using default mplayer compile.
Both sides have some good arguments (i truly understand the points for OSS!, it is just not realistic), but discussing them in this context is useless and the way it is done on this mailing-list is very childish and out of reality. Mplayer should set Alsa as default output for linux, because 1) all major distributions do this and do this with good reason: 2) OSS in linux is deprecated. Reading this thread made me feel tired of (the immaturity of) the open source scene.
But today I am a happy guy again. Some troll suggested removing Alsa from the linux kernel and I was afraid of another useless thread. However I found a message from Takashi (one of Alsa's most productive driver and patchwriters:
Honestly, I'm not fully against changing the current code base (or
crap, whatever, any childish name). There are indeed many misdesigns.
But, replacing with the above is no option, IMO. The OSS have also
many misdesigns, so the same argument would start again. One should
learn something from history...
Anyway, if it's going to be more constructive, I'm willing to join in.
Takashi
Hannu (the main OSS developer) then said this:
We have no intention to push OSS back to the kernel or to replace ALSA. That alternative is not
realistic any more. In addition OSS is a cross-platform product and staying more or less outside
various kernel trees should provide better flexibility.
What we would like to push is that the old "deprecated" OSS/Free are removed from the kernel.
OSS/Free is based on about years old OSS API version which was too limited for many applications.
Having OSS/Free in the kernel doesn't serve any purpose.
Also we would like to stop the silly OSS vs ALSA war. OSS and ALSA are rather different. Both of
them have some good points and bad points. For ordinary users it doesn't matter which API is used by
the applications as long as they work. Just the application developers can see the real difference.
Some of them prefer OSS while some other prefer ALSA and this should be their "freedom of choice".
I think the ideal solution would be that both ALSA and OSS APIs can co-exist by sharing the same low
level drivers (which has already been demonstrated). The low level driver interfaces in both systems
are practically identical. This means that ALSA's core can work with OSS' drivers and vice versa.
Today both OSS and ALSA teams have to spend significant amounts of time in emulating the "alien"
APIs. Making OSS and ALSA to co-exist will require some work in both sides but that should be
nothing when compared to the effort required for emulation.
Just my 2 cents.
Best regards,
Hannu
Fortunately there are still a lot of sane people in the community. Thanks!
[Permalink] -- Filed under: [linux]
The Wicklow Way
Back from a nice holiday. Photos are updated.
[Permalink] -- Filed under: [photos] [holiday]
Dead on
Good presentation on captchas by google. See this video. The group that is headed by the prof doing the presentation should easily be able to break current current used image captchas if their statements are true...
Perhaps I like it because perfectly reflects my own opinion though ;-).
[Permalink] -- Filed under: [linux] [science] [web]
You've got mail
Since I have searched for the maildirmake command on debian now two times (using http://packages.debian.org and apt-cache) with no result, I decided to blog the answer here.
You need to apt-get install courier-base. (and then /etc/init.d/courier-authdaemon stop; update-rc.d remove courier-authdaemon. This is not logical (I do not need courier at all, only postfix and mutt), so this post will help me and probably others in the future.
[update]
After hitting save I thought of an easier solution (?),
use something like
echo 'function maildirmake { mkdir -p "$1"/{cur,new,tmp}; chmod -R 700 "$1";}' >> ~/.bashrc
[/update]
[Permalink] -- Filed under: [linux]
Away
Linux and 64 bit computers are a good combination. The first linux 64 bit support dates from 1995. To be able to compile everything from source really helps supporting a platform. Windows mostly runs 32 bit programs at this moment, because proprietary software vendors (which account for most windows software) are not really fast in releasing new versions. Not all is well for linux though. Macromedia Flash is such a proprietary program of which no 64 bit player exists. Now, I do not really like flash (see also a previous entry about this, but for some reason flash is used to display movies on the web. If you think that that is weird, I agree. What has a vector renderer to do with a movie codec? The masters from youtube.com can perhaps tell you; we just have to comply.
I like to watch movies, so now I have a problem... Or not? Fortunately the flash way of bringing movies is just an container trick around a normal mpeg movie, and my favorite audio/movieplayer mplayer can play them just fine.
So if you are on debian, add contrib to /etc/apt/sources.list and apt-get install iceweasel iceweasel-greasemonkey mozilla-mplayer (the mplayer plugin is broken for firefox in etch at this moment). Now you only need a way to let mozilla know how to feed the movies. This can be done with a simple script like Michael Sheldons's.
So finally I can be an ultrahip blagotuber and and bring you movies ;-)
Happy Christmas Everyone!
[Permalink] -- Filed under: [holiday] [linux] [web]