Originally Posted by Rookie1337
I'm trying to get this; so you're telling me that because a dev will code to only look in one directory when they could have the OS look everywhere I end up with incorrectly identified hardware? Why would they do that in the first place? And this means that currently there isn't one directory dedicated to just hardware code and libraries like /etc ? I enjoy doing the terminal work to look around and all but when things are all over the place I don't have the time to search each and every sub directory and file for what I need to edit because I'm also spending the time trying to figure out the things to do in that edit to get hardware working.
Regardless of the all the other hardware issues I've mentioned the GPU, webcam, and mic/audio in general I see as the only major ones to overcome. I know I'm repeating myself but those things really are a big general user concern. I feel like I've wasted time when I have to get hardware working correctly; not so much when I have to tinker around to get software working.
This mainly happens when people mess with /lib and /usr/lib. I've had scenarios where they want stuff in /usr/lib and not in /lib. Unfortunately for me at the time I was putting things in /lib manually (cause debian didn't have the right files at the time). It kept driving me crazy, so what I did was I created a new dir and merged /lib + /usr/lib and made a softlink from both /lib and /usr/lib to this new dir. BAM, everything worked. I then realized they wanted the lib files put in /usr/lib for the GLX extentions.
Now why does this seem wrong? Shouldn't the OS search both /lib and /usr/lib to report libs for a querying program? You would think so, that the program should ask the OS for libs/files and the OS reports yes or no and points the program in the right direction. This is how MS works, though they don't have userspace/system differences. Unfortunately this isn't how Linux runs. It's much quicker to compile and run a program to search in a specific area. If the maintainer of a driver or piece of hardware decides he wants all his files put into /usr/lib for security reasons and the distro doesn't default you then get broken crap. That becomes the problem. My nvidia drivers might be installed in /lib, as they should be. Lets say a program expects my drivers to be in /usr/lib and gives me the output that my GLX is broken or non-existent (because it can't find the libs). I'm then going to think my hardware is broke, only to find out the system has things in a different order. Now, is this directly hardware? Probably not, but since the program is going to spit out a hardware error it's going to be lumped as a hardware bug.
I could do many different scenarios I've seen over the years. These don't happen nearly as often as dependency problems or simple hardware failures. This is also generally due to stuff that isn't kernel integrated or hardware features (such as GLX). Usually your hardware still works, but just crippled.
 A big reason for directly linking to locations is latency. This becomes more so with Audio, you want the lowest latency possible. You do this by removing anything that could hinter how the audio is routing. So instead of using ld you directly link to the audio files and build that into the program. ALSA had huge problems in the past with latency and some people were doing this. Though I haven't actually payed huge attention over the years, most of my problems were 5+ years ago. A lot of this has changed and people have started to do things for most hardware at a reasonable standard. Over the past 5 years or so hardware support has become amazing compared to what it was.
 Think of it this way, hardware drivers provide a front. /dev/dsp for your sound is a good example. Now lets take that /dev/dsp and use it by the system. /dev/dsp alone gives you nothing without a way to interface with that. You could do direct interface, but then we get the OSS problem of /dev/dsp being locked by whatever program was using it. Ok, so we decided to create mixing! Now through libs we have created /dev/mixer that interacts with /dev/dsp! Great you say, I can hear sound from 2 programs. What you don't know is that mixing support is dependent on libs. You get a lib failure, due to in proper structure, bad coding, hard coding things poorly, you get a hardware failure of no sound. What do you think libalsa/libasound gives you? It's there as a layer of interaction between the kernel driver (module) and the software that wants to use that driver.Edited by mushroomboy - 1/24/11 at 11:41am