I was reasonably certain, but left it open in case OP knew of some edge case where flags that are intended to be machine independent caused bugs on different architectures

-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?

For historical info - Oracle bought OpenOffice and started to close it down, so all the developers that worked on it forked it into LibreOffice

Oracle has since given OpenOffice to an open source group, Apache, but the main development still happens on LibreOffice

Well, a.out doesn’t make much sense these days.

Gotta move to .elf

Thanks! That sounds like exactly what I’d want to run mpd. I’ll check it out

For virtualization, I’m all good since I went with uBlue instead of Silverblue for now - the developer images come with lxc/lxd/qemu/libvirt :)

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 😅

When I check out the ISO for microOS, it lists microOS Kalpa as “alpha”

Is it ready to be used as a primary install?

The developer image, dx, includes rocm-hip and rocm-opencl:

https://github.com/ublue-os/bluefin/blob/main/packages.json

The packages under “dx” are the main reason I’m considering it over stock Fedora

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

The software has improved a lot since I got the phone in 2022 (I pre ordered it in 2017)

I would be willing to use it as a daily driver if it had better battery life

As the other poster said, the camera is kind of crap, but I don’t take many pictures. At least you don’t have to manually set the exposure/balance/focus to take a picture now, though

The updater has been a little flakey and I’ve just fallen back to update via command line frequently

Fairly thick, but it feels quite sturdy to me. SD card slot and headphone jack are great. Charging speed is kind of slow

Netflix is limited to 720p on Linux due to the DRM they use… maybe OP was confused because of that?

They do when Qualcomm wants to use their processors in Android phones

Qualcomm has, so far, been extremely against upstreaming drivers. Google has told them they can’t touch the kernel anymore over it

If that’s actually changing, it could be huge for a real alternative

I don’t use PIA, but /opt and /etc are both r/w in Silverblue/Kionite

I wonder if development has actually accelerated, or if this is just a change in the approach to the release/versioning process

Both.

Development has increased, but you should use your comparison from the last 2.6 release.

It stayed on 2.6.y for 8 years - that was where it got stable enough that there wasn’t some major milestone to use as a new marker for its update number

There are cool new features, but if it followed the old versioning scheme, we’d still be on 2.6 because it hasn’t (intentionally) broken the API between the kernel and userspace

Wait. He lost a finger or toe???

Edit: more seriously it’s been since 3.0 after being on 2.6 forever

there are no special landmark features or incompatibilities related to the version number change, it’s simply a way to drop an inconvenient numbering system

It used to only get bumped after a major new feature update, but it was stable enough at 2.6 that it got stuck there for 8 years, so he switched to a different update number

The comment over on hackaday pointing to it being bricked possibly being down to font licensing is funny if true

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