Quoting: GOL_USERI think I've gotten in just waiting for the invite to clear. Got in through the games discussion section in steam. Seems a little too easy and you've got to wonder if Valve will shut down invites. Not sure they have the server capacity for all the people getting in...

They have the server capacity twice over.
On Valve's scale server capacity isn't a bottle neck.
Why do you think Microsoft, Google and Dropbox try to convince everyone on the planet to host their files on their cloud.
Hosting your first server is hard, but hosting ten thousand isn't significantly harder(until crowdstrike takes your system offline, but you can buy off that risk by intiating a testing server.)

This is a new game I expect it's about development and marketing resources.
The thing is still in beta and the more people use your game, the more bugs will be discovered.
A gradual release like this allows you to get user feedback and data, so you can fix the production issues before millions of people start filing the complaints.

View this comment - View article - View full comments

Quoting: CalinouI feel DXVK had such a positive impact on gaming as a whole. It did so much more than just improve the state of Linux gaming:

- Make RTX Remix possible, as it uses a fork of DXVK.
- Basically fix performance of some Windows games (mainly GTA IV, but many others also benefit). If a Windows user talks to you about DXVK, they probably tried it on GTA IV at some point. It's really that much of a requirement to enjoy that game on modern PCs :)
- Fix/reduce shader compilation stutter in some games through DXVK Async [External Link].
- Provide an easy way to run old games on modern Windows/Linux versions, with support for graphical enhancements, automatic FPS caps (to avoid gameplay issues) and so on. The recently-added D3D8 support opens this to a lot more games released in the early 2000s. dgVoodoo can also do that, but it's not open source and is more cumbersome to set up.

In the end, everyone benefitted from an initiative that was mostly designed around Linux gaming at first.

And that my friend is "the tide that lifts all boats" and one of the primary advertisements to businesses for open source and a direct effect from the third software freedom.
To quote the fsf in the third of the four software freedoms: "By doing this you can give the whole community a chance to benefit from your changes."
The designers of DXVK didn't care enough about these improvements to make them, but they refused to stop them, so they gave others the freedom to make them and now they're here.

View this comment - View article - View full comments

They modded grub.
They didn't install it, they've their own bootloader called Windows Boot Manager.
They specifically set out and changed the grub bootloader.
The grub bootloader is the indication of dual boot and microsoft has a long and frustrating history of messing with it.
They didn't need to "fix" this, it's not their product and not their problem.
Paws off pal.

View this comment - View article - View full comments

About the stability issue.
The current design of the wine release program is as such that staging is better for new breakages(new games) and that stable avoids regression(old games).

The problem with "stability" in the case of wine is that wine is inherently a patch.
All currently unimplemented features for wine are all "instability" in a certain way, especially in a wild market like video games.
As such Wine defines "stability" different than a user would experience.
Wine defines stability as: no regression. Something that worked in the past still works.
While from the user side "stability" means: "doing your primary job consistently."

View this comment - View article - View full comments

Quoting: Pyrate

Quoting: dpanterDo not use Experimental as default or as a permanent choice. It cannot be overstated or repeated enough times. Come on people.

I think you left the part where you explain what's so bad about using the Experimental version as default :wink:.

I've one argument that might be compelling to you the rest you don't believe.
It keeps the devs from experimenting.
I know that the wine staging developers refuse to start implementing a certain graphics feature, because "people treat wine staging as yet another wine release".
The problem with this is that it would be a lot of work and thus could span multiple wine releases before it gets finalized and until than users will have to content with crashy apps in staging version.

Edit:
my source [External Link]

View this comment - View article - View full comments

Quoting: dziadulewicz

Quoting: nwildner

Quoting: dziadulewicz

If you install it via the new Flatpak package from Flathub, you still need to set up some udev rules from the GitHub.

Now this is not good again for normal users; why are these "udev rules" (whatever they are) not just included with the Flatpak?

The fact here is that Oversteer do have udev rules - https://github.com/berarma/oversteer/tree/master/data/udev [External Link] - but Flatpaks do not distribute/install udev rules and that is by design - https://github.com/flatpak/flatpak/issues/961 [External Link] .As @tfk pointed out on the previous comment, udev access requires operating system admin and there is no API/ABI for the user to manipulate it.

Flatpaks use a different philosophy and they don't install stuff around normal configuration directories like `/etc`.

Also, it is hard to track `udev` rules for every existing device and software on earth in a centralized fashion, and some of them fall into more generic rules like "USB Input device" and you have to make customization that would apply to your specific device. That's why there is no curated list of udev rules for every device that exists, and it is up to the Linux Distribution providers to create a packages with specific udev rules if you think those oversteer udev rules should be bundle on every distribution

Some distros provide a really good amount of Udev rulesets for different devices. Examples:

- retroarch-autoconfig-udev-git - https://aur.archlinux.org/packages/retroarch-autoconfig-udev-git [External Link] - Rules to autoconfig usb and bluetooth gamepads for retroarch.
- nintendo-udev - https://aur.archlinux.org/packages/nintendo-udev [External Link] - Rules for joycons (and to fix controller ownership for steam). I can confirm this also works for Datafrog and 8BitDo controllers as well.

Udev rules can also be pretty destructive as well because it also depends on systemd changes. I had a 100% CPU usage experience in the past with OpenRGB keyboard backlight rules but the developer fixed it really quickly - https://gitlab.com/CalcProgrammer1/OpenRGB/-/issues/4166 [External Link] - I think this is a good reason to not bundle "by default" millions of udev rules that target specific devices.

So it will forever be an issue and manual tinkering is required? What about Snap? Udev workaround in Snaps [External Link]

I don't think, so.
I think flatpack will go the android path and ask for a specific permission.
Another thing I can see happening is a containerized udev project(sounds crap to do, but fully within the flatpack mission).

Edit: see the comment of @tfk he's more knowledgable about the subject than I'm and has a better and less complicated solution.

View this comment - View article - View full comments

Quoting: Klaas 
 Vampire Survivors_BurstDebugInformation_DoNotShip/Data/Plugins/lib_burst_generated.txt 
I wonder how many games are uploaded with that file. I've seen it many times.

:grin:It's a file specially included for reverse engineers and modders(and internal testing).
I think it's one of those debug symbol files allowing you to see find the variable names in compiled code.
Usefull stuff, but if people decide they want to play around with your program you've just made it a lot easier.

View this comment - View article - View full comments

The feature list they mentioned is also somewhat amusing

Their compatibility list is quite amusing too: c++ and OpenGL.
OpenGL is supported by essentially everybody and c++ is hard not to support in binary form(windows succeeded for some time, but it required active effort).
I think they will find more problems with their libc dependencies.

Also Apple design award winner sounds like a significant achievement, since creatives seem to be great fans of the apple platform.

View this comment - View article - View full comments

Quoting: Purple Library Guy

Quoting: LoudTechie

Quoting: 14And it's immune to CrowdStrike.

only [External Link] as a racing stripe. [External Link]

Apperantly Linux servers also encountered this issue, but for linux it was caught by the admins before it could cause an outage.
In conclusion:
Linux is pretty secure, cool and stable, but Linux servers are all those things 10 times more than Linux causes them to be, because they're being managed by Linux users.

Looking at that, it would appear that Linux was vulnerable . . . if it was running virtualized Windows with Crowdstrike on it, using VMWare. I'm not sure a vulnerability that only shows up if you're running Windows counts as a Linux vulnerability.

No the linux was virtualized and crashed.
All his "debian vms" crashed.
Meaning all his vms running debian.
There exists a native version of crowdstrike falcon for linux.

What you describe would have been much, much worse.
That would've been a vm escape exploit, a privilege escalation exploit and a kernel panic(bsod for linux) in one.

Edit:
Translated in less-nerdish the last part would bring it from a stability issue to a critical security exploit and a stability issue.

View this comment - View article - View full comments

Quoting: 14And it's immune to CrowdStrike.

only [External Link] as a racing stripe. [External Link]

Apperantly Linux servers also encountered this issue, but for linux it was caught by the admins before it could cause an outage.
In conclusion:
Linux is pretty secure, cool and stable, but Linux servers are all those things 10 times more than Linux causes them to be, because they're being managed by Linux users.

View this comment - View article - View full comments