
How to install LibreOffice 5.3 from snap on Ubuntu 16.04 (and others) - elopio
https://blog.simos.info/how-to-install-libreoffice-5-3-on-ubuntu-16-04-from-snap/
======
pwnna
Snap looks like the way forward by bring some of the isolation from things
like Android to desktop, but at the same time the way it handles app
distribution makes it tempting to use instead of docker especially if your
machine is a single purpose machine (runs 1 application only).

Can anyone comment on using snap vs something like flatpak and docker for
deploy your own applications to servers?

~~~
elopio
Here's the docker question in askubuntu.com:
[https://askubuntu.com/questions/808524/whats-the-main-
differ...](https://askubuntu.com/questions/808524/whats-the-main-difference-
between-docker-and-snap)

------
Mister_Snuggles
I wish there was a better divide between "system" and "other" software in
Linux distributions.

The BSDs, for example, keep all of the system stuff in /usr, /etc, /bin, etc,
and any extra stuff you install from ports or packages ends up in /usr/local.

It looks like Snaps are a way of accomplishing much the same thing (and more)
in the Linux world.

~~~
lmm
> The BSDs, for example, keep all of the system stuff in /usr, /etc, /bin,
> etc, and any extra stuff you install from ports or packages ends up in
> /usr/local.

Which is awful, because it means stuff you install from ports ends up in the
same place as hand-compiled programs and there's no way to tell them apart. A
distinction between "system" and "ports" is maybe sort of useful I guess
(though I'm not sure exactly what I'm supposed to be gaining from it), but the
distinction between automatically-managed-at-all and not is far far more
important.

~~~
Mister_Snuggles
The problem I have with Linux distributions in general is that applications
are too infrequently updated. Of course, you can add extra repos to get these
updated applications but then you end up with a horrible mix of base-system
stuff plus 3rd-party stuff.

BSD sidesteps this problem, but introduces the one you mention.

It sounds like snaps will potentially solve both problems.

------
smacktoward
What's the benefit to me as a user to installing it via snap, instead of via
the traditional methods of apt-get/the Ubuntu software app?

~~~
jamiebennett09
Generally the snap will be much more up to date.

Installing from the Ubuntu Archive with apt-get means you get the version that
was released with that version of the OS, say Ubuntu 16.10, sometimes with
minor updates. With Snaps you get the version that the software developer
pushes to you which could be their latest stable software released just
yesterday (there is a concept of Snap channels that open up things like
beta/candidate/daily builds e.t.c. but that is another topic).

Snaps can also update themselves, allow dependency bundling, are confined in
sandboxes e.t.c. but for a user, it means you get very fresh software on your
device. You can read more about them at
[https://snapcraft.io/](https://snapcraft.io/)

~~~
zzalpha
This is a solved problem with ppa's.

~~~
snovv_crash
Not if the ppa depends on a system library not available on your release. Then
you need to go hunting for more ppas, until you eventually need to
up/downgrade your entire system.

~~~
zzalpha
Yes, you're right, the originator of the package actually has to release PPAs
that work on your release.

That's a perfectly manageable issue.

But don't claim snap's are the only solution to the problem of getting up-to-
date software. That's not at all true. We've been solving this problem for far
longer than Ubuntu has been around, and their approach is hardly a panacea.
For example, it can and will result in additional memory and on-disk bloat as
a consequence of duplicated dependencies across packages until de-duplication
is implemented.

~~~
snovv_crash
You only get a single duplicate of the library no matter how many things
depend on it. That is the whole point of snaps over just statically linking.

Well, that and the sandbox features, so that they can't interfere with the
rest of the system.

~~~
zzalpha
_You only get a single duplicate of the library no matter how many things
depend on it._

Huh?

If a snap includes version 1.0.0 of libxyz, and another does the same, you
have two copies. If a third snap comes along and uses version 1.0.0 libxyz,
you now have three.

Snaps do not automatically de-duplicate today.

That means two copies of the library living on disk and in memory at run-time.

~~~
jamiebennett09
That would be the same with any platform that does not use some kind of
explicit linking/sharing of resources. Snaps have a sharing mechanism called
interfaces but yes, the software author has to declare they want to use it, no
magic there.

~~~
zzalpha
_Snaps have a sharing mechanism called interfaces but yes, the software author
has to declare they want to use it, no magic there._

So, they've reinvented dependencies (though, to their credit, they gave them a
different name), one of the very things snaps were intended to alleviate?

Look, don't get me wrong, snaps have some interesting advantages (sandboxing
being the one major selling point, IMO). But, again, they're no panacea.

~~~
slitaz
Snaps are apps in a container. Why bother with docker containers to run
services while you can install everything together on a single computer? Each
docker replicates the same rooted again and again.

Just like docker, snaps make sense even if there is some duplication of the
libraries. Other benefits outweigh the extra size.

------
platz
"snap run libreoffice" gives me this error
[http://i.imgur.com/tTKkpZe.png](http://i.imgur.com/tTKkpZe.png)

~~~
jamiebennett09
You should be using just 'libreoffice' on the command line or to be 100% sure,
/snap/bin/libreoffice or running it from the dash (second icon per the blog
post if you have both deb and snap installed). Why snap run? Also, knowing
which version of snapd and which Ubuntu version would be interesting but if
you feel this is a bug then it would be great to see more information at
[https://launchpad.net/ubuntu/+source/snapd](https://launchpad.net/ubuntu/+source/snapd).

~~~
platz
/snap/bin/ is not on my path after installation of snapd and libreoffice, so
just 'libreoffice' results in 'command not found'

    
    
        [1] $ snap version
    
        snap    2.21+16.10
        snapd   2.21+16.10
        series  16
        ubuntu  16.10
    
        $ /snap/bin/libreoffice
        datahome: /home/jon/snap/libreoffice/17/.local-5.3.0.3/share
    
        (soffice:13608): Gtk-WARNING **: Locale not supported by C library.
    	    Using the fallback 'C' locale.
    
        (soffice:13608): Gtk-WARNING **: Could not find the icon 'dialog-warning-symbolic-ltr'. The 'hicolor' theme
        was not found either, perhaps you need to install it.
        You can get a copy from:
    	    http://icon-theme.freedesktop.org/releases
    
        (soffice:13608): Gtk-WARNING **: Error loading theme icon 'image-missing' for stock: Icon 'image-missing' not present in theme ubuntu-mono-dark
    
        (soffice:13608): Gtk-WARNING **: Error loading theme icon 'image-missing' for stock: Icon 'image-missing' not present in theme ubuntu-mono-dark
    
        (soffice:13608): GLib-GObject-CRITICAL **: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
    
        (soffice:13608): Gtk-WARNING **: Error loading theme icon 'image-missing' for stock: Icon 'image-missing' not present in theme ubuntu-mono-dark
    
        (soffice:13608): Gtk-WARNING **: Error loading theme icon 'image-missing' for stock: Icon 'image-missing' not present in theme ubuntu-mono-dark
    
        (soffice:13608): GLib-GObject-CRITICAL **: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
        Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.
    
        (soffice:13608): Gtk-WARNING **: Error loading theme icon 'image-missing' for stock: Icon 'image-missing' not present in theme ubuntu-mono-dark
    
        (soffice:13608): Gtk-WARNING **: Error loading theme icon 'image-missing' for stock: Icon 'image-missing' not present in theme ubuntu-mono-dark
    
        (soffice:13608): GLib-GObject-CRITICAL **: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
    
        (soffice:13608): Gtk-WARNING **: Error loading theme icon 'image-missing' for stock: Icon 'image-missing' not present in theme ubuntu-mono-dark
    
        (soffice:13608): Gtk-WARNING **: Error loading theme icon 'image-missing' for stock: Icon 'image-missing' not present in theme ubuntu-mono-dark
    
        (soffice:13608): GLib-GObject-CRITICAL **: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
    
        (soffice:13608): Gtk-WARNING **: Error loading theme icon 'image-missing' for stock: Icon 'image-missing' not present in theme ubuntu-mono-dark
    
        (soffice:13608): Gtk-WARNING **: Error loading theme icon 'image-missing' for stock: Icon 'image-missing' not present in theme ubuntu-mono-dark
    
        (soffice:13608): GLib-GObject-CRITICAL **: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
    
        (soffice:13608): Gtk-WARNING **: Error loading theme icon 'image-missing' for stock: Icon 'image-missing' not present in theme ubuntu-mono-dark
    
        (soffice:13608): Gtk-WARNING **: Error loading theme icon 'image-missing' for stock: Icon 'image-missing' not present in theme ubuntu-mono-dark
    
        (soffice:13608): GLib-GObject-CRITICAL **: g_object_ref: assertion 'G_IS_OBJECT (object)' failed

~~~
mhall119
/snap/bin will likely be added to your PATH from now on, but if your current
shell session was already running when you installed snapd it wouldn't be
updated.

------
amelius
I'm wondering how Snap deals with shared libraries? Are they downloaded with
the release and placed in a sandbox? Or are binaries "statified" somehow?

~~~
rlpb
They're bundled into the snap at build time. The tooling to create snaps makes
this process fairly automatic. In this respect it works like Docker. App
developers shipping snaps don't have to worry about how their users are going
to get dependencies, or if the dependency versions will make a difference to
the behavior of the app.

~~~
amelius
So a snap runs inside some sort of chroot jail?

(By the way, shared libraries were invented to reduce memory usage. Not sure
what will happen to that goal now.)

~~~
mhall119
Kind of, they run in a restricted AppArmor profile that limits what they can
see and do, but the filesystem the do see is the same as any other process.

KSM should prevent duplicate libraries from taking up extra memory on your
machine.

