Quoting: GroganWell... if they were to release a "next gen" Steam Deck too soon, it would ruin the credibility of the platform.

A viable platform doesn't just run games, it has to stabilize so people can build on it. If the deck is a moving target, nobody is going to want to chase it.

Technically speaking, PC gaming as a whole is always a moving target. With new hardware that brings (sometimes) big improvements almost yearly, PC game developers are very much accustomed to following a moving target.

View this comment - View article - View full comments

Quoting: KimyrielleI belong to the 58% who still plays mostly on the desktop, but I am not parting with my Deck. It has become the device for gaming on the sofa or in bed and filled a gap for me there (I don't own a "proper" console and don't want one). I am still surprised how many recent games it can run just fine (including Hogwarts Legacies). Yes, that's probably going to change in the next few years when newer GPU generations become more widespread, but I expect the Deck to run most if not all the games I am playing for years to come.

Oof consoles. I'm glad I got away from them!

I do agree though, Steam deck is great for portable gaming or playing in otherwise off-limits locations! It should run games for many years as you say (assuming you don't get hardware failure) simply because PC games allow adjusting graphics settings and such, so anything that doesn't quite run can probably be tweaked to run at some point (with less visual quality).

The biggest plus over consoles though? All games you're playing on it now, should Deck 2 or even Deck 3 become a thing, you can still use them without needing to buy them again for the current "generation". This for me has always been a major plus of PC gaming over consoles.

View this comment - View article - View full comments

I hate that I'm saying this but.. I've lately fallen back to playing games on my desktop computer. I do have a deck, well who doesn't, but I tend to find it's just quicker to set things up on my desktop.

There is one thing I love about the Steam Deck, for every improvement that's made for games, it translates directly to desktop linux too.

So, whether you're using a deck or not, you're still benefiting from the proton/wine, mesa, vk3d and so on improvements!

View this comment - View article - View full comments

What do I think of EOS in all titles? Even on GOG? No. Just no. That would mean games would have DRM (EOS) built in, even on GOG.

That's just bad. Looks like I'll have to check closer as to what games bundle even more now.

View this comment - View article - View full comments

Now that you mention it and I had a quick listen, you must be Salad Fingers! That's awesome, did you do the voice acting or?

View this comment - View article - View full comments

Quoting: Eike

Quoting: BlackBloodRumBut rather.. the entitled gaming community. Generally being crappy as usual. For example, still, to this day, when a dev proudly announces "Hey, we're Steam deck verified", the community still sends a ton of crap and hate their way. For example, Cyberpunk 2077:

I didn't step through many pages, but aren't most people there angry about the game's quality itself and are using every chance to bitch around?

They are, but the sad part is they're also basically crapping on the deck too. Claiming it has poor performance and so on.

With that said, as a player of that game, on Linux using both Desktop & Deck, it really isn't as bad as they'd have you believe. So far my only complaints are lag after using map (restart game to fix) and extended sessions (4+ hrs) will cause it to eventually crash. Although, my own install is not a regular one (I use lots of mods). It has it's glitches, but honestly what game doesn't?

View this comment - View article - View full comments

While I agree, I feel like the Deck was successful in achieving what it aimed to do, it hasn't gone overly smoothly. However, it's not valves fault, nor any developers fault this time around.

But rather.. the entitled gaming community. Generally being crappy as usual. For example, still, to this day, when a dev proudly announces "Hey, we're Steam deck verified", the community still sends a ton of crap and hate their way. For example, Cyberpunk 2077:

https://steamcommunity.com/app/1091500/eventcomments/3772365358800523525 [External Link]

Most of the comments are:
- Misleading or incorrect regarding the decks capabilities
- Pure FUD
- Generally anti-Deck
- Some anti-linux
- Overall mocking

For it to be smoother, we need to get the community to stop effectively shitting on it for no particular reason other than "I know best, despite knowing nothing about it, so I'm just going to post some random crap comment to hate on it.", which appears to be the mind set of most of the commenters.

But why is this a problem? Simple, imagine your a game developer and you think "cool, we'll expand our customer base a bit by supporting this platform somewhat-officially as well". Then you read those responses. What would your next move be?

View this comment - View article - View full comments

Quoting: BoldosWell, majority of the discussion so far is about the technology itself: how open or not open it is, how slow/fast it is, what can/cannot be run with it etc...

But I'm missing another typical use case topic in the discussion:
The "security/trust" level of "let me install the app I need for work" things. Especially when used "professionally" as a daily workload driver within a company.

And even if not necessarily directly visible, the >security< question of things is always floating somewhere around when OS and apps are installed and run inside a company network.

And - with regards to installing apps from external stores - this usually translates into certain level of "trust": When installing the app, I do/do not trust the source that it will most probably e.g. not install malware packed with it (unless intentional -> looking at you Google & Micro$oft... :angry:). This applies especially when installing 3rd party apps, which are not usually normally available in standard official repos (.NET SDK, Rider, Pycharm, Teams, Spotify, ...)

With Snaps, I *can* have that certain level of trust, because there is a trusted (by me) publisher verification authority (Canonical) working behind the scenes, so if the package is marked as *Verified developer* e.g. Microsoft, or JetBrains or Spotify, I trust it is really them and not that proverbial "some anonymous person somewhere in Nebraska" who packaged it on his/her PC and then published it to the store with whatever hacks attached inside.

In my opinion this critical topic is totally omitted with Flatpacks/Flathub.

You're mostly correct. As it stands, it's difficult to be sure of who uploaded said Flatpak and what they have put into it, that's a problem. In fact, in the early days this is why I was hesitant with Flatpak, I liked the idea of having centralized repositories from my distribution of choice for trustworthiness and peace of mind (if you can't trust your distro packagers? Well.. good luck to ya!).

There's three potential existing solutions for this that can offer peace of mind:

1) After installing an application, manually adjust its sandbox permissions, remove any overly broad permissions such as "access all home files" and restrict its permissions to strictly what it needs. Doesn't need network access? Turn it off. Naturally you do this before launching the application for the first time.

This can be done in two ways, in KDE 5.27: System Settings -> Applications -> Flatpak Permission Settings

Without KDE or an older version of it: Flatseal

Honestly, changing these settings is always the first thing I do with new applications from Flathub.

2) Use a more trustworthy repository. Now you might be thinking "well who can you trust?". Well some distributions, such as Fedora offer their own flatpak repositories, which are curated and compiled by the project. Naturally however, being Fedora, that repository only includes FOSS software.

Honestly, if you can't trust Fedora / Redhat Developers? You might as well just give up trying to secure your Linux from them as their code is in almost every core component.

3) Don't go installing things you've never heard of, or things you're not sure if you can trust. Research it before you install it. I once knew someone who wasn't sure what dd did in detail and somehow managed to overwrite their operating system disk with an ISO file.

View this comment - View article - View full comments

Oooh.. so that's why I'm banned now. It's a bit unfair in my opinion, but okay :tongue:

View this comment - View article - View full comments

Quoting: Purple Library Guy

Quoting: sprocketThe one argument I have for Snap over Flatpak is that Snap works for CLI software and system software. As of now, Flatpak is only Userland and GUI-based software.

Um . . . I can kind of see how Flatpak might only work for userland software. And I can see how Flatpak itself might have only GUI-based installation software, and no CLI-based tool for installing Flatpaks. But I don't see how, technically, it would be possible for Flatpak to even be able to tell if the software being packaged was CLI software. I suppose it would feel weird and backwards to use a GUI to install CLI software, but I don't get how they could make that not work.

Well.. I know I'm the village idiot and all, but I'll try and explain it to as I know :tongue:

1) You can manage and install flatpak applications via CLI without any GUI software, in fact that's how I always manage them :tongue:

List of options, based on the output of: flatpak --help:

Usage:
flatpak [OPTION…] COMMAND

Builtin Commands:
Manage installed applications and runtimes
install Install an application or runtime
update Update an installed application or runtime
uninstall Uninstall an installed application or runtime
mask Mask out updates and automatic installation
pin Pin a runtime to prevent automatic removal
list List installed apps and/or runtimes
info Show info for installed app or runtime
history Show history
config Configure flatpak
repair Repair flatpak installation
create-usb Put applications or runtimes onto removable media

Find applications and runtimes
search Search for remote apps/runtimes

Manage running applications
run Run an application
override Override permissions for an application
make-current Specify default version to run
enter Enter the namespace of a running application
ps Enumerate running applications
kill Stop a running application

Manage file access
documents List exported files
document-export Grant an application access to a specific file
document-unexport Revoke access to a specific file
document-info Show information about a specific file

Manage dynamic permissions
permissions List permissions
permission-remove Remove item from permission store
permission-set Set permissions
permission-show Show app permissions
permission-reset Reset app permissions

Manage remote repositories
remotes List all configured remotes
remote-add Add a new remote repository (by URL)
remote-modify Modify properties of a configured remote
remote-delete Delete a configured remote
remote-ls List contents of a configured remote
remote-info Show information about a remote app or runtime

Build applications
build-init Initialise a directory for building
build Run a build command inside the build dir
build-finish Finish a build dir for export
build-export Export a build dir to a repository
build-bundle Create a bundle file from a ref in a local repository
build-import-bundle Import a bundle file
build-sign Sign an application or runtime
build-update-repo Update the summary file in a repository
build-commit-from Create new commit based on existing ref
repo Show information about a repo

Help Options:
-h, --help Show help options

Application Options:
--version Print version information and exit
--default-arch Print default arch and exit
--supported-arches Print supported arches and exit
--gl-drivers Print active gl drivers and exit
--installations Print paths for system installations and exit
--print-updated-env Print the updated environment needed to run flatpaks
--print-system-only Only include the system installation with --print-updated-env
-v, --verbose Show debug information, -vv for more detail
--ostree-verbose Show OSTree debug information

2) Technically you can access a flatpak applications CLI. It's a little complex. But it can be done.

For a CLI only application, you could in theory just do "flatpak run org.app.Command -o options" or stick an alias for this in your local rc file to just have "command -o options".

You can also access a shell within a flatpak applications sandbox by doing: "flatpak run --command=sh --devel org.app.Command" and so on.

Typically you'd only do this for debugging.

More on that here:
https://docs.flatpak.org/en/latest/debugging.html [External Link]

3) Often the complaint is not that flatpak cannot do CLI-only applications but rather, flatpak can't be used to install some more deeper system applications, for example a system wide daemon.

And lastly, there's lots of FUD being spread about flatpak out there by people who don't know it, use it, or understand it.

View this comment - View article - View full comments