Hoping that the preliminary Wayland support makes it in.
If you continue without adding the keys, you may have issues if you rely on out of tree drivers like Nvidia. Personally, I would hit continue then leave secure boot off.
You can still do MOK management when Secure Boot is off.
For Secure Boot, the kernel is “signed” with a key. During boot up, Secure Boot checks to make sure that key is valid. Most kernels are signed with Microsoft’s key that is preloaded on basically every system. However, not all kernels can be signed with Microsoft’s key; if you install a proprietary driver (which you likely selected to during the setup), to continue using secure boot you need to sign the kernel using your own key.
That’s what MOK management is for. You are adding your own key to your system to use for Secure Boot.
Personally, I just disable Secure Boot. While it does have some security benefits, it’s not worth the headache IMO.
It says that in the 9to5Linux article, not the original source. The blog post simply says “becomes ready for inclusion in the next version of Cinnamon.”
Not to say that the 9to5Linux article is wrong since Linux Mint very well could ship the new theme as an option, but not the default theme.
I don’t think this new design will be used in Linux Mint by default. I believe this is just for distros that use Cinnamon’s default theme, which is different from Linux Mint’s default theme.
But who knows, maybe it could also become default in Linux Mint.
I haven’t been able to try it yet. I only use Proton, but Valve compiles it without winewayland.
Not directly helping with SteamOS 3. But this financial support is helping Arch improve.
Safari + AdGuard + PiPifier would probably be a good combo.
I’ll change it whenever I post these.
It’s kinda ironic that theming GTK is easier when it doesn’t officially support theming. Especially when it comes to Qt flatpak apps.
Linux support is definitely moving slower than the Rust team wants, but the team and Linus are still optimistic.
Android uses forked versions of the Linux kernel, based on Linux LTS versions. They added in Rust support in 2019 and most new code since then has been written in Rust in order to avoid memory safety vulnerabilities. And memory safety vulnerabilities have been significantly down since 2019.
Now that upstream Linux is adopting Rust, we should hopefully see a similar results. Though likely slower than Google (they went all-in on Rust) while upstream Linux new code will seemingly be mainly C for the foreseeable future.
Note that this is from late July.
I think that’s just a dependency issue unrelated to the script.
I have a bash script I use to script my Silverblue install. Something like this should work.
# space-separated list of packages to install
S_RPM_PACKAGES_TO_INSTALL="pkg1 pkg2 pkg3"
# function to install the packages
dnf_install () {
sudo dnf install -y $1
}
# call to function, passing the list
dnf_install "$S_RPM_PACKAGES_TO_INSTALL"
I have it set up this way so that I just have a bunch of bash variables describing the stuff I want to install all at the top of the file, but the function definitions and calls lower down since I don’t need to see them.
It also does other things like removes packages from the system, removes some preinstalled flatpaks, installs flatpaks from Fedora Flatpaks / Flathub / gnome-nightly, and sets up gnome through a list gsettings commands.
As I use my system, I add new apps to the list I want next time I install and remove apps I don’t use.
I doubt this will have much of an effect. Compositors already implement protocols that aren’t in upstream yet.
All this really is is putting some of those protocols in a GitHub repo and giving them a nice name. Gamescope will naturally implement them because frog works on gamescope. KDE might implement a few. Gnome and wlroots probably won’t implement them because (1) Gnome prefers a more lean set of protocols and likely won’t adopt a protocol until it’s “finished” and (2) Simon Ser, the wlroots main maintainer, is very involved with upstream protocols and would rather see development happen there.
Worked on Flathub Firefox for me.
Fedora 41 is shipping the 2.99 version. And naturally will update to RC1 and later once they release.
Could you clarify your second point?