Live data from Hacker News

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

zdnet.com

91–100 of 124 posts

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

#91

From a 2023 POV about desktop OS security running things sandboxed is a _strong must have_. Even for well curated applications, through less so. So I'm happy about the general direction here. But last time I looked at flathub (and related topics), I was quite disappointed to a point that I would say they majorly failed this. Now that was quite a while ago. But just the fact that in a non well curated app store you co…

I strongly agree. Luckily, a lot of other people do, and the ecosystem is moving towards run-time permissios ("portals") that allow users to confirm access.

It does take a while for toolkits to start using them, but AFAIK, as an example, both KDE and GNOME now transparently use portals for the file chooser dialog.

It will take more time for everything to move to newer, safer APIs (Wayland, screensharing portal, etc). The situation is much better than it was a few years ago, though.

And most frontends now display required permissions; KDE even recently integrated permission management in is system settings.

Some portals still need to be devised though, especially for device access (gamepads, webcams, etc).

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

#93
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.

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

#94
As a non-technical linux user, seeing the ecosystem move towards some sort of standard on this front is wonderful and feels long overdue. Understanding how to install (or uninstall) software is one of greatest pain points for new / non-technical linux users.

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

#95
post #69

Earlier quoted context omitted.

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…

Sorry for only reading a bit at t he top, but languages often need their own library installers not because (all) OSes are failing the package deployment, but that some OSes that the language targets doesn't. It just takes one bad OS (though really it's windows/OSX) that can't have good package managers. Why do chocolaty / brew exist? Because the os vendors aren't interested in propagating software that's not making…

On Windows the normal install method is by downloading an installer and executing it, almost nobody uses app stores or package managers. And it works great.

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

#96
post #12

Earlier quoted context omitted.

Forgive me if it seems like this question comes from a place of ignorance and misunderstanding; it probably does. Why can't we just static link everything, and distribute binaries like we're on win32?

That works on Windows because Microsoft have made a commitment to doing things that way, as an intentional moat. If you've got $$$$ of CAD software (or whatever) in binary form, which you know will work on pretty much every version of Windows but will absolutely not work on Linux or OS X - that's a good reason to stay on Windows. Microsoft is willing to do a bunch of compatibility testing etc to maintain that moat. T…

> some of those stakeholders take the opinion that closed source software can go fuck itself.

It is sadly a very common misconception that backwards compatibility is only for close source software but in reality FLOSS benefit a ton from backwards compatibility too.

Imagine for example if glibc decided to add a third parameter to fopen (ignore if it is realistic for glibc to do that, this is for the sake of argument).

The only benefit of FLOSS[0] would be that it'd be easier for someone to update it to use the third parameter instead of waiting for the original developer to do so - but still every program, FLOSS or not, would need to be updated anyway and someone would need to spend time doing that update.

A more realistic example would be GIMP: the stable releases (last was made a few weeks ago) still rely on Gtk2 and the Gtk3 port (i.e. the effort to move from Gtk2 to Gtk3) is still in beta while the Gtk devs consider it deprecated. And this is all open source, no closed source software in sight, yet see how much time was lost (not only for GIMP but for any software that relied on Gtk2 and had to switch to Gtk3, with the story repeating for Gtk4) - time that could have spent improving the actual functionality that the GIMP users use the program for - adding functionality for manipulating images - instead of using yet another approach to draw and lay out buttons, menus and checkboxes - something that was already solved back in Gtk 1.x days.

[0] actually of any source available that doesn't have a "see but don't touch" rule

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

#97

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.

You could try Flatpak and override some of the defaults. I would probably open an issue with Mozilla since they maintain at least the Flatpak. Not sure about the Snap.

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

#98

I'd rather use rpm or deb under Linux. Flatpack means potentially duplicating lots of files.

Not really. Runtimes have lots of software that is shared. If you are building a run of the mill GTK application, you probably use the GNOME runtime with no extra dependencies.

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

#99
post #89

Earlier quoted context omitted.

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…

I know this is going to sound like a stupid question, but does MuseScore run versioning control? Like can you use $sudo apt-get install musescore=4_0_2 as you can with other packages like Tenacity or Dolphin?

Sorry if it wasn't clear, this approach doesn't work since I need both versions. Besides, old versions are ultimately removed from the cache and rendered uninstallable by `pacman`. So, no that wouldn't work.

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

#100

I owned a Librem 5 phone and used it as my daily driver for a few months. During this time I exclusively used Flatpaks for my apps that I installed. After installing about 15-20 apps, the 32 GB of internal storage were completely full and my phone stopped working. I had no clue how huge Flatpak apps are. Even worse, I could not find out which apps to delete. All the space was taken up by excess "runtimes" I don't kno…

The problem is that system libraries DO solve a problem that docker recreates - the kernel can efficiently map in a virtual address range for shared libraries and then add the map to all of the tasks that are using the same library, and the disk space is minimal because you only have maybe a few copies of the same lib. For some pieces like glibc, that's huge savings system wide.

With container images you're bundling your app with exactly the libraries it needs at the exact versions you want. This means that the kernel is loading all of this auxiliary pieces for you, distinct copies, that then have to reside in their own mappings, so you get no saving there (it's actually slower in terms of program startup), and then you also are wasting tons of disk space to have all of these duplicate dependencies lying around.

Really, the idea of duplicating an entire os tree for containers is just a bad idea, and it leads to lots of super vulnerable images and destroys the whole concept of sharing a system base for performance and storage wins.

Post reply on HN