Quoting: Eike

Quoting: stretch611By helping AMD, Intel keeps regulators off its back by avoiding being labeled a monopoly. (While the current US administration is unlikely to care about monopolies, the EU does tend to take a stronger stance against them, and of course there is a lot of CPUs sold in the EU.)

I don't think so. It's not forbidden not to have competitors - it's forbidden to abuse the powers that come with it.

Or more to the point, you are not allowed to use your monopoly in order to gain traction in other markets. Now consider that Intel could be accused of doing just that with them integrating GPU:s in their CPU:s i.e. And Intel also creates motherboards, motherboard chips, NICs and so on so it's in their best interest to not have a monopoly or a monopoly like situation.

View this comment - View article - View full comments

Quoting: F.Ultra

Quoting: LinasAnybody brave enough to try it on AMD and post the results here, so I can make a risk-free purchase? ;)

Works flawless for me on my RX480 and Mesa 17.2.2

Unfortunately I hadn't tested as far as that first door where everyone else get stuck when I wrote the above. It breaks for me there as well. I wonder if any of the mesa devs would accept a steam gift of this game in order to see why it breaks on mesa at that point?! If so I have no problem providing that.

View this comment - View article - View full comments

Quoting: Luke_NukemFrom Ryan's blog:

QuoteHere's what you need to know about Nightdive: instead of shipping this in DOSBox or something, they rewrote the assembly to be portable, 64-bit clean C++11. Nightdive is hardcore like you wouldn't _believe_.

Holy shit! That's crazy... Sure, assembly is bare metal fast, if you're able to produce better code than a compiler can. Which I guess in the mid 90's probably wasn't unheard of.

Yes back in 1994 it was not problem to outperform a compiler by far. Also you basically targeted the 80486 or first Pentium processors and they contained very little of the "magic" that compilers are far more better to utilize. Since then processors have increased in complexity and compilers have gained tremendous optimizations.

View this comment - View article - View full comments

Quoting: LinasAnybody brave enough to try it on AMD and post the results here, so I can make a risk-free purchase? ;)

Works flawless for me on my RX480 and Mesa 17.2.2

View this comment - View article - View full comments

Quoting: razing32

Quoting: GuestI have never played any similar horror game but it can be a fun game.

Have you tried Lone Survivor ?

EDIT : I could swear this had linux support but cannot find any trace on GOG/Steam

AFAIK Lone Survivor was only released for linux in a Humble Bundle (that's how I got hold of it anyway).

View this comment - View article - View full comments

Quoting: razing32I don't get the Steve Balmer quote tbh

Also kinda sad this game is so broken at release and so far from what GTA was .

View video on youtube.com

View this comment - View article - View full comments

Works mostly fine here on my AMD Rx480 on Mesa-17.30.0-devel (Padoka PPA), the only thing that does not work is the cutscenes, there are sound but no video for some reason. Only 6 hours in at the moment and have not made it further than Sector 3 but oboy is this one fun piece of a game!

View this comment - View article - View full comments

Quoting: Guest

Quoting: F.UltraIf it's glibc (and not libc++) can you not do like: https://web.archive.org/web/20160107032111/http://www.trevorpounds.com/blog/?p=103 ? Should be no reason to build a GCC toolchain, just download the appropriate libc package for your distribution that contains the older version and use the info from the link.

That method is completely impractical - you would end up having hundreds of symver statements, and then it is no guarantee things would work properly. Similarly you would have to cook up the symvers for any library you wanted to build.

So then we are back to how we have always done things like this, keep a chroot around with those old versions of libs and compilers and build your stuff there. Now a days people perhaps use various containers for this instead, but I'm not there yet :)

View this comment - View article - View full comments

Quoting: GuestBy far one of the biggest issues with libs on Linux is glibc versioning. While they are not supposed to break the ABI, they frequently do. Making sure your game is compiled to use a sufficiently older version is a nightmare as well - you basically have to build your own GCC toolchain. I have found no other way of doing it.

IMO an rpath in the executable is a far better solution than manually dicking about with LD_LIBRARY_PATH. This way you would only have to have an rpath like "./libs.x86_64/" in your 64 bit executable, and "./libs.i386/" in your 32-bit one. A launch script using "arch" to identify whether the 32 or 64 bit executable should be launched takes care of the rest.

It is true that the Steam Runtime could use updating, however this would introduce problems as well for the same reason as using the system libraries introduces problems.

If it's glibc (and not libc++) can you not do like: https://web.archive.org/web/20160107032111/http://www.trevorpounds.com/blog/?p=103 ? Should be no reason to build a GCC toolchain, just download the appropriate libc package for your distribution that contains the older version and use the info from the link.

View this comment - View article - View full comments

Quoting: Guest

Quoting: F.Ultra#1 have existed on Linux since day one. This is where the semantic versioning of the shared library kicks in, unfortunately not everyone who writes shared libraries follows the rules for semantic versioning and simply put their actual version there.

No it hasn't, not as I describe. Semantic versioning is basically naming symbols in a particular way, but then the programmer has to go to a lot of effort to explicitly bind to those symbols rather than the library's default ones.

Also .so has no version number embedded in it - this is only actually ever indicate by the file name, which is arbitrary and can be modified too easily to falsify or remove this information. It would be better if it was explicitly stated inside the ELF file.

Are you talking about linking with an older version of a lib than what you have installed? Because by default the linker (when compiling) will bind to the SONAME version of the library that you have installed.

The SONAME is also not only in the filename but also stored inside the ELF file:
f.ultra@ubuntu:~$ objdump -p /usr/lib/x86_64-linux-gnu/libmysqlclient.so | grep SONAME
  SONAME               libmysqlclient.so.18

When you try to run an application linked with this on a machine which only have .so.17 or .so.19 then ldd will fail since your application needs the v18 ABI interface of this library. I don't really understand what it is that your extended version from Mach-O is supposed to do more than this anyway, it cannot make your application use v17 or v19 since it cannot know what it is that have changed in between those versions.

So I might misunderstand what you are saying, so please enlighten me!

View this comment - View article - View full comments