Frameworks in Ubuntu Core

Ted Gould ted at
Wed Oct 21 13:32:57 UTC 2015

On Wed, 2015-10-21 at 12:05 +0200, Víctor Mayoral Vilches wrote:
>         What problems did the size cause? Were you running out of disk
>         space or was the download difficult?
> Size actually is a problem if we think of extending a robot's behavior
> with snaps. The main reason why we haven't pushed ROS snaps to the
> store is because it doesn't make sense to have a 200 MB simple ROS
> package (or even 50 MB if we manually strip it down). Updating it
> wirelessly sounds even less plausible (which is what really excites
> me). 

I think that, long term, we'll have to solve the size problem; but that
is an optimization. The first things we need to get right are the
developer experience from build to test to deployment to support. Then
we can optimize those experiences to make them fast and efficient. I was
more asking from the perspective as to understand where the pain points
are so that we can figure out where to prioritize optimization. For
instance, it sounds like your pain point is download bandwidth, which
will have a different set of solutions than other pain points.

>         The problem with including the library inside the framework is
>         that suddenly you're starting to make a choice about which
>         version every app on the system has to use. If they have a bug
>         fix or patch that effects them, but is considered not
>         important for the framework, they can't get it for their app.
>         Also, it makes deploying and testing apps more difficult as
>         their behavior can change depending on the other snaps that
>         are installed on the system. Neither of these are desirable
>         traits. 

> Your reasoning here makes sense from the Snappy perspective, still, as
> a roboticist using ROS, my view is not far from what Gianluca proposes
> and i believe i've shared this before. I tend to split my software in
> separate parts (ROS packages) that will have dependencies as. This is
> the ROS approach and it'll take quite a bit to make a change here
> (community-wise), specially in the research community.

I think that this is one that many developers who have worked in Open
Source come from. We're used to having large repositories of shared
dependencies that we start to build from and have made many great
things. But there is a significant difference between when you're
building a one-off device to do research and development and when you're
building a product that will be used by consumers. And that difference
is the same between traditional deb-based Ubuntu and Snappy Ubuntu. I
think that a lot of the confusion comes from the fact that most desktops
have moved from being one-off solutions to being consumer devices, so
the traditional language (desktop vs. mobile for instance) that we've
used to describe these differences fails us in a more modern context.

>         While it makes sense to do shared maintenance of dependencies,
>         and the reason orgs like the OSRF exist, it is also important
>         to build a system where developers can expect their software
>         work consistently.
> I completely disagree with this claim. The OSRF existence is not
> justified by doing "shared maintenance of dependencies". It exists for
> many other relevant matters and digging into the ROS community will
> actually show that many ROS dependencies are maintained by ROS users.

Sorry, I didn't mean to imply that about the work of the OSRF or the ROS
community. I was more trying to highlight how the companies that
surround ROS have realized that if they pool their assets and fund a
foundation to do shared work, they all gain. It's not just maintenance
or build servers. I think it is pretty sweet that it exists and is
supported by the community at large.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <>

More information about the snappy-devel mailing list