> > this problem seems to have been solved quite satisfactorily in Windows? quite satisfactorily to you. despite (linux) 64bit drivers for my sound hardware in 2004: - Echo took 4 years to rls 64bit windows drivers - MOTU's drivers never worked right. the reverse engineered linux stuff at least made sound without chewing 35% CPU and breaking frequently intricate tweaks, or even basic fixes/recompiles arent possible without source, so youre reduced to whining on your developer's forum.. hopefuly enough people have the same whine as you, and they decide to do something about it, and the fix arrives in some future update (that you can then pay for or use a crack) (forum-trolling) sounds more like intricate tweaking to me. intricate half-futile posturing to achieve a goal, instead of just achieving it yourself > integration packaging, distribution, > deployment, support, and fixes for major issues. Everything you observe > as a difference derives from the difference in control. this is why i use Paludis. funneling everything thru a centrla point of compilation/approval slows things down quite a bit Debian (and surely redhat, et al) slow things down even more by adapting to its weird licensing/build requriements, and frequent patch-related fiddling... a simple metadata file which contains pointers to source packages and git/hg repos is a hallmark of simplicity, i thnk. if some superismple pkgman cant ./configure&&make&&makeinstall (or scons/waf/whateveR) the upstream should fix their siht.. virtually every obscure piece of software mentioned on this list is available for installation, given the proaudio ebuild repository.. eg: paludis -i --dl-reinstall-scm always ingen will give you the latest SVN version with other SVN'd depchain items rebuilt beforehand, automagically.. [1] http://paludis.pioto.org/ [2] http://proaudio.tuxfamily.org/ _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
