Patreon Logo Support us on Patreon to keep GamingOnLinux alive. This ensures all of our main content remains free for everyone. Just good, fresh content! Alternatively, you can donate through PayPal Logo PayPal. You can also buy games using our partner links for GOG and Humble Store.
Latest Comments by F.Ultra
GTA: San Andreas is being remade (unofficially) in Unity and it supports Linux
6 Sep 2019 at 5:43 pm UTC

Quoting: Ardje
Quoting: Liam Dawe
Quoting: razing32Curios about one thing.
Won't Rockstar DMCA-nuke this into the ground ??
It requires you own the original game to play it, so they shouldn't be able to do anything. If they do and they manage to succeed, it would put basically any other similar project in a grey area: openXcom, OpenMW, OpenRA and so on.
DMCA-nuke actually means threatening with so much legal shit without even going legal, that even if you are right, it does not really matter. There are 2 ways you can defend against that: comply, or money up for the actual legal defense.
Now seriously: who is going to invest so much time and money into a legal war, just to be able to program it.
They would have zero standing with such a case since none of Rockstars copyright (The 'C' in DMCA) can be infringed with a rewrite of their game engine. They would have to prove that these guys somehow had gotten access to the source code of the original engine or that they shipped Rockstars assets (which they don't since you are required to own the original game since this new engine reads those files).

Techland update Dying Light again with a new enemy and new dockets to come
27 Aug 2019 at 12:20 pm UTC

Glad to see that they still keep supporting the game. Just hoping that they one day will fix the game breaking bugs, e.g I'm currently since a year back stuck in one of the last levels of The Following where the game crashes as soon as I get too far up in the grainary.

Goonies-inspired adventure Knights And Bikes releasing with Linux support on August 27th
12 Aug 2019 at 8:14 pm UTC Likes: 1

Quoting: Whitewolfe80Isnt double fine now owned by microsoft so is this still coming to linux ?
They are releasing it on PS4, that is by far the largest enemy for games as far as Microsoft is concerned. So this tells us that MS might have bought Double Fine and is the one paying the checks but decisions are still made by Double Fine (not saying that it will stay this way forever).

NVIDIA have released some GPU documentation on GitHub
8 Aug 2019 at 2:13 pm UTC

Quoting: TheRiddickHopefully AMD's open-source vulkan drivers can pull ahead and make some real impressive wins against NVIDIA's closed drivers in the future, that would really put the pressure on, we have seen what open-source opengl drivers have done for AMD, quite impressive.
Actually I doubt that this will happen. One of the reasons that the binary drivers are faster is that they add tons of per game optimizations and that is something that Mesa frowns upon big time so we will probably not see such work in the open drivers.

Quoting: ElectricPrism
Someone check the weather in hell, as NVIDIA seem to be opening themselves up a bit more with the release of some GPU documentation.
Indeed.

I used to be a full nvidia customer for at least 10+ years.

Then AMD did such an amazing job with their Open Source MESA Linux Driver. I switched. AMD earned my loyalty and in exchange I have built at least 6+ full AMD rigs in the last 2 years alone. Now I am looking to exclusively do AMD in laptops too because the Linux Drivers are so much better than Nvidia and more performant than Intel.

As it stands currently, AMD is a superior experience on Linux because the open source driver makes everything stable as software marches forward.

NVIDIA -- you are late to the race, AMD and Intel have already finished the open-source race. You have a lot of work to do before we are swayed to even consider your products again.

Edit:

It goes back to at least 2012 when they said they would release more docs while now it appears they are living up to that promise for helping Nouveau. -- Phoronix
Jesus Christ! Am I to understand it took 7 years for them to even begin to deliver progress on this task? They're going to have to do better than that! I want to see current-gen documentation delivered in this Fiscal Quarter. Unacceptable, at this speed I will sooner see them dethroned.
7 years is nothing for huge corporations to do stuff. In a previous workplace we had to negotiate for 10 years in order to be able to redistribute Reuters Financal News (now Refinitiv) in our system and terminal, only for them to 2 years later decide that they no longer wanted to do it.

KDE has an unpatched security issue that's been made public
8 Aug 2019 at 2:04 pm UTC

Quoting: ShmerlIsn't there some way to disable automatic launching for such files? Autoruns is such an old nasty issue, that it's surprising KDE still has it enabled by default.
It's not autorun per say, it's more like KDE can execute some scripts from the .desktop file e.g in order to determine what to display as the title if you hover over it (not 100% sure since I'm basing this on reading from the KDE site for a few seconds).

Which of course in practice turns it into autorun, but since that was never the intended purpose there is not a way to disable the feature. If the KDE devs had understood that they had actually implemented autorun I'm sure that they would not have implemented this at all. Some one with lots of time on their hand could hunt over their bugzilla and see when this feature was implemented and why, high chance is that it was due to some feature request/bug-report.

KDE has an unpatched security issue that's been made public
7 Aug 2019 at 8:34 am UTC Likes: 9

Quoting: chancho_zombiedon't read this
Spoiler, click me
[Desktop Entry]
Exec=/bin/thisisavirus

you are doomed!!
That one you have to actively click on, the problem here is the shell expansion in where you can say set the title to a dynamic value like "title[$ie]=$(/bin/thisisavirus)"

What have you been clicking on this weekend?
5 Aug 2019 at 7:59 pm UTC Likes: 2

Quoting: tuubi
Quoting: F.UltraBought and launched Mad Max so I'll guess that I'll be stuck with my computer for 100-200hours. Don't know how my employer will react though...
Took me less than 90 to get all but one of the achievements, and I wasn't exactly speedrunning. But I guess 90 hours is plenty.
I have a tendency in games like this to spend 10+ hours on infiltrating some outpost just to realise that I probably need to level up first :)

What have you been clicking on this weekend?
5 Aug 2019 at 7:58 pm UTC

Quoting: Dunc
Quoting: F.UltraBought and launched Mad Max so I'll guess that I'll be stuck with my computer for 100-200hours. Don't know how my employer will react though...
Make sure it's using Vulkan. I haven't played it in a while, so I don't know if you still need to use a beta version, but it's well worth it. It improved my experience from “playable, but a bit rough in places” to a solid 60+fps with maxed-out settings.
I think one still requires the beta branch to go Vulkan (the option is not in the launcher which AFAIK it is in the vulkan build) so I've only tested it with OpenGL so far but it flies on my Ryzen+RX480 at max settings so I haven't yet found it necessary to test the beta branch.

What have you been clicking on this weekend?
5 Aug 2019 at 10:38 am UTC Likes: 2

Bought and launched Mad Max so I'll guess that I'll be stuck with my computer for 100-200hours. Don't know how my employer will react though...

Steam Play Proton 4.11 released, a pretty huge release pulling in D9VK and a replacement for esync
31 Jul 2019 at 4:22 pm UTC Likes: 1

Quoting: EagleDelta
When Valve identified issues with multi-threaded games as Proton development was being ramped up, CodeWeavers worked on developing the "esync" patchset to address it. It worked well but it came with multiple issues. As Valve said it needed a "special setup" and can cause "file descriptor exhaustion problems in event-hungry applications", they also think it "results in extraneous spinning in the kernel". So, they're working on what they're calling fsync and suggesting changes to accommodate it in the Linux Kernel.
That is awesome, though It's probably important to have everyone temper expectations for a stable version of fsync for a while. The kernel patches were submitted, but it will probably take some time to actually get those changes into the kernel, followed by even more time waiting for Desktop distros to update/patch their own kernels with the changes.

Still cool nonetheless
Yeah the patch to the kernel have already met some resistance on LKML and there are some strange things with it as well. The reason esync was a problem was the file descriptor limit that for some applications ranged to the millions but the fsync patches for the kernel can only handle 75k objects.