Running on real hardware...

[Dan Kegel]

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.
- 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.