I can understand MIT being an issue in some cases. For example, VSCode is a proprietary fork of the MIT open-source Code. If Microsoft wanted, they could stop publishing the MIT open source version. Of course that code would still exist as MIT, but development would slow down without Microsoft.

But I don’t see uutils being MIT as an issue. It’s primary goal is to be compatible with GNU coreutils. You can’t really rug pull a project with a goal like that. And permissively licensed utils have been around thanks to BSD and it’s never been an issue. You don’t see companies like Apple using proprietary forked versions as benefit. The “value” they add is higher up the tech stack with their own truly proprietary stuff or open stuff that encourages lock-in to its ecosystem, like Swift.

It certainly has it’s issues. Takes up quite a bit of space since each app tends ships its own copy of electron (though distros like Arch do try to make apps share a single Electron build). Apps may ship out of date versions that may have security vulnerabilities, though it’s not always the end of the world since they tend not to access outside of their own domains. As for slowness and resource usages, it’s bit of a tricky subject; an Electron app can be optimized, but will always use quite a bit of RAM.

Though undeniably they have been beneficial for Linux if only because it allows some companies to support Linux without too much extra work.

SSD is still supported, just tested Spotify and Flathub’s Electron test app in a VM with Plasma.

That’s misleading, there was a significant outlier. Gnome was on average slower, but not that much slower.

And with community maintained distros like Debian and Fedora, you kinda get the best of both worlds. You have a mostly community distro that doesn’t have corporate interests pushed on it, but have a corporation paying developers to work on it because it’s in their interest to.

I see two options.

The simpler of which is to have a wrapper script that says HOME=/custom/path/for/appimage. Apps that correctly follow xdg-specs will then put all their data in that path. But not all apps will. Apps that put stuff in /home/$USER will not use the correct location.

The more foolproof way would be using something like bubblewrap, which is used by flatpak. With bubblewrap, the sandboxing can make /home/$USER appear as /custom/path/for/appimage. However, this would take more work to setup, since I presume you want the appimages to feel unsandboxed.

It doesn’t work better or worse on Ubuntu. The fact it (partially) uses Ubuntu libraries matters very little given that the libraries are 14 years old… But I think the client now mostly relies on Debian 12 libraries to run since a year or two ago.

In this case, the DE is the main cause of issue, not the distro base.

That was a combination of the Steam client being a piece of trash (incredible complexity and technical debt*) and COSMIC. COSMIC is quite buggy when it comes to Xwayland. I’ve had plenty of issues where I close a Xwayland window, but a ghost of the window remains.

• the Steam Client runs on a combination of Ubuntu 12.04 LTS and Debian 12 libraries. It has a combination of their old VGUI code and newer Chromium GUI. It remains 32-bit and only supports X11.

Arch is quite an old distro and extremely popular. Valve could have chosen any distro, but settled on Arch.

Pixels have better security features than Samsung and doesn’t prevent you from using third party OSes.

More details here: https://grapheneos.org/faq#recommended-devices

Any program that takes in input has a greater chance of bugs that may result in security vulnerabilities. And I should hope that a text editor can take inputs…