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 tsimo...@ubuntu.com tsimonq2 on freenode and OFTC 5C7A BEA2 0F86 3045 9CC8 C8B5 E27F 2CF8 458C 2FA4
signature.asc
Description: OpenPGP digital signature
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel