Michael Larabel is not backed by a pile of money from a big company, he basically lives off monetizing Phoronix, and is notoriously strapped for cash for a long while

He works almost round the clock on articles and benchmarks to make ends meet and this unfortunately reflects on the quality of the articles.

He used to have time to even do bissections and notify devs of the exact commit that caused an issue, but it's been a few years since I last read an article where he mentions doing so.

It's unfortunate, but he's only human and very tired (measurable by how well or poorly structured his phrasing is at each article, and trending down).

I'd cut him some slack or find him some professional money backing for his work (which everyone benefits off, by the way, because performance regressions aren't that easy to spot without his approach).

View this comment - View article - View full comments

yay, I can finally try it with my incomparable (bad) gaming skills!

View this comment - View article - View full comments

Quoting: itscalledreality

Quoting: EikeFile transfer ist okish for me at the moment - device discovery is not even that. More like hot and miss. And it's still a favourite of mine. Looking forward for the improvements!

Device discovery has been a joke. When I had problems and asked why I had to readd my phone after each restart the IRC channel told me it must be how my network was configured, which was clearly just an opt out of knowing anything (typical IRC). Glad this will finally be fixed (ideally).

recent enough Android phones default to a randomized MAC address when connecting to WiFi

if KDE Connect uses MAC Addresses to identify the device,rebooting the phone (and maybe even disconnecting and reconnecting only after a while or after going to other connections) might rotate the address and make it appear as a new device

you can change this behaviour for specific memorized wifis on the phone, maybe worth trying for you home network

View this comment - View article - View full comments

Quoting: Klaas

Quoting: LanzWe really need to start holding the developers to account for low-effort ports. Too many people will buy it anyway.

But how? The Windows users will buy it anyway – most of them even if the game has an additional layer of inconvenience (AKA always online launcher) sprinkled on top.

If a huge percentage of Linux users does not buy the game due to broken promises, the developers/publisher ends up saying that it wouldn't have been worth it to spend more to satisfy such a small percentage of users.

Edit: What I should have included is that with broken promises I'm talking about the “it will run on the Steam Deck” tweet.

You maje an interesting point... i'm left wondering if "buy, try, refund if it doesn't run fine" is better for linux than "don't buy if others have issues"

but then again some devs will say they'll never do linux again because it's not worth the effort with so many open support tickets, etc

View this comment - View article - View full comments

Quoting: elgatilHere goes a funny thought. Around 1% of the users who doesn't their steam client are running Linux, SD or otherwise. But how many people got steam to play some CS or pubg or other popular game but never pay anything else? Actually, probably a lot of users simply start steam because they marked the start on boot checkbox but they don't mind it at all.

Now, the steam deck is basically a console meant to play first and foremost, most of the people who wake the device are going to play.

So it stands to reason that people using SD are going to play and buy more than the average steam user on pc.

So maybe the weight of the steam deck in the market is far superior than our sad 1%. If other developers are having similar figures it would mean we are not negligible anymore ^^

Maybe Liam could reach to some developers to ask about sd sales and check whether this is a trend or an exception? 😁

there is a common trend among devs that do linux-native game releases to see a higher-than-1% linux purchase share

there are several takes on when and why this happens... your take for the Deck is novel to my eyes, quite interesting, and left me wondering if the same might also accounts for a portion of the non-deck linux purchase's extra weight too (after all linux users are more privacy and resource-conscious than average, so the ones that do run steam might be more prone to actually buy and play too)

we do know from previous takes that linux users tend to avoid piracy and also vote with their wallets (me included) when they see linux native titles

sheers!

View this comment - View article - View full comments

Quoting: ripper81358I tried it and it worked on my end with Kubuntu 22.10 and Plasma 5.27. As of now some Apps are only working with it when installed as native packages. There seems to be a problem with universal packages (Snaps and Flatpaks) in some cases.

Developers of Electron based Apps should upgrade to newer Electron releases and enable pipewire. Pipewire runs on Wayland and X11. There are also other reasons besides linuxspecific stuff to keep Electron up to date. Older Electron releases have a very long list of security issues. This should have been fixed for a long time.

Looking at how browsers need constant and swift updates to avoid hackers,it's pretty obvious Electron apps should be using an OS-provided electron component that gets updated regardless of any effort by each electron-based app dev... but then they'd probably break all the time because those apps usually do hackish things instead of strictly adhering to standards and use browser-component version freezing as if it were a valid solution to those breakages and not a menace.

View this comment - View article - View full comments

Quoting: Linas

Quoting: MayeulC

Quoting: LinasSomething like that should really be built into Wayland.

I'm not sure if you mean screensharing or that video bridge? [...]

Should it be in XWayland? Maybe, but this modular solution is good as well.

What I mean is that there should be a way for legacy apps to continue functioning, including screen sharing. Otherwise we end up with a chicken and egg problem where people cannot switch to Wayland if their apps don't work, and apps won't support Wayland if nobody uses it.

They already can (this app is in fact proof of that), but in X.org any app could see any other app (or the entire user's screen for that matter) at any time, without explicit user consent.

It was actually barely impossible to block an app from seeing others even if you actively tried to... and that's the gaping security hole that strongly motivates the switch to Wayland.

You'll notice that the new app's dev comments on their blog that they could've even made it entirely automatic, so any app could see any other app without asking the user anything, if their solution was designed slightly different... but they chose to design it in a way that both makes things easier and still keeps you safe from silent snooping.

View this comment - View article - View full comments

Quoting: minidou

The problem is that currently in the likes of Discord, MS Teams, Slack, Zoom and others that you run through Xwayland, you may end up with a black screen and no windows listed — this should solve it.

I don't understand which case this will help that xdg-desktop-portal-wlr doesn't handle.

If you read the details you'll see their app is a convenient GUI for a non-expert user to be able to leverage what already exists (xdg-portals, pipewire, etc) through a system tray minimalist app

how do you leverage xdg-desktop-portal-wlr at the moment?

View this comment - View article - View full comments

Quoting: TheRiddickIs Zink doing performance fixing on a per Game basis? if so it may take them a few hundred years to catch up. lol

They are, but most often than not it's not really for 1 game, just a more general improvement noticed because it affects 1 game more so that is what is noticed and triggers the effort to fix/improve it

Same thing as happens with WINE, where fixed bugs are even listed in changelogs in the version they notice a reported issue was fixed, not in the version that actually fixed it (because they often only notice a change helps game Y much later than it was made to help another issue in game X)

View this comment - View article - View full comments

Quoting: slaapliedjeHa, at this point there are too many wrappers with various names. For some reason I was thinking Zink was a macOS thing, and was surprised to see the article here initially. Since macOS doesn't actually have Vulkan support directly, I was thinking translating Vulkan to OpenGL makes more sense there.

https://www.phoronix.com/news/Zink-macOS-OpenGL-Vulkan [External Link]
That's likely where I got that idea.

Native OpenGL support on MacOSX and iOS has been deprecated years ago (meaning they won't outright remove it but they won't improve it nor fix it when it breaks)

Vulkan over OpenGL is very hard because it's a more flexible API that more closely resembles how a modern GPU works internally, while OpenGL is more abstracted and high-level, so it does a lot of stuff in the background for each command... easier to ask it to do X but harder to optimize (and damn hard to make it do exactly each thing you can do in vulkan without crazy wasteful workarounds). OpenGL over Vulkan isn't easy, but it sure is much much easier than that.

MacOSX and iOS also have no Vulkan support, but their Metal API is quite similar to Vulkan so there is MoltenVK to translate Vulkan to Metal... and this works quite cleanly with mostly zero overhead, the entire vulkan featureset and no big quirks.

It works so well that using Zync to provide OpenGL over Vulkan over MoltenVK over Metal works pretty much as expected when Zync is just running over Vulkan... and it is something pretty useful to have there because of OpenGL being deprecated.

For continuously developed apps like an Office Suite Apple's pressure over app devs seems reasonable (eg: making every app use the best APIs available and etc), but for gaming it's an impossible long-term proposition (because old games frequently don't even get simple updates, much less entirely rewritten).

What makes it a bit less impossible are exactly the efforts of 3rd-party opensource devs like the ones behing Zync, MoltenVK and etc.

In that realm it's hard to not admire the stuff that's modular, stackable, fully compliant to open standards, cross-platform, open to new maintainers so the torch is passed along and almost never goes out, etc.

View this comment - View article - View full comments