deleted by creator

And “the specific resource ID” is almost certainly for localization of the text

-O2 vs -O3 adds -fgcse-after-reload -fipa-cp-clone -floop-interchange -floop-unroll-and-jam -fpeel-loops -fpredictive-commoning -fsplit-loops -fsplit-paths -ftree-loop-distribution -ftree-partial-pre -funswitch-loops -fvect-cost-model=dynamic -fversion-loops-for-strides

I don’t think any of these optimizations require more modern hardware?

The summary here and in the paper isn’t very helpful to check what CVEs are relevant

The kernels referenced aren’t supported, and it says the issues were reported upstream

Checking some of the references of the paper, it says

By the time we posted this writeup, all the distros have patched this vulnerability.

Do you know what CVEs users should check against?

Hey! Thanks!

I’ve installed Aurora to my new drive based off the comments here so far, and it’s been pretty smooth bringing my configs over :)

Immutable is new to me, so I’m wondering how you manage host daemons and cli applications, such as mpd for music and password-store for password management

Is the best practice to keep one Fedora <current release> distrobox with them?

Also, are there any issues with upgrading a distrobox to a new major release over time?

So far my mindset has been make sure I don’t layer anything, but maybe some things like mpd do make sense to layer?

I also see brew as another option. Perhaps that’s the preferred way for those types of tools? However, it seems like the system upgrade script updates distrobox and not brew?

Sorry for the rambling question - just trying to understand best practices with an immutable distro 😅

How does bluefin fit in the dependency chain here - is this just the repository that builds official uBlue images?

Part of my confusion is trying to understand how these projects are related to each other

Edit - oh, I guess bluefin is the Gnome variant

Wow! I didn’t expect sched_ext to be accepted based off historical precedent of not allowing multiple schedulers

I thought the focus would be on optimizing EEVDF now

They’re saying that it only works if your browser is installed natively and your password manager is sandboxed, which is the exact opposite of what you’d want

The browser is the vulnerable software that needs sandboxing

Both being sandboxed would be fine, too

A big thing the other comments are missing is that just running the iptables rule only works for the current boot. You need something to rerun it every restart

ufw is a front end to make it easier to use them

If you want/need more control, you should look into /etc/iptables/rules.d config files

Edit: or depending on what your distro already has, the firewalld comment makes a lot of sense. E.g. that’s Fedora’s default front end

As much as I love openSUSE, and reproducible builds are a core requirement for trusted computing…

reproducible builds were reported as being useful

Really buries the lede of the xz attack results

either both are trojaned, or none

Edit: It is very useful for the first half - to ensure new packages extracted by a compromised xz weren’t modified during the extraction.

It’s just that reproducing the build of the tampered xz would still produce a bit-for-bit identical compromised version due to the way it modified the build system

The ext4 driver can read ext2/ext3 partitions while supporting the 2038 time issue

The only change here is the driver loading the filesystem

Ext3 support is already only available through the ext4 driver

Professionally, we’ve only used Wayland in our products since 2015

Personally, I switched all my home computers to Wayland in 2021

GKI will still limit you to Google’s fork of the kernel