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!
> MarkHi, 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
signature.asc
Description: Digital signature
-- technical-board mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/technical-board
