15
submitted 1 day ago* (last edited 1 day ago) by mecen@lemmy.ca to c/linux@lemmy.ml

I read it is better than flatpak/appimage/snap.

"Adapting Snap on deepin: Since Snap has many compatibility issues except for Ubuntu, we gave up.

  • Converting some of our homegrown apps to AppImage: AppImage has good portability, and these apps can easily be used on other distributions. However, it doesn't have centralized repository storage and package management, and doesn't provide the same level of sandboxing as Snap and Flatpak, so its security can't be guaranteed, and it's not suitable to be used as the default package management method for the operating system.
  • In 2017, deepin followed up the Flatpak format and completed the construction of 100+ packages, but did not continue to adapt due to the large size of the application, excessive disk
    occupation, slow bug fixing and other reasons. "

Did someone consider it as better alternative for these package formats or is this just "15 standard" for package formats because deepin wanted to make something.

Are there any distros which use it apart from deepin and which is packaged in this format, because I want to drop flatpak because it takes too much space on my system.

top 11 comments
sorted by: hot top controversial new old
[-] Bronstein_Tardigrade@lemmygrad.ml 2 points 19 hours ago

They tried Flatpak in 2017? I'm sure it is the same today as it was 9 years ago, since we know software never evolves. /s

[-] adarza@lemmy.ca 4 points 23 hours ago

from deepin? the DE that got yeeted from suse and fedora? nty.

[-] moonpiedumplings@programming.dev 7 points 1 day ago* (last edited 1 day ago)

Maybe. But they, and many others overestimate the amount of size flatpaks take up.

Flatpaks use a "runtime", a shared set of libraries and programs flatpak apps use. With one flatpak app, there is just one runtime. But with 2, 3, 10 flatpak apps, there are still only going to be 1 (to 3) runtimes on the system. This is not the same for something like appimage.

In the blog, they compare the size of deepin calculator across formats. But this is not a fair comparison. A more fair comparison would involve comparing the app size without the runtime, or comparing many apps installed.

In addition to this, if you are on btrfs, further deduplication and compression is done. This (and symlinks) won't show up in many disk and space usage analysis tools. To get a more accurate measure, use compsize instead of traditional tools. It will show you how much transparent compression (when btrfs compresses files but you can stilll access them normally), symlimks and the like are saving space.

Anyway, I am interested in more cross distro package managers though. Flatpak, docker, and nix cover a lot of things but have their annoying edge cases and paper cuts, especially in comparison to snap in some ways for some apps.

Edit: linglong appears to reuse system libraries, which would probably lead to significanr space savings at the cost of portability across distros

[-] KianaTabion@lemmy.today 4 points 1 day ago

Flatpak, docker, and nix cover a lot of things but have their annoying edge cases and paper cuts, especially in comparison to snap in some ways for some apps.

I'm still pretty new to nix - I've only recently started experimenting within a NixOS-loaded VM. So, please pardon me for my ignorance. But would you be so kind to point me towards its "annoying edge cases and paper cuts especially in comparison to snap in some ways for some apps"? Thank you in advance :) !

[-] moonpiedumplings@programming.dev 3 points 1 day ago* (last edited 1 day ago)

I use nix to get many cli apps (on arch/cachyos), but the flakes and non flakes split makes things very tough, and causes this annoying documentation split. And then certain things can only be done via flakes and vice versa.

I try to limit my use of nix to using home manager to ONLY install packages, but even then there are annoying things.

Like for example, many users may gravitate towards nix-env for installing packages, not understanding that oops, you aren't actually supposed to use nix-env. nix profile install is better and more supported, but it's flakes only. Flakes are off by default, and must explicitly be enabled because they are still "experimental" despite them being extremely popular. The official documentation is often hesitant to touch flakes because of this, so there is this horrific documentation split where a bunch of different unofficial docs cover flakes in varying manners.

Or, another thing is that nix apps on non nix distros have no gpu access/hardware acceleration. I have a home manager config to enable that: https://github.com/moonpiedumplings/home-manager/blob/main/home.nix#L32

And then I couldn't figure out how to make that work on aarch64 (asahi) so I just had to disable it,

But it is something that is insane to make someone learn how to do for just installing programs. But the latter issue doesn't affect nixos.

Anyway, I like nix. I use home manager, but for packages only, and I use it for my development environments.

[-] KianaTabion@lemmy.today 2 points 4 hours ago

Thank you very much for the elaborate answer!

If I'd have to distill your points, they mostly seem related to documention. Which is unfortunate. Would you say that's a fair take?

[-] moonpiedumplings@programming.dev 1 points 9 minutes ago

Yes. Nix is fine as long as you do "supported" things. But the moment you step outside of that, it's a nightmare and you have to be or consult an expert.

The lack of gpu acceleration is a dealbraker for making nix a flatpak alternative. And you can get it working but then it breaks the desktop integration unless you do more work and yeah.

[-] mecen@lemmy.ca 2 points 1 day ago* (last edited 1 day ago)

1 runtime is ≈1gb

24.08 1gb

2xQt 250 mb

2xGNOME 250 mb

25.08 1 gb

2xQt 250 mb

2xGNOME 250

It gets big fast.

If you have one app with outdated runtime it is additional 1 gb for just runtime. If you rely mostly on system packages most packages you install from flatpak will have additional weight of 1 gb runtime. So you can get app which weights 4mb with runtime which weight 250 more than app itself.

And other flatpak repos use other runtimes for example fedora.

Appimages weight much less but lack sandboxing.

I hadn't tried nix but it also lacks sandboxing.

[-] moonpiedumplings@programming.dev 2 points 22 hours ago

Were these numbers generated using compsize or a similar tool that asseses deduplication, symlinks, and compression properly?

I get much different numbers than I use one or the other.

gdu:

gdu ~ Use arrow keys to navigate, press ? for help

***
/var/lib/flatpak
***
    2.6 GiB ████████  ▏/runtime
  471.7 MiB █▍        ▏/app
  114.4 MiB ▎         ▏/repo
    9.1 MiB           ▏/appstream
  164.0 KiB           ▏/exports
        0 B           ▏.changed

compsize:

[moonpie@nefertem flatpak]$ sudo compsize -x /var/lib/flatpak
Processed 73225 files, 31115 regular extents (70649 refs), 35977 inline.
Type       Perc     Disk Usage   Uncompressed Referenced
TOTAL       64%      1.9G         2.9G         6.4G
none       100%      1.3G         1.3G         2.6G
zstd        35%      596M         1.6G         3.8G

Only 2 gb's are actually being used, even though some tools might be reporting 6.4 gb.

And this is with these runtimes installed:

Name                                               Application ID                                     Version                               Branch                  Installation
Freedesktop Platform                               org.freedesktop.Platform                           freedesktop-sdk-23.08.34              23.08                   system
Mesa                                               org.freedesktop.Platform.GL.default                25.0.7                                23.08                   system
Mesa (Extra)                                       org.freedesktop.Platform.GL.default                25.0.7                                23.08-extra             system
Mesa                                               org.freedesktop.Platform.GL.default                26.0.5                                25.08                   system
Mesa (Extra)                                       org.freedesktop.Platform.GL.default                26.0.5                                25.08-extra             system
Codecs Extra Extension                             org.freedesktop.Platform.codecs-extra                                                    25.08-extra             system
GNOME Application Platform version 49              org.gnome.Platform                                                                       49                      system
Breeze GTK theme                                   org.gtk.Gtk3theme.Breeze                           6.6.5                                 3.22                    system

So you can get app which weights 4mb with runtime which weight 250 more than app itself.

Except for the fact that the runtime is reused across apps, meaning that another app which uses up that runtime won't be taking up any extra space.

Appimages weight much less but lack sandboxing.

You can sandbox them with something like firejail or bubblewrap.

I hadn’t tried nix but it also lacks sandboxing.

Similar, you can sandbox with bubblewrap. But you gotta write nix code to do it because ofc:

https://github.com/fgaz/nix-bubblewrap , https://github.com/nixpak/nixpak , https://sr.ht/~alexdavid/jail.nix/

I've tried to use them before though, definitely not as easy as flatpak's flatseal sandboxing in comparison. Also, nix apps on non nix distros aren't GPU accelerated.

[-] juipeltje@lemmy.world 2 points 1 day ago* (last edited 1 day ago)

I actually didn't know this was a thing. I doubt i'd be interested in using it though. I wouldn't be surprised if this kinda goes the way of snap where pretty much only deepin is going to be using this on their distro. I'm personally sold on the nix/guix way of doing things, but i understand that's not for everyone. In the rare instance that i can't get something to work through guix or nix i like using flatpaks mainly because they work on these distros without fhs-related issues. With appimages for example they often won't run because, eventhough they claim to be portable, they do actually rely on some things being installed on your system.

[-] Parodper@foros.fediverso.gal 3 points 1 day ago* (last edited 1 day ago)

as better alternative for these formats or is this just xkcd for package formats

It can be both. But in this case I see they reuse system libraries, which goes against the idea of ending dependency hell. Apart from that, I don't see any advantage with respect to snap or flatpak.

this post was submitted on 22 May 2026
15 points (94.1% liked)

Linux

65400 readers
427 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 7 years ago
MODERATORS