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