Running on real hardware...

[Dan Kegel]

I'm sure Xorg and its bazillion packages can be
built with a different prefix, but I'm not sure that nvidia/ati
drivers or dkms can be done outside of base.


On Mon, Dec 15, 2014 at 4:33 PM, Alexander Sack <asac at canonical.com> wrote:
> On Tue, Dec 16, 2014 at 12:57 AM, Dan Kegel <dank at kegel.com> wrote:
>> 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?
>
> our first snappy build release does not have the magic needed to make
> all legacy software that hard codes paths at built time work with zero
> effort. While that would be cool, I was kind of hoping that most grown
> up software has means to override where to look for modules,
> resources, binaries etc. through one out of env, cli args and .conf. I
> think I hear you saying that Xorg is one of those that just doesn't
> like to be relocated like that?
>
>>
>> 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.