Running on real hardware...

[Dan Kegel]

OK, thanks.  Given that X wants to be installed at particular
locations, might I need to at least put some symlinks or mount
points in base to get that to work?

If it all works out, I'd still be interested in putting the reusable parts
(e.g. X + OpenGL) into a framework to share among other single-app
use cases.

On Mon, Dec 15, 2014 at 3:54 PM, Alexander Sack <asac at canonical.com> wrote:
> On Tue, Dec 16, 2014 at 12:21 AM, Dan Kegel <dank at kegel.com> 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 canonical.com> 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 kegel.com> 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
>>> ubuntu.com/snappy. 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.