Interesting, will look into this. The issue is of course that these tools are optional.
But if they work, they may fix nearly many issues. Some will remain, for example many proprietary apps dont use Github releases, while these may be especially targets of fakes.
Appimages came before these tools, and the tools (forgot the name GearLever, AppimagePool is another one) came afterwards.
They are structurally better as they are external.
That verification is interesting. So it is another appimage, used to verify appimages? Are all Appimages using that, if not what percentage of the ones you know? And are tools like Gearlever enforcing or using that signature check?
You still have to give the exec permission to the appimage.
True, but this only prevents against stuff executing itself.
Mandatory access controls and sandboxes only protect the core system. Like installing packages with root.
You put things there privileged, so you know what you run comes from a protected area.
Running things from random directories (like ~/Applications which AppimagePool uses) destroys that.
Suddenly you rely on an executable home dir, which means any regular software (including appimages which are nearly impossible to sandbox) can write to the area where your programs are.
That concept is so broken that it needs to go.
I am against flatpak install --user for that reason, because no program should come from an unprivileged directory.
The issue especially is if it doesnt follow standards. ~/.local/bin is a standard, and with SELinux confined users you may be able to protect that directory. But random ones like ~/Applications that dont follow any standards, will not work.
Maybe no context menu depending on what you mean exactly
The "open with" and "create new" things. Actually,
Flatpaks cannot create "create new" entries too. I am currently experimenting with these, as it sucks to not be able to "create new Libreoffice writer document". And the xdg-templates directory doesnt do anything lol, you still need desktop entries.
but the rest are fully possible and I do it on a regular basics
The concept of an installer is that the app does that on its own. That is pretty bad and the kind of Windows crap we absolutely dont want.
But on good operating systems, a privileged package manager does all that. Puts the stuff where it belongs. Flatpak for example links the desktop entry that the app itself contains in a sandboxed directory, to the export directory where the OS sees it.
And some portal or whatever deals with the "standard apps" stuff, like that Okular Flatpak will be shown to support opening PDFs.
If apps do this on their own that means a single app can mess up your entire system, also malicious.
Appimage may have tools, I only tried AppimagePool for curiosity and the experience was pretty bad and incomplete.
But the issue is that they were just thrown out there, "here devs, do the same shit you do on Windows, it is totally normal for people to double click an executable, not have any sandboxing, deal with updates on their own, dont have any cryptographic verification, ...".
And only afterwards came the managers, the daemons, which cover a part of it.
They (could) solve:
And they often dont even do that. There are no signatures, as devs were never told "either you add a signature, or people will not install your app". So there is zero verification
But they dont solve the core issues that are:
Flatpak is similar to Android. On Android you still have a package manager but the APKs are signed individually, updates just allowed if the signatures match. So you can sideload how you want, it is still secure.
And using Obtainium, which is kind of like an AppimagePool, you can get all the apps from independend developers.
But they were told they need to follow all these rules, Appimage developers can do whatever they want.
Sorry that was long.
I see you haven't changed one bit.
Regarding what? XD
Just downloading anything from anywhere sets one up for failure/malware.
Reducing the size of the OS helps a ton here.
And mounting home read-only. I think Android and ChromeOS do that. I will experiment with that too, it is really interesting. You mainly need a different place to store user scripts, and appimages are broken (how sad), the rest should be fine.
Then a few more core concepts help too:
Flatpak helps a ton centralizing the packaging efforts. And it works. There are tons of officially supported packages. And I guess many of them will be maintained upstream.
But you still have a secure system, sandboxing, verification and packagers that keep an eye on it, kind of.
On a secure system you would need to pay a lot of people, like the typical 3-5 people that package most apps. For doing security analyses, opting-in to every new update etc.
That's strange
Seems you can use all the libraries too as if they were binaries. Updated my Fedora post.
Currently testing how to run the freedesktop.org runtime with home permission, this would allow to not give any app permanent home permission.
But wait, you can run apps with different permissions temporarily, right?
Like flatpak run --filesystem=home org.app.name
but I read the PKGBUILDs and understand them.
That is the best way but not scalable for most users. You need access control and trust. On COPR I add the repo of an individual and only get packages from them.
And programs can bypass it anyway with
/home/$USERif they're feeling vindictive, though I haven't run into any yet. It'd definitely be nice to have more complete isolation one day.
This is not about isolation, even though this should totally be done. Its just about preventing dotfile mess.
Scalable, you know. A system should stay vanilla in 20 years, in 40 years.
In the end it would be
I mean we are not there yet, but close.
I really hate
apt.
Apt is an ugly mess and nala might be python bloat but it looks fancy and automates things. Now that it runs on Debian 12 I installed it everywhere.
I really have no idea what to expect. But if I never need to use
rpmfor querying or whatever again I'll be happy.
Yeah or add curl instructions to projects like librewolf, to avoid needing "oh and on atomic distros you dont use 'dnf blabla' but download it directly".
Even though I like my COPR command...
Hmm, is that a feature or a flaw?
This should be an effect not changed icons. Maybe the taskbar still uses scaled PNGs?
Try to use a 256x256 PNG instead
A yes, the fear of opensourcing.
Trust me, proprietary code is often total garbage because nobody looks at it.
Like any other distribution with KDE software.
Kubuntu deviates from upstream, which is problematic but shows that it can be done differently.
Someone has to be the first.
Arch unstable, Fedora Rawhide, Debian Testing...
The first Plasma 6.1 update has been released yesterday.
I think I have it since a few days on Kinoite?
Plasma is not the default desktop of Fedora.
Not yet, but a close second.
noobs who should stick to defaults anyway and also not make experiments with Atomic editions either.
Noobs should absolutely use atomic editions. Totally. Every bad behavior should just break so they dont mess up.
The system is resettable which is so valuable. It has transparent changes. It has integrated backups.
But taking Fedoras defaults is difficult, as Fedora Flatpaks and Toolbox are not really great.
If you mean downloading random stuff from random websites, yes.
But they dont have installers, so no verification, no moving to locations where executing is allowed (on Linux the entire home is executable which is a huge security issue) no desktop integration, no context menu, no file associations.
Yes true, thats why it is not published on Flathub.
I will add an override to it that makes sense.