We should not suddenly change terminology to imply that an open source game must have free assets too. It's already tough enough to get developers to understand that they can release just the program source code to their games and still keep making money on the assets, so muddying the waters even more is just plain unnecessary.

Even without free assets, releasing this software as open source provides significant longevity and preservation, not to mention opening the door to expansion and derivative works. Frankly, for that reason the people that made the software open source deserve some copies to be bought.

View this comment - View article - View full comments

I guess a potential new practice ought to be checking the hash of the tag pull against that of the release tarball to see if those release tarballs contain anything not part of the source repository. Or just building off of tags in the first place, so at least any hostile code needs to be in the source repository and thus publicly visible.

View this comment - View article - View full comments

And now not on Steam, since people weren't happy with the bundling of DLC and issues with linked accounts.

View this comment - View article - View full comments

Quoting: LoftyChecking your pc info reveals you are a gnome user and as such i expect 'i don't need any extensions' kind of reply but from what i have seen lots of gnome users do.

Actually my response is that I don't care about the flame war. How much you need to customize your DE isn't really the point of the article, the point of the article is that customizing your DE with third-party extensions, regardless of how much or how little you feel like you need to do it, exposes you to the risk of poorly written or malicious third-party code.

My comment was simply about that while the specific problem that the article was about could possibly solved, albeit with significant amounts of work, a similar problem can happen with GNOME extensions too and that solving the problem comes with caveats that some people might not find palatable.

View this comment - View article - View full comments

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