That’s not what this is about. It seems like several Red Hat teams have been merged into IBM.

The ffmpeg from Flathub is a “runtime” package, intended to be used by other flatpak apps. It’s not meant for CLI use.

Flatpak apps are not added to your $PATH. They’re run with flatpak run appID. Though again, ffmpeg is not an app so it cannot be run this way. Though technically you could use it for CLI use by doing something like flatpak run --command=sh org.mozilla.firefox. This will open a shell inside the flatpak environment, which can use the ffmpeg flatpak runtime.

Though now that I think about it, it would be fun to create my own flatpak package for ffmpeg for CLI use. Should be pretty simple, it would just be a mostly empty package that relies on the ffmpeg-full flatpak runtime. Edit: and I did

The manifest is simply

id: my.custom.ffmpeg
runtime: org.freedesktop.Platform
runtime-version: '24.08'
sdk: org.freedesktop.Sdk
add-extensions:
  org.freedesktop.Platform.ffmpeg-full:
    directory: lib/ffmpeg
    version: '24.08'
    add-ld-path: .
command: ffmpeg
modules:
  - name: ffmpeg-wrapper
    buildsystem: simple
    build-commands:
      - mkdir -p /app/lib/ffmpeg
      - install -Dm755 ffmpeg.sh /app/bin/ffmpeg
    sources:
      - type: script
        dest-filename: ffmpeg.sh
        commands:
          - /usr/bin/ffmpeg "$@"
finish-args:
    - --filesystem=host

I’m not saying they’re running with special privileges, just that they’re part of the “OS”. Stuff that comes included with every system and that should not be removed.

I’m not sure what you mean with the update tooling having some “clear separation of OS from these packages”, but maybe you want to try and expand on that a bit

On FreeBSD and OpenBSD, OS upgrades are handled by the freebsd-update and syspatch commands respectively. User package installs are handled by the pkg and pkg_* commands respectively.

The pkg tools do not touch the base OS. That also helps avoiding issues like uninstalling critical system packages and makes it easier to wipe the system to a “clean” state, undoing user modifications.

It’s hard to succinctly describe the difference between BSD and Linux, but essentially, in BSD the OS is everything: kernel, tools, extensions…etc

It also certainly helps that neither FreeBSD or OpenBSD comes with desktop environments by default. That muddies the water of what is an OS package and what is a user package. If desktop environments were treated as OS packages, then it would not be possible for the users to uninstall the DE apps.

I’m worried about complexity. Traditional Linux package management isn’t perfect. Atomic distros try to address this in various ways, including but not limited to a clear separation of OS and user packages.

For example, on Fedora Silverblue you’re not meant to modify the base OS with rpm-ostree. You’re supposed to use flatpak and toolbox (homebrew and appimages are also options, but not preinstalled). But these have limitations that rpms do not.

On the BSDs, this isn’t really a problem. It manages a clear OS and user package split without the sandboxing limitations. That’s not to say that sandboxing is bad, I fully support it, but when you run into the currently unfixed limitations, it’s a pain. As an example, in the snap and flatpak versions of Chromium-based browsers, you can’t use Android’s adb tools, which I used to need when using custom OSs on my Pixel. You either have to overlay the rpm or use a non-atomic distro.

Systemd sysext is being thrown around as the solution to this problem as the way to install software that needs to be unsandboxed but without modifying the base OS. But I don’t see why instead we can’t just still be able to install RPMs on the base system, but to places like /usr/local/bin. The systemd sysext method seems like an unnecessary reliance on systemd and additional complexity. Take this for example: https://github.com/mmcnutt/Bazzite-Discover-Sys-Ext. There’s so much work being done, what what is basically just taking the existing Plasma Discover rpm and converting it into a new format.

I can’t understand this logic.

Assume as stated that a website is a copyrighted and protected. Sure, that means I can’t redistribute it to others without permission or a license. But I can’t see how me locally, privately modifying the site would be against the law. Should Crayola be sued because their crayons can be used to modify a copyrighted art piece? Is it illegal for me to watch a movie with a blue-light filter on because it modifies how the content is displayed?

Edit: After further thought, a stronger argument would be that it’s illegal (in some places) to bypass DRM protections. That’s because if I break DRM of some media (say, of a rented DVD) so that I can keep it forever, that would technically be illegal even if I never shared it with anybody else. So if a site tries to break ad blockers but an ad blocker works around that, that would be “breaking” DRM, therefore illegal. But I still find that to be an lacking argument.

Debian 12.7 is a year old. You’re supposed to upgrade to the latest version (currently 12.11) before doing the upgrade.

For fastest hardware support, you will want a rolling distribution like Arch (requires a do-it-yourself attitude) or OpenSUSE Tumbleweed (complete out of box, but some quirks, like missing codecs requires manual work). Fedora also has decent new hardware support, not rolling so not as good, but same problem as OpenSUSE Tumbleweed. You can also consider derivitives like CachyOS (Arch, but has a nice installer).

Ubuntu and Linux Mint have OK new hardware support. Twice a year they release new “hardware enablement upgrades” to bring new support.

And worst is Debian. They don’t do hardware ennoblement upgrades at all. It’s something you have to do yourself by using backports. They bring new hardware enablement by default with new releases every 2 years.

We have to wait and see if it’s really mediocre. Gnome Web certainly has performance issues, but those may be due to WebkitGTK.

Orion is not using WebkitGTK, despite using GTK and Libadwaita. Their port may not have the same performance issues.

And when I say performance issues, I don’t mean benchmarks. Gnome Web actually does pretty decent on benchmarks, but things like scrolling with a mouse just don’t feel smooth (but do with a trackpad).

This also affects dnf since OpenH264 is distributed from Cisco’s server’s, not Fedora’s.

You can follow this blog post: https://yselkowitz.github.io/blog/2025/08/12/openh264-fedora-flatpaks.html

Should be fine with option 1. Just need to install flatpak-module-tools beforehand.

I don’t believe that’s the case, according to Aeon. The state of secure boot can be measured, so if you have it enabled/disabled, you have to keep it that way or else the measurement will fail and the TPM will complain.

For Linux, the protection is weak.

But if properly implemented, it’s good. But it would be a hassle to do and would require users to register new keys and blacklist Microsoft’s.

Measured boot is a better solution for Linux. It’s decentralized and does not rely on Microsoft. It uses the TPM to “measure” various parts of the UEFI, bootloader, and OS to ensure they have not been tampered with.

Discovers talks to PackageKit, a project that attempts to abstract packaging concepts. So rather than Discover supporting dnf, apt, pacman, etc, it talks to PackageKit and that handles the lower level stuff.

But PackageKit is not perfect. It’s better to use dnf directly and use the flag for offline upgrades (for more reliable upgrades).

Maybe. The thing is that Electron is not made by Google. There’s always a chance that downstream they may still default to X11.

Chromium defaults to using X11, even on Wayland. By setting the ozone hint to auto, it will then default Wayland users to using Chromium’s Wayland backend.

Fedora Flatpaks are better in this regard. They are built entirely from Fedora rpms. When an rpm gets updated in the Fedora repos, rebuilding the flatpak will automatically pull in that updated rpm. And with flatpak’s deduplication feature, any reused vendored dependency should be perfectly deduplicated since the input is exactly the same (the rpm).

The problem just is that the repo is small, it’s affected by Fedora’s risk-averseness (so no codecs), and people don’t like them.

Yes

Gnome article on same topic: https://blogs.gnome.org/shell-dev/2024/09/20/understanding-gnome-shells-focus-stealing-prevention/

You can test the more strict focus stealing prevention on Gnome with: gsettings set org.gnome.desktop.wm.preferences focus-new-windows ‘strict’.

And to unset it: gsettings set org.gnome.desktop.wm.preferences focus-new-windows ‘smart’

Firefox should also now have proper support for it in 141, but I think for Gnome you might need to wait for a bug fix in Gnome 49:

Is there a pixel device with a jack port?

None that are still supported by GrapheneOS. But you can buy a USB-C to 3.5mm jack dongle.

My main OS is debian. How easy is to transfer data from GrapheneOS to debian and the other way round?

Pretty easy, either by cable or using an app like LocalSend (they have an apk on their Github).

Overall if you run GrapheneOS on a pixel, how many years running it and what do you think about it?

Haven’t used it in a while. I think it was cool, but was definitely more of a hassle than regular Android. The default apps are pretty barebones and feel old. Though I do still dream about replacing my iPhone with a device with GrapheneOS.