Slashdot Mirror
Installing/Configuring ALSA Sound Modules In Debian
GonzoJohn writes "Linux Orbit explains how: "A very common question that comes up when trying Debian GNU/Linux is how the heck do you get Advanced Linux Sound Architecture (a.k.a. ALSA) sound modules set up properly? In this HOWTO we'll show you how to compile and install the ALSA kernel modules, and then setup things using the ALSA Debian script so that modules are automatically loaded and unloaded, and your mixer levels are saved and restored on boot up. Here are some things you'll need to have before you start this HOWTO""
I spent a week getting sound to work on my system by using Google and experimenting. Then they decide to make it easy so that my accomplishment would mean nothing to all of the newbies who show up.
I can hear/see it now:
"Hey guys, do YOU have sound on your system? I do!", I exclaim, with beaming pride.
"Uh, yeah whatever dude," they would say. "I got sound working too. Dumbass."
I can no longer consider myself 1337. B-(
I have 3656.9 Bogomips. How many Bogomips do you have?
NOW look at all those Windows people giggling and pointing their fingers at us!
(Remember the airplane joke, what the linux people did...)
WARNING: Smartphones have side effects--most of them undocumented.
Wow, another gentoo post on a Debian story. Now that's something you don't see everyday.
I can't see how this is newsworthy, it's already in your /usr/share/doc/alsa-source/README.Debian.gz. And they use the far simpler make-kpkg instead of building manually with lengthy vars to define that nobody remembers. ;-)
Ok, the big news was indeed: use apt-get install alsa-source and read the manual to get alsa to work on Debian
have you been defaced today?
Why does linux make everything so damn hard. I use linux, but only because I believe in free software and right now its the only real provider capable of doing what I want to do. But it is so outdated it just bugs me. Somebody needs to take these suggestions, and actually think for a second about how much better linux would be if they were just implemented (also I have running about 4 linux desktops and 2 linux servers, so I'm not a super mega linux geek, correct me if I have an off point here):
1) Why does everything have to be compiled into the kernel. What? Can the kernel not map shared objects into its memory space? And if it can't, why not?
2) Why don't they establish only standard APIs that device drivers have to implement (seperate of the kernel and not built into some stupid x-windowing system or something irrelevant to what it does example: sound drivers for KDE), i.e.:
OpenGL - graphics library
OpenAL - audio library
insert appropriate nic standard
insert appropriate printer standard, etc. and make the stupid x-windowing system just another interface that runs on top of OpenGL, jeez.
3) The everything is a file mechanism is really getting outdated. Why are there not object oriented shells yet? Come on, just pop a javascript shell in there, make ObjectInstantiators/ObjectSerializers that detect file types and convert to the appropriate object instance, so javascript can instantiate it, use it, serialize it back to disk, and then move on.
4) Why do we still use program based architectures? Programs are way too linear. We need objects and an object handling mechanism (like javascript or something similar to it, like a Delphi UI or something) not programs. Once you make a program things get hard coded in that make it too specialized to be used in anything other than what it is designed for, if everything was just an interactive object, you could chain them together and do all sorts of neat tricks, that you could never dream of with standard file based shells/programs. And then you could serialize these object webs you create to disk for use as kind of a template(I'd say program but you could easily modify these to fit your needs). Sounds way better than standard file based scripts to me. Although javascript scripts sound nice too.
5) If we are going to be using a program/file based OS, lets make the program names intelligible. Lets see: vi, emacs, joe (joe??? what the hell man), yast, lilo, initrd, sh, etc., etc.. Come on guys name your programs something intelligible, and leave the credits in the fscking readme file. At least if dos had something it had convenient keywords (copy, rename, delete, deltree, EDIT). I realize I could make symlinks to my hearts delight, but that is only assuming you know what the program your looking for is called.
6) Why did anybody think it would be a good idea to integrate the inetd with the x-windowing system (xinetd). Yippee, all the speed of NT servers on a linux system. Of course thats assuming you use inetd to begin with.
7) This one is for the distros: quit using the damn graphical installers. Graphical installers don't make installing any faster (quite to the contrary in a lot of cases), and in installing on older hardware a lot of times it makes it nearly impossible. I'm all for straightforward installers, but you don't have to be in a graphics mode to do it (fine standard VGA modes will work)
8) Hey I got a fun idea, lets put all those binaries in one directory, with no real index as to what each of these programs with obfuscated names do, and then lets give no easy way to find out what it does short of running it. Woo! And don't say, "One word, man" or "info" those systems are pretty fucked up as it is.
9) Standardize the damn locations, follow the LSB biatches.
10) This may sound contradictory to the above, but... abolish the Unix file system layout. I can't stress enough how a simple object persistence/serialization mechanism would be way better than a file system any day. Anyways, those are just my rants/suggestions as to what needs to be changed or layered on top of the linux filesystem if they wanted it to actually be a BETTER OS than windows or MacOS.
Occam's razor is the blind faith in the natural selection of least resistance and in universal oversimplification. -- EF