Changing things so that the global themes cannot do this kind of damage would probably demand pretty drastic changes to the theming and widget systems on KDE. It's worth noting too that installing GNOME Extensions is similarly dangerous in that extensions also have access to the user files and whatnot.

It might be possible to sandbox these things, but that will inevitably lead to these systems becoming less flexible and that will result in complaints about KDE and GNOME restricting user freedom or whatever. Maybe that'll still be worth it for themes but for widgets that'll get pretty tricky.

I guess what they can do fairly easily is more clearly communicate that a theme can run arbitrary code and you shouldn't trust just any theme, widget or extension out there. And then users also needing to obey the warning.

View this comment - View article - View full comments

Quoting: TheSHEEEPMaybe I should have mentioned it was in an Option in a Result and also containing a Mutex (or another permutation of that situation, I worked with in a REST project back then, don't fully remember), it wasn't just the simplest possible case.

 
fn make_copy(value: Option<Result<Mutex<String>, String>>) -> Option<String> {
    if let Some(option) = value {
        if let Ok(mutex) = option {
            let string = mutex.lock().expect("Failed to acquire lock");

            return Some(string.clone());
        }
    }

    return None;
}
Even in this pretty pathological case where you are nesting containers like this, it isn't exactly complicated. And all of these steps are going to be necessary anyway, you might be allowed to read-write a mutex without locking it or attempt to read a null pointer in other languages but it almost certainly is not correct. And if you are developing something that can fail then you always have the choice to `.unwrap()` or `.expect()` your problems away. As a bonus when those fail, you'll get told exactly where it failed rather than needing to go through your the core dump from your segfault.

Quoting: TheSHEEEPThe "error safety" of Rust is somewhat overrated. It's certainly safer than C, but far from "safe" safe.
So you still have to do all of the testing routines you'd do in any other language, not really saving you much time there.

You have to always do testing, but it's debatable whether you have to "do all of the testing routines" compared to other languages. In some cases you can just API design some error scenarios to be wholly unrepresentable, whereas in Java or something any object can at any point be null and you either test for how your system deals with that or you let it die. Not to mention the nature of the beast by default limits the scope of entire categories of errors. Runtime errors exist, sure, but outright crashes are rare.

Quoting: TheSHEEEPAgain, I'm not saying Rust is bad.
It's pretty good. It has very clear advantages and disadvantages. Depending on the project, I wish I was working with it instead of what it is I'm forced to use.
I'm just somewhat annoyed by (some) Rust fanboys seeing only the good bits and brushing the downsides off as "you just don't know what you're doing", is all.

I get that Rust fans can be annoying, like all programming language fans, but I disagree strongly with the notion that Rust makes things necessarily "ridiculously complicated", especially with the kind of hyperbole you were throwing around. Yes, I understand that you can write some real spaghetti with Rust but as a language it's not unique in this regard. And after a bit of time with the language you'll start to see why Rust was giving you trouble with a particular approach and you'll learn approaches that work out better. And often those approaches involve less nested containers too.

View this comment - View article - View full comments

Quoting: TheSHEEEPI once couldn't stop laughing when I made a string copy, it's like trying to thread a needle, but with both hands tied behind your back to make sure you won't accidentally poke yourself.

 
    let string1 = String::from("Hello, world!");
    let string2 = String::from(&string1);

    println!("Here they are: {} {}", string1, string2);
You can write spaghetti in any language, Rust enforces a couple of pretty basic rules and most times when you are actually having to thread code through unwraps and whatnot you are dealing with nullability. And sure, languages like C and C++ will let you just bulldoze your way through that, you'll probably just catch a segfault at the end. :)

View this comment - View article - View full comments

Ah, finally. Enjoyed the old version and have been waiting in case the new version might get Linux support. Happy to buy it now.

View this comment - View article - View full comments

Quoting: Kithop

Quoting: Samsai

Quoting: Kithop...really, the sound issue is because it's trying to hit ALSA natively? PulseAudio is... *checks notes*... 19 years old at this point. (GitHub issue link )

Though at least later on it sounds like it's from people using the Flatpak version instead of native - and yeah, that's the first thing I'd say for almost anyone: don't use Flatpaks for this. Use your distro's native Steam package as your first choice, and then move down the line to like, getting it direct from Valve or whatnot if they don't have one. Running Steam in Flatpak or Snap just sounds like a Bad Time. But hey, at least there's validation that the sandbox is, uh, sandboxing things!

...like your own app from a decent audio API... ;p

That's not how that works, the sandbox isn't just arbitrarily deciding to block a game from using ALSA (there's a bunch of other games that also use ALSA which work just fine). And, funnily enough, I tried it out on Flatpak Steam today and it seems to work fine, sound and all.

So, it's almost like the game either had regular launch problems or some setup-specific problems, but which weren't the fault of Flatpak. So, it seems your blame was misplaced.

I've admittedly never bothered with Flatpaks at all outside of the Steam Deck, and yes, there are potentially plenty of complicating factors, but multiple people had Flatpak issues; that's all I mean to reference, there. It sounds like it wasn't blocking ALSA, but access to PipeWire, so presumably there just needs to be some updated default configs upstream somewhere.

That's after people started throwing "-sdlaudiodriver pipewire" at things, which isn't a very normal use case currently. Basically the only reason the game even has direct Pipewire support is because they use a really new version of SDL, and I bet Valve themselves have probably not tested the game with it. Most apps out there don't hit Pipewire directly but instead go through ALSA or PulseAudio. So, I am not super surprised if the Steam Flatpak doesn't expose the Pipewire socket by default because there has basically been no reason for it to do that. That'll probably change if apps start to rely on Pipewire audio, but that still seems pretty far away right now.

View this comment - View article - View full comments

Quoting: Kithop...really, the sound issue is because it's trying to hit ALSA natively? PulseAudio is... *checks notes*... 19 years old at this point. (GitHub issue link )

Though at least later on it sounds like it's from people using the Flatpak version instead of native - and yeah, that's the first thing I'd say for almost anyone: don't use Flatpaks for this. Use your distro's native Steam package as your first choice, and then move down the line to like, getting it direct from Valve or whatnot if they don't have one. Running Steam in Flatpak or Snap just sounds like a Bad Time. But hey, at least there's validation that the sandbox is, uh, sandboxing things!

...like your own app from a decent audio API... ;p

That's not how that works, the sandbox isn't just arbitrarily deciding to block a game from using ALSA (there's a bunch of other games that also use ALSA which work just fine). And, funnily enough, I tried it out on Flatpak Steam today and it seems to work fine, sound and all.

So, it's almost like the game either had regular launch problems or some setup-specific problems, but which weren't the fault of Flatpak. So, it seems your blame was misplaced.

View this comment - View article - View full comments

Quoting: dziadulewiczInspired by this tried Fedora 38. The videos still don't play on Twitch and other video platforms... Even though the codecs were checked to install. Then i tried to go to rpmfusion website as adviced to click those two links https://rpmfusion.org/Configuration:

Graphical Setup via Firefox web browser

1. First enable access to the free repository. For users of gpk (gnome package kit) or kpackagekit in Fedora that is easy and basically only one step: just click on one of the following files, depending on what distribution you use and then follow the default options that Firefox and Package Kit offer by clicking Enter a few times (¹):

RPM Fusion free for Fedora 36

RPM Fusion free for Fedora 37

this > RPM Fusion free for Fedora 38

RPM Fusion free for Fedora Rawhide

RPM Fusion free for RHEL 9 or compatible like CentOS

RPM Fusion free for RHEL 8 or compatible like CentOS

RPM Fusion free for RHEL 7 or compatible like CentOS

2. Once that succeeds, you can enable access to the nonfree repositories by clicking on one of the following files, depending on what distribution you use and then follow the default options that Firefox and Package Kit offer by clicking Enter a few times(¹):

RPM Fusion nonfree for Fedora 36

RPM Fusion nonfree for Fedora 37

and this > RPM Fusion nonfree for Fedora 38

RPM Fusion nonfree for Fedora Rawhide

RPM Fusion nonfree for RHEL 9 or compatible like CentOS

RPM Fusion nonfree for RHEL 8 or compatible like CentOS

RPM Fusion nonfree for RHEL 7 or compatible like CentOS

And it made no difference. Youtube plays videos though that's it. I don't know what is Fedora team doing but obviously something is done wrong. Of course at least the videos should play. What other tweaking is the user supposed to do to get the damn videos play?

It all comes back to non-free codecs, which Fedora won't ship because of patents and license fees. If you want to get around the problem easily just install your Firefox and other multimedia apps from Flathub and be done with it. If you want to go the more troublesome road, you follow the RPM Fusion Multimedia instructions, with the potential exception of the parts that talk about mesa-freeworld. RPM Fusion is a fast way to break something if you don't pay attention when DNF tells you that an update has broken dependencies.

Eventually the codec problem will solve itself as platforms abandon H.264/H.265 and move to AV1.

View this comment - View article - View full comments

Seems decent enough if you just need a launcher that pulls your games into one place from distinct sources. It happily discovered all my Itch, GOG and Steam games and seems to properly shell out to the correct launcher with XDG. So, kind of a launcher of launchers, which is really only useful if your library is scattered. I suppose I could also manually add a few games that I currently manage in custom app directories. Doesn't seem like it does a whole lot of actual management, but what it does it seems to do well enough.

View this comment - View article - View full comments

Quoting: damarrinIt's not his job to say why the regression happened, or rather it is only if he decides it is. It’s Canonical’s job to keep their system in shape, or put pressure on Gnome to fix their shit if the problem is on their side and can’t be fixed by others.

Well, technically it's not his job to even provide benchmarks unless he decides it is. But it certainly would be quite nice if he proposes a hypothesis he'd at least take a moment to test it, considering he'd realistically only need one of the systems switched over to a small WM or something and one test to verify it. It's hard to believe the article had to come out so quickly that there wasn't any time to set that up.

View this comment - View article - View full comments

I tried it quickly on my Fedora Silverblue 37, my full PC info is naturally in my profile.

I was positively surprised that the game ran even without me applying any containerization to it. Often tarballed binaries require some libraries that aren't installed on the base system of a Silverblue install, but this one seems to not need any. That gives a fairly strong indicator of cross-distro compatibility. I also ran it via Lutris on the Flatpak runtime and it executed there too, so people who run their Steam via Flatpak (like many do on Silverblue) should not have issues with it either.

There were only two notable issues I ran into.

First one is a minor issue that the game cannot necessarily be faulted for, which is that the game takes long enough on initial load without reacting to signals from GNOME for it to trigger the "Application is not responding" pop-up. It's not really a big deal because that happens with plenty of games and I'm not sure if Unity will allow anything to be done about it anyway. Regardless, people on GNOME generally aren't going to be too surprised by this and it's not going to be any sort of a deal-breaker. If it can be fixed though, then that's all the better.

Second issue I ran into was a weird one. Basically, if you mash escape while the game is starting it apparently doesn't load into the main menu and instead gets stuck. I repeated this a few times and I seem to be able to reproduce it consistently. If you don't touch escape during start up the game loads into the main menu without issues.

Edit: Forgot to mention that the game looks pretty cool! Kind of a blend of Jupiter Hell and Duskers, very atmospheric. Will be checking it out further on release for sure.

View this comment - View article - View full comments