Wow, this is actually fairly technical unlike うぶんちゅ. SSH and X11 forwarding in the first chapter. By chapter 4 we're already exiting Vim.

In general I agree, though had something to add regarding these points:

by defaults the sandbox is pretty good

This is a rather major problem with Flatpak; the maintainer decides what permissions they need by default, not the user. The user needs to retroactively roll them back or specify global options and manually override them per-app, but that's not user-friendly at all. Though many Flatpaks do have good permissions because Flathub maintainers step in and offer suggestions before approving the Flatpak for publication, there are a number of Flatpaks that punch big holes in the sandbox; so much so that they might as well be unsandboxed.

But Bottles has a great sandbox, for instance, which is just what you'd want when running lots of proprietary Windows applications you maybe don't trust as much as your Linux-y software.

It's better than what we have with traditional packages but it can sometimes get in the way and not all beginners can easily figure out how to fix permissions issues with Flatseal. This will probably improve as we get more portals built.

some apps are less maintained and use EOL runtimes etc

Not much is different for distribution-maintained packages, either. See TheEvilSkeleton's post about how there are over 1200 unmaintained packages in the Debian repositories, and even over 400 in Arch's much smaller repositories that are outdated (!). At least Flathub applications are usually maintained by upstream, and so are usually as up to date as they can be.

not suited for some apps like terminal apps or system stuff

This isn't really true. It's only true when terminal applications need privileged access to something. Flathub ships Mesa userpace drivers and NVIDIA's proprietary userspace drivers just fine. You can package something like yt-dlp in Flatpak just fine with --filesystem=host. Hell, they've even got Neovim on Flathub. Sure, it's a little more cumbersome to type, but you can always create an alias.

Flatpak is not suitable for all graphical applications, either. Wireshark's full feature-set cannot be supported, for example.

I would add that:

• You can easily rollback Flatpaks to a previous version (even from a long time ago) with flatpak update --commit. Much harder with traditional package systems, and you'll probably need to downgrade shared libraries too.
• You get a consistent build environment with Flatpak manifests. If you want to build a newer version of a stable package you're using straight from master or with a few patches, all you really need to do is clone it from flathub/whatever, change a few lines, and it has a very high chance of building properly. No need to figure out dependencies, toolchains, or sane build options. And it's all controlled from an easy-to-read and modify file.

When my KDE screenlocker crashes on Wayland, all my monitors tell me to switch to a TTY and run a manual unlock. Which is reassuring!

NVK is looking to be a viable replacement for general desktop computing in a few months, so long as you don't need NVENC and any of the other stuff.

I have a lot to say about the Pinephone, but in the interest of not re-iterating what has been said before, I'll just say this:

Correctly inserting the SIM card was the most harrowing experience I've ever had with a phone.

The Linux Foundation and Kernel devs don't really deal with the OS layer much. This is something that would need to be implemented at the desktop environment level; like GNOME or KDE. Neither LF nor Linus Torvalds has any say over that.

This is the kind of high-quality technical discussion I don't understand a word of that rarely surfaced on reddit.

Windows users have been asking for HEVC support for years: https://bugzilla.mozilla.org/show_bug.cgi?id=1332136

7 years ago, this was the answer:

Mozilla currently has no plans to support H.265. Our focus will be on AV1.

The reason we won't support H265 has nothing to do with the difficulty in finding a decoder, or that a decoder source code is released under GPL. Those are trivial matters.

We will not support h265 video while its patent encumbered.

BTW, even today vp9 provides better results than H265.

The conversation changed to, "Firefox could at least do hardware decode support without worrying about patents, right?"

My guess is they're doing this because Chrome added HEVC hardware decoding support last year.

It seems more likely that Adobe supports Safari because Safari is the main browser on macOS. Adobe supports Windows and macOS (and I would guess a lot of their users are on macOS), so it doesn't make sense not to support it, regardless of how cumbersome that makes the codebase.

Additionally, Photoshop Web (Beta), which is available to paying customers, has the same levels of browser support.

While we're talking about history, Firefox was originally called Phoenix, then Firebird (trademark infringements), and was born from the ashes of Netscape Navigator (and the original architect behind the Mozilla project did not have much faith in the future of Mozilla and left the company/project).

Microsoft Edge was previously based on EdgeHTML, which was canned within 2 years, and is now based on Chromium. Opera used the Presto engine for a long time, but now uses Chromium, and a bunch of Opera developers used this as an excuse to split and create their own browser with their own—yeah, okay, Vivaldi uses Chromium too. There was a time when Google promoted Firefox on the front page of google.com instead of Internet Explorer. A time obviously before Google Chrome became a thing—after that, Firefox's position as "second-most popular browser" was quickly retired. It's kind of crazy Firefox ever managed to get that much market share considering it was competing with pre-installed browsers like Internet Explorer and Safari; Firefox was never pre-installed on any platform except GNU/Linux.

And Konqueror is still kind of around today. First comes the Navigator, then the Explorer, and then the Konqueror, anybody?

Raivo was never free software anyway: https://github.com/raivo-otp/ios-application/blob/master/LICENSE.md

Modification, duplication, and (re)distribution of the Services in binary or published format ("Processed Format") for any purposes and/or reasons is strictly prohibited without the explicit permission from Raivo OTP. Permission for modification, duplication, and (re)distribution of the "Service" in Processed Format can be requested via GitHub.

I usually don't mind when most packages get behind, but the one I always notice is GNOME. It's been taking longer than I would generally expect for Arch to ship a new major update for GNOME. Fedora seems to have more up-to-date packages in most areas and ships them vanilla like Arch, as well as coming with a host of other sane defaults, so I've been thinking of making the switch...soon.

I actually agree with Red Hat's decision to not make their sources publicly available to non-customers, and I think this is a good example to set for free software companies. However, this quote shows a fundamental lack of understanding of what free software is. It's not a "threat to open source companies everywhere"; it's a feature. It's the horse you rode in on.

The SFC has suggested this, and Alma Linux wrote about their understanding of Red Hat's terms, but it seems that Red Hat may terminate contracts with customers who redistribute their sources. I think that's quite nasty and very much disagree with it. Grsecurity already does this, and my opinions about that company are the same. I thought it was interesting that Red Hat didn't address this at all in their post...