git was created because a proprietary VCS was being a dick

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

If this is normally only used for full screen 3D, would there be a way to enable it only on fullscreen, a. la. the old unredirect full screen windows in X11?

Ironic timing https://christianselig.com/2024/10/juno-removed/

If your speedometer/tachometer is a screen instead of dials, it’s extremely likely it’s running Linux, too

So still somewhat useful in the auto space

Both GNU and GrapheneOS have staunch requirements and will accept no compromises.

This is a situation where their requirements don’t align, so they’ll never reach an agreement.

GrapheneOS, for example, is also strictly against making the Fairphone line of phones a little more secure because it doesn’t meet all of their security requirements

In this case GNU won’t certify GrapheneOS as fully open because it includes binaries that aren’t open

The FSF is more along your line of improving the situation where they can

I’d used Linux a bit out of curiosity in the Windows XP era

Windows Vista came out and was completely unusable on the computers I or anyone around me owned. It was also harder to configure than Linux and the new UI looked worse than the Linux UIs at the time

So I switched and haven’t been back to Windows since

If an attacker gets access to your system, they will be able to ensure you can’t get rid of their access

It will persist across operating system installs

However, this requires them to get access first

For whatever reason org.gtk.Gtk3theme.Breeze-Dark was deprecated

The workaround listed here: https://github.com/flathub/org.gtk.Gtk3theme.Breeze

Is to run: flatpak override --user --filesystem=xdg-config/gtk-3.0:ro

However, that exposes a little extra if you have favorite places stored

I think it works if you only expose xdg-config/gtk-3.0/colors.css, xdg-config/gtk-3.0/gtk.css, and xdg-config/gtk-3.0/settings.ini

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?

It’s a strange suggestion after very recently working closely with openSUSE to ensure Leap can use the same binaries as SLE, though

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

Gotta move to .elf

It looks like an alternative to LocalSend rather than Syncthing

For the Steam Folders, you can use Flatseal to declare other folders any Flatpak you install is allowed to access

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 :)

To expand - DirectX is a proprietary Windows solution. Any time you pick it on Linux, it will run through a translation layer

OpenGL/Vulkan are cross-platform

OpenGL is to DirectX 11 as Vulkan is to DirectX 12

Microsoft kept the same branding, but also followed in Vulkans/Metals footsteps of using lower level calls to the hardware. This makes the graphics drivers simpler, and can be way more performant because the CPU doesn’t have to do as much

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?