Great point! At the end of the day, the apps I want to use will decide which distro I main. Many FOSS fanatics are quick to critique Ubuntu, So they should support solutions that allow our distro to be diverse and use all the killer apps.

Laughs in support

Snickers in pipx

Sounds neat! Don’t really care much for messing with config files for hours. This is from someone who uses arch on all his systems. I’ve been in config hell for a while, I use kde now.

Yes! This is something I do on 3 of my machines. My ArchLinux Distrobox with paru works like a charm. (so far)

most likely but I’m super lazy with my pc unless I’m having hyperfocus going, so I don’t know

Agreed, but I also feel like such a thing should be included with Flatpak by default instead of leaving it to the users to solve.

Well, Flatpak always builds the aliases, so as long as the <installation>/exports/bin folder is in $PATH there’s no need to symlink.

If you’re talking specifically about having symlinks with some arbitrary name that you prefer, then that’s something you’ll have to do yourself, the Flatpak applications only provide their canonical name after all.
You could probably do something like that with inotify and a simple script though, just point it at the exports/bin folders for the installations that you care about, and set up your own mapping between canonical names and whatever names you prefer.

[Honk Honk]

Sewer Count: 999

Is compiling it yourself with the time and effort that it costs worth more than a few GB of disk space?

Then your disk is very expensive and your labor very cheap.

I mean it’s 2024. I regularly download archives that are several tens or even over 100 GB and then completely forget they’re sitting on my drive, because I don’t notice it when the drive is 4TB. Last time I cared about 10GB here and there was in the late-2000s.

flatpak has dedub, so no

TEN WHOLE GIGABYTES!! OMG WHAT ARE WE TO DO??

Based

“Intuitive UI” results in Gnome.

For the keys - do you mean something like

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 00000000 where 00000000 is replaced with the fingerprint of the key you want to fetch?

I do agree - the apt-key command is kinda dangerous because it imports keys that will be generally trusted, IIRC. So a similar command to fetch a key by fingerprint for it to be available to choose as signing keys for repositories that we configure for a single application (suite) would be nice.

I always disliked that signing keys are available for download from the same websites that have the repository. What’s the point in that? If someone can inject malicious code in the repository, they sure as hell can generate a matching signing key & sign the code with that.

Hence I always verify signing keys / fingerprints against somewhat trustworthy third parties.

What we really need though is a crowdsourced, reputation-based code review system. Where open source code is stored in git-like versioning history, and has clear documentations for each function what it should and should not do. And a reviewer can pick as little as an individual function and review the code to confirm (or refute) that the function

1. does exactly what the interface documentation claims it does
2. does nothing else
3. performs input validation (range checks etc)
4. is well-written (in terms of performance)

Then, your reputation score would increase according to other users concurring with your assessment (or decrease if people disagree), and your reputation can be used as a weighting factor in contributing to the “review thoroughness” of a code module that you reviewed. E.g.: a user with a reputation of 0.5 confirms that a module does exactly what it claims to do: Module gets review count +1, module gets new total score of +0.5, new total weight of ( combined previous weights + 0.5 ) and the average review score is “reviews total score” / “total weight”.

Something like that. And if you have a reputation of “0.9”, the review count goes +1, total score +0.9, total weight +0.9 (so the average score stays between 0 and 1).

Independent of the user reputation, the user’s review conclusion is stored as “1” (= performs as claimed) or “0” (= does not perform as claimed) for this module.

Reputation of reviewers could be calculated as the sum of all their individual review scores (at the time the reputation is needed), where the score they get is 1 minus the absolute difference between the average review score of a reviewed module and their own review conclusion.

E.g. User A concludes: module does what it claims to do: User A assessment is 1 (score for the module) User B concludes: module does NOT what it claims to do: User B assessment is 0 (score)

Module score is 0.8 (most reviewers agreed that it does what it claims to do)

User A reputation gained from their review of this module is 1 - abs( 1 - 0.8 ) = 0.8 User B reputation gained from their review of this module is 1 - abs( 0 - 0.8 ) = 0.2

If both users have previously gained a reputation of 1.0 from 10 reviews (where everyone agreed on the same assessment, thus full scores):

User A new reputation: ( 1 * 10 + 0.8 ) / 11 = 0.982 User B new reputation: ( 1 * 10 + 0.2 ) / 11 = 0.927

The basic idea being that all modules in the decentralized review database would have a review count which everyone could filter by, and find the least-reviewed modules (presumably weakest links) to focus their attention on.

If technically feasible, a decentralized database should prevent any given entity (secret services, botfarms) to falsify the overall review picture too much. I am not sure this can be accomplished - especially with the sophistication of the climate-destroying large language model technology. :/

No, because they’re not apt packages. You can, however, flatpak update them, and you don’t even need sudo since they’re installed in the user context rather than system.

Using your shared libraries is always a good thing, no? Like your distro’s packages should always have the latest security fixes and such, while flatpaks require a separate upgrade path.

Access to your entire filesystem, however, I agree with you on.

And with topgrade you can even upgrade flatpaks and your distros repos in one go

I’m now confused if they’re saying that flatpak is centrally managed or not. To me it seems centrally managed, both the flatpak ecosystem but your whole machine (repo packages, firmware, flatpak) if you use those app stores. I might’ve misunderstood what they said.

I’ve written a small script that does all the updates (repo, flatpak, docker), verified the packages, does cleanup and shows if stuff needs rebooted. Handy. That way I can do everything from one short command

Define “the OS package manager”. If the distro comes with flatpack and dnf equally, and both are invoked by the generic “get updates” tooling, then both could count as “the” update manager. They both check all apps for updates.

Odd to advocate for docker containers, they always have the app provider also on the hook for all dependencies because they always are inherently bundled. If a library has a critical bug fix, then your docker like containers will be stuck without the fix until the app provider gets around to fixing it, and app providers are highly unreliable on docker hub. Besides, update discipline among docker/podman users is generally atrocious, and given the relatively tedious nature of following updates with that ecosystem, I am not surprised. Even best case, docker style uses more disk space and more memory than any other option, apart from VM.

With respect to never having to worry about bundled dependencies with rpm/deb, third party packages bundle or statically link all the time. If they don’t, then they sometimes overwrite the OS provided dependency with an incompatible one that breaks OS packages, if the dependency is obscure enough for them not to notice other usage.

While I agree that developers (like myself) are not necessarily experts at packaging stuff, to conclude that it’s fine that a developer provides a flatpak is promoting shitty software. Whether a software should run in a jail, or within user space is a decision that - for most use cases - should be made by the user.

There is absolutely no reason not to provide software as a tar.gz source code archive with a proper makefile & documentation of dependencies - or automake configuration if that’s preferred.

From that kind of delivery, any package maintainer can easily build a distro-package.

Usually they work well enough, especially things that just involve repacking binaries (e.g. printer drivers)