https://fedoraproject.org/wiki/Changes/AnacondaWebUIforFedoraWorkstation
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
== Summary == The new PatternFly-based UI has been developed by the Anaconda team for some time now and we would like to make it available for users of Fedora to enhance and modernize installation experience. As the first step in this user adoption process, we are targeting Fedora Workstation only.
== Owner ==
* Name: Anaconda team ([[User:jkonecny| Jiří Konečný]])
* Email: jkonecny@redhat.com * Name: Fedora Workstation SIG * Email: desktop@lists.fedoraproject.org
== Detailed Description == The Anaconda team has been working on a new web-based UI for the OS installer for some time. We would like to give users the fruits of our work and get feedback so that we know what we need to improve or where we should focus. To make the adoption as painless as possible, the Fedora Workstation was chosen as the first target so we have better control over the environment and can have a focus. Also, Fedora Workstation has a smaller featureset than other installation media. The adoption for the other media later is planned too, but the exact date will be based on feedback and our capacity allowance.
=== What will '''not''' change with the new Web UI? === The new UI will mostly use already existing functional code (some modifications are necessary), so the stability should be similar. The Anaconda specific kernel boot parameters are also staying almost unchanged. The Anaconda team aims to reduce functionality that is not used but still put a maintenance burden on the team. This should result in much easier future extensions and stability of the installer. The current approach is to start from what is known to be required and used, then add future features based on the feedback.
=== What is going to change with the new Web UI? === The new web UI is not just a change of the UI technology, which is based on the React and Cockpit framework, but also a complete overhaul of the user experience. The new UI is trying to be easier to use by removing most of the complexities but still leaving possibilities to do everything you might need to do. We are trying to achieve a state where even users who don’t have previous experience with the Linux operating system will be able to do the installation smoothly.
List of what is part of the new UI: * Wizard solution instead of hub and spoke * New welcome screen to select language (will be preselected from a language configured in system) * Timezone and date configuration * Disk selection * Guided partitioning * Review configuration * Installation progress * Build-in help
Let’s go over the important sections from the UI.
==== Use of wizard ==== Anaconda was a hub&spoke solution where users entered spoke to configure an aspect. The benefit of this solution is that you can skip what you don’t need. However, the drawback is that it’s much more information at once and harder to use when you are not familiar with what you need. For that reason, the team decided to go with an easier to use solution, the traditional wizard. See here for more details https://communityblog.fedoraproject.org/anaconda-is-getting-a-new-suit-and-a... .
==== Guided partitioning ==== The current (GTK) Anaconda UI approach is to have three types of partitioning. * Automatic - do everything automatically * Custom - you can do everything with top-down approach where users work on mount points and specified what technology they want to use and how * Blivet-gui - added later as bottom-up approach which enables users to create the partitioning stack themselves manually
These methods are giving great freedom but each of these has its issues. For automatic, the issue is almost no customizations and not a clear output. For custom and blivet-gui, you need to understand the Linux storage really well to know what you are doing, which could be intimidating. Because of those issues, we decided to choose another approach, which we are calling guided partitioning. This type of partitioning is giving users paths with explanations of what will happen but does not overload them with too many options at once. These paths could be then customized. This solution was taken as the best compromise between the automatic (no customization) and custom/blivet-gui, which was too heavy and hard to maintain.
We will provide the recommended solution and improved customization based on the users feedback. However, in case someone is not happy about the recommended solution, we are going to provide a way to guide users, to create their partitioning themselves (with a tool of their choice) and then tell Anaconda how to use it. This method could be also used for easy re-installation of the existing system and we are planning to improve the experience in the future even more.
==== Build-in help ==== Another pain point of the current UI is problematic help content. Currently, it’s a button that will show a lot of text from the documentation, which might be misleading because it’s not part of the feature development. To improve the state, the help side panel was added, which will provide specific help for what the user wants to know directly in a UI. For example, if you are in the guided partitioning screen you can find a link (blue text) with “learn more about the…” and after clicking on this you will find details about the given guided path. Another benefit of the new help solution is that it is part of the source code so it changes with the feature work and could be localized (harder to achieve before).
==== Changes not directly related to UI ==== The Anaconda team is in contact with Fedora Workstation SIG and actively working with them to get the best user experience for users. Together, we agreed on building the approach with the support of Gnome Initial Setup as part of the Fedora Workstation Live environment, which will prompt you for language and keyboard layout. Configuration from the system is then used by Anaconda. This way, Anaconda doesn't need to ask a second time for language (maybe just confirmation) and keyboard layout which will be converted from the live system into the installed system. This should result in a much better user experience.
=== Additional information === * We are not planning to add support for spins with this change, they will use the existing GTK UI. * We don’t support remote connections to the WebUI yet.
== Feedback == Currently we mainly discuss this with Fedora Workstation SIG and have their support for this change. We also have feedback from our preview builds https://fedoramagazine.org/anaconda-web-ui-preview-image-now-public/ . The feedback was mostly positive even though there are some concerns.
Other than that we also reached to Fedora QE team and [[User:Mattdm| Matthew Miller]] and more.
For more details about the feedback here are some tickets:
* https://pagure.io/fedora-workstation/issue/362 * https://pagure.io/fedora-workstation/issue/366 * https://pagure.io/fedora-workstation/issue/367 * https://pagure.io/fedora-workstation/issue/368 * https://pagure.io/fedora-workstation/issue/371 * https://pagure.io/fedora-workstation/issue/375 * https://pagure.io/fedora-workstation/issue/377 * https://github.com/rhinstaller/anaconda/discussions/categories/web-ui
== Benefit to Fedora == Fedora Workstation installation will have a more comfortable and better user experience, especially for the new-to-distro users. We are also targeting to have a consistent look and feel with Cockpit and Image Builder projects, so that users might be more familiar with the new Anaconda. By this, we would be more aligned with Fedora Workstation SIG goals of simple and easy-to-use solutions, and hide the complexities to make the installation experience more robust. It should be easier for users to reinstall the existing system. It will also allow the Anaconda team to make the extensions to the UI faster than it was before and should be less prone to errors compared to the current UI.
== Scope == * Proposal owners: ** Anaconda team ** Fedora Workstation SIG
* Other developers: Should not have impact out of the Fedora Workstation Live environment.
* Release engineering: Will be added
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: TBD
* Alignment with Community Initiatives:
== Upgrade/compatibility impact == No upgrade or compatibility impact.
== How To Test == Standard installation testing of Live installation always before. We already reached the Fedora QE team to discuss an impact on them and ideally set the test day for more comprehensive testing with more details.
Steps: * Download the ISO image (not yet available - WIP) * Start a VM with this ISO image * Run the installation * See journal log and/or browser console in case we missed error in the Anaconda
Bugs should be filed to [https://bugzilla.redhat.com/ Red Hat Bugzilla] on the Anaconda component.
== User Experience == Installation of the system should provide a much better and more polished user experience. Compared to the current UI users should be fine without the familiarity of the complexities of OS installation.
== Dependencies == None packages should be impacted by this change. The current GTK UI will still be available for other uses.
== Contingency Plan == * Contingency mechanism: Return back to the current GTK UI by changing packages to build the ISO. * Contingency deadline: Beta freeze * Blocks release? No, we can ship without the new web UI
Another solution for the contingency plan which we would like to have is support for the current GTK UI as a second UI on the same Live ISO. That should be doable easily and if the new UI would be really a blocker for someone, they can provide us feedback and until resolved use the GTK UI instead.
== Documentation == Documentation will be expected especially for custom partitioning replacement but not only that.
== Release Notes ==
Once upon a time, Aoife Moloney amoloney@redhat.com said:
== Summary == The new PatternFly-based UI has been developed by the Anaconda team for some time now and we would like to make it available for users of Fedora to enhance and modernize installation experience. As the first step in this user adoption process, we are targeting Fedora Workstation only.
One thing not mentioned: what does this do to the install image size, especially for network booting?
On Mon, 2023-06-26 at 12:19 -0500, Chris Adams wrote:
Once upon a time, Aoife Moloney amoloney@redhat.com said:
== Summary == The new PatternFly-based UI has been developed by the Anaconda team for some time now and we would like to make it available for users of Fedora to enhance and modernize installation experience. As the first step in this user adoption process, we are targeting Fedora Workstation only.
One thing not mentioned: what does this do to the install image size, especially for network booting?
It won't do anything to the network install image size for the present, because it won't be used for it - only for the Workstation live.
AIUI it shouldn't make the Workstation live any larger, because it's being run through Firefox, which is on the Workstation live already.
When this does get applied to the network install image it will likely have to make it a bit bigger, though it is a bit complicated. The current images actually already have a web engine in them - webkitgtk, as backing for yelp, to display anaconda's current help pages. Since the new UI also comes with a new help system which is not yelp-based, I think we'll actually end up effectively trading out webkitgtk and trading in firefox, hopefully, unless something else drags in webkitgtk somehow. So it's *possible* the change won't be huge, unless I'm missing something.
Dne 26. 06. 23 v 22:22 Adam Williamson napsal(a):
On Mon, 2023-06-26 at 12:19 -0500, Chris Adams wrote:
Once upon a time, Aoife Moloney amoloney@redhat.com said:
== Summary == The new PatternFly-based UI has been developed by the Anaconda team for some time now and we would like to make it available for users of Fedora to enhance and modernize installation experience. As the first step in this user adoption process, we are targeting Fedora Workstation only.
One thing not mentioned: what does this do to the install image size, especially for network booting?
It won't do anything to the network install image size for the present, because it won't be used for it - only for the Workstation live.
AIUI it shouldn't make the Workstation live any larger, because it's being run through Firefox, which is on the Workstation live already.
When this does get applied to the network install image it will likely have to make it a bit bigger, though it is a bit complicated. The current images actually already have a web engine in them - webkitgtk, as backing for yelp, to display anaconda's current help pages. Since the new UI also comes with a new help system which is not yelp-based, I think we'll actually end up effectively trading out webkitgtk and trading in firefox, hopefully, unless something else drags in webkitgtk somehow. So it's *possible* the change won't be huge, unless I'm missing something.
Yes, that is correct. We did some simple testing (might be inaccurate) and the size increase was around +40MB size. However, as said this is not true for Live image which should be almost the same size.
Jirka
Hi,
On 6/26/23 18:00, Aoife Moloney wrote:
https://fedoraproject.org/wiki/Changes/AnacondaWebUIforFedoraWorkstation
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
== Summary == The new PatternFly-based UI has been developed by the Anaconda team for some time now and we would like to make it available for users of Fedora to enhance and modernize installation experience. As the first step in this user adoption process, we are targeting Fedora Workstation only.
<snip>
This all sounds great, thank you for working on this.
=== Additional information ===
- We are not planning to add support for spins with this change, they
will use the existing GTK UI.
- We don’t support remote connections to the WebUI yet.
Hmm, this really is going to be a problem for low memory machines.
I regularly install Fedora Workstation on 2G (not an issue atm) and 1G (requires some trickery) RAM systems. I know this is not a lot of RAM but generally speaking these systems work fine for non demanding work after the install.
I'm pretty sure that not only the 1G but also the 2G RAM installs, which currently barely fit in RAM will become a problem with the new web installers. I was actually hoping the web-installer would help here since one can then just setup networking in the live environment and then have the browser showing the UI run somewhere else, hopefully reducing memory consumption compared to the gtk installer.
Is there any chance this (remote installs) can at least be enabled with a commandline option for advanced users?
I realize that making something for remote installs which works well for average users (and is also somehow using an authenticated connection) is quite a bit of work.
But in the interim a cmdline option to start listening on other interfaces then the loopback device (and to not start the local browser) would be nice to have for power users.
Note related to this ATM:
https://docs.fedoraproject.org/en-US/fedora/latest/release-notes/welcome/Har...
"Minimum System Configuration"
Says 2G is the supported minimum. It would be good to see if that can actually be made to / kept working.
Has anyone already tested the new installer on a system with its RAM limited to 2G ?
As said I have some tricks to help with this which currently allow me to go down to 1G. We should probably look into making some of those the default on the livecd.
E.g. changing a few things to not run evolution-data-services on the livecd (no calendering will be configured anyways) is an easy win of at least 50 MB of RAM.
Regards,
Hans
Dne 26. 06. 23 v 20:39 Hans de Goede napsal(a):
Hi,
On 6/26/23 18:00, Aoife Moloney wrote:
https://fedoraproject.org/wiki/Changes/AnacondaWebUIforFedoraWorkstation
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
== Summary == The new PatternFly-based UI has been developed by the Anaconda team for some time now and we would like to make it available for users of Fedora to enhance and modernize installation experience. As the first step in this user adoption process, we are targeting Fedora Workstation only.
<snip>
This all sounds great, thank you for working on this.
=== Additional information ===
- We are not planning to add support for spins with this change, they
will use the existing GTK UI.
- We don’t support remote connections to the WebUI yet.
Hmm, this really is going to be a problem for low memory machines.
I regularly install Fedora Workstation on 2G (not an issue atm) and 1G (requires some trickery) RAM systems. I know this is not a lot of RAM but generally speaking these systems work fine for non demanding work after the install.
I'm pretty sure that not only the 1G but also the 2G RAM installs, which currently barely fit in RAM will become a problem with the new web installers. I was actually hoping the web-installer would help here since one can then just setup networking in the live environment and then have the browser showing the UI run somewhere else, hopefully reducing memory consumption compared to the gtk installer.
Is there any chance this (remote installs) can at least be enabled with a commandline option for advanced users?
I realize that making something for remote installs which works well for average users (and is also somehow using an authenticated connection) is quite a bit of work.
But in the interim a cmdline option to start listening on other interfaces then the loopback device (and to not start the local browser) would be nice to have for power users.
Note related to this ATM:
https://docs.fedoraproject.org/en-US/fedora/latest/release-notes/welcome/Har...
"Minimum System Configuration"
Says 2G is the supported minimum. It would be good to see if that can actually be made to / kept working.
Has anyone already tested the new installer on a system with its RAM limited to 2G ?
As said I have some tricks to help with this which currently allow me to go down to 1G. We should probably look into making some of those the default on the livecd.
E.g. changing a few things to not run evolution-data-services on the livecd (no calendering will be configured anyways) is an easy win of at least 50 MB of RAM.
Regards,
Hans
If you need low memory footprint you probably don't want to use Live image for installation. It's the biggest one because it needs to have whole Gnome environment in memory. For that, I would suggest you to use Fedora Server network installation ISO. It has much smaller memory footprint for installation and still can install workstation system in the Software Selection. The Fedora Server ISO is not part of this change so still GTK UI. If you want even smaller memory footprint then you can run the Server ISO in the text mode by setting 'inst.text' kernel boot parameter in the grub menu.
We did some testing for the memory footprint of the web UI but it was some time ago and I don't remember the results. We can definitely verify it.
To answer your question, remote installations work (probably not great on Live environment). We have 'inst.webui.remote' kernel boot parameter to enable that, however, we decided to not officially support it from a few reasons: - we don't have support for HTTPS connections yet (we are looking on the security aspects of this) - it will not work on Live out of the box because Anaconda is not autostarted there (something needs to start the Anaconda backend). This is the same reason why we don't support VNC installations on Live.
About the improvements on the Live ISO, that should be a question on Fedora Workstation SIG. Anaconda team is not in charge of the environment on the Live ISO.
Best Regards, Jirka
Hi Jirka,
On 6/27/23 01:09, Jiri Konecny wrote:
Dne 26. 06. 23 v 20:39 Hans de Goede napsal(a):
Hi,
On 6/26/23 18:00, Aoife Moloney wrote:
https://fedoraproject.org/wiki/Changes/AnacondaWebUIforFedoraWorkstation
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
== Summary == The new PatternFly-based UI has been developed by the Anaconda team for some time now and we would like to make it available for users of Fedora to enhance and modernize installation experience. As the first step in this user adoption process, we are targeting Fedora Workstation only.
<snip>
This all sounds great, thank you for working on this.
=== Additional information ===
- We are not planning to add support for spins with this change, they
will use the existing GTK UI.
- We don’t support remote connections to the WebUI yet.
Hmm, this really is going to be a problem for low memory machines.
I regularly install Fedora Workstation on 2G (not an issue atm) and 1G (requires some trickery) RAM systems. I know this is not a lot of RAM but generally speaking these systems work fine for non demanding work after the install.
I'm pretty sure that not only the 1G but also the 2G RAM installs, which currently barely fit in RAM will become a problem with the new web installers. I was actually hoping the web-installer would help here since one can then just setup networking in the live environment and then have the browser showing the UI run somewhere else, hopefully reducing memory consumption compared to the gtk installer.
Is there any chance this (remote installs) can at least be enabled with a commandline option for advanced users?
I realize that making something for remote installs which works well for average users (and is also somehow using an authenticated connection) is quite a bit of work.
But in the interim a cmdline option to start listening on other interfaces then the loopback device (and to not start the local browser) would be nice to have for power users.
Note related to this ATM:
https://docs.fedoraproject.org/en-US/fedora/latest/release-notes/welcome/Har...
"Minimum System Configuration"
Says 2G is the supported minimum. It would be good to see if that can actually be made to / kept working.
Has anyone already tested the new installer on a system with its RAM limited to 2G ?
As said I have some tricks to help with this which currently allow me to go down to 1G. We should probably look into making some of those the default on the livecd.
E.g. changing a few things to not run evolution-data-services on the livecd (no calendering will be configured anyways) is an easy win of at least 50 MB of RAM.
Regards,
Hans
If you need low memory footprint you probably don't want to use Live image for installation. It's the biggest one because it needs to have whole Gnome environment in memory. For that, I would suggest you to use Fedora Server network installation ISO. It has much smaller memory footprint for installation and still can install workstation system in the Software Selection. The Fedora Server ISO is not part of this change so still GTK UI. If you want even smaller memory footprint then you can run the Server ISO in the text mode by setting 'inst.text' kernel boot parameter in the grub menu.
We did some testing for the memory footprint of the web UI but it was some time ago and I don't remember the results. We can definitely verify it.
The Workstation livecd is *the* default download on https://getfedora.org/ all the other Workstation options are hidden behind a "other Downloads" button.
Currently that default Workstation Download can be installed on machines with 2G of RAM matching the advertised minimum system requirements.
Telling people with systems with 2G of RAM that they now need to use the server iso and then manually select the right package set is IMHO an unacceptable regressions and I consider this a blocker for moving forward with making the web based installer for Fedora Workstation.
Also you cannot assume that everyone will have enough bandwidth to do network installs...
To answer your question, remote installations work (probably not great on Live environment). We have 'inst.webui.remote' kernel boot parameter to enable that, however, we decided to not officially support it from a few reasons:
- we don't have support for HTTPS connections yet (we are looking on the security aspects of this)
- it will not work on Live out of the box because Anaconda is not autostarted there (something needs to start the Anaconda backend). This is the same reason why we don't support VNC installations on Live.
Ok, so can you provide some instructions for how to make this work ? I guess it would be something like add the cmdline option + then start some systemd unit ? Can you please put some instructions for this in the testing section of: https://fedoraproject.org/wiki/Changes/AnacondaWebUIforFedoraWorkstation (with a note that this is currently not supported / recommended).
About the improvements on the Live ISO, that should be a question on Fedora Workstation SIG. Anaconda team is not in charge of the environment on the Live ISO.
Well you are suggesting a change that is likely going to significantly increase the amount of memory needed to do a livecd workstation install and as mentioned above pushing the requirements above 2G would basically block this change since 2G RAM is currently the advertised minimum RAM requirement for Fedora workstation installs.
So although I realize this is not entirely fair IMHO if you want to push forward with this feature then you may also be on the hook to look into reducing the memory footprint elsewhere so that the end result still fits in 2G RAM. I have some experience with tweaking the livecd to work with less RAM and I'm happy to share my experience in this, but I do not have time to actually implement needed changes for this.
Regards,
Hans
On 6/27/23 10:40, Hans de Goede wrote:
Ok, so can you provide some instructions for how to make this work ?
I guess it would be something like add the cmdline option + then start some systemd unit ? Can you please put some instructions for this in the testing section of: https://fedoraproject.org/wiki/Changes/AnacondaWebUIforFedoraWorkstation (with a note that this is currently not supported / recommended).
About the improvements on the Live ISO, that should be a question on
Fedora Workstation SIG. Anaconda team is not in charge of the environment on the Live ISO.
Well you are suggesting a change that is likely going to
significantly increase the amount of memory needed to do a livecd workstation install and as mentioned above pushing the requirements above 2G would basically block this change since 2G RAM is currently the advertised minimum RAM requirement for Fedora workstation installs.
So although I realize this is not entirely fair IMHO if you want to
push forward with this feature then you may also be on the hook to look into reducing the memory footprint elsewhere so that the end result still fits in 2G RAM. I have some experience with tweaking the livecd to work with less RAM and I'm happy to share my experience in this, but I do not have time to actually implement needed changes for this. Hi Hans,
it would indeed involve adding the `inst.webui` and `inst.webui.remote` kernel command line options and a systemd unit to start the relevant services (I *think* that'd only be `cockpit.service`).
You likely also want to truncate the `/etc/cockpit/allowed-users` file so you can use your empty password root login during installation.
This is normally taken care of when anaconda starts the webservice [1].
I've been working on landing live-installer generation in the image builder projects (there's a separate change request for this). You can follow progress on that here [2].
When the image builder PR lands the first follow ups will involve customization of the live-installer. Including kernel options, packages, and systemd service files. This would allow you to build a lighter version of the live-installer locally to use on the devices you work with.
I am interested to know which tweaks you perform to have the livecd use less RAM to see if I can codify those. Could you share your experience?
Regards, Simon
[1]: https://github.com/rhinstaller/anaconda/blob/413007214f8f7f0dfbdff98431eee57... [2]: https://github.com/osbuild/osbuild-composer/pull/3440
Hi Simon,
On 6/27/23 11:00, Simon de Vlieger wrote:
On 6/27/23 10:40, Hans de Goede wrote:
Ok, so can you provide some instructions for how to make this work ? I guess it would be something like add the cmdline option + then start some systemd unit ? Can you please put some instructions for this in the testing section of: https://fedoraproject.org/wiki/Changes/AnacondaWebUIforFedoraWorkstation (with a note that this is currently not supported / recommended).
About the improvements on the Live ISO, that should be a question on Fedora Workstation SIG. Anaconda team is not in charge of the environment on the Live ISO.
Well you are suggesting a change that is likely going to significantly increase the amount of memory needed to do a livecd workstation install and as mentioned above pushing the requirements above 2G would basically block this change since 2G RAM is currently the advertised minimum RAM requirement for Fedora workstation installs.
So although I realize this is not entirely fair IMHO if you want to push forward with this feature then you may also be on the hook to look into reducing the memory footprint elsewhere so that the end result still fits in 2G RAM. I have some experience with tweaking the livecd to work with less RAM and I'm happy to share my experience in this, but I do not have time to actually implement needed changes for this.
Hi Hans,
it would indeed involve adding the `inst.webui` and `inst.webui.remote` kernel command line options and a systemd unit to start the relevant services (I *think* that'd only be `cockpit.service`).
You likely also want to truncate the `/etc/cockpit/allowed-users` file so you can use your empty password root login during installation.
This is normally taken care of when anaconda starts the webservice [1].
I've been working on landing live-installer generation in the image builder projects (there's a separate change request for this). You can follow progress on that here [2].
When the image builder PR lands the first follow ups will involve customization of the live-installer. Including kernel options, packages, and systemd service files. This would allow you to build a lighter version of the live-installer locally to use on the devices you work with.
I am interested to know which tweaks you perform to have the livecd use less RAM to see if I can codify those. Could you share your experience?
At the end of this email is a copy & paste of my own notes of the set of hacks which I use to do a livecd install on 1G RAM x86 tablets.
Low hanging fruit would be evolution and gnome-software + packagekit.
There are 3 ways (IIRC) how the whole set of evolution-daya-server processes gets started on a GNOME session:
1. Through /etc/xdg/autostart/org.gnome.Evolution-alarm-notify.desktop for this we would need some way to annotate .desktop files to not start on a livecd. This could be e.g. a X-GNOME-no-livecd-autostart=yes on the .desktop + code in GNOME's code to generate systemd user unit files to honor this.
2. Through a calendar search provider. This can easily be disabled in the livecd sessions with a drop-in gconf settings file disabling the search provider. In general many of the gnome-shell search providers can be quite heavy for low spec machines. I think there might even already be some code to disable some of them.
3. Stop gnome-shell starting /usr/libexec/gnome-shell-calendar-server, which does the calendar integration in the clock widget in the top bar. The main gnome-shell talks to this over a dbus proxy and if it cannot be started it logs one warning and everything is fine.
Making it possible to run gnome-shell with calendar integration disabled has been on my wishlist for quite a while now. This may also be useful for the efforts to make gnome-shell work better on mobile devices. Since the evolution data server processes might be a bit too heavy for some mobile platforms too.
As for gnome-software + packagekit getting started (and taking up quite a lot of RAM). I think these might already be disabled on the livecd case, since auto downloading updates to have them ready for installation on shutdown / reboot makes little sense there. So the first thing to do there would be to check if these are running at all.
If they are running there are 2 places where gnome-software gets started:
1. /etc/xdg/autostart/org.gnome.Software.desktop 2. From a gnome-shell search provider
As for packagekit (will that still be there in F39?) this gets triggered by both gnome-software as well as by some code in gnome-shell talking to it to see if offline-updates should be offered on shutdown/reboot.
One last thing to consider is to slightly increase the zram factor on low RAM systems. Currently the zram real ram relation is 1:1 which assuming a worst case compression of 1:2 means that at full zram we end up with 1/2 real RAM left, 1/2 RAM used for compressed swap through zram.
But typically RAM contents compresses pretty well, at least achieving 1:3 compression. So if we are willing to reserve half of the total RAM for compressed swap through zram then we could make the zram size 1.5 times real RAM.
Regards,
Hans
p.s. here is the promised 1:1 copy of my notes on doing 1G RAM installs:
Fedora workstation Live install on 1G machine: - At boot edit cmdline, add "3" - vi /lib/systemd/zram-generator.conf change zram-size to 2048 - systemctl stop systemd-zram-setup@.service - systemctl start systemd-zram-setup@.service - rm /usr/libexec/gnome-shell-calendar-server - rm /etc/xdg/autostart/org.gnome.Evolution-alarm-notify.desktop - rm /usr/bin/ibus-daemon - systemctl disable --now sssd-kcm.socket - backup existing efi\boot\bootx64.efi ? - blkdiscard to fully-wipe ? - resize partitions to make space ? - systemctl start gdm - settings -> search -> disable - start a terminal with top, press shift+M kill unnecessary processes like sssd_kcm, gnome-calendar, evolution*, tracker, ... - start install to disk, cross fingers
On 6/27/23 05:00, Simon de Vlieger wrote:
On 6/27/23 10:40, Hans de Goede wrote:
Ok, so can you provide some instructions for how to make this work ?
I guess it would be something like add the cmdline option + then start some systemd unit ? Can you please put some instructions for this in the testing section of: https://fedoraproject.org/wiki/Changes/AnacondaWebUIforFedoraWorkstation (with a note that this is currently not supported / recommended).
About the improvements on the Live ISO, that should be a question on
Fedora Workstation SIG. Anaconda team is not in charge of the environment on the Live ISO.
Well you are suggesting a change that is likely going to
significantly increase the amount of memory needed to do a livecd workstation install and as mentioned above pushing the requirements above 2G would basically block this change since 2G RAM is currently the advertised minimum RAM requirement for Fedora workstation installs.
So although I realize this is not entirely fair IMHO if you want to
push forward with this feature then you may also be on the hook to look into reducing the memory footprint elsewhere so that the end result still fits in 2G RAM. I have some experience with tweaking the livecd to work with less RAM and I'm happy to share my experience in this, but I do not have time to actually implement needed changes for this. Hi Hans,
it would indeed involve adding the `inst.webui` and `inst.webui.remote` kernel command line options and a systemd unit to start the relevant services (I *think* that'd only be `cockpit.service`).
Remote installation is not a solution to the memory bloat. It only pushes the problem to whatever machine the browser runs on, and it has significant and negative security implications. A solution here would be ensuring that the web UI uses no more RAM than the GTK UI that preceded it.
On 7/2/23 23:56, Demi Marie Obenour wrote:
Remote installation is not a solution to the memory bloat. It only pushes the problem to whatever machine the browser runs on, and it has significant and negative security implications. A solution here would be ensuring that the web UI uses no more RAM than the GTK UI that preceded it.
Hi Demi Marie,
From what I can see by using `smem` the RSS/PSS for the Anaconda GTK installer in Fedora 38 is 62 MiB RSS and 22 MiB PSS. The Anaconda WebUI installer (Firefox) in Fedora 39 is 170 MiB RSS and 115 MiB PSS.
Note that Hans mentioned removing/disabling sssd_kcm and gnome-calendar in his thread about minimizing memory usage which is a much larger dent in total memory usage in the scheme of things.
Personally I'd also like to point out that I an using a 2 GiB memory single core VM to test these images to see if the live installer performs on the lower memory devices (yes, I think we can call 2 GiB low memory nowadays...).
Regards,
Simon
On 7/3/23 03:18, Simon de Vlieger wrote:
On 7/2/23 23:56, Demi Marie Obenour wrote:
Remote installation is not a solution to the memory bloat. It only pushes the problem to whatever machine the browser runs on, and it has significant and negative security implications. A solution here would be ensuring that the web UI uses no more RAM than the GTK UI that preceded it.
Hi Demi Marie,
From what I can see by using `smem` the RSS/PSS for the Anaconda GTK installer in Fedora 38 is 62 MiB RSS and 22 MiB PSS. The Anaconda WebUI installer (Firefox) in Fedora 39 is 170 MiB RSS and 115 MiB PSS.
Note that Hans mentioned removing/disabling sssd_kcm and gnome-calendar in his thread about minimizing memory usage which is a much larger dent in total memory usage in the scheme of things.
Personally I'd also like to point out that I an using a 2 GiB memory single core VM to test these images to see if the live installer performs on the lower memory devices (yes, I think we can call 2 GiB low memory nowadays...).
Regards,
Simon
Fair. I wonder how much of that memory use would go away if instead of using Firefox, the web content ran in an embedded WebKitGTK+ webview. Browser security is not a concern here because in this case the web content is trusted, and this would also allow using WebKitGTK+’s URL redirection features instead of HTTP over localhost.
That said, I do want to check that the new Anaconda installer and all of its transitive dependencies will be built from source on Fedora infrastructure. That means _actual_ sources as found in the SCM repository, not the minified blobs one finds on NPM. Web stuff has historically been extremely packaging-unfriendly for this reason, and the Node ecosystem has a long history of supply-chain attacks. Using a React-based UI should mean finding the original source code to all of the transitive NPM dependencies, then rebuilding all of them on Fedora infrastructure.
On 7/3/23 17:18, Demi Marie Obenour wrote:
Fair. I wonder how much of that memory use would go away if instead of using Firefox, the web content ran in an embedded WebKitGTK+ webview. Browser security is not a concern here because in this case the web content is trusted, and this would also allow using WebKitGTK+’s URL redirection features instead of HTTP over localhost.
Funnily enough it was switched explicitly from webkitgtk to Firefox for a reason I forget; I think it was related to disk size. Perhaps Martin or Jiri has more details to share on that.
That said, I do want to check that the new Anaconda installer and all of its transitive dependencies will be built from source on Fedora infrastructure. That means _actual_ sources as found in the SCM repository, not the minified blobs one finds on NPM. Web stuff has historically been extremely packaging-unfriendly for this reason, and the Node ecosystem has a long history of supply-chain attacks. Using a React-based UI should mean finding the original source code to all of the transitive NPM dependencies, then rebuilding all of them on Fedora infrastructure.
As far as I know cockpit builds (don't know where) all its dependencies and ships them as part of their package but I could be very wrong on this. You could take a look there or direct questions about it there.
The Anaconda WebUI is implemented "in" cockpit.
On Mon, Jul 3 2023 at 06:15:43 PM +0200, Simon de Vlieger cmdr@supakeen.com wrote:
Funnily enough it was switched explicitly from webkitgtk to Firefox for a reason I forget; I think it was related to disk size. Perhaps Martin or Jiri has more details to share on that.
It's because we're going to remove WebKitGTK from ELN.
Michael
On 7/3/23 12:30, Michael Catanzaro wrote:
On Mon, Jul 3 2023 at 06:15:43 PM +0200, Simon de Vlieger cmdr@supakeen.com wrote:
Funnily enough it was switched explicitly from webkitgtk to Firefox for a reason I forget; I think it was related to disk size. Perhaps Martin or Jiri has more details to share on that.
It's because we're going to remove WebKitGTK from ELN.
Michael
Why is that? WebKitGTK+ is one of those packages that one should only ship if one is willing to take every update from upstream, but my understanding is that WebKitGTK+ tries quite hard to make this easy.
On Mon, Jul 3 2023 at 12:32:02 PM -0400, Demi Marie Obenour demiobenour@gmail.com wrote:
Why is that? WebKitGTK+ is one of those packages that one should only ship if one is willing to take every update from upstream, but my understanding is that WebKitGTK+ tries quite hard to make this easy.
The set of packages to include in ELN is a business decision (which is in contrast to normal Fedora, where Fedora contributors should hopefully be making decisions in the best interest of the Fedora community). Although I don't get to talk directly about future enterprise Linux, what we are doing in ELN is inherently public and you can see some discussion here:
https://src.fedoraproject.org/rpms/webkitgtk/pull-request/4
Michael
Hi
3. července 2023 18:57:39 SELČ, Michael Catanzaro mcatanzaro@redhat.com napsal:
On Mon, Jul 3 2023 at 12:32:02 PM -0400, Demi Marie Obenour demiobenour@gmail.com wrote:
Why is that? WebKitGTK+ is one of those packages that one should only ship if one is willing to take every update from upstream, but my understanding is that WebKitGTK+ tries quite hard to make this easy.
The set of packages to include in ELN is a business decision (which is in contrast to normal Fedora, where Fedora contributors should hopefully be making decisions in the best interest of the Fedora community). Although I don't get to talk directly about future enterprise Linux, what we are doing in ELN is inherently public and you can see some discussion here:
https://src.fedoraproject.org/rpms/webkitgtk/pull-request/4
Michael
Thanks Michael for answering this. I'll also add that even now we already hit a bug in WebKit which seems to not get fixed anytime soon. In other words Firefox has much better support level.
Anyway, if someone really wish for something else to show the Anaconda it could be discussed. It's definitely doable but we have to think about maintainability PoV.
Best Regards, Jirka
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Hello.
And to add to the reasons, if the GTK4 bindings of webkit would be used, we would lose screen reader accessibility completely, see https://bugs.webkit.org/show_bug.cgi?id=227528.
Regards,
Lukáš
Dne 03.07.2023 v 18:15 Simon de Vlieger napsal(a):
On 7/3/23 17:18, Demi Marie Obenour wrote:
Fair. I wonder how much of that memory use would go away if instead of using Firefox, the web content ran in an embedded WebKitGTK+ webview. Browser security is not a concern here because in this case the web content is trusted, and this would also allow using WebKitGTK+’s URL redirection features instead of HTTP over localhost.
Funnily enough it was switched explicitly from webkitgtk to Firefox for a reason I forget; I think it was related to disk size. Perhaps Martin or Jiri has more details to share on that.
That said, I do want to check that the new Anaconda installer and all of its transitive dependencies will be built from source on Fedora infrastructure. That means _actual_ sources as found in the SCM repository, not the minified blobs one finds on NPM. Web stuff has historically been extremely packaging-unfriendly for this reason, and the Node ecosystem has a long history of supply-chain attacks. Using a React-based UI should mean finding the original source code to all of the transitive NPM dependencies, then rebuilding all of them on Fedora infrastructure.
As far as I know cockpit builds (don't know where) all its dependencies and ships them as part of their package but I could be very wrong on this. You could take a look there or direct questions about it there.
The Anaconda WebUI is implemented "in" cockpit. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Hi, see my replies below.
2. července 2023 23:56:59 SELČ, Demi Marie Obenour demiobenour@gmail.com napsal:
On 6/27/23 05:00, Simon de Vlieger wrote:
On 6/27/23 10:40, Hans de Goede wrote:
Ok, so can you provide some instructions for how to make this work ?
I guess it would be something like add the cmdline option + then start some systemd unit ? Can you please put some instructions for this in the testing section of: https://fedoraproject.org/wiki/Changes/AnacondaWebUIforFedoraWorkstation (with a note that this is currently not supported / recommended).
About the improvements on the Live ISO, that should be a question on
Fedora Workstation SIG. Anaconda team is not in charge of the environment on the Live ISO.
Well you are suggesting a change that is likely going to
significantly increase the amount of memory needed to do a livecd workstation install and as mentioned above pushing the requirements above 2G would basically block this change since 2G RAM is currently the advertised minimum RAM requirement for Fedora workstation installs.
So although I realize this is not entirely fair IMHO if you want to
push forward with this feature then you may also be on the hook to look into reducing the memory footprint elsewhere so that the end result still fits in 2G RAM. I have some experience with tweaking the livecd to work with less RAM and I'm happy to share my experience in this, but I do not have time to actually implement needed changes for this. Hi Hans,
it would indeed involve adding the `inst.webui` and `inst.webui.remote` kernel command line options and a systemd unit to start the relevant services (I *think* that'd only be `cockpit.service`).
Remote installation is not a solution to the memory bloat. It only pushes the problem to whatever machine the browser runs on, and it has significant and negative security implications. A solution here would be ensuring that the web UI uses no more RAM than the GTK UI that preceded it.
Please, take into account that we are not an application which stays open on background for hours (usually), so you can't put this to the same level as music player or similar apps. Anyway, I'm pretty sure that every usable machine as desktop PC, is able to open one web page for the installation process.
From the other point, I wonder how much memory the VNC client (solution right now) is taking. And security point with VNC is (based on my understanding) maybe worse than HTTPS browsers.
Hard to say what technology has the same memory footprint as GTK3. I think, there are not many options. From the other point, using this logic in the past, we would still be using ncurses based installations. Don't take me wrong, I see your point and memory footprint is important. Just saying it is not the only point you should take into account.
Best Regards, Jirka
On Mon, Jul 3, 2023 at 6:36 PM Jiří Konečný jiri.konec@pacse.eu wrote:
Hi, see my replies below.
- července 2023 23:56:59 SELČ, Demi Marie Obenour demiobenour@gmail.com napsal:
On 6/27/23 05:00, Simon de Vlieger wrote:
On 6/27/23 10:40, Hans de Goede wrote:
Ok, so can you provide some instructions for how to make this work ?
I guess it would be something like add the cmdline option + then start some systemd unit ? Can you please put some instructions for this in the testing section of: https://fedoraproject.org/wiki/Changes/AnacondaWebUIforFedoraWorkstation (with a note that this is currently not supported / recommended).
About the improvements on the Live ISO, that should be a question on
Fedora Workstation SIG. Anaconda team is not in charge of the environment on the Live ISO.
Well you are suggesting a change that is likely going to
significantly increase the amount of memory needed to do a livecd workstation install and as mentioned above pushing the requirements above 2G would basically block this change since 2G RAM is currently the advertised minimum RAM requirement for Fedora workstation installs.
So although I realize this is not entirely fair IMHO if you want to
push forward with this feature then you may also be on the hook to look into reducing the memory footprint elsewhere so that the end result still fits in 2G RAM. I have some experience with tweaking the livecd to work with less RAM and I'm happy to share my experience in this, but I do not have time to actually implement needed changes for this. Hi Hans,
it would indeed involve adding the `inst.webui` and `inst.webui.remote` kernel command line options and a systemd unit to start the relevant services (I *think* that'd only be `cockpit.service`).
Remote installation is not a solution to the memory bloat. It only pushes the problem to whatever machine the browser runs on, and it has significant and negative security implications. A solution here would be ensuring that the web UI uses no more RAM than the GTK UI that preceded it.
Please, take into account that we are not an application which stays open on background for hours (usually), so you can't put this to the same level as music player or similar apps. Anyway, I'm pretty sure that every usable machine as desktop PC, is able to open one web page for the installation process.
From the other point, I wonder how much memory the VNC client (solution right now) is taking. And security point with VNC is (based on my understanding) maybe worse than HTTPS browsers.
Hard to say what technology has the same memory footprint as GTK3. I think, there are not many options. From the other point, using this logic in the past, we would still be using ncurses based installations. Don't take me wrong, I see your point and memory footprint is important. Just saying it is not the only point you should take into account.
I would also note that the work being done here does not obviate the future return of a community-developed graphical frontend for Anaconda. For example, the previous architecture made it impossible for anyone to consider developing a Qt based frontend for Anaconda. That option is now open for the first time in Anaconda's history.
And the GUI could run unprivileged while the Anaconda services run privileged in the background, which is required for a Wayland-based application anyway.
4. července 2023 0:44:41 SELČ, Neal Gompa ngompa13@gmail.com napsal:
On Mon, Jul 3, 2023 at 6:36 PM Jiří Konečný jiri.konec@pacse.eu wrote:
Hi, see my replies below.
- července 2023 23:56:59 SELČ, Demi Marie Obenour demiobenour@gmail.com napsal:
On 6/27/23 05:00, Simon de Vlieger wrote:
On 6/27/23 10:40, Hans de Goede wrote:
Ok, so can you provide some instructions for how to make this work ?
I guess it would be something like add the cmdline option + then start some systemd unit ? Can you please put some instructions for this in the testing section of: https://fedoraproject.org/wiki/Changes/AnacondaWebUIforFedoraWorkstation (with a note that this is currently not supported / recommended).
About the improvements on the Live ISO, that should be a question on
Fedora Workstation SIG. Anaconda team is not in charge of the environment on the Live ISO.
Well you are suggesting a change that is likely going to
significantly increase the amount of memory needed to do a livecd workstation install and as mentioned above pushing the requirements above 2G would basically block this change since 2G RAM is currently the advertised minimum RAM requirement for Fedora workstation installs.
So although I realize this is not entirely fair IMHO if you want to
push forward with this feature then you may also be on the hook to look into reducing the memory footprint elsewhere so that the end result still fits in 2G RAM. I have some experience with tweaking the livecd to work with less RAM and I'm happy to share my experience in this, but I do not have time to actually implement needed changes for this. Hi Hans,
it would indeed involve adding the `inst.webui` and `inst.webui.remote` kernel command line options and a systemd unit to start the relevant services (I *think* that'd only be `cockpit.service`).
Remote installation is not a solution to the memory bloat. It only pushes the problem to whatever machine the browser runs on, and it has significant and negative security implications. A solution here would be ensuring that the web UI uses no more RAM than the GTK UI that preceded it.
Please, take into account that we are not an application which stays open on background for hours (usually), so you can't put this to the same level as music player or similar apps. Anyway, I'm pretty sure that every usable machine as desktop PC, is able to open one web page for the installation process.
From the other point, I wonder how much memory the VNC client (solution right now) is taking. And security point with VNC is (based on my understanding) maybe worse than HTTPS browsers.
Hard to say what technology has the same memory footprint as GTK3. I think, there are not many options. From the other point, using this logic in the past, we would still be using ncurses based installations. Don't take me wrong, I see your point and memory footprint is important. Just saying it is not the only point you should take into account.
I would also note that the work being done here does not obviate the future return of a community-developed graphical frontend for Anaconda. For example, the previous architecture made it impossible for anyone to consider developing a Qt based frontend for Anaconda. That option is now open for the first time in Anaconda's history.
And the GUI could run unprivileged while the Anaconda services run privileged in the background, which is required for a Wayland-based application anyway.
Good point Neal.
That is correct, if anyone would like to have the ncourses frontend again, you can create it yourself. 😃
Jirka
On Tue, 2023-06-27 at 10:40 +0200, Hans de Goede wrote:
So although I realize this is not entirely fair IMHO if you want to push forward with this feature then you may also be on the hook to look into reducing the memory footprint elsewhere so that the end result still fits in 2G RAM. I have some experience with tweaking the livecd to work with less RAM and I'm happy to share my experience in this, but I do not have time to actually implement needed changes for this.
To be fair, you're writing as if it's certain that a webUI-based Workstation live cannot install to a 2G system, but AFAIK that has not yet been demonstrated. It would seem reasonable to test it before deciding we have a huge blocker issue here.
Hi,
On 6/27/23 12:36, Adam Williamson wrote:
On Tue, 2023-06-27 at 10:40 +0200, Hans de Goede wrote:
So although I realize this is not entirely fair IMHO if you want to push forward with this feature then you may also be on the hook to look into reducing the memory footprint elsewhere so that the end result still fits in 2G RAM. I have some experience with tweaking the livecd to work with less RAM and I'm happy to share my experience in this, but I do not have time to actually implement needed changes for this.
To be fair, you're writing as if it's certain that a webUI-based Workstation live cannot install to a 2G system, but AFAIK that has not yet been demonstrated. It would seem reasonable to test it before deciding we have a huge blocker issue here.
Right, first we need to test if this is a problem at all. That is why I wrote "*may also* be on the hook".
Regards,
Hans
On 6/27/23 13:04, Hans de Goede wrote:
Hi,
On 6/27/23 12:36, Adam Williamson wrote:
To be fair, you're writing as if it's certain that a webUI-based Workstation live cannot install to a 2G system, but AFAIK that has not yet been demonstrated. It would seem reasonable to test it before deciding we have a huge blocker issue here.
Right, first we need to test if this is a problem at all. That is why I wrote "*may also* be on the hook".
What I read from this is that test ISOs should be provided ASAP so people can test them out in their usecases. I'm currently working on getting those somewhere together with the Anaconda team and will update this thread once available.
Regards,
Simon
On Mon, Jun 26, 2023, at 7:09 PM, Jiri Konecny wrote:
Dne 26. 06. 23 v 20:39 Hans de Goede napsal(a):
Says 2G is the supported minimum. It would be good to see if that can actually be made to / kept working.
Has anyone already tested the new installer on a system with its RAM limited to 2G ?
If you need low memory footprint you probably don't want to use Live image for installation. It's the biggest one because it needs to have whole Gnome environment in memory. For that, I would suggest you to use Fedora Server network installation ISO.
I recommend Everything netinstaller for the desktop use case. It's also a netinstaller, but the partitioning defaults are the same as Workstation edition.
It's not that easy to find with the new web site design. It's in alternative downloads. I had to web search to find it. But it is the first option on that page.
https://alt.fedoraproject.org/
On Mon, 2023-06-26 at 17:00 +0100, Aoife Moloney wrote:
https://fedoraproject.org/wiki/Changes/AnacondaWebUIforFedoraWorkstation
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
== Summary == The new PatternFly-based UI has been developed by the Anaconda team for some time now and we would like to make it available for users of Fedora to enhance and modernize installation experience. As the first step in this user adoption process, we are targeting Fedora Workstation only.
I am in favor of giving the web UI a shot, but I do think this is a pretty aggressive timeline given the amount of fairly large issues that remain to be resolved, especially exactly how the 'choose-your-own- partitioning' workflow is going to run (considering the stuff we discussed about constraints around partition size and boot partition requirements and disk label type requirements and so on). I think we need to be really ready, in advance, to pull the contingency lever for this one if it seems necessary. It should be fairly safe to do, since we'll still be testing the existing UI on other images, including the KDE live.
Naming nitpicks: I'm pretty sure the existing non-custom partitioning flow is formally called "guided partitioning", so calling a new slightly-more-customizable-one "guided partitioning" and retroactively renaming the existing one "automatic partitioning" might be a bit confusing, at least to old-timers. Also, I still think of the existing UI as 'newUI', so I'm gonna keep calling this one 'webUI'. :D
Hi Adam,
Dne 26. 06. 23 v 22:25 Adam Williamson napsal(a):
On Mon, 2023-06-26 at 17:00 +0100, Aoife Moloney wrote:
https://fedoraproject.org/wiki/Changes/AnacondaWebUIforFedoraWorkstation
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
== Summary == The new PatternFly-based UI has been developed by the Anaconda team for some time now and we would like to make it available for users of Fedora to enhance and modernize installation experience. As the first step in this user adoption process, we are targeting Fedora Workstation only.
I am in favor of giving the web UI a shot, but I do think this is a pretty aggressive timeline given the amount of fairly large issues that remain to be resolved, especially exactly how the 'choose-your-own- partitioning' workflow is going to run (considering the stuff we discussed about constraints around partition size and boot partition requirements and disk label type requirements and so on). I think we need to be really ready, in advance, to pull the contingency lever for this one if it seems necessary. It should be fairly safe to do, since we'll still be testing the existing UI on other images, including the KDE live.
First, thanks you and your team for all the help.
I won't lie, we are on tight deadline, however, we decided that we would like to try to get the web UI in, so we have more feedback from the real users, thus we know what to focus on. Also, the benefit is that the fallback is pretty simple (just use the current GTK UI), so if we found any blocker, we can easily just post-pone this change to next Fedora.
Another fallback is to also to add the current UI to the image next to the web UI. If we release the ISO and users will miss something it won't be blocking issue to anyone.
We are trying to embrace quick releases and fast development cycle, by getting valuable feedback on real usage from our community, while ensuring that we provide a safe fallback solutions at any point.
Best Regards, Jirka
Naming nitpicks: I'm pretty sure the existing non-custom partitioning flow is formally called "guided partitioning", so calling a new slightly-more-customizable-one "guided partitioning" and retroactively renaming the existing one "automatic partitioning" might be a bit confusing, at least to old-timers. Also, I still think of the existing UI as 'newUI', so I'm gonna keep calling this one 'webUI'. :D
Dne 26. 06. 23 v 18:00 Aoife Moloney napsal(a):
https://fedoraproject.org/wiki/Changes/AnacondaWebUIforFedoraWorkstation
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
== Summary == The new PatternFly-based UI has been developed by the Anaconda team for some time now and we would like to make it available for users of Fedora to enhance and modernize installation experience. As the first step in this user adoption process, we are targeting Fedora Workstation only.
== Owner ==
Name: Anaconda team ([[User:jkonecny| Jiří Konečný]])
Email: jkonecny@redhat.com
Name: Fedora Workstation SIG
Email: desktop@lists.fedoraproject.org
== Detailed Description == The Anaconda team has been working on a new web-based UI for the OS installer for some time. We would like to give users the fruits of our work and get feedback so that we know what we need to improve or where we should focus. To make the adoption as painless as possible, the Fedora Workstation was chosen as the first target so we have better control over the environment and can have a focus. Also, Fedora Workstation has a smaller featureset than other installation media. The adoption for the other media later is planned too, but the exact date will be based on feedback and our capacity allowance.
=== What will '''not''' change with the new Web UI? === The new UI will mostly use already existing functional code (some modifications are necessary), so the stability should be similar. The Anaconda specific kernel boot parameters are also staying almost unchanged. The Anaconda team aims to reduce functionality that is not used but still put a maintenance burden on the team. This should result in much easier future extensions and stability of the installer. The current approach is to start from what is known to be required and used, then add future features based on the feedback.
=== What is going to change with the new Web UI? === The new web UI is not just a change of the UI technology, which is based on the React and Cockpit framework, but also a complete overhaul of the user experience. The new UI is trying to be easier to use by removing most of the complexities but still leaving possibilities to do everything you might need to do. We are trying to achieve a state where even users who don’t have previous experience with the Linux operating system will be able to do the installation smoothly.
List of what is part of the new UI:
- Wizard solution instead of hub and spoke
I am sad to see the "hub and spoke" to go away :(
Vít
Hi Vit,
Dne 27. 06. 23 v 12:43 Vít Ondruch napsal(a):
Dne 26. 06. 23 v 18:00 Aoife Moloney napsal(a):
https://fedoraproject.org/wiki/Changes/AnacondaWebUIforFedoraWorkstation
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
== Summary == The new PatternFly-based UI has been developed by the Anaconda team for some time now and we would like to make it available for users of Fedora to enhance and modernize installation experience. As the first step in this user adoption process, we are targeting Fedora Workstation only.
== Owner ==
Name: Anaconda team ([[User:jkonecny| Jiří Konečný]])
Email: jkonecny@redhat.com
Name: Fedora Workstation SIG
Email: desktop@lists.fedoraproject.org
== Detailed Description == The Anaconda team has been working on a new web-based UI for the OS installer for some time. We would like to give users the fruits of our work and get feedback so that we know what we need to improve or where we should focus. To make the adoption as painless as possible, the Fedora Workstation was chosen as the first target so we have better control over the environment and can have a focus. Also, Fedora Workstation has a smaller featureset than other installation media. The adoption for the other media later is planned too, but the exact date will be based on feedback and our capacity allowance.
=== What will '''not''' change with the new Web UI? === The new UI will mostly use already existing functional code (some modifications are necessary), so the stability should be similar. The Anaconda specific kernel boot parameters are also staying almost unchanged. The Anaconda team aims to reduce functionality that is not used but still put a maintenance burden on the team. This should result in much easier future extensions and stability of the installer. The current approach is to start from what is known to be required and used, then add future features based on the feedback.
=== What is going to change with the new Web UI? === The new web UI is not just a change of the UI technology, which is based on the React and Cockpit framework, but also a complete overhaul of the user experience. The new UI is trying to be easier to use by removing most of the complexities but still leaving possibilities to do everything you might need to do. We are trying to achieve a state where even users who don’t have previous experience with the Linux operating system will be able to do the installation smoothly.
List of what is part of the new UI:
- Wizard solution instead of hub and spoke
I am sad to see the "hub and spoke" to go away :(
I understand your point and honestly I felt the same way. However, I see it as improvement after working with that a few times. Our ultimate goal (not target right now) is to enable users to skip unnecessary steps so we would get to similar level of what we had but easily understandable.
Jirka
Vít
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Mon, Jun 26, 2023 at 10:01 AM Aoife Moloney amoloney@redhat.com wrote:
== Summary == The new PatternFly-based UI has been developed by the Anaconda team for some time now and we would like to make it available for users of Fedora to enhance and modernize installation experience. As the first step in this user adoption process, we are targeting Fedora Workstation only.
I was pleasantly surprised with the progress here based on the test image I randomly stumbled upon this year. It's a big change from the familiar and should be treated as such.
Does it make more sense to focus efforts on releasing an official alternative Workstation install ISO? Generally, when you make people feel like they are forced to change it's more likely to cause frustration. We could make this more a celebration, a special access/preview to what is next, and attract testers on https://fedoraproject.org/workstation/ with some simple messaging. Completely understood that this would add yet another QA target and that might be more burdensome than it's worth.
If changing the default install experience is the main goal, we should start producing install media as soon as possible and promote it through the F38 cycle. Maybe as part of the respin process in F38. The more comfortable everyone is with this change, before the F39 release day, the more likely this change will be well received.
Hi,
I am not a developer, I do rely on accessibility such as orca. I think the last time I tested it, the image booted but there seems to be know way to get orca speaking so could not test accessibility of installing. I am guessing this is being taking into account? As it stands now, if an orca user wants to install fedora workstation, you have to switch to org session rather than Wayland to get the current installer to work. This is just my thoughts of a general fedora user. Fear mate works fine however.
Matthew
On Jun 27, 2023, at 7:11 PM, Jonathan Steffan jonathansteffan@gmail.com wrote:
On Mon, Jun 26, 2023 at 10:01 AM Aoife Moloney <amoloney@redhat.com mailto:amoloney@redhat.com> wrote:
== Summary == The new PatternFly-based UI has been developed by the Anaconda team for some time now and we would like to make it available for users of Fedora to enhance and modernize installation experience. As the first step in this user adoption process, we are targeting Fedora Workstation only.
I was pleasantly surprised with the progress here based on the test image I randomly stumbled upon this year. It's a big change from the familiar and should be treated as such.
Does it make more sense to focus efforts on releasing an official alternative Workstation install ISO? Generally, when you make people feel like they are forced to change it's more likely to cause frustration. We could make this more a celebration, a special access/preview to what is next, and attract testers on https://fedoraproject.org/workstation/ with some simple messaging. Completely understood that this would add yet another QA target and that might be more burdensome than it's worth.
If changing the default install experience is the main goal, we should start producing install media as soon as possible and promote it through the F38 cycle. Maybe as part of the respin process in F38. The more comfortable everyone is with this change, before the F39 release day, the more likely this change will be well received.
-- Jonathan Steffan jonathansteffan@gmail.com mailto:jonathansteffan@gmail.com_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Hi, thanks for this question.
We tested the accessibility and so far looks good. The benefit of this solution is that we based on PatternFly components which takes care of accessibility for us. For showing Web UI we are going to use Firefox so that should be also fine.
However, I'm not sure how you can start Orca on the Workstation Live environment. Would be great to find that out from someone who knows GNOME more than me.
Also, side benefit of this should be that this new installer UI can work as Wayland app but that needs to be verified.
Best Regards, Jirka
28. června 2023 18:49:23 SELČ, matthew dyer ilovecountrymusic483@gmail.com napsal:
Hi,
I am not a developer, I do rely on accessibility such as orca. I think the last time I tested it, the image booted but there seems to be know way to get orca speaking so could not test accessibility of installing. I am guessing this is being taking into account? As it stands now, if an orca user wants to install fedora workstation, you have to switch to org session rather than Wayland to get the current installer to work. This is just my thoughts of a general fedora user. Fear mate works fine however.
Matthew
On Jun 27, 2023, at 7:11 PM, Jonathan Steffan jonathansteffan@gmail.com wrote:
On Mon, Jun 26, 2023 at 10:01 AM Aoife Moloney <amoloney@redhat.com mailto:amoloney@redhat.com> wrote:
== Summary == The new PatternFly-based UI has been developed by the Anaconda team for some time now and we would like to make it available for users of Fedora to enhance and modernize installation experience. As the first step in this user adoption process, we are targeting Fedora Workstation only.
I was pleasantly surprised with the progress here based on the test image I randomly stumbled upon this year. It's a big change from the familiar and should be treated as such.
Does it make more sense to focus efforts on releasing an official alternative Workstation install ISO? Generally, when you make people feel like they are forced to change it's more likely to cause frustration. We could make this more a celebration, a special access/preview to what is next, and attract testers on https://fedoraproject.org/workstation/ with some simple messaging. Completely understood that this would add yet another QA target and that might be more burdensome than it's worth.
If changing the default install experience is the main goal, we should start producing install media as soon as possible and promote it through the F38 cycle. Maybe as part of the respin process in F38. The more comfortable everyone is with this change, before the F39 release day, the more likely this change will be well received.
-- Jonathan Steffan jonathansteffan@gmail.com mailto:jonathansteffan@gmail.com_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Wed, Jun 28 2023 at 07:06:13 PM +0200, Jiří Konečný jiri.konec@pacse.eu wrote:
However, I'm not sure how you can start Orca on the Workstation Live environment. Would be great to find that out from someone who knows GNOME more than me.
Should be: Alt+Super+S
On 6/26/23 12:00, Aoife Moloney wrote:
https://fedoraproject.org/wiki/Changes/AnacondaWebUIforFedoraWorkstation
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
== Summary == The new PatternFly-based UI has been developed by the Anaconda team for some time now and we would like to make it available for users of Fedora to enhance and modernize installation experience. As the first step in this user adoption process, we are targeting Fedora Workstation only.
== Owner ==
Name: Anaconda team ([[User:jkonecny| Jiří Konečný]])
Email: jkonecny@redhat.com
Name: Fedora Workstation SIG
Email: desktop@lists.fedoraproject.org
== Detailed Description == The Anaconda team has been working on a new web-based UI for the OS installer for some time. We would like to give users the fruits of our work and get feedback so that we know what we need to improve or where we should focus. To make the adoption as painless as possible, the Fedora Workstation was chosen as the first target so we have better control over the environment and can have a focus. Also, Fedora Workstation has a smaller featureset than other installation media. The adoption for the other media later is planned too, but the exact date will be based on feedback and our capacity allowance.
What is the reason for using a web-based UI instead of continuing to use GTK?
Dne 02. 07. 23 v 23:54 Demi Marie Obenour napsal(a):
On 6/26/23 12:00, Aoife Moloney wrote:
https://fedoraproject.org/wiki/Changes/AnacondaWebUIforFedoraWorkstation
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
== Summary == The new PatternFly-based UI has been developed by the Anaconda team for some time now and we would like to make it available for users of Fedora to enhance and modernize installation experience. As the first step in this user adoption process, we are targeting Fedora Workstation only.
== Owner ==
Name: Anaconda team ([[User:jkonecny| Jiří Konečný]])
Email: jkonecny@redhat.com
Name: Fedora Workstation SIG
Email: desktop@lists.fedoraproject.org
== Detailed Description == The Anaconda team has been working on a new web-based UI for the OS installer for some time. We would like to give users the fruits of our work and get feedback so that we know what we need to improve or where we should focus. To make the adoption as painless as possible, the Fedora Workstation was chosen as the first target so we have better control over the environment and can have a focus. Also, Fedora Workstation has a smaller featureset than other installation media. The adoption for the other media later is planned too, but the exact date will be based on feedback and our capacity allowance.
What is the reason for using a web-based UI instead of continuing to use GTK?
Hi,
the reasons are mainly these: - faster development (we don't have to reboot the machine for each change but just reload a page) - great CI support from the cockpit team (pixel tests support and we use their test suite with their infrastructure) - consistency with the other projects who use Pattern Fly (mainly around RHEL but not only) as Cockpit, Image Builder and more - possibility to share modules and code with the Cockpit project - great support from the Cockpit team - great support from the Pattern Fly team
In overall these benefits should allow us better cooperation between teams, better integration and more stable product at the end.
Best Regards, Jirka