On 14 August 2015 at 09:26, Kai Wasserbäch <kai at dev.carbon-project.org> wrote: > Emil Velikov wrote on 14.08.2015 10:17: >> On 14 August 2015 at 08:59, Kai Wasserbäch <kai at dev.carbon-project.org> >> wrote: >>> Zhou, Jammy wrote on 14.08.2015 07:59: >>>> We tried several different ways already for the enumeration interface >>>> (libpciaccess, libudev, etc). But we ran into some problems with these >>>> options for example when run Steam games which ships 32bit libraries >>>> (including libudev) in the steam runtime, so finally we decided to use >>>> sysfs directly to avoid introducing some additional dependencies into >>>> libdrm. >>> >>> The reason sounds wrong. There was a similar discussion over at Mesa. I >>> think >>> you (as in hardware/driver vendors like AMD/Intel/Nvidia) need to push >>> Valve (or >>> the game devs through Valve or directly) to fix their setup. Steam runtime >>> is >>> fine and all, but please only pre-load it, if needed (ie. library foo is >>> missing >>> on the system and can't be installed through the package manager). IIRC the >>> VMWare guys said in the Mesa discussion, they have a script in place for >>> their >>> virtualisation products, that checks whether a library needs to be loaded >>> from >>> their "baseline directory" or from the system. >>> >>> Working around a bug/design flaw in Steam's Linux version doesn't sound >>> like a >>> supportable solution in the long run. As long as you let them get away with >>> that, you will face this problem over and over with different libraries. >>> (For me >>> it's usually libstdc++ (needed by LLVM), libncurses and a few X(CB) >>> libraries I >>> need to remove from Steam, before anything works. Though I do have script >>> for >>> that, that I can run after every upgrade, this is not a solution for >>> everyone.) >>> >> Helping and applying pressure to resolve the issue is the way to go. >> But until that is resolved it's great to have a solution that does not >> lead to a crash. It feels rude towards you and other users to >> deliberately use the problematic combo and expect from you to remove >> libfoo.so. > > Well, I'd rather remove stuff from Steam's runtime than burden you and other > developers with maintaing code that is unnecessrily ugly. (Though that's > obviously just my opinion.) > >> When things get sorted out, we can easily replace this (a tad ugly >> implementation) with libudev. > > As long as you allow this behaviour by working around it, There is a saying (roughly translated to) "The wiser man always steps back". Or we could/should be like Linus - "F* you $company"
> I don't see Valve/game > developers "invest" in a real solution (because it works now). Businesses > usually only move from a position, when there's outside pressure and a clear > advantage to do so (here: no bug reports about crashing games). > There have been plenty of reports opened wrt libudev/libgcc_s/libstdc++ on their trackers and seemingly limited interest to fix things. This is a catch 20/20 afaics. "FOSS drivers do not work thus they are s**t" is how a sizeable hunk of people think. They rarely consider what the actual issue might be, because "I installed the nvidia/amd proprietary drivers and things work now". > Anyway, this was just my two cents and you can obviously decide in any way you > deem to be the best. > Personally, I'd love if there was no "options" and we can just use libfoo. Who knows Valve devs might get a wake up call and fix the problem ? -Emil P.S. Fun fact: Valve's annual "TI" Dota2 tournament managed to accumulate some 66 million USD gross income, over 100 days.
