Matters approaching

[Stéphane Graber]

On Tue, Mar 18, 2014 at 05:59:17AM -0700, Mark Shuttleworth wrote:
> Dear Tech Board
> 
> Our current phone images have pioneered some new approaches to
> delivering both system software ("image-based updates") and applications
> ("click packages"). The folks driving that work have solved some really
> thorny problems and the results feel great on the phone - I look forward
> to updates, because they have been very reliable (one glitch in six
> months) and the QA process that screens out bad images means I happily
> press the button every chance I get to update.
> 
> I'd like to ask the tech-board to look forward a few months in
> anticipation to the full convergence of phone, tablet and PC environments.
> 
> How could we deliver a system-image based platform to the laptop, with
> click based packages, that would still feel familiar, flexible and
> useful for a developer?
> 
> There are any number of points that need to be considered:
> 
>  * configuration in /etc/ and ways that can feel comfortable but remain
> secure
>  * the meaning of /usr/local/ in this sort of environments
>  * the use of LVM and other filesystem capabilities to enable user
> customisation
> 
> My expectation is this will be a very deep conversation and so I'm
> writing to request that you folks take time with some of the leads of
> the phone effort to consider the question before it becomes imminent
> (i.e. before too many people start trying to use their phones as
> laptops, or vice versa :)).
> 
> Thank you!
> Mark

Hi,

So I think there are 3 things here which we need to look at individually:

== Software convergence ==
This I believe is the main priority, the main example of this being the
current difference in Unity version between the desktop and the phone. I
believe same goes with indicators and a few other bits here and there.

This feels like the first and most important things to resolve before we
can consider any real convergance between desktop and phone/tablet.


== Click packages ==
Having all of our Ubuntu SDK based apps available on all platforms,
using click, I expect this should be pretty easy once 1) is resolved
and the desktop and phone share the same APIs and desktop environment.


== System images ==
That one I believe will be much much trickier to get right and I'm not
personaly convinced we'll find a solution which will ever work fine for
all our users, not by using system images as we currently think of them
anyway.

I believe some of our biggest problems there will be:
 - Allowing installation of our existing (non-click) packages. We have
   tens of thousands of packages which are currently installable and I
   really don't think we want to regress there. This also covers dealing
   with configuration files, upgrading between config file formats, ...
 - Supporting a much much larger selection of hardware, hardware
   components and installation setups (think, nvidia/ati binary drivers,
   RAID, hybrid HDDs, ...). Phones are a pretty easy target compared to
   that because while diferences between phone models are massive, there
   aren't nearly as many combinations as we can find on the desktop.
 - I doubt all of our desktop users will be happy having to reboot their
   entire systems possibly multiple times a day for updates. Phone updates
   are less of a problem due to the restricted number of security sensitive
   services running on them, so we can aggregate updates and only reboot
   once a week or so, desktops, not so much...

Taking just the first point, because we did spend a bit of time
discussing this last year while designing system-image and while we
didn't come up with a solution, we at least came up with most of the
problems and a few ideas:
 - Using overlayfs isn't an option there, overlayfs works as a
   copy-on-write fs overlay which means that if you were to install even a
   single package, the dpkg status database, as well as any other shared
   databases will be forked forever, leading to a pretty inconsistent
   state. overlayfs also comes with quite a few limitations of its own,
   like the lack of support for inotify.
 - Using block level overlays (LVM) is even worse as those simply don't
   allow rebasing while still keeping your changes...
 - Modifying dpkg to use multiple databases and install extra packages
   in a separate location could work, however, there are some edge cases
   that need to be taken care of, such as the removal of a package in the
   base image which is a dependency of a locally installed package, or the
   addition of a new package to the base system which is already part of
   the locally installed packages as well as package and version conflicts
   between those two.
 - Keep the base system entirely read-only, don't try to add extra
   packages to it but instead allow the user to setup a container of the
   version of their choosing (so they could be on trusty+1 but use a trusty
   container as LTS tend to have better support from ISVs), integration
   between the desktop and the container would then let them seemlessly
   install packages in there and use them, required data and devices would
   be made available to the container through bind-mounts or similar
   configuration. The main downside of this idea is the data duplication
   between the base system and the container. I am obviously biased
   towards that particular solution as that's already pretty close to what
   I'm using day to day on my laptop and I'm after all one of the upstream
   LXC maintainers :)


If we do manage to solve that problem, then it should be reasonably easy
to produce a desktop system image, targetting say laptops with a single
hard disk. I don't think we'd be able to do away with our current
install media any time soon, but offering some targeted images that way,
as well as the tools for corporate deployments to build and manage their
own, should be a realistic mid-term goal.

-- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/technical-board/attachments/20140331/a1e032fc/attachment.pgp>