Ubiquity NG - was Re: ubiquity migrated to git
On Tue, May 8, 2018 at 7:31 PM, Simon Quigley <tsimonq2 at ubuntu.com> wrote:
> Hello Mark,
> On 05/05/2018 01:15 AM, Mark Shuttleworth wrote:
> <snip />
> > First, we have Curtin, which knows how to take a description of a
> > machine and do-the-right-thing; partitioning, installing, and cleaning
> > up. Curtin is neat and efficient, super-fast, and it's used by both MAAS
> > and the new Ubuntu Server installer, Subiquity. It knows how to install
> > a couple of different flavours of Linux, including Ubuntu and CentOS,
> > which could be handy. It's probably the best place for us to handle new
> > kinds of partitioning and root filesystem and network storage.
> > Second, we have MAAS, which has some very nice HTML interfaces for
> > configuring network and storage on a machine. All of that lines up with
> > Curtin, because MAAS uses Curtin to do the actual install. So we have
> > the beginnings of an HTML5 installer.
> Would we be able to customize this in a way that's fit for desktop users
> rather than server users? A fork might need to happen there.
There are no technical reasons why MAAS/Curtin can't be used for desktop
I'm not sure how much sense it makes to reuse the MAAS UI bits though.. We
only ask for network bits if you are not connected to a wireless network.
I'd love if we at least move to subiquity/curtin because that means we have
publish desktop MAAS images which has been something I've been pushing for
a while now .
This would push us in the direction of "one" best practice way to install
Ubuntu on almost everything.
It may even be possible with subiquity to have a text based fallback on a
normal live image. If possible
this might allow an Alternate style install (like Lubuntu has) for all
flavors for free.
> > Third, we have Electron, which is the HTML5 app framework used by world
> > class app developers. Skype, Spotify and a ton of GREAT apps on Ubuntu
> > are Electron apps.
> I respectfully disagree that this is the correct approach for a system
> installer. With all due respect to these very popular applications,
> Electron uses quite a bit of system resources and could be interesting
> to get working correctly. If you are absolutely certain that this is the
> way to go, I won't argue this point too much, but I believe that you
> would have triple the speed (and/or it would use a third of the memory)
> by writing a native application rather than an Electron one, and with
> proper testing and organization (perhaps by using a compiled language
> rather than an interpreted one, etc.), it would be a very welcome speed
> jump over the current Ubiquity codebase.
Additionally, we'd have to bring Chromium up to the requirements (snappy
edition) for Main. (which I wouldn't mind, but doesn't make sense just for
-------------- next part --------------
An HTML attachment was scrubbed...