Interesting. Will they be using the native engine? I've had performance issues (Vulkan ans OpenGL) and issues with the config not saving properly and opted therefore to play using DXVK since it performed better and seemed better tested. Didn't try the native one in a while though.

Would be really cool if they can get the native engine better by optimizing for the steamdeck. It's good enough with DXVK though, so not really a painpoint there.

View this comment - View article - View full comments

Quoting: XpanderStill same old GPU :( Damn those prices. I want to upgrade already.

I actually decided to buy a complete new rig, since the whole PC with a 3070Ti did cost almost the same as the card itself... and since that a half year passed.

Vendors seem to still get them at reasonable prices

Given, I did not like my old rig and I wanted a passively cooled one, all in all it did cost me about 400 more for the whole PC than buying the card itself.

Silent (heatpipe cooled), tripled the RAM which is faster, special silent case, good SSD, and a stable mainboard (my old was a real pain).

View this comment - View article - View full comments

Quoting: Samsai

Quoting: STiATIsn't that a risk and circumvents the whole idea? I mean.. you have profile.d which gets executed and could do all kind of stuff there. Even modifying the ostree...

Who's going to modify it though? You'd still need root and none of the recommended ways to install software grant root access to any installation procedure. You would have to pipe some script off the net into sudo bash and at that point the script could just dd your drive full of garbage anyway. The immutability is not primarily a security feature but a stability feature: it ensures atomic and transactional system updates so that the software is always in a consistent state.

Point taken, I still think there will need to be technology innovations or adoptions to make it really "immutable" and you can automatically mount hard drives without actually every having to touch any root file system. Or generally making really the whole root file system read only.

But I take your point about the applications, which isn't actually true with flatpak though, since they do have file access and you only need one bug there to exploit it. And as of the current state, there is no difference in flatpaks <where> in the FS they potentially could access, if they can get privileged out of the container - they are.

As a stability feature - yes, that's pretty much clear that's a good feature I'm certainly interested in. It's basically how I do treat my main system (despite driver installs - this nvidia driver :D .. but that could be installed into ostree too).

I get where they're going. Maybe not there yet 100 %, but the distinction of making it a stable base and having apps work independently of the base makes sense. I actually like the approach. Maybe too early for me to switch there yet though, I'm really not prepared to do development containers for everything I do :D.

View this comment - View article - View full comments

Quoting: ljrk

They've been continuing to rewrite various parts of the C code into much newer C++20/23.

Maybe kind of a nitpick, but to me this kind of implies that C++ would be some kind of "updated" Version of C. The next C standard is likely C23, so will it then be "more modern" than C++20?

These are simply two different languages that evolve separately although the workgroups do coordinate development together.

I think it's a matter of preference, as they state in their wiki:

Very early versions of Cemu were written mostly in the C language. This was out of habit more than any actual reason. Since then, we are continuously rewriting code to make use of new C++20/23 features. Another related task has been switching the project from a Visual Studio solution to cmake, a necessary step for porting to other OSes. We are also using the opportunity to re-think and improve the general source file and folder structure or just to clean up code from the early days.

Seems more they have switched mainly to developing in C++ and are going to switch the rest of the codebase now. I can see - depending on usecases - benefit in both languages in my projects, but I'm doomed anyway since I mostly switched to Go (mostly web API crap and automation) and Rust (for more complex stuff) for my projects.

It's always a question of preference. There may have been reasons for C++, I personally can live very well with both in my development, and I do have C and C++ projects at work, which by now start to get replaced by Go and Rust projects gradually... but it will probably take another 10 years or more until our C/C++ codebase is completely gone (since it has to make sense to actually rewrite something too).

View this comment - View article - View full comments

Quoting: Samsai

Quoting: STiATSince you are using Silverblue and I have yet to find sb else who does ... how does Silverblue do with additional disks? I mean immutable system means no writing to /etc, means not being able to add additional disks on boot time.

/etc and a few other directories (such as /home, naturally) are mounted writable. So, to mount disks you just edit /etc/fstab as you would ordinarily. Basically, Silverblue feels like just an ordinary distro up until you go to install software or run system updates. All of the regular system configuration, service management and all of that is basically the same as anywhere else.

Isn't that a risk and circumvents the whole idea? I mean.. you have profile.d which gets executed and could do all kind of stuff there. Even modifying the ostree... using systemd in example

View this comment - View article - View full comments

Quoting: Samsai...

Since you are using Silverblue and I have yet to find sb else who does ... how does Silverblue do with additional disks? I mean immutable system means no writing to /etc, means not being able to add additional disks on boot time.

Example are the two disks where my games are, spanned to one LV which I usually just mount in /mnt/data, and which holds my steam library.

I could tell ostree to actually do that.. but doing that circumvents the whole idea of Silverblue.

For all the flatpaks/snaps, I still do not think it's really ready. They made huge leaps in the past year with integration, but issues remain.

I think Nitrux is interesting too, doing basically the same but based on AppImages, but it is not immutable.. which kills the point of treating an OS as just what it is, the base, as silverblue does.

View this comment - View article - View full comments

So Valve will sponsor different hardware configurations in the CI to test? Won't cost them a lot, since they'll very likely get it for free by the vendors, but it's nice anyway to provide the testing infrastrucuture for better CI testing.

View this comment - View article - View full comments

I can see where titles which are still in active development/patch cycles are not adding it. It's additional Q&A, it's additional support they have to do.

And those are the ones who mostly have EAC still active.

If it's a finished product and they just have to do that once the incentive may be high enough to do that, and to support the Steam Deck.

For stuff like New World... I don't know, the handheld market is for sure not their target audience, and which each release they'd have to verify the steam deck build, and who ever has done some Q&A work in the past ... another platform is testing everything over twice.

View this comment - View article - View full comments

I think for binary distributions/commercial apps, AppImages actually the better choice.

But that's my opinion, I'd love a spotify AppImage...

View this comment - View article - View full comments

And there it is, the dark theme not recognized by GTK apps until session restart which annoys me every time.

I hit a few of those in the past. It's a good initiative, and I think if those bugs which are easy to encounter are fixed that's a huge benefit for a lot of users.

I really like it, and KDE will be a lot better off quality whise if they keep this effort up.

Now "all" they need to do is actually fix them, and some of those are not trivial. But I am glad they started the effort.

View this comment - View article - View full comments