Found out that the Flathub version apparently doesn't play nice with my RX 7600 XT when trying to use EEVEE Next, but the standalone package does work. Probably just a matter of the Mesa version in Freedesktop being slightly older than the one on my system. So, if you run into crashes, try the blender.org version.

View this comment - View article - View full comments

Let it be known that I challenge Liam to a duel! My Shining Kuneko and Ramtasm will throw you in a Binvader!

View this comment - View article - View full comments

Here's a potentially quite wild and controversial opinion. While libdecor is indeed a simple enough way to solve the client side decoration problem for games and especially since you get it for free with SDL you may as well go for it, I think with games I probably wouldn't really need those decorations if someone did omit them.

Moving a window around without decorations requires just Super pressed down and the GNOME activities view adds close buttons to windows anyway, and a quick Alt-F4 or a regional equivalent kills windows quite nicely too. Not to mention you're probably going to have an Exit button in your in-game menu anyway.

I'm sure there are probably plenty of people that would be annoyed by missing decorations though.

View this comment - View article - View full comments

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