wrote:
> On Tue, May 8, 2018 at 7:31 PM, Simon Quigley <tsimonq2@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
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 [1].
> 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)
The Korora guys were considering adding a web-based desktop frontend to
Anaconda a few years ago, and developed the Lens framework[1][2] for that
purpose. It's a much more lightweight alternative that also supports some
level of integration for Qt and GTK+ based desktop environments.
[1]:
https://kororaproject.org/about/news/lens-an-alernative-to-desktop-agnostic-uis
[2]: https://github.com/kororaproject/kp-lens
--
真実はいつも一つ！/ Always, there's only one truth!
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
