Fedora Workstation's Anaconda Web UI Installer Delayed To Fedora 41

[phoronix]

Phoronix: Fedora Workstation's Anaconda Web UI Installer Delayed To Fedora 41

For over two years Red Hat's engineers working on the Anaconda installer have been working on a modern web-based installer UI that integrates with Cockpit and is a modern alternative to their GTK-based installer interface for deploying Fedora Linux and eventually RHEL too. The hope was to offer this web UI installer option for Fedora Workstation 40 but that's now been delayed to Fedora 41...

https://www.phoronix.com/news/Fedora-Web-Installer-F41-Delay

[skeevy420]

My Anaconda don't want none
Unless Fedora got BUNS, hun

Batch Udisk Numeration Service

[Eudyptula]

EDIT: I misinterpreted the shape of the problem and now I'm more aligned with their sentiment. Perhaps a bit conflicted (probably because I really don't like the current installer and would much rather have the Calamares installer).

To be fair, the missing functionality is quite essential and I don't understand why this wasn't clear from the very beginning. Also, can someone tell me why Fedora didn't adopt Calamares instead of their own "really not great" installer?

---

Original comment:

Somewhat disappointing. The current installer is a weak point. Fedora 40 would've been such a complete release with DNF5, Plasma 6 and the new (hopefully better) installer!

I don't see how this can't be temporarily resolved with clear information and/or descriptive buttons like "Apply storage formatting (warning: cannot be undone) and continue to next step".

The text is just a random example from the top of my head, there are a lot of ways to make this "idiot-safe", so to speak.

"To avoid risking the unintended data loss due to this fundamental difference in how storage configuration changes are made, the Fedora Engineering and Steering Committee (FESCo) decided to delay the web UI installer change to the Fedora 41 cycle."

If the steps are descriptive and clear, it's fine for now until the installer is fully fleshed out. The entire installer already looks nothing like the old one and functions differently. It's immediately clear that it's different, for those familiar with the previous one.

Make the warning text red, make the user confirm twice (like you already do for certain options in the current installer). There are many ways to ensure users can't make hasty assumptions!

I agree you should be able to plan out and play around with storage configuration options before applying. However, this feature improvement can be released when it's ready, can it not? Why wait for the next release?


Does this really have to be delayed?

[johnandmegh]

I don't really see how this cannot be resolved with clear and descriptive buttons and information like "Apply storage formatting (warning: permanent) and continue to next step".

I might be wrong, but I would think the big problem is that the optimal user experience for partition changes is to build up a queue of changes, then apply with one confirmation for all - like how GParted works in most cases. Requiring every individual action to be confirmed, then applied, before determining the next action would be a step backward in functionality IMO.

[ehansin]

I've done a fair number of Fedora and RHEL-esqe installs. I saw the screenshots recently for the new installer and looked nice (same for what SuSE is doing.) To the point and not so much "noise" if you will. Happy to give it a go when have the opportunity to do so.

Regarding DNF5, it is really fast compared to DNF4. I have it installed on Fedora 39, with an "alias dnf='dnf5'" and "alias sudo='sudo '" in my aliases file, so can run it for my DNF. So far so good!

[Eudyptula]

I might be wrong, but I would think the big problem is that the optimal user experience for partition changes is to build up a queue of changes, then apply with one confirmation for all - like how GParted works in most cases. Requiring every individual action to be confirmed, then applied, before determining the next action would be a step backward in functionality IMO.

You're right, I initially misinterpreted it as storage configuration being applied when you went to the next step. But it's indeed a "apply per action" type of deal without the option to plan out the configuration on a whole before applying.

Now I'm more confused about how this behaviour was incorporated in the first place. Who on earth prefers it this way?

I've done a fair number of Fedora and RHEL-esqe installs. I saw the screenshots recently for the new installer and looked nice (same for what SuSE is doing.) To the point and not so much "noise" if you will. Happy to give it a go when have the opportunity to do so.

Regarding DNF5, it is really fast compared to DNF4. I have it installed on Fedora 39, with an "alias dnf='dnf5'" and "alias sudo='sudo '" in my aliases file, so can run it for my DNF. So far so good!

I'm confused as to why they don't use Calamares, it's always been better than Fedora's installer and it still is.

I've been waiting for DNF5 for a long time, Python is criminally slow. It'll be so satisfying I'll look for any excuse to watch it go.

[andyprough]

alias sudo='sudo '

What's the point of aliasing sudo to 'sudo '?

[andyprough]

Also, can someone tell me why Fedora didn't adopt Calamares instead of their own "really not great" installer?

I'm more familiar with SuSE's YaST installer than I am with Anaconda, but at least in the case of SuSE the Calamares installer would not give nearly enough detailed options. Probably the same with Fedora. You have to keep in mind that with SuSE and RedHat, their installers are going to be used in some extremely complex setups.

[finalzone]

I'm confused as to why they don't use Calamares, it's always been better than Fedora's installer and it still is.

Because the overhauled Anaconda, Fedora's installer, will be a web-based user interface using Cockpit framework.
Edit: andyprough beat me for the explanation about complex setups Calamares lacks.

[AdamW]

I'm more familiar with SuSE's YaST installer than I am with Anaconda, but at least in the case of SuSE the Calamares installer would not give nearly enough detailed options. Probably the same with Fedora. You have to keep in mind that with SuSE and RedHat, their installers are going to be used in some extremely complex setups.

Calamares also doesn't support kickstart, which is the real end boss of anaconda. If you want to get fired from Red Hat *really fast*, say "hey folks, I've got a great idea - let's ship an installer with no kickstart support!" https://github.com/calamares/calamares/issues/508

Still, you could imagine just slapping something like Calamares on a desktop spin, I guess. I'm sure Neal Gompa already has.