How safe it is to upgrade to Pop!_OS 24.04 by manually editing /etc/apt/sources.list (or whatever it was).

I tried doing it and running sudo apt update, and nothing suspicious seemed to appear. I used the Ubuntu 24.04 repos.

It is worth nothing that I have ran sudo apt remove with the --allow-remove-essential flag; I did it long ago to remove some "bloat".

I want to upgrade; 22.04 is so old Debian stable is more up-to-date. There are also bugs with Sway and Mangohud that I am interested in getting rid of.

I am uninterested in the Rust desktop.

It might be lack of sleep, but I can't figure this out.

I have a Label, and I want its text to be red when it represents an error, and I want it be green when it represent "good to go".

I found search result for C and maybe a solution for Python, but nothing for Rust.

I tried manually setting the css-classes property and running queue_draw(); it didn't work.

I can have a gtk::Box or a Frame that I place where the Label should go, then declare two Labels, and use set_child() to switch between them, but that seems like an ugly solution.

Do you have a solution?

SOLVED:

I have to add a "." before declaring a CSS "thing" for it to be considered a class.

Ex:

.overlay {
        background: rgba(60, 60, 60, 1);
        font-size: 25px;
}

instead of:

overlay {
        background: rgba(60, 60, 60, 1);
        font-size: 25px;)
}

Just use label.add_css_class(), label.remove_css_class() or label.set_css_classes() and make sure to properly load your CSS style sheets,

Source: the comment of d_k_bo@feddit.org

I was using Iced as a dependency, but wanted to tweak its source code for some reason, so I jumped into the folder where cargo downloads dependencies, and went into iced_wgpu 13.5 (I think that's the version).

I could make a change, then run

cargo clean -p iced_wgpu && cargo check

in my other project for instant feedback, yet it took rust_analyzer at least 5 whole minutes to stop hallucinating.

Can I disable some functionality of rust_analyzer? I only use it for jump-to-definition, linting and syntax highlighting; I don't even use autocomplete.

Setup:

• Desktop that thermally throttles only when both the IGPU and the CPU are under full load, and is cool otherwise.

• CPU: Intel I5-7500

• RAM: 8 GiB DDR-4

• Editor: NVIM v0.11.0-dev | Build type: RelWithDebInfo | LuaJIT 2.1.0-beta3 (I had the same issue with other versions as well).

TLDR

What can I disable in rust_analyzer to boost performance while maintaining jump-to-definition, linting and syntax-highlighting, or what can I do to boost rust_analyzer for big projects in general?

Another crazy idea I share with this website.

I was developing a game and an engine in Rust, so I was reading many articles, most of which criticize the 'borrow checker'.

I know that Rust is a big agenda language, and the extreme 'borrow checker' shows that, but if it weren't for the checker, Rust would be a straight-up better C++ for Game development, so I thought: "Why not just use unsafe?", but the truth is: unsafe is not ergonomic, and so is Refcell<T> so after thinking for a bit, I came up with this pattern:

let mut enemies = if cfg!(debug_assertions) {
    // We use `expect()` in debug mode as a layer of safety in order
    // to detect any possibility of undefined bahavior.
    enemies.expect("*message*");
    } else {
    // SAFETY: The `if` statement (if self.body.overlaps...) must
    // run only once, and it is the only thing that can make
    // `self.enemies == None`.
    unsafe { enemies.unwrap_unchecked() }
};

You can also use the same pattern to create a RefCell<T> clone that only does its checks in 'debug' mode, but I didn't test that; it's too much of an investment until I get feedback for the idea.

This has several benefits:

1 - No performance drawbacks, the compiler optimizes away the if statement if opt-level is 1 or more. (source: Compiler Explorer)

2 - It's as safe as expect() for all practical use cases, since you'll run the game in debug mode 1000s of times, and you'll know it doesn't produce Undefined Behavior If it doesn't crash.

You can also wrap it in a "safe" API for convenience:

// The 'U' stands for 'unsafe'.
pub trait UnwrapUExt {
    type Target;

    fn unwrap_u(self) -> Self::Target;
}

impl<T> UnwrapUExt for Option<T> {
    type Target = T;

    fn unwrap_u(self) -> Self::Target {
        if cfg!(debug_assertions) {
            self.unwrap()
        } else {
            unsafe { self.unwrap_unchecked() }
        }
    }
}

I imagine you can do many cool things with these probably-safe APIs, an example of which is macroquad's possibly unsound usage of get_context() to acquire a static mut variable.

Game development is a risky business, and while borrow-checking by default is nice, just like immutability-by-default, we shouldn't feel bad about disabling it, as forcing it upon ourselves is like forcing immutability, just like Haskell does, and while it has 100% side-effect safety, you don't use much software that's written in Haskell, do you?

Conclusion: we shouldn't fear unsafe even when it's probably unsafe, and we must remember that we're programming a computer, a machine built upon chaotic mutable state, and that our languages are but an abstraction around assembly.

I have written a calculator in Rust and libcosmic, the design is copied from gnome-calculator; I discovered 2 things:

1. I don't like working on UIs.
2. I have no idea how to transform

cosmic::widget::button::Builder

to

cosmic::widget::Button;

this code would be so much cleaner if I could return a button::standard() from a function.

The source code.

Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3.

I am in love with this awsome document; I love its guidelines, and coding conventions.

However, when Rust was introduced into the kernel, they butchered these beautiful guidelines, I know it's hard to look at such heretic actions, but you have to see this:

The default settings of rustfmt are used. This means the idiomatic Rust style is followed. For instance, 4 spaces are used for indentation rather than tabs.

How can this even relate to the ideology of the first document? I am deeply saddened by these new rules.

I know this is "The Rust experiment", but this must be fixed before it's too late! This has to reach someone.

A counter-argument might be:

The code should be formatted using rustfmt. In this way, a person contributing from time to time to the kernel does not need to learn and remember one more style guide. More importantly, reviewers and maintainers do not need to spend time pointing out style issues anymore, and thus less patch roundtrips may be needed to land a change.

And to that I say that rustfmt is configurable per project, and if it isn't, then it has to be. Doesn't something like .editorconfig exist?

Edit: I think I read enough comments to come up with a conclusion.

At first, forcing another language's code style upon another sounds backwards, but both styles are actually more similar than I originally though, the kernel's C style is just rustfmt’s default with:

• 80 character line.
• 8-space hard tabs.
• Indentation limited to 3.
• Short local-variable names.
• Having function length scale negatively with complexity.

The part about switch statements doesn't apply as Rust replaced them with match.*

The part about function brackets on new lines doesn't apply because Rust does have nested functions.

The bad part about bracket-less if statements doesn't apply as Rust doesn't support such anti-features.

The part about editor cruft is probably solved in this day & age.

The rest are either forced by the borrow checker, made obsolete by the great type system, or are just C exclusive issues that are unique to C.

I left out some parts of the standard that I do not understand.

This all turned up to be an indentation and line-size argument. Embarrassing!

*: I experimented with not-indenting the arms of the root match expression, it's surprisingly very good for simple match expressions, and feels very much like a switch, though I am not confident in recommending to people. Example:

match x {
5 => foo(),
3 => bar(),
1 => match baz(x) {
	Ok(_) => foo2(),
	Err(e) => match maybe(e) {
		Ok(_) => bar2(),
		_ => panic!(),
		}
	}
_ => panic!(),
}

I have a huge library of game EXEs on my computer, but they run at a 4:3 aspect ratio as they're old, Proton/Proton-GE/WINE-GE keep the aspect ratio and place black bars left and right, which is desireble, unlike wine who stocks them to the left side of the screen.

I am probably unqualified to speak about this, as I am using an RX 550 low profile and a 768P monitor and almost never play newer titles, but I want to kickstart a discussion, so hear me out.

The push for more realistic graphics was ongoing for longer than most of us can remember, and it made sense for most of its lifespan, as anyone who looked at an older game can confirm - I am a person who has fun making fun of weird looking 3D people.

But I feel games' graphics have reached the point of diminishing returns, AAA studios of today spend millions of dollars just to match the graphics' level of their previous titles - often sacrificing other, more important things on the way, and that people are unnecessarily spending lots of money on electricity consuming heat generating GPUs.

I understand getting an expensive GPU for high resolution, high refresh rate gaming but for 1080P? you shouldn't need anything more powerful than a 1080 TI for years. I think game studios should just slow down their graphical improvements, as they are unnecessary - in my opinion - and just prevent people with lower end systems from enjoying games, and who knows, maybe we will start seeing 50 watt gaming GPUs being viable and capable of running games at medium/high settings, going for cheap - even iGPUs render good graphics now.

TLDR: why pay for more and hurt the environment with higher power consumption when what we have is enough - and possibly overkill.

Note: it would be insane of me to claim that there is not a big difference between both pictures - Tomb Raider 2013 Vs Shadow of the Tomb raider 2018 - but can you really call either of them bad, especially the right picture (5 years old)?

Note 2: this is not much more that a discussion starter that is unlikely to evolve into something larger.

I might clean under a non-functioning button after this.

I used an old charging cable with a broken micro USB port.

My 9yr old sister felt something is preventing her leg from moving, so she used violence.

A joystick USB cable.

*Without buying - or ripping off - another USB head of course.

This might seem stupid, but hear me out.

Fallout 3 on Epic is 39 GiB, the reason for that huge size is you're forced to download all the language packs, same story for Tomb Raider and FFXIII.

As someone with a monthly data limit of 140 Gib, and who has to share it with a family, these - unnecessary - download sizes are unacceptable and make me want - and plan - to pirate the game -which even though I didn't play for I still legally own*- and only having to download 7 GiB.

I would've complained about disk space but you can just remove the extra languages conveniently located in saperate folders**.

This also applies to single player games with privacy-invasive DRM and usability-hurting DRM***, and for people who hate the idea of DRM in general.

*Own as a service and a using license.

**Unless you are tight on disk space and cannot fully download the game before removing the files.

**DOOM 2016 didn't work on Linux duo to the DRM being incompatible with proton.