Live data from Hacker News

Linux desktop leaders unite behind Flathub app store. Here's why

zdnet.com

101–110 of 124 posts

Re: Linux desktop leaders unite behind Flathub app store. Here's why

#101

One thing I really dislike with snap/flatpak is how it breaks connectivity with other parts your system. Example, I run Ubuntu and wanted to use a smartcard for authentication in certain websites. That didn't work because Firefox is in a snap, and can not communicate with the pkcs11 libraries... To solve that I have to scrap Firefox as snap and install as debian package from PPA.

To some degree, I like this, but the experience for both to allow access is still pretty draconian. I'm not quite sure what the process is for Snap to adjust this (it might require a rebuild?), but I know for Flatpak it's common for folks to say "Use Flatseal to adjust the permissions of what the app has access to" to resolve problems like this.

In an ideal world, the application would be Flatpak or Snapcraft aware (or there'd be a middleware to intercept these calls), and ask for access to parts of the system it needs.

Re: Linux desktop leaders unite behind Flathub app store. Here's why

#102
post #29

Earlier quoted context omitted.

Once the linux world moves completely to Flatpak, that would truly help languages like C++ - whose evolution and cleanliness has been tremendously crippled by being unable to have a clean ABI break.

I know this is a controversial opinion, some would strongly disagree with me, maybe most would consider me downright wrong . But as a system designer I always thoughts (by always, I mean last ~5 years since I've been thinking about this) the misery we experience with C/C++ package management is an OS problem, not a language problem. The fact that some languages roll their own package manager like pip, npm, cargo etc…

There wasn't enough disk space to do deliver statically-linked-like apps by default in the 90s.; I think around the time Debian started I had a 386DX40 and a 1 or 2GB hard disk.

Traditional distros are able to install the same apps side-by-side, such as python2 and python3, if they put their mind to it. It is just a bit clumsy. Sounds like they didn't allow for that with your app. That's a shame, I guess you could ask or cough up a donation to help?

I generally just wait for things to get packaged in the regular distro, but it is nice to have choices.

Re: Linux desktop leaders unite behind Flathub app store. Here's why

#103
post #29

Earlier quoted context omitted.

Once the linux world moves completely to Flatpak, that would truly help languages like C++ - whose evolution and cleanliness has been tremendously crippled by being unable to have a clean ABI break.

Let me repeat a message i wrote some time ago here because i really don't think Flatpak is a good solution (note that this isn't issues from some ancient distro, this is from openSUSE Tumbleweed, this is only a few months old): -- Flatpak is awful, i tried installing software from it a few times and not only it always installs a ton of unnecessary stuff (practically an entire distro!) but also the software doesn't in…

For desktop integration, install flatseal and pass ~/.themes and other desktop directories to the flatpak app. It doesn't happen by default cause sandboxing.

Command line software does show up in CLI, just not by its short name. You have to use the fully qualified app name - com.xyz.whatever. You can make an alias if you want.

> Even worse, while there is an option to install things in the user's directory only (so i can make a separate user to try some things that i can easily delete later) not everything installs with that options and wants root access to pollute the rest of my system.

Are you talking about flatpak install --user ? Yes youre right some apps might not work with it but how is that any worse than traditional packaging.

Flatpak isn't perfect and I prefer distro packaging over everything else but it isn't feasable to have distro packaging for everything - not with the strict packaging rules most distros have atleast.

But out of snap, appimage and flatpak I'd go with Flatpak.

Re: Linux desktop leaders unite behind Flathub app store. Here's why

#104

Earlier quoted context omitted.

Let me repeat a message i wrote some time ago here because i really don't think Flatpak is a good solution (note that this isn't issues from some ancient distro, this is from openSUSE Tumbleweed, this is only a few months old): -- Flatpak is awful, i tried installing software from it a few times and not only it always installs a ton of unnecessary stuff (practically an entire distro!) but also the software doesn't in…

For desktop integration, install flatseal and pass ~/.themes and other desktop directories to the flatpak app. It doesn't happen by default cause sandboxing. Command line software does show up in CLI, just not by its short name. You have to use the fully qualified app name - com.xyz.whatever. You can make an alias if you want. > Even worse, while there is an option to install things in the user's directory only (so i…

There are workarounds for everything i mentioned, including just taking out the application binaries and placing them in /usr/local or whatever by hand. The point is that while Flatpak might solve some issues, it also introduces others.

Re: Linux desktop leaders unite behind Flathub app store. Here's why

#105
post #34

Earlier quoted context omitted.

> forwards compatibility longer than 3 years Maintaining backwards and forwards compatibility will cripple you as a lib developer. If you do it, your solution will be slower to change, and probably slower overall than a solution that breaks compatibility occasionally. So you get less contribution and small bus factor means this library is more likely to die.

On the other hand the developers who rely on your library wont need to waste time trying to play catch up with your breakage so that their programs keep doing the exact same stuff they were already doing and instead their most likely limited time (especially important for FLOSS developers, many of whom do that in their free time) will be instead put into improving what their applications actually does. In addition, e…

> In addition, even in the case the applications stop getting developed, they will keep working since their dependencies would not break and other developers can pick them up if needed, even years later.

In theory, yes. In practice due to Hyrum's law you'll have to reproduce bugged behavior because an application exploited a bug in your code. See for example SimCity Windows 95 compatibility story.

https://arstechnica.com/gadgets/2022/10/windows-95-went-the-...

Now Microsoft could afford to buy and test a wide combination of hardware and applications to ensure future compatiblity.

Re: Linux desktop leaders unite behind Flathub app store. Here's why

#107
post #5

What advantages does Flatpak offer over Nix? The only benefit(s) I see are: 1. Sandboxed applications (via containers?) - so applications you have don't technically have access to your home directories by default. That's sort of nice - but how many applications really warrant this overhead? 2. Possibly easier to write/package? That said, in Nix you pretty much just need to package once. I've not used Flatpak - can so…

Nix sounds amazing and better than everything else, but it also sounds really hardcore and not for common usage.

You have to learn a specific programming language just to use it, so the barrier is: learn to use a computer, learn to program, learn a specific language

Compare that to desktop distributions, or windows, or macOS the barrier is: learn to use a computer

Re: Linux desktop leaders unite behind Flathub app store. Here's why

#108

Earlier quoted context omitted.

AppImage is a more localized approach to Flatpak's "bundle everything" in that instead of trying to have shared libraries across different applications (Flatpak tries to share runtimes), every set of dependencies is local to the application itself. In a way it is kinda like trying to static link everything, though of course it doesn't technically use static linking - and it is really up to the developer what "everyth…

I've looked at your other comments here but I can't find elaboration on the bad parts of AppImage. I tend to agree that AppImage is the best of the available options - do you mean that the best solution would be rich system libraries that never break backwards compatibility ala Windows? And since we don't have that, AppImage is the best we can do?

Interesting enough, appimage is basically what Windows does

Re: Linux desktop leaders unite behind Flathub app store. Here's why

#109
post #8

Earlier quoted context omitted.

What do you think about Nix

Nix is the ultimate expression of this abandonment of the concept of a desktop distro. It doesn't even try to have system libraries. Nix gives up re: future shock. The entire OS is just containers. I'm sure it works fine if you only ever use popular software but as someone that's constantly compiling and adding little .c programs from the 'net to my bin/ having to manually create and specify the entire "system" libra…

You really misunderstand Nix then.

Nix is the actual and only novel solution in this space — you can just have a single flake file in your repository to make it always reproducible. It will only build/download files that are necessary, using a minimum required space.

But for this reason it can also just point you to a binary cache and you can copy the necessary data (basically just a diff of what is required dependency for running program P and your system). Just because the source is not available doesn’t mean that the dependencies can’t be explicitly specified and use some standard deps. Chances are that proprietary app will just depend on a libc you already have downloaded.

Re: Linux desktop leaders unite behind Flathub app store. Here's why

#110
post #60

Earlier quoted context omitted.

You are confusing it. Nix does not use containers.

Right. Nix is containers.

Maybe don’t double down on something you don’t understand and has been corrected about several times.
Post reply on HN