
Snap, Flatpak and AppImage, package formats compared - hydrot3k
https://verummeum.com/blog/2018/10/14/portable-package-formats/
======
eberkund
I upvoted this only because of the discussion that it could spark in the HN
comments, the article itself is actually very poor. It compares only disk
space, memory and CPU usage and of those another user pointed out that the
disk space calculation for snaps is not even correct.

Furthermore these metrics are amongst the least important when discussing
"next gen" package managers. I am more interested in hearing about developer
tools, sand-boxing capabilities, the update mechanism, OS support, private
distribution, enterprise pricing. I don't care if one packaging system uses
slightly more memory or whatever because of how it handles shared libraries,
and if I do care I would still be interested in hearing what the trade off for
that increased memory usage is.

~~~
niemeyer
Indeed the size calculation is incorrect. It's likely looking at the unpacked
size, but snaps are never unpacked, which ironically is a difference missed by
itself.

These are the actual sizes for these snaps:

    
    
      $ snap info vlc | grep stable:       
      stable:    3.0.4                   (555) 204MB -
    
      $ snap info libreoffice | grep stable:      
      stable:    6.1.2.1 (86) 501MB -
    
      $ snap info gimp | grep stable:
      stable:    2.10.6 (47) 192MB -

------
jake_the_third
A very important aspect of snap that should have been noted in the article is
the lack of user control over the a snap's updating process; Users are not
allowed to control when updates are applied, leading to a windows 10-like user
experience: [https://forum.snapcraft.io/t/disabling-automatic-refresh-
for...](https://forum.snapcraft.io/t/disabling-automatic-refresh-for-snap-
from-store/707)

From what I could understand, placing the update process under the control of
snap app developers - rather that device owners - is deliberate design
decision.

~~~
niemeyer
There's a long thread with in depth discussion about this:

[https://forum.snapcraft.io/t/disabling-automatic-refresh-
for...](https://forum.snapcraft.io/t/disabling-automatic-refresh-for-snap-
from-store/707/201)

For those that understandably won't want to go through it all, the short
version is that by design snaps will force the update _eventually_ , so that a
system isn't simply left behind, but since snapd came out a few years ago
we've been constantly working on multiple methods to offer _control_ over when
exactly the update takes place. These are features such as:

\- Fine scheduling of updates ([https://forum.snapcraft.io/t/refresh-
scheduling-on-specific-...](https://forum.snapcraft.io/t/refresh-scheduling-
on-specific-days-of-the-month/1239/10))

\- Disabling over metered connections ([https://forum.snapcraft.io/t/snap-
refresh-over-metered-conne...](https://forum.snapcraft.io/t/snap-refresh-over-
metered-connections/5001/8))

\- Holding of refreshes after boot ([https://forum.snapcraft.io/t/delaying-
refreshes-and-registra...](https://forum.snapcraft.io/t/delaying-refreshes-
and-registration-in-particular-for-pre-seeded-classic-images/4106/3))

\- Manual delaying of updates (can't find topic)

So, the goal is actually to offer control, but we are indeed trying to prevent
systems from getting out of date for good. Maybe that's a bad idea, and if it
turns out to be we can change that in the future, but we've been making an
honest effort to try to fix the problems of automatic updates instead of
simply giving up. Once we give up, there's no going back since the dynamics
around package updates will change. We have plenty of experience around these
aspects with the traditional systems.

~~~
Longhanks
Sorry, but unless there's an option to hold back the update until I
_explicitly_ allow it, that's not being in control. This is still my computer
and _I_ decide when to update software.

~~~
vetinari
This is this being downvoted? He is exactly right.

The ability to pin at specific version is needed not just because, but for
multitude of reason: the newer version breaks something, or you have only
license for up to certain version (think non-subscription Jetbrains products),
etc.

The inability to disable updates removes that packaging system from further
consideration. It is a showstopper.

~~~
seenitall
The comment is mistaken. I suspect it’s being downvoted not because update
control isn’t appreciated, but because it’s very much there with snaps. There
are several ways to disable snap updates, and they are really quite nicely
balanced for modern operations.

For example, if you publish a snap that depends on another snap, say an app
which uses a database, you can set things up so the database won’t update
until you publish a validation certificate that your app snap version X has
been validated with database snap version Y.

Updates can be deferred by anybody, and I think there is a plan for snaps
themselves to be able to defer their own updates (for example, a movie payer
that is playing a movie at the scheduled update time).

Enterprise management systems can also control the flow of updates very
nicely. For example, they can have a different snap revision as ‘stable’ or
‘beta’, which means they decide when a new revision of a snap will be
considered for update by all the machines tracking those channels. They can
also prevent any updates from happening on specific machines.

Device manufacturers also get a layer of control, similar to snap publishers
with their dependencies. So an appliance that uses snaps might see specific
revisions of snaps only once those have been certified on that device.

Considering how rich the actual reality of ‘software update distribution and
managment’ is in practice, it’s nice to see that level of thinking built in to
the system. We’ve had simplistic approaches around for decades and the results
in practice are too or, there are millions of vulnerable machines out there
because of neglect. I’m interested to see if these mechanisms achieve a better
result all round, and the simple thing you are focused on is certainly already
there.

~~~
crankylinuxuser
Tl;dr. Your computer isn't yours, and "We" know better than you, lousy user.

(That's what I took out of the shitty design decision and disgusting
justification you wrote. I'll be damned if I have to defend myself against
open source apps in some shitty all-in-1 format with fascists at the helm.)

~~~
apexalpha
Could you tone it down a bit?

Your opinion is one shared by many on HN regarding forced updates, but the
parent comment has made a proper effort to answer your questions and you
resort to name calling.

I am all for freedom of speech but if you write it on a brick and throw it
through my windows you're going to have a hard time getting me on your side.

Comments like these alienate people from what you're trying to accomplish.

~~~
crankylinuxuser
> Could you tone it down a bit?

So, a decorum "argument"... Every last thing I said was true.

I'm putting the Snap maintainers in the same bin as Facebook, Microsoft, and
Google. They want to idiot-ify the user experience with "We know better than
you" style of rules and degrade __MY __ownership.

For that, yes, I will show anger. Even if this is -1'ed and buried, I'm sure
one or more of the maintainers saw it.

~~~
niemeyer
If it makes you happy, yes, I see it. But that doesn't make things better for
anyone. We've had more interesting discussions around this issue where people
could actually present good arguments towards more control, and some of these
conversations resulted in the development of more control features, as
presented earlier in this thread.

Also, it's important to realize that it's not me or Canonical that has control
over the updates, so it's not me knowing better than you. The goal of this
exercise is to have good tooling that would allow updates to flow between a
publisher and a user with a better overall outcome.

That means, for example, that we are putting more pressure on publishers to
get it right, because they will more quickly and obviously break people if
they release something broken. There are actual high profile publishers that
changed their processes because of that.

We are also putting more pressure on the tooling, because we need to be able
to recover gracefully when the update does fail, and that's one of the reasons
why we have a more polished transition and rollback mechanism than any package
manager out there.

Yes, maybe it won't work, but it's a very interesting problem and is worth
solving. Then, even if we don't fully solve it, the exercise will have been
worth it, because it improved all those aspects in meaningful ways.

But I hear you... you're mad at me. Point taken. :-)

~~~
vetinari
Hi, I'm a poster somewhere up in the thread, not crankylinuxuser.

However, I still have an impression from seenitall's and your comment, that
you are solving the wrong problem.

\- dependencies - that's something the traditional package managers solve very
well :)

\- temporary defer updates while running: not interrupting the user is a
different issue than not updating. (In my opinion, Flatpak solves this
elegantly: it can tell the running application, that a new update is
installed, and when it is convenient to the application, it can restart
itself. Until then, both versions are available.)

\- not everyone uses EMS; I'd say that no SOHO and only some SMEs do; so here
you are creating a problem for power users and small businesses;
notwithstanding, that your competition (Flatpak) has the stable/beta/whatever
channels too, without needing EMS or other tooling;

\- device manufacturers were always able to do this with traditional package
management (using a metapackage that depends on specific versions);

\- some of the problems above seems to stem from the insistence of snap to
have a single source of truth, under a control of single entity. All the other
package systems avoid some of the issues by being decentralized. For example,
you can have your own apt/yum/flatpak repository and you can control, what
packages get in. AFAIK, this is impossible with snap, thus needing to
implement it's own solutions for a defined scenarios.

\- the above scenarios are still missing the crucial component, that
crankylinuxuser points out: the user's consent to update. Neither poster in
this thread addressed this concern.

The issue is, that you cannot rely on vendor/someone upstream to certify the
solution for you, because they may be wrong. When it is wrong, it will break
your system and the vendor will not be quick enough (or even willing) to un-
break your system.

My example: we are using a certain well-known ETL tool (I won't name it here,
no point in shaming them), that has a bug since some version, where it drops
characters in certain Unicode range. Most customers do not have a problem,
only those who are unfortunate enough processing data in a language that falls
into this range. The vendor has a bug report in their bug tracking system,
they are claiming to work on it, and they semi-regularly do new releases -
without the bug fixed.

Of course, nobody that needs that specific Unicode range can update. Nobody in
this context means a handful of users worldwide, i.e. a small fraction of
percentage of customers, so that means the bug fix priority is not exactly a
big one.

With traditional yum, it is easy enough to solve - just exclude that specific
package from updating. With your competition, Flatpak, it would be easy too:
just do not update that package. At installation time, they can still install
the "old" version, when needed.

Here, the vendor certification would be not enough - the application works for
most users, it's just too bad when it doesn't work for you. In the absence of
EMS, there would be not much what the users could do.

And that's where the issue "someone else has control over update process, not
me" comes from.

~~~
crankylinuxuser
> \- the above scenarios are still missing the crucial component, that
> crankylinuxuser points out: the user's consent to update. Neither poster in
> this thread addressed this concern.

Indeed. Lack of control is my biggest source of anger.

I'm accustomed these days that most devices are under some sort of remote
control/ownership from the "mothership". Free Software and friends have made
it so we could avoid this, and retain ownership of our systems.

On Windows, reboots are a fact of life. I was in an MRI last year that took
1.5 hours. The MRI itself was a 1/2 hour, but the required mandatory update
came in when I showed up.

I also know people who 3d print have used Windows, reboot cycle update, and
lost their print.

Long story short, Windows, Mac, iPhones, and Androids are not our devices. We
at best rent them. Ownership = control.

So when some open source group wants to centralize and force updates like
this, its because they are trying to fight for ownership of my devices. Ive
fought long and hard to free myself from most onerous software. And I see it
now popping up in what was once a bastion of freedom.

So yeah, I'm angry. And yes, Ill do what I think is right in terms of impeding
this.

------
robotmay
I really dislike AppImage when it's the only way to get an app. I find it
quite annoying to get set up on my system in such a way that it behaves like a
normal piece of installed software (I run a fairly basic i3 setup with dmenu
for app launching). I mostly just keep an unorganised "AppImage" folder now
full of random clicky items I can launch. It's like being on an early 2000s
iMac.

Flatpak has been good when I've used it; it works more similarly to how apt
functions, and seems to need less faffing to get going on my system.

Snap is almost good. I found the documentation for how to actually make snaps
incredibly frustrating (hard to explain, it was like lots of little steps were
missing) and I find the permissions model with them more awkward. I tried
installing Gitea on my home server via snap the other day, and promptly got
annoyed enough to just give up, as I wasn't that invested in it.

~~~
techntoke
I use i3wm and Rofi (similar to dmenu). Pacman from Arch and apk from Alpine
are so much easier at managing packages. Until they can make a containerized
distro that works basically the same, then I don't see a good use case for
changing, unless you want to try something out in a more isolated environment
(and even then there is Docker).

~~~
cprecioso
Do you mean Ubuntu Core?

~~~
techntoke
No. I've not had much luck with Ubuntu Core and use Arch generally, Alpine for
Docker, and have had better luck with other distros for embedded Linux.

------
emilsedgh
My biggest problem with them all is that I don't really have a problem with my
apt.

I understand that this situation is problematic with vendors who want to
distribute their apps. But to me it feels like that the packaging situation
has always been an excuse for them to drop Linux support.

If they consider desktop Linux supported during development, providing a
couple statically linked deb and rpm files is no big deal. And a lot of
vendors are doing that nowadays.

Sandboxing would've been nice for sure. But again, I don't have a security
problem with my Linux Desktop as of right now.

~~~
jcelerier
> If they consider desktop Linux supported during development, providing a
> couple statically linked deb and rpm files is no big deal.

well, yes it is, because it only covers two families of distros over many. I
develop a software with a fairly small niche and you wouldn't believe the
weird distros on which people test it. With the AppImage, everyone is happy -
and also the software can be installed without administrative permissions
which is fairly useful when you want to use it in a class room without having
to spend a week with the local system administrators to get the .deb deployed
and just have the students download the AppImage and execute it.

~~~
xfer
It isn't really that hard to repackage it for any packaging format after
extracting the deb file. I have used those distros(arch, void, now nixos) for
a long time, i never had a problem with anyone providing just a deb file.

~~~
X6S1x6Okd1st
It sounds like you are exceptional

~~~
adrianN
It sounds like a software vendor that sells their product shouldn't have
problems creating packages for their customers.

~~~
jcelerier
yes, but a software vendor who provides FOSS on his free time certainly does
not have time for this.

~~~
syn0byte
Crazy novel idea; The FOSS developer could just give out the source code,
maybe with some helper build scripts, and then users could just build the
software on whatever platform they want. Maybe making changes to which
features they need and which external dependencies they required.

Even crazier; what if we had a standard, well supported build system that we
could included with every OS and distro?

Nah, thats crazy talk. Lets repackage an entire OS so you can run an OS while
your running your OS so you can listen to internet radio.

~~~
jcelerier
> and then users could just build the software on whatever platform they want.

most of my users are non-technical (yes, even on linux). Also, if you want to
use a modern development environment this won't work: for instance, I use
C++14 / 17 which restricts me to distros at least as recent as ubuntu 18.04
for building and cuts out an immense part of the user base. With AppImage it
does not matter what OS my user is running - even if the OS isn't able to
build my software, it will be able to run it.

> Even crazier; what if we had a standard, well supported build system that we
> could included with every OS and distro?

won't happen. I have users on ubuntu 12.04 which still uses e.g. CMake 2.8
which is way too old and a frankly different language than CMake > 3.0. Even
if it was another build system it would be the same problem : you would have
to restrict yourself to the oldest released version still in used of the build
system, which really really sucks because build systems hardly ever "get it
right" in their 1.0 version.

------
askvictor
This is a pretty light-weight article - doesn't go into security/isolation
differences, or disk usage comparison. Here's something I came across a few
days ago while I was researching the differences:
[https://askubuntu.com/questions/866511/what-are-the-
differen...](https://askubuntu.com/questions/866511/what-are-the-differences-
between-snaps-appimage-flatpak-and-others)

~~~
gcb0
wait, "run without sandbox" is a pro-feature?!

~~~
StavrosK
That you have the option to, for applications that won't work without full
access? Yes, definitely. I don't want my format to say "well this file manager
application needs to access your filesystem so it's not available for your OS
because your packaging format doesn't allow us to run unsandboxed, good luck".

~~~
gcb0
I assumed the goal of those systems was for end users with no system or
programming knowledge. hability to escape sandbox will only cause pain and
security holes, while serving one or two advanced users.

~~~
StavrosK
So? Just don't allow the app to escape the sandbox.

------
flaprimo
Snaps size computation in the article is wrong according to official
documentation [https://docs.snapcraft.io/t/the-snap-
directory/2817](https://docs.snapcraft.io/t/the-snap-directory/2817)

~~~
niemeyer
Yes, the size is wrong. It's looking at the unpacked size, but the snaps are
never unpackaged. Here are the actual sizes for the mentioned snaps:

    
    
      $ snap info vlc | grep stable:       
      stable:    3.0.4                   (555) 204MB -
    
      $ snap info libreoffice | grep stable:      
      stable:    6.1.2.1 (86) 501MB -
    
      $ snap info gimp | grep stable:
      stable:    2.10.6 (47) 192MB -

------
burtonator
As a developer having these three formats is a real pain. I wish we had a
standard already.

The app I'm working on, Polar
([https://getpolarized.io/](https://getpolarized.io/)) is a cross platform
document repository. The Windows and MacOS builds are pretty straight forward.

But with Linux I now have Appimage, deb, rpm, snap, flatpak, and of course
tar.gz (but maybe that doesn't count).

~~~
nsomaru
Saw a comment from you the other day on HN. Was really excited, even installed
snap to try it out.

For some reason the application is not automatically in my path after
installation. That’s enough for me to go back to apt, and unfortunately
Polarized is collateral damage.

I preferred installing from a ‘repo’ which updates my software automatically,
something it seems that your deb does not do.

~~~
hollerith
>the application is not automatically in my path after installation. That’s
enough for me to go back to apt

Wow, tough customer! I have resigned myself to the need to do the equivalent
of `dpkg -L | grep /bin/` to discover where the binaries are.

------
mathw
I feel this article misses the point entirely. Flatpak runtimes - which
unbundle a huge number of dependencies (such as GNOME's entire platform
library set) and allow independent security updates for them - aren't even
mentioned. Neither is sandboxing.

I was hoping for something interesting about the technical tradeoffs between
the three formats and why I might want to have Fedora support Snap in the
future (or why I might not to), etc.

Interesting to read the other comments and discover that Flatpak's really
oriented towards desktop software only. I didn't know that.

~~~
niemeyer
Yes, the article indeed is on the low end. It focuses mainly on the package
sizes, and gets it very wrong as mentioned in other comments.

------
tannhaeuser
They're repeating the .rpm vs .deb situation again, for no-ones gain. Wake me
up if they're actually collaborating on a common standard.

~~~
CogitoCogito
I agree with you that there is nothing new to this sort of thing, but why does
there need to be a common standard? Personally I'd prefer a few different
standards with their own ideas competing instead of a single one that is just
some compromise between the different ones.

~~~
tannhaeuser
"Let a thousand blossoms bloom" isn't the right approach for package
management. A package manager is IMHO not the place for creativity,
competition, bikeshedding, and fragmentation because that's what we have
already. The focus should be on winning devs to actually use a package format,
so that users can more easily install software without upstream devs needing
to maintain yet another format.

~~~
CogitoCogito
We're not talking about thousands of formats...only a few formats make up the
most popular formats around.

I see nothing special about package managers that makes competition
undesirable. I think creativity and competition are good for package managers.
Besides why does an upstream dev need to maintain these new formats? They can
choose to support whatever they want.

Personally I don't understand why this is a big deal. Any fragmentation is the
result of reasonable people disagreeing on the best approach. The plethora of
different ideas is a feature of the ecosystem not a bug.

~~~
michaelt

      I see nothing special about package managers
      that makes competition undesirable.
    

The most common rationale I hear for using Snap/Flatpak/AppImage over
traditional deb/rpm is that the fragmentation of the latter is burdensome [1].

One of the main claims of Flatpak is "The days of chasing multiple Linux
distributions are over. [...] Create one app and distribute it to the entire
Linux desktop market." [2]

If you are designing something to solve the problem of fragmentation, and by
so doing you increase fragmentation, you've achieved the opposite of your
goal.

[1]
[https://news.ycombinator.com/item?id=18215978](https://news.ycombinator.com/item?id=18215978)
[2] [https://flatpak.org/](https://flatpak.org/)

~~~
CogitoCogito
Just to be clear, I see no reason to use Snap/etc. over older packaging
solutions. However I wouldn't necessarily agree that this automatically
increases fragmentation. If Snap/etc. were to support Ubuntu, debian, Redhat,
etc., they could provide maintainers a single target across many systems. Then
the maintainer could just target that solution and be done. Of course this
requires them to win that developer marketshare, but if they believe they can,
then they believe they can achieve their goals without fragmenting they
system.

I personally don't see the need for these systems, but I still see absolutely
nothing special about packaging. No maintainer has to support these new
packaging methods if they want. If some developers believe they can introduce
new and improved packaging systems, I wish them luck.

------
_emacsomancer_
Snaps seem to work well where they work, but it's limited by their systemd
dependency. So they're most useful on an LTS Ubuntu or Debian stable in order
to get more up-to-date version (or missing) of a package. But if you're in a
more esoteric environment with a different init, Snaps do you no good - which
is a pity, because that's where they would actually be the most useful to me.

Flatpak and AppImage aren't limited in this fashion, but have few packaged
apps, and they're generally all the apps I already have access to.

In practice, I've found Guix, Nix, and Docker to be most useful solutions to
missing/outdated apps, though these are more complicated than Snap, Flatpak,
or AppImage.

~~~
sjellis
> Snaps seem to work well where they work, but it's limited by their systemd
> dependency.

A more serious issue with snaps is that they rely on AppArmor as a security
mechanism, which is not actually present on most Linux systems (only Ubuntu
variants, SUSE and Solus). The snaps will still run elsewhere, but not with
the same security as you might think you were getting.

~~~
apexalpha
will installing snapd not install AppArmor as well?

~~~
sjellis
> will installing snapd not install AppArmor as well?

It can't, because AppArmor is a kernel-level feature that also requires some
level of integration into the rest of the distribution. Red Hat/Fedora-based
distributions already use SELinux in place of AppArmor, so using snap on those
systems can't have full security capabilities (making SELinux and snap work
together would be non-trivial, and I don't think anyone is motivated to do
it).

Flatpak uses other mechanisms for limiting the access that applications have,
so does not rely on either AppArmor or SELinux being on the host system.

------
amaccuish
I'm not sure he included the runtimes that flatpak downloads in space usage
requirements, so the results may not be accurate :/

------
saderror256
What Flatpak also does well wasn't mentioned, which is sandboxing applications
(can snap do this as well i think), I use proprietary applications on flatpak
sometimes so i can feed them the resources they only need, like discord, it
does not need to see my files or my running processes for the running games
feature, so i just restrict them with flatpak. Sandboxing is nice for
proprietary software basically, or software that collects info or just any
software that connects to a server, you can snip out useless stuff you don't
need while it still hopefully functions well.

~~~
erlehmann_
[http://flatkill.org/](http://flatkill.org/) claims that “The sandbox is a
lie”:

> Almost all popular applications on flathub come with filesystem=host,
> filesystem=home or device=all permissions, that is, write permissions to the
> user home directory (and more), this effectively means that all it takes to
> "escape the sandbox" is echo download_and_execute_evil >> ~/.bashrc. That's
> it.

> To make matters worse, the users are misled to believe the apps run
> sandboxed. For all these apps flatpak shows a reassuring "sandbox" icon when
> installing the app (things do not get much better even when installing in
> the command line - you need to know flatpak internals to understand the
> warnings).

I have not used flatpack. Is this description accurate? Also:

> Up until 0.8.7 all it took to get root on the host was to install a flatpak
> package that contains a suid binary (flatpaks are installed to
> /var/lib/flatpak on your host system). Again, could this be any easier? A
> high severity CVE-2017-9780 (CVSS Score 7.2) has indeed been assigned to
> this vulnerability. Flatpak developers consider this a minor security issue.

~~~
Natela
There was already a post on this. Basically the argument about home is true
but this is because 1) apps should not use filesystem access but rather
portals (if they can) 2) nothing should be executable in the home folder
(nobashrc, no script, etc...)

If I remember well the second argument was about update not being frequent
enough.

So nothing fundamentally about Flatpak but more about the infrastructure (lack
of updates) and the use of it (we should not allow home access and use Portals
or we should disable bashrc).

~~~
jake_the_third
> nothing should be executable in the home folder

Says who? The purpose of a home directory to contain user-specific files
including executables. Developers compile their software and write their
scripts in their home directory. Even if we made the absurd decision that no
file may be executed from the directory, there are many ways to cause harm by
simply editing user-specific configuration files (e.g. in ~/.config).

Arguing that the problem is with executables in $HOME rather than Flatpak is
incredibly delusional.

------
cmurf
It's not integrated in flatpak cli yet, but you can use ostree to do a
rollback/downgrade.
[https://github.com/flatpak/flatpak/wiki/Tips-&-Tricks](https://github.com/flatpak/flatpak/wiki/Tips-&-Tricks)

------
bfrog
It honestly feels like these solutions are the wrong approach when compared to
something like Nix.

~~~
Fnoord
Would you mind elaborating on that?

------
auganov
Had a pretty bad experience with snap. A project I wanted to try was
distributed as a snap package, after fixing many download issues, finally got
my package, it didn't work but that was okay, was going to make some changes
anyways. Built from source just fine, but it turned out the project itself
depended on snap's sandboxing heavily, so I'd have to create a snap package
anyways. Unfortunately at the time (and likely still true), the dev tools
didn't like anything that wasn't the latest Ubuntu (recent Debian didn't cut
it). Apt purged snapd, but still had to manually delete a bunch of snapd
related files (systemd units mostly).

------
api
There are three competing standards, so everyone will still use curl|bash.

~~~
saderror256
the issue is though is that we have to make sure everything is safe, when
passing custom install scripts through bash, in the future it could get hacked
and end up running malicious commands, mainly the issue is that it just
fetches and runs a script, which sometimes people blindly run these

------
rainygold
So basically AppImage is the standard we ought to be using?

------
elheffe80
I couldn't make it past the third paragraph. So poorly written that it
literally made me mad.

------
mitchtbaum
I looked at these a tiny bit already and think it'd be better to package in
each distro's standard channels. I'd be interested in good reading material
about packaging for debian apt, ubuntu ppm, arch aur, red hat rpm, etc if
anyone's got some.

~~~
debiandev
[https://wiki.debian.org/Packaging](https://wiki.debian.org/Packaging) is a
good source and you can easily generate packages from other distributions from
a .deb

------
apatheticonion
Is this docker for regular applications?

~~~
apexalpha
it's more like .exe on windows. It requires more disk space because some
dependacies might be installed twice or more, but it saves both the end users,
the distributors and the developers of a program an enormous amount of
headache having to support dozens of different linux distro's with their own
dependancies etc...

------
aritmo
Half-assed article with several mistakes.

