[mosh-devel] snap package for mosh

[Leo Arias]

Hello!

I’m Leo. I work as part of the engineering team around Ubuntu and Snapcraft [1].

Last year I found about mosh, and it has been the most amazing experience. It
solves most of the problems due to my unstable latin american internet
connection; so first, let me say thank you very much!

I was reading about your new candidate release, and I thought that this might be
interesting for you. We’re working on snaps, a platform to enable developers to
directly control delivery of software updates to their users, and make their
software available in a secure way, with automatic updates in different
channels.

The channels are particularly relevant when trying to release new versions, and
solve an old problem we had with Ubuntu. Instead of having a 6 month cycle for
everybody, you can push different versions whenever you want. So you could push
a new version to the edge channel every time something lands on your repository,
to get extreme early feedback from your contributors. When you make a freeze to
stabilize for the release, you can push that to the beta channel. And when you
are ready to release but want to give it to a greater audience for the final
checks, you can push to the candidate channel. When everybody is happy with the
release, it can be pushed to the stable channel. Your users just decide the
level of risk they want to take, and they will constantly receive updates when
you push something new.

I this sounds like a good fit for your project, I would love to work with you
making the snap. I'm particularly interested in the feedback that you can give
us about a few new features that might be useful for mosh.

pura vida.

[1] http://snapcraft.io/

[Keith Winstein]

Hello Leo,

Thanks for getting in touch, and thanks for your kind words about mosh!

Right now we have a Debian package, which we maintain in our own source
tree, and which we upload to Debian every time there's a new release. That
flows into Ubuntu as part of the normal release schedule. For users who
want something more immediate, we also have the mosh-dev PPA that pulls
from our GitHub repository once a day and auto-builds the Ubuntu source and
binary packages, and then we have a "stable" mosh PPA as well, which only
gets updated on new releases.

Is it possible to teach Launchpad to also auto-build a snap once a day (if
our Git repo has changed), alongside the PPA .debs? Can we script Travis-CI
to automatically build and push a snap each time it runs a successful CI
test on the master branch? Or how would you recommend we do this?

Mosh is pretty simple so I doubt we're going to be pushing the boundaries
of the snap format -- it's basically two unprivileged binaries and some man
pages. And a bash-completion script that gets put
in /usr/share/bash-completion/completions/mosh. I guess that might be a
little more interesting, depending on whether snap can handle that.

Happy to work with you on this if you think there is user demand for it.

Cheers,
Keith

Post by Leo Arias
Hello!
I’m Leo. I work as part of the engineering team around Ubuntu and
Snapcraft [1].
Last year I found about mosh, and it has been the most amazing experience. It
solves most of the problems due to my unstable latin american internet
connection; so first, let me say thank you very much!
I was reading about your new candidate release, and I thought that this might be
interesting for you. We’re working on snaps, a platform to enable
developers to
directly control delivery of software updates to their users, and make their
software available in a secure way, with automatic updates in different
channels.
The channels are particularly relevant when trying to release new versions, and
solve an old problem we had with Ubuntu. Instead of having a 6 month cycle for
everybody, you can push different versions whenever you want. So you could push
a new version to the edge channel every time something lands on your repository,
to get extreme early feedback from your contributors. When you make a freeze to
stabilize for the release, you can push that to the beta channel. And when you
are ready to release but want to give it to a greater audience for the final
checks, you can push to the candidate channel. When everybody is happy with the
release, it can be pushed to the stable channel. Your users just decide the
level of risk they want to take, and they will constantly receive updates when
you push something new.
I this sounds like a good fit for your project, I would love to work with you
making the snap. I'm particularly interested in the feedback that you can give
us about a few new features that might be useful for mosh.
pura vida.
[1] http://snapcraft.io/
_______________________________________________
mosh-devel mailing list
http://mailman.mit.edu/mailman/listinfo/mosh-devel

[Leo Arias]

Post by Keith Winstein
Right now we have a Debian package, which we maintain in our own source
tree, and which we upload to Debian every time there's a new release. That
flows into Ubuntu as part of the normal release schedule. For users who
want something more immediate, we also have the mosh-dev PPA that pulls
from our GitHub repository once a day and auto-builds the Ubuntu source and
binary packages, and then we have a "stable" mosh PPA as well, which only
gets updated on new releases.

That is great because we would love to hear your impressions, taking into
account your experience with debs and PPAs.

In classic Ubuntu you have to follow our 2 years/6 months release cycle, or use
a PPA. When you release a deb to an LTS, you will quickly get many users in an
outdated version for many years, you need maintainers to review your package to
make sure it's compatible with the archive, and you need to follow a
heavy-weight format full of conventions and rules to make the archive
consistent. debs are great for some projects and some users, and we are using
them as a base for our new Ubuntu Core distro; but something like getting the
mosh 1.3.0 to xenial, or even to trusty, it's a huge pain.

That's what we are trying to improve with this new dev experience. Snaps are
mounted read-only directly from the uncompressed package and they bundle all
their dependencies. So there is no conflict between snaps, nor with the base
system, and then we can get out of your way, you don't need the distro as a
middle man and you can just push to the store any version you want, any time
you want.

Snaps are also isolated to their sandbox for security reasons. But there's
where things get interesting with mosh...

Post by Keith Winstein
Is it possible to teach Launchpad to also auto-build a snap once a day (if
our Git repo has changed), alongside the PPA .debs? Can we script Travis-CI
to automatically build and push a snap each time it runs a successful CI
test on the master branch? Or how would you recommend we do this?

Yes, we want the snapcraft.yaml metadata to be as simple as possible, and to
use continuous deployment, so you will just have to spend a little time
packaging one time, and then everything is automatic. You can take a look here:
http://snapcraft.io/docs/build-snaps/ci-integration

Post by Keith Winstein
Mosh is pretty simple so I doubt we're going to be pushing the boundaries
of the snap format -- it's basically two unprivileged binaries and some man
pages. And a bash-completion script that gets put
in /usr/share/bash-completion/completions/mosh. I guess that might be a
little more interesting, depending on whether snap can handle that.

If I understand correctly, the mosh server is a terminal emulator. (I'm not
sure about mosh internals, so I'm eager to understand more about that too :)
By default, snaps can't do anything outside of their confinement, so things
like calling binaries they don't provide or accessing devices will be blocked.
And that's good enough for the vast majority of applications out there, they
just declare a few "plugs", like listening to the network, and they can fully
function. But now we are turning our eyes to also support developer tools, like
emacs which needs to be able to read and write to /etc, or a shell like zsh, or
mosh.
They pose a bigger security risk than normal apps, but still we think it should
be a direct agreement between the user and the developers distributing that
package. So you would declare on your snap the kind of things that your
application will do out of its confinement, and the user decides to grant that
permission or not.

Post by Keith Winstein
Happy to work with you on this if you think there is user demand for it.

Well, I'm sure it will make it easier for you to do early testing of the new
release, and once you are ready to release to the stable channel, many of your
users on current Ubuntu versions will find the update in the store and make the
jump.

But as I said above, we are trying to make it extremely lightweight, so it
shouldn't take a lot of your time. Developers usually just start by dumping an
existing binary into the snap, and use the devmode confinement to get a list of
the security exceptions that they need. Then if you like, you can build the
binary during the snapcraft packaging, which will make it easier to provide the
snap for other architectures.

I'm about to leave for vacations, so I encourage you to take a look at
http://snapcraft.io/create/ and give it a quick try. Then when I return the
following week I would be happy to answer any of your questions, and give you a
hand with the packaging if you need it.

I'm sorry for the long email, but I'm excited about snaps and mosh, and really
eager to hear your comments :)

pura vida

[Keith Winstein]

Thanks, Leo. Do you already have snaps for similar programs (e.g. screen,
tmux, ssh)? Mosh is probably going to have similar needs to those re: the
isolation or "plugs".

Generally we add new platforms/distros when somebody submits a PR or
volunteers to be a maintainer; my suggestion is for you to just submit a PR
with a proposed snapcraft.yaml (and changes to .travis.yml if appropriate)
and we can all try it out.

Cheers,
Keith

Post by Leo Arias

Post by Keith Winstein
Right now we have a Debian package, which we maintain in our own source
tree, and which we upload to Debian every time there's a new release.

That

Post by Keith Winstein
flows into Ubuntu as part of the normal release schedule. For users who
want something more immediate, we also have the mosh-dev PPA that pulls
from our GitHub repository once a day and auto-builds the Ubuntu source

and

Post by Keith Winstein
binary packages, and then we have a "stable" mosh PPA as well, which only
gets updated on new releases.

That is great because we would love to hear your impressions, taking into
account your experience with debs and PPAs.
In classic Ubuntu you have to follow our 2 years/6 months release cycle, or use
a PPA. When you release a deb to an LTS, you will quickly get many users in an
outdated version for many years, you need maintainers to review your package to
make sure it's compatible with the archive, and you need to follow a
heavy-weight format full of conventions and rules to make the archive
consistent. debs are great for some projects and some users, and we are using
them as a base for our new Ubuntu Core distro; but something like getting the
mosh 1.3.0 to xenial, or even to trusty, it's a huge pain.
That's what we are trying to improve with this new dev experience. Snaps are
mounted read-only directly from the uncompressed package and they bundle all
their dependencies. So there is no conflict between snaps, nor with the base
system, and then we can get out of your way, you don't need the distro as a
middle man and you can just push to the store any version you want, any time
you want.
Snaps are also isolated to their sandbox for security reasons. But there's
where things get interesting with mosh...

Post by Keith Winstein
Is it possible to teach Launchpad to also auto-build a snap once a day

(if

Post by Keith Winstein
our Git repo has changed), alongside the PPA .debs? Can we script

Travis-CI

Post by Keith Winstein
to automatically build and push a snap each time it runs a successful CI
test on the master branch? Or how would you recommend we do this?

Yes, we want the snapcraft.yaml metadata to be as simple as possible, and to
use continuous deployment, so you will just have to spend a little time
http://snapcraft.io/docs/build-snaps/ci-integration

Post by Keith Winstein
Mosh is pretty simple so I doubt we're going to be pushing the boundaries
of the snap format -- it's basically two unprivileged binaries and some

man

Post by Keith Winstein
pages. And a bash-completion script that gets put
in /usr/share/bash-completion/completions/mosh. I guess that might be a
little more interesting, depending on whether snap can handle that.

If I understand correctly, the mosh server is a terminal emulator. (I'm not
sure about mosh internals, so I'm eager to understand more about that too :)
By default, snaps can't do anything outside of their confinement, so things
like calling binaries they don't provide or accessing devices will be blocked.
And that's good enough for the vast majority of applications out there, they
just declare a few "plugs", like listening to the network, and they can fully
function. But now we are turning our eyes to also support developer tools, like
emacs which needs to be able to read and write to /etc, or a shell like zsh, or
mosh.
They pose a bigger security risk than normal apps, but still we think it should
be a direct agreement between the user and the developers distributing that
package. So you would declare on your snap the kind of things that your
application will do out of its confinement, and the user decides to grant that
permission or not.

Post by Keith Winstein
Happy to work with you on this if you think there is user demand for it.

Well, I'm sure it will make it easier for you to do early testing of the new
release, and once you are ready to release to the stable channel, many of your
users on current Ubuntu versions will find the update in the store and make the
jump.
But as I said above, we are trying to make it extremely lightweight, so it
shouldn't take a lot of your time. Developers usually just start by dumping an
existing binary into the snap, and use the devmode confinement to get a list of
the security exceptions that they need. Then if you like, you can build the
binary during the snapcraft packaging, which will make it easier to provide the
snap for other architectures.
I'm about to leave for vacations, so I encourage you to take a look at
http://snapcraft.io/create/ and give it a quick try. Then when I return the
following week I would be happy to answer any of your questions, and give you a
hand with the packaging if you need it.
I'm sorry for the long email, but I'm excited about snaps and mosh, and really
eager to hear your comments :)
pura vida

[Leo Arias]

Hello Keith,

Post by Keith Winstein
Thanks, Leo. Do you already have snaps for similar programs (e.g. screen,
tmux, ssh)? Mosh is probably going to have similar needs to those re: the
isolation or "plugs".
Generally we add new platforms/distros when somebody submits a PR or
volunteers to be a maintainer; my suggestion is for you to just submit a PR
with a proposed snapcraft.yaml (and changes to .travis.yml if appropriate)
and we can all try it out.

I've been playing with mosh and our tools, and proposed this:

https://github.com/mobile-shell/mosh/pull/854

As I told you before, it would be great for us to get feedback from use cases
like yours, so I would appreciate if you take a look.

In particular, with your snap we are introducing the concepts of classic and
alias. Most snaps won't require them, but mosh is special in many ways :)

I also found a usability bug when trying it, so it has already been very
useful. You will find a note about that in the PR.

Please, let me know what do you think.

pura vida.