Yes. GUI stores tend to use something called PackageKit. It’s basically an abstraction layer, each package manager writes its own packagekit backend.

That way, GUI stores just have to support PackageKit rather than every single package manager. But there are bugs with PackageKit and the backends may have bugs too. Pacman’s is notoriously bad.

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

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

GrapheneOS is talking to OEMs to create a phone. Up to this point, they’ve only supported Pixels because they’ve had the best security. But with Android 16, Google stopped sharing important files that make it more difficult to continue supporting Pixels. Hence the desire to create their own device.

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

Steam is still usable. They’re just saying that running 32 bit packages on 32 bit hardware doesn’t get full support anymore.

32 bit packages are still supported on 64 bit hardware, such as for Steam.

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.

Timeshift is completely unnecessary. Fedora Atomic’s rollbacking is more powerful and avoids certain issues.

You should only be backing up personal files, not OS files. The OS is replaceable, your personal files are not.

A recovery code. I did a test install of Aeon and was given the code: dhnhlgc-fbndjbni-ufrkcfnk-nfebvtut-ftkkiiur-tijidtub-hujnucgu-erduhije

64 digits, but only alphabetical and a certain subset (16/26) due to weirdness of keyboard layouts.

TPM is used for measured boot. Measured boot can check various parts of the system to ensure they are the expected values haven’t been tampered with. You don’t want a part of the system to be replaced with malware and not realize it.

If it detects something changed, it won’t release its secret. It may signal to you that something malicious was done or something benign that the OS updated didn’t account for.

TPM unlocking FDE is complicated for me. I fully understand measured boot and support it, but it seems less secure to me than manually unlocking the disk.

Once the disk is unlocked and you’re put onto the display manager, I feel like there are many more vulnerabilities that could be exploited to gain access to your data.

With manually entering the disk password, the data is locked. You either need to brute force it or use the XKCD wrench method.

So I feel TPM+Pin is the best for security. Unfortunately Aeon, which is based on OpenSUSE and implements TPM, doesn’t support TPM+Pin. I think it’s mainly due to how poor and widespread TPM support is. It could lock you out entirely.

There’s still plenty of inefficiencies to criticize.

• Electron apps bundle an entire browser dedicated just to running the app. That takes up storage space and requires loading multiple instances of electron in memory if you’re running multiple electronic apps. Would be better if these apps could all share the same dynamically linked Chromium instance to run. Web apps are a decent alternative, but can lack desktop integration.
• Rise of interpreted languages like JavaScript, though this is mitigated by JIT compilation.