simosx

Snap is not "centralized". It comes with a default Store, and this helps most users that require modern package management.

If you want to distribute manually your .snap packages, then you can certainly do so.

For example, the libreoffice snap is easily available for download at https://uappexplorer.com/snap/ubuntu/libreoffice The recipe to create the snap package is shown on the same page. You can recreate the snap package and then keep it for yourself. Or, upload it to your website and share with your friends.

After you download the .snap package, just click on it and it will prompt you to install it.

What you do not get with snaps, is the source code of the Ubuntu Store. Most likely, if someone is really interested to replicate the store, I believe it is easy to reverse-engineer, then create a reference implementation.

I said that there is no "default" central store for package in AppImage. Which means that there is a "default" central store for snaps and flatpaks.

And if you do not like the "default" central store, you are free to distribute yourself the individual snap or flatpak package. Just like with AppImage.

Some version of LibreOffice is native to a distribution. Those new formats have benefits, including the ability to automate the processes of updates (mostly thanks to better tooling as they are newer), the ability for confinement, etc.

Most likely it is a preload issue. With the apt version, the libraries are already preloaded on your system, because they are shared and in use.

With the snap version, the application needs to load up the common core image, then load the set of libraries that are specific to the application. The core image can probably get preloaded, but the set of libraries that are specific to the application probably not. Definitely in the disk cache, but maybe not preloaded.

On Intellij, JetBrains are producing themselves snap packages for their whole range of products. It makes it so easy to install on your system, and updates happen automatically.

Here is their initial announcement, https://blog.jetbrains.com/idea/2017/11/install-intellij-ide...

Here is the snap package page for Intellij Ultimate, https://snapcraft.io/intellij-idea-ultimate You can see the usage stats and also the list of other JetBrains packages.

You will most likely get a malicious AppImage from some website because there is no default central store with such packages.

You could argue that there is a freedom with AppImage that you are not bound to a Store. But that would not be correct, because you can self-host both snaps and flatpaks, if you really need to.

With snaps, you have more fine-grained security privileges. For example, "httpstat" [1] is a network utility to benchmark the access to a website. As a utility, it only requires access to the network. With snaps, the packager can only permit access to the network, and no access at all to the user's files or anything else.

1. https://github.com/davecheney/httpstat

The "snap for servers" was an issue so long time ago. I do not think it is worth repeating.

Both snaps and flatpaks require a core image (a rootfs), and each package sits on top of that rootfs.

For snaps, there is the core16 (and core18) images, which have quite a lot of shared libraries. Your snap package simply contains your program and any other extra libraries that are missing from the core image.

For snap packages, you can use the build servers at https://snapcraft.io/build Point to your github repository with the snapcraft.yaml file and it will create the snap package for you. I think the publishing is very straightforward, and you can get a new package published very quickly.

Of course, you need to work a bit in creating the snapcraft.yaml configuration file in the first place.

A post by Christian Brauner (LXC/LXD developer) on how LXC and LXD are affected. In summary, unprivileged containers (as found in LXD) are not affected.

https://brauner.github.io/2019/02/12/privileged-containers.h...

Here is that feature request for the PROXY protocol, https://github.com/lxc/lxd/issues/4786

Was reported on July 14th and committed on July 19th.

As a user you should be unaffected by the packaging of software as long as it works.

A Linux distribution can repackage LXD in their native packaging format and some distributions are doing it already (Debian, Alpine, Fedora, etc). If you are familiar with packaging, you can help promote those packages to the official repositories.

Debian: https://wiki.debian.org/LXD

Fedora: https://copr.fedorainfracloud.org/coprs/ganto/lxd/

Alpine: https://git.alpinelinux.org/cgit/aports/tree/testing/lxd?h=m...

If you use the command "lxc" to manage your container, then you are using LXD. The command "lxc" communicates with the LXD supervisor over REST for you.

If instead you are using commands like "lxc-start", then you are using "LXC".

There are two possible aspects of confusion:

1. LXD uses the "lxc" command line utility for all the management of LXD containers.

2. LXC is both the name for the Linux kernel "Linux Containers" functionality and the first/early implementation of tools (those "lxc-????") for Linux Containers.

Currently I think the official LXD packages will be snap packages for all distros, with the exception of the Ubuntu LTS releases. That is, in Ubuntu 16.04 LTS and Ubuntu 18.04 LTS you get LXD as an official deb package.

Obviously, this does not preclude the distributions from packaging LXD in their own packaging format.

Apart from the AlpineLinux effort to package LXD, there is also a Debian effort, https://wiki.debian.org/LXD

There were some issues with specific kernel features not being upstreamed timely.

Having said that, here is a distribution usage for the snap package of LXD, https://snapcraft.io/lxd (see that the end of the page).

I have written some entry-level tutorials shown at https://discuss.linuxcontainers.org/t/the-lxd-tutorials-of-s...

I would like as well to see usage examples in the official documentation.

LXD is used in Crostini (https://www.reddit.com/r/Crostini/) as a way to be able to run Linux applications in chromebooks.

In addition, Samsung is somehow using LXD in their new phones, with "Linux on DeX". In that way, you can get a Linux interface with Ubuntu when you plug your phone to a monitor/TV.

If you use a Linux desktop, you can get to run GUI applications in a LXD "system container", therefore isolating the files from your host's filesystem.

Here is how to do this by sharing the X server of the host (filesystem separation but sharing the X for convenience), https://blog.simos.info/how-to-easily-run-graphics-accelerat...

You can run things like CS GO DeathZone in such a LXD container with full GPU acceleration, and even closed-source NVidia driver.

Some people also got an LXD container to run in a separate X server, thus having even better isolation.

LXD provides "system containers" in contrast to the "application containers" from Docker.

You create a "system container" and it keeps running as a stock Linux distribution (many flavors are supported). It takes about a couple of seconds to create a new container, and a bit less to remove it.

The first commit for LXD on github is from November 2014:

commit 3153b57369b7cf3e96979897c335a5c1d69e7f07 Author: Stéphane Graber Date: Wed Nov 5 10:09:28 2014 -0500

    Add licensing and contributing guidelines
    
    Signed-off-by: Stéphane Graber <stgraber@ubuntu.com>

Source: https://github.com/lxc/lxd

There is a migration path from LXC to LXD and probably the OP migrated at some point in time.

Being pedantic here. It is in fact versus "Google's current business plan of Android", not Android per se.

This Bloomberg article has several shortcomings.

1. "Android and Chrome OS are built on Linux, a widely used open-source programming language."

Here they mix up the Linux kernel with the Java programming language.

2. "Moving from Linux, though, could have upsides for Google. Android’s use of the technology, which is owned by Oracle Corp., is at the center of a lengthy, bitter lawsuit between the two companies. Shifting away from using Linux would help Google’s legal case that its software isn’t reliant on Oracle."

While here they mix up the Java programming language with the Linux kernel.

The X11 protocol has been around several decades. The Wayland protocol has been around several years. There are more tools available for X11 and it's used extensively in all distributions. Even in those that are based on Wayland, those have XWayland as well meaning that X11 works there as well. Gradually, the Linux desktop will be moving towards Wayland and it's a good thing that this happens.

Xephyr is the appropriate tool for what we do (it's a display server for the X11 protocol, can reuse the acceleration of the desktop). There are equivalent tools for Wayland, it's just not required yet. It is possible though to do these things with Wayland as well and probably there is already a tool that I am not aware of.

There is already process isolation with the containers. The lingering issue is with the graphical output on either X11 or Wayland. That needs some extra care. With X11, choice is Xephyr. With Wayland, there should be something equivalent and is probably simpler.

In terms of security of Xephyr, there is an issue. It is a tool that is not used very much and may have some unreported security vulnerabilities. But the same goes with qemu, the hardware emulator. qemu is big and has too much functionality which makes it likely to have yet unreported security vulnerabilities. Have a look at https://cloudplatform.googleblog.com/2017/01/7-ways-we-harde... which specifically mentions the risk in points 2 and 3.

Nevertheless, it should be very important to also implement an option of using Xephyr as part of the application isolation efforts.

Thanks!

Sandboxing (snap or flatpack) is more fragile than running the application in a GUI container. If you do not grant a permission, the application will fail. You will get to know about these issues from bug reports.

With a GUI LXD container, you can set up Wine as best as possible, then take a snapshot of the container in its pristine condition. Then, you can install Windows programs in the same container, or clone the original container and install each in a separate container. Each action takes only a few seconds compared to what you would get with Virtualbox.

There are two steps to set up your LXD installation in order to create GUI containers.

If you are using the snap package of LXD, you only need to perform the second step.

If you are using the deb package of LXD, you need to perform both steps.

A snap package of LXD is not required to setup GUI containers, it just makes it a bit simpler (one step instead of two).

If there is some Windows application that is really useful to have on Linux, then it makes sense to invest the effort to create a snap package. The snap package will be usable to everyone. There are already Windows games that have been packaged as snaps, and the process could be replicated with some effort (example: https://github.com/snapcrafters/tmnationsforever).

The GUI container instead, is helpful if there is an application that you would like to run but cannot invest the effort to package it as a snap.

As a sidenote, Chrome OS uses LXD in a similar way to run Linux GUI applications like the terminal application they showed in Google I/O 2018.

Here is an article on how they do it, https://blog.simos.info/a-closer-look-at-chrome-os-using-lxd...

Answering the updated question regarding the security of running what is described in the post, but using Xephyr and not the desktop's existing X11 session.

It is as secure as the individual components, that is whether there are security vulnerabilities in LXD, and in Xephyr. There are currently no pending security vulnerabilities to fix in either (as far as I know).

Of course, the same goes with VirtualBox. It is as secure as there are no pending known security vulnerabilities (https://www.techrepublic.com/article/10-new-vm-escape-vulner...).

This is a convenience tool, that uses your existing X11 session. You would not use it when testing malicious programs because they would be able to attack the X11 session (but not your host's filesystem).

If you want to test programs that might be malicious, then you would set up a separate X11 server like Xephyr and get the output to get directed over there. In that way, both the filesystem and X11 session would be separate from those of your host.

I mention the use of Xephyr in the Conclusions of the post. There is some new functionality in LXD that is being released soon that will make it very easy to use Xephyr as well.

The person that started this type of videos has the channel "Primitive Technology" at https://www.youtube.com/channel/UCAL3JXZSzSm8AlZyD3nQdBA

It is nice that others are following the lead. I do doubt though in this video that they filled up the pool with just those two buckets.

Did the community contributors assigned the copyright of their work to the original maintainer?

I created a snap package for LibreSprite. You can try it out on Linux (with snap package support: https://docs.snapcraft.io/core/install) by running

sudo snap install libresprite-simosx

Then, run 'libresprite-simosx.libresprite' to launch it.

Follow here the discussion for getting an official snap package of LibreSprite: https://github.com/LibreSprite/LibreSprite/pull/25