ozymandias117

We're still using them on machines where performance doesn't matter

On build machines, they're on a special VLAN and don't have endpoint protection, but they only download from a protected mirror

Their ftrace hooks caused all disk usage to be serialized, making your multi-core processor single-core when doing anything I/O bound

We saw between 500% - 800% increases in build times with their software installed

without any distro or configuration caveats.

In those cases, they generally have the Ubuntu version that's supported in the specs section

Oh god. Sentinel one is horrible. If they're taking issue with your testing, you've really screwed the pooch

Somewhere around 0,0 or 1,1

There are amazing possibilities in the theoretical space, but there hasn't been enough of a breakthrough on how to practically make stable qubits on a scale to create widespread hype

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

How does one flash a ROM without unlocking the bootloader these days?

Shouldn't that break Android Verified Boot?

A pure GSI image could use a Google key, I suppose, but others shouldn't, right?

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?

eSIM requires proprietary google services to activate, so if you're planning on messing with ROMs I find physical to be easier