Running on real hardware...

Dan Kegel dank at
Tue Dec 16 00:10:12 UTC 2014

- Dan

On Mon, Dec 15, 2014 at 4:00 PM, Alexander Sack <asac at> wrote:
> ooops :)...
> was trying to say, you can find docs how to manually hack the
> confinement of your local snappy app here:
> To get something going quickly you can select unconfined template for
> your binaries/services.
> Once stuff is up and running you can see how you can punt holes into
> our default template instead of going fully unconfined. I think the
> wiki has most info you will need.
> On Tue, Dec 16, 2014 at 12:54 AM, Alexander Sack <asac at> wrote:
>> On Tue, Dec 16, 2014 at 12:21 AM, Dan Kegel <dank at> wrote:
>>> The target app uses modern OpenGL heavily, and also uses X.
>>> It's probably beyond the scope of my exercise to try porting the app
>>> from X to Mir or Wayland.
>>> As long as I can still use X and OpenGL, and have control over which
>>> version of the official proprietary ATI/Nvidia drivers are in use,
>>> I don't care if Mir is there, too.  Well, depending on performance,
>>> I guess.  The compositor might hurt benchmarks.  (I'm at the edge of
>>> my knowledge here.)
>>> The use case is essentially "chromeos", i.e. a system that boots into
>>> a web browser
>>> and autoupdates silently, as an exercise to see if it can be done.
>>> A more real-world use case is "arbitrary graphics-intensive
>>> autoupdating appliance",
>>> where there is exactly one OpenGL app (for instance, a media player),
>>> so I'm not at all worried about crosstalk between apps,
>>> but I am interested in stability and efficient/safe autoupdating.
>>> In neither case is any kind of OS UI exposed to the user, it's all app ui.
>> Allright, in that case I wouldn't bother about framework nor  pumping
>> up the system base. Instead try to put everything together in your
>> snapp as one big bundle.
>> Would be interesting to see what the most minimal confinement holes
>> you have to punt into our default confinement template:
>> I think it's likely that you will hit some apparmor barriers that will
>> prevent this from working, but once you hit that issue come back with
>> the logs stating the apparmor denies and we can see how you can
>> manually punch very carefully crafted holes into snappy confinement.
>>> - Dan
>>> On Mon, Dec 15, 2014 at 2:55 PM, Alexander Sack <asac at> wrote:
>>>> Hi Dan!
>>>> very interesting things you are exploring here :)...
>>>> below more detailed input, but before I wonder if you have a specific
>>>> use case in mind that made you try this?
>>>> On Mon, Dec 15, 2014 at 2:13 AM, Dan Kegel <dank at> wrote:
>>>>> Haven't gotten nvidia working yet, but here's a recipe that at least lets
>>>>> you run 'sudo startx' and get an X terminal using vesa.
>>>>> 1) on a throwaway vm, install a 15.05 daily, then do
>>>>> pkgs="
>>>>> libc6
>>>>> libevdev2
>>>>> libfontconfig1
>>>>> libfontenc1
>>>>> libice6
>>>>> libmtdev1
>>>>> libpciaccess0
>>>>> libpixman-1-0
>>>>> libSM6
>>>>> libtinfo5
>>>>> libutempter0
>>>>> libx11-6
>>>>> libx11-xcb1
>>>>> libxau6
>>>>> libxaw7
>>>>> libxcb1
>>>>> libxdmcp6
>>>>> libxext6
>>>>> libxfont1
>>>>> libxft2
>>>>> libxkbfile1
>>>>> libxmu6
>>>>> libxmuu1
>>>>> libxpm4
>>>>> libxrender1
>>>>> libxshmfence1
>>>>> libxt6
>>>>> nvidia-304
>>>>> nvidia-331
>>>>> x11-common
>>>>> x11-xkb-utils
>>>>> xauth
>>>>> xbitmaps
>>>>> xinit
>>>>> xkb-data
>>>>> xserver-xorg
>>>>> xserver-xorg-core
>>>>> xserver-xorg-input-evdev
>>>>> xserver-xorg-input-kbd
>>>>> xserver-xorg-input-mouse
>>>>> xserver-xorg-input-void
>>>>> xserver-xorg-video-nouveau
>>>>> xserver-xorg-video-vesa
>>>>> xterm
>>>>> "
>>>>> rm -rf staging
>>>>> mkdir staging
>>>>> cd staging
>>>>> apt-get download $pkgs
>>>>> for pkg in *.deb
>>>>> do
>>>>>     dpkg-deb -x $pkg .
>>>>> done
>>>>> tar -czvf x.tgz usr etc
>>>>> 2) transfer x.tgz to the Core system,
>>>>> remount / read-write,
>>>>> unpack into /,
>>>>> put 'xterm &' in ~/.xinitrc
>>>>> sudo startx
>>>>> I also had to add video modes to /etc/X/xorg.conf, but that's probably just
>>>>> my crappy monitor.
>>>>> That's an awful lot of bytes just to run X.  Presumably a real use
>>>>> would whittle that
>>>>> down and pickle just the minimal amount needed for your app (possibly
>>>>> remounting using atime, or tracing using strace, to see which files
>>>>> are really needed
>>>>> during a full run of the app).  And then there's the whole question of
>>>>> how to build a custom version of Core that includes these files,
>>>>> and lets you build a delta update stream for the custom system...
>>>> Hmm...
>>>> the official approach to extend a snappy system is NOT by adding stuff
>>>> to our system-image; instead, snappy systems are extended through a
>>>> special type of .snap package: FRAMEWORKS. Frameworks allow you to
>>>> extend the base-system for apps that use it. Unfortunately, our docs
>>>> don't explain this concept very well right now as we wanted to first
>>>> focus on seeing how far apps can go without extending the base system
>>>> (e.g. through bundling etc.).
>>>> Depending on what you are after, making X11 available part some
>>>> framework should be doable, but be warned that in almost all cases the
>>>> real challenge will be to make X11 behave securely so that other
>>>> snapps don't end up getting hacked and highjacked by other evil
>>>> snapps.
>>>> As a sidenote, if you are just looking at something that powers a GL
>>>> apps, maybe check if using MIR might be a valid alternative. I assume
>>>> that's not an option?
>>>> Hope that helped a bit. Let us know how things go!
>>>>  -  Alexander
>>>> p.s. for more info about frameworks, search for "frameworks" on
>>>> WRT to examples: the current only (and far from
>>>> complete) example of a framework is docker on snappy-hub: bzr branch
>>>> lp:~snappy-dev/snappy-hub/docker - I am also around on #snappy IRC for
>>>> more interactive chat.

More information about the snappy-devel mailing list