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.

VLC 4.0 will be released with a massive change in the interface...eventually.

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.

Red Hat, the world’s largest provider of open source software, would begin to reserve the source code of its flagship product, Red Hat Enterprise Linux, to paying customers only.

I think they should have done that in the first place. You can sell open source software just fine; you shouldn't be expected to make the sources public—only to those with a binary copy of your software who ask for it. Organizations that write and maintain open source software should be paid for their work.

In 1984, a researcher named Richard Stallman released a software project called GNU. Stallman licensed GNU for free, with his only stipulation that users sign an agreement called the GNU General Public License. [...] To Stallman, freedom meant no restrictions — not necessarily no costs. “Think free as in free speech, not free beer,” he is quoted as saying.

Yes. Stallman sold copies of GNU Emacs on physical media back in the day.

This article doesn't touch on the contentious issue, which is that RHEL's terms say, if you share the Red hat sources as a customer to a non-customer, Red Hat may stop serving you as a customer. The controversy isn't about cost. It's about being punished for exercising the freedoms Red Hat gives you.

Of course, SUSE and Ubuntu Enterprise have had the same terms for years. Red Hat was the outlier until now.

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

So it does! I didn't know that. Admittedly, I don't actually use that much proprietary software on Linux-based systems, so my knowledge is limited. It'd be interesting if Lightworks or DaVinci Resolve were one day distributed with Flatpak, although Blackmagic Design believes Flatpak can't handle DaVinci Resolve's needs.

But hey, a community-built Flatpak for Resolve exists already.

This is the original developer/maintainer of Sway and Wlroots' opinion on NVIDIA with regard to Wayland. This doesn't seem like an unfair opinion to me. Gamescope breaks regularly due to bugs in NVIDIA's proprietary driver; even if they know what the issue is, they can't send patches to fix it because it's proprietary. The best they can do is open a bug and beg them to fix it, which is what they do. If there's an issue on Intel or AMD, they can just send patches upstream to Mesa, and I would guess they do.

Thankfully, with the heavy active development of NVK, this might change in a few years.

Mind you, I've actually had a better experience on KDE Wayland than Xorg. Categorically...with the exception of Steam. While the games themselves play fine, the client is very glitchy. But it's a small price to pay for all the other nonsense I've had to deal with on GNOME/KDE X11.

I like Kdenlive and used it for a few months, but I also really like Lightworks. Lightworks is proprietary, but it's also a professional tool. Unlike DaVinci Resolve, it will decode and encode H.264/AAC, and most people don't need much more than that, though AV1 is also supported. The color correction tools in Lightworks are better than Kdenlive's and the cutting tools, while they take a while to get used to, are quite nice when paired with they keyboard. Best of all, Lightworks is a lot faster to startup, doesn't crash as easily and it's always responsive.

The most annoying part has to be dealing with licenses. If you use up your two licenses, you need to contact their support via email to shuffle them around. It's a great program, but this is super annoying. It also discourages you from purchasing the perpetual license because you don't want to get stuck in this situation. Mind you, their support is very friendly so I have no doubt they'd help you out, but it's an issue of needing to ask them in the first place. DaVinci Resolve's licensing system at least works perfectly fine, no matter what, or so I've heard. If you activate a new computer, it will just deactivate an old installation, and that's it. No need to wrangle customer support while everyone's on holiday...

The other professional option on GNU/Linux is DaVinci Resolve.

DaVinci Resolve is a very nice NLE at a very nice price, though proprietary. But $500 is a lot better than the $800,000 it used to cost. Annoying to install although fat-tire's containerization project is worth a look for easy installation. However, it doesn't work for my source footage, even with Studio. The free version doesn't support H.264 decode/encode or AAC decode/encode, which are the two main codecs you'll see with MP4, the most ubiquitous (and patent-encumbered) video format in the world. The Studio version supports H.264 decode/encode only with NVIDIA GPUs, but it still doesn't support AAC decode/encode. It can encode H.264 though, which will leave you with an MP4 file with no audio track.

To use DaVinci Resolve with H.264/AAC in a livable way, you need a NVIDIA GPU, you need to purchase the Studio edition, and you need to transcode your audio from AAC to something Resolve can ingest. There are scripts to automate this. Optionally, you should also purchase a third-party AAC encoder plugin for Resolve so you don't need to transcode again after rendering, assuming you're targeting H.264/AAC on render. If you're not, you can just render to Quicktime/PCM .mov.

As much as I love DaVinci Resolve, I kind of didn't think that was worth it for me at the time so I went with Lightworks which supports H.264/AAC encode fine with their Free/Paid licenses. I think I'll come back to DaVinci Resolve after 2028, when the patents for H.264 and AAC have finally expired (hopefully), and DaVinci Resolve includes decode support for AAC (hopefully). I might still use the Fusion tab for creating some VFX, but I'm trying to see if I can work with Natron first.

As for other NLEs:

• Cinelerra-GG: I quite like this editor, but damn it is particular and some things are just annoying to do. I've also heard it has color management issues... that was the main reason I stopped using it. That, and I can't actually get it to build anymore, haha. The manual is super amazing and beats out almost every other NLE mentioned here except DaVinci Resolve. It's not a bad read even for just generally learning video editing.
• Blender VSE: It works okay but the workflow is very slow and the lack of sequences (only projects) only makes things more annoying.
• Openshot: I'm not a fan of the interface and found the workflow, at least initially, slow.
• Shotcut: Seems nice enough but it didn't work for me. I forget why.
• Pitivi: It crashed the instant I tried working with 4K footage.

Edit: Olive is nice too but very early stages. Color tools are very basic. And unfortunately development is winding down.

Ah...sorry, I just realized this probably isn't the response you're looking for. But I've spent a lot of this week trying to find a professional NLE on GNU/Linux and that was what I came up with. For the record, I'm a GNOME user and I liked Kdenlive the most out of free software NLEs. I'm looking forward to the new improvements to come from the fundraiser to improve workflow!

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?