The current Ubuntu Desktop installer, Ubiquity, dates back to 2006. While still functional, Ubiquity hasn’t seen significant feature development for some years and due to its legacy is becoming cumbersome to maintain. Meanwhile, a new installer for Ubuntu Server has been developed, called Subiquity, which uses curtin.
Consolidating the installer for server and desktop on common technologies will mean we can deliver a consistent, robust, installation experience across the Ubuntu family and focus our efforts on maintaining a single code base.
The development process for the new desktop installer is being led by the Canonical Design Team and Ubuntu Desktop Team. Both teams have a wealth of experience navigating the challenges presented when installing a modern operating system.
Plan
We have been collaborating with the Flutter team at Google to enable Flutter for the Linux desktop. We will be leveraging this work to implement the desktop frontend of the new installer.
We have started working on the new desktop installer, and plan to have a preliminary version ready for testing in the 21.10 release; due in October 2021. This paves the way to transitioning to the new installer for the next LTS release, which will be 22.04, due for release in April 2022.
The Ubiquity installer will remain available in the Ubuntu archive for official flavours, remixes or derivatives to continue using in their images.
Rationale
We have evaluated existing desktop installer projects and toolkits. Our goal is to deliver a consistent installer experience across the Ubuntu product portfolio. Flutter is a great Open Source technology to deliver highly optimised desktop applications for Linux. We will leverage existing work of the Yaru team to ensure the new installer is consistent with the Ubuntu desktop style.
Creating a new desktop installer gives us the opportunity to revisit what features are most desirable to our community and enterprise customers. We have scoped the initial functional requirements, but welcome your feedback and contributions for the capabilities most important to you, your flavour, derivative or organisation.
I think this is a very good idea. Although Flutter may not be the best choice, as it only runs in Snaps. Also, the repair option is long overdue, good job.
uuu nice. I like that you guys are trying to replace the installer especially since the subiquity installer feels like its in another class completly with the whole speed of installing.
Flutter can be snapped like any other app, but that isn’t a requirement. A Flutter application is compiled to a native binary just like any other native Linux application.
I’m hoping for more ZFS installation options such as the ability to install to a mirrored or a RAIDZ pool. I would like to see the partitioning tool be able to create ZFS partitions and the ability to install Ubuntu to ZFS alongside Windows or another OS on a single disk.
It’s slightly OT here but the MATE welcome tool should be adjusted so that it installs all packages chosen in one command. It takes forever to install them all if you are using ZFS on your root drive because it creates a new snapshot and updates GRUB for every package you chose to install.
Great to see a repair option finally get added to the installer!
Dan i am not sure but i think that installing ubuntu with zfs alongside windows on a single disk is generaly not recommended because ZFS likes to take over whole device and because there is certien performance hit if it doesnt. and windows cant be installed on ZFS because it doesnt support it.
I have successfully installed Arch Linux with ZFS root alongside Ubuntu (installed to ext4) onto a single disk (using ALEZ) so it is certainly possible.
GhostBSD’s installer also supposedly allows this for FreeBSD (dual booting with ZFS on a partition of a single disk) although I haven’t tested that yet.
well personaly i dont have opinion either way but because ubuntu mainline desktop is gtk based same with most of its flavours GTK would make more sense then qt.
To my eyes it looks like those are distinctly different toolkits aimed at providing distinctly different experience. And while mixing them both would certainly work from a technical point, one thing you could not say is that they are visually consistent.
Quite the contrary they follow a very different design and UX approaches and that is simply because those are different toolkits for very different desktop environments. And since both have a clearly defined visual style and both are quite popular, users can immediately spot the difference. It actually hurts both design projects to mix them both as they have clear guidelines to ensure consistency and satisfactory user experience and mixing them with something different will degrade the user experience and quality of the overall product.
You can think about it like sweet and sour. I like vinegar and I like cake. Both are delicious in their own way. But nobody would ever put vinegar on their cake.
Now if flutter followed gnome hig, then you might say that it’s visually a good sweet and sour sauce. But it doesn’t, everything is different and the same colors does not make it consistent in any way.
You mean you’ll change the color scheme of a totally foreign toolkit and you think that makes it look consistent with the rest of the OS? It makes it stick out like a sore thumb. It totally still looks like an android app. Everything is different, the menus, the buttons, the ugly top bar etc…
Doesn’t Ubuntu use GTK? Using Flutter for something like this looks out of place. It doesn’t provide a consistent experience with the rest of Ubuntu.
Imagine Android, ChromeOS or Windows using GTK for their installer or initial setup.
What if Google decides to dump Flutter a year later? Are we stuck with maintaining all three ( d-i, subiquity, and flutter) for extended time periods (LTS).
I’m weary of adopting their technologies outside their own ecosystem. Look at what happened with Angular 1 and 2, Angular NativeScript, Google web designer, Google poly, Google Daydream… Even Dart was pretty much dead and then for whatever reason they decided to bring it back in Flutter.
Now one thing I will say is that Go will probably stay around for a long time.
Now I’d also be concerned about another thing. We don’t know what the US will do about their IT corporations but id be surprised if they don’t start breaking them up sooner or later. What would that mean for Flutter or any other project can’t be predicted. I tend to see GNOME and GTK as more future proof then anything Google can offer.
Another thing to consider is that Google is stuck on their material design and Flutter is fixed to it. And I don’t know how well material design has aged or will age in the future. With the bigger and bigger push away from it with trends like neumorphism and such I think that users and designers might slowly be tired of that same Material design that didn’t change much since Android Lolypop.
GNOME to me personally looks better. It’s not stuck with their design, they are always thinking, adapting, innovating and they constantly bring new improvements. On the other hand while they are doing that, Google is just selling us Flutter. They are guiding us into their ecosystem is what I mean by selling us Flutter. And if you thought Gnome might be difficult to deal with at times, try changing something in a project Flutter.
And while I may hate some of GNOME’s decisions, I’d be remiss not to say that they are doing a great work with their design and design progression.
In the end material design is a clear and unique element of a Google product, Google’s platforms and their ecosystem. Recognizable by everyone everywhere in the world. Material design is not a generic thing like it is portraying to be. It would hurt the Ubuntu brand to use it in their default apps.
Just like Apple and Windows don’t use it and just like Ubuntu doesn’t ship with any Qt apps and KDE neon doesn’t ship any GTK apps. So it hurts branding, visual consistency + ux and maintainability of the software.
