-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEXHq+og+GMEWcyMi14n8s+EWML6QFAlryM0UACgkQ4n8s+EWM
L6SinA//cgvYYB+vKFB+1fOjmJeMGmiSi6TseFRkUiS1UyZO20pWNjln1x2Lywob
pnpL8y+iAS119iTMUanJk5CL9A07Qm8ktBHhpA86AWzGe/wD8mAGuzJiiOqpEGS5
WMk0igb+SS8jfemGelWOCXVz04FtNApfdRheeeradO3vBbFE0Av5dwZRx2hDTXt5
q30VfhHBgEIqFun4sKl0i6401E1TVIXWsGPUTSMJRTzDiTYUFg8TXaiFzpjOBJNZ
9MXTx4NSKKiUKNRGZOS+2vyFYT3nT64At2Pg/w2cdlRjdY7aB5uvYHQkCFaFdMJI
LG23Ei9ftXGlm/D9KgI4DUIrUFRXnE1f//FGDeu1WOd6TiypqdqEhudxifQZZalR
pPRUdMN3fAavN8yxXCcFrLKOogiLyXyiUH18mkCBLJjSYyM/PTW6bNGDhTC13BLM
23efkCr5j42X0RNIfVSgkkppQheZRSjOpV2VOdsT49trVtfBCH2f9g4+ns9tQbXD
PdEEHkOCw5dDZdyx3Ulk7KnYv+ongMtmodipN7B9o7Fb6N8JEXpaoHRyfepaHFpb
jyvDjw6XvyYUrAlHBwFa1EMoWxeIh14H1O0SmU919TEc5Yk1wWcM+VfTrvtp5qr4
pcot+SaBXuVnJSidn+y1S1UY7WnnkgwA18As0rfNoju15tqbhnA=
=WYjI
-----END PGP SIGNATURE-----
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.
> 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.
> Fourth, we have snaps, which are just amazingly tasty ways to get the
> latest bits in the hands of your community.
I would also respectfully disagree that this is the correct way to
deliver a desktop system installer. With snaps, while you have the
advantage of one installer across all versions of Ubuntu (and the usual
advantages of such a workflow), it could sacrifice stability, especially
if the snap has to be updated to a new version on boot (think about
systems with no internet access on install time), and with confinement,
it needs to be done just right to get the proper bits to do a full
system install. There is also the issue currently with desktop
integration (so GTK or Qt theming will not work correctly, and a few
other issues that won't make the experience as smooth as can be).
I'm not entirely opposed to the idea of snapping it and delivering it
that way, but the ecosystem and integration has some issues that should
really be worked out before the installer is done this way. Delivering
as a deb does have the advantage of the Stable Release Updates process
for stable releases, which can ensure that proper QA processes are
followed (with bug tracking), and any Ubuntu Core Developer has the
upload access to provide bugfixes (and doesn't have to learn an entirely
new ecosystem to fix a bug in the installer, which is important for
flavors).
Thanks for the thread, Mark!
--
Simon Quigley
tsimonq2@ubuntu.com
tsimonq2 on freenode and OFTC
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4
