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
My assumption is baseball
AAA is the best you can get in minor leagues before you move to the major leagues
without any distro or configuration caveats.
In those cases, they generally have the Ubuntu version that’s supported in the specs section
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?
eSIM requires proprietary google services to activate, so if you’re planning on messing with ROMs I find physical to be easier
It’s a strange suggestion after very recently working closely with openSUSE to ensure Leap can use the same binaries as SLE, though
It doesn’t have to, but GrapheneOS is designed around security first, privacy second, and usability third
If you install Fennec browser on it and open, e.g., https://www.learningcontainer.com/download/sample-pdf-file-for-testing/?wpdmdl=1566&refresh=6697dcd62a0141721228502
The PDF will display inside Firefox
The default web browser on GrapheneOS, Vanadium, doesn’t parse PDF’s (they’re an incredibly insecure format) and passes them off to a sandboxed, hardened app specifically for that usecase
This allows rejecting more permissions than doing it in the same process
Apple’s using Qualcomm modems, and the complaint seems to be around the modem
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 :)
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
All of the security features mentioned in the article even started from work done by GrapheneOS - they’re simply upstreamed now