On Tue, May 8, 2018 at 7:31 PM, Simon Quigley <firstname.lastname@example.org> wrote:
On 05/05/2018 01:15 AM, Mark Shuttleworth wrote:
> 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 installs.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 to
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 this)