Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

[Jiri Konecny]

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: jkone...@redhat.com
* Name: Fedora Workstation SIG
* Email: desk...@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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

[Jiří Konečný]

4. července 2023 0:44:41 SELČ, Neal Gompa  napsal:
>On Mon, Jul 3, 2023 at 6:36 PM Jiří Konečný  wrote:
>>
>> Hi, see my replies below.
>>
>> 2. července 2023 23:56:59 SELČ, Demi Marie Obenour  
>> 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

[Neal Gompa]

On Mon, Jul 3, 2023 at 6:36 PM Jiří Konečný  wrote:
>
> Hi, see my replies below.
>
> 2. července 2023 23:56:59 SELČ, Demi Marie Obenour  
> 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.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

[Jiří Konečný]

Hi, see my replies below.

2. července 2023 23:56:59 SELČ, Demi Marie Obenour  
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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

[Jiří Konečný]

Hi

3. července 2023 18:57:39 SELČ, Michael Catanzaro  
napsal:
>On Mon, Jul 3 2023 at 12:32:02 PM -0400, Demi Marie Obenour 
> 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-le...@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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

[Lukáš Tyrychtr]

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-le...@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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

[Michael Catanzaro]

On Mon, Jul 3 2023 at 12:32:02 PM -0400, Demi Marie Obenour 
 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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

[Demi Marie Obenour]

On 7/3/23 12:30, Michael Catanzaro wrote:
> On Mon, Jul 3 2023 at 06:15:43 PM +0200, Simon de Vlieger 
>  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.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

[Michael Catanzaro]

On Mon, Jul 3 2023 at 06:15:43 PM +0200, Simon de Vlieger 
 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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

[Simon de Vlieger]

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-le...@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

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

[Demi Marie Obenour]

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.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

[Simon de Vlieger]

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

[Demi Marie Obenour]

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.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

[Demi Marie Obenour]

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: jkone...@redhat.com
> * Name: Fedora Workstation SIG
> * Email: desk...@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?
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

[Michael Catanzaro]

On Wed, Jun 28 2023 at 07:06:13 PM +0200, Jiří Konečný 
 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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

[Jiří Konečný]

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  
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  
>> wrote:
>> 
>> On Mon, Jun 26, 2023 at 10:01 AM Aoife Moloney > > 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
>> jonathanstef...@gmail.com 
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@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
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

[matthew dyer]

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  
> wrote:
> 
> On Mon, Jun 26, 2023 at 10:01 AM Aoife Moloney  > 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
> jonathanstef...@gmail.com 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

[Jonathan Steffan]

On Mon, Jun 26, 2023 at 10:01 AM Aoife Moloney  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
jonathanstef...@gmail.com
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

[Chris Murphy]

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/


-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

[Jiri Konecny]

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: jkone...@redhat.com
* Name: Fedora Workstation SIG
* Email: desk...@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-le...@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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

[Jiri Konecny]

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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

[Simon de Vlieger]

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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

[Hans de Goede]

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


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

[Vít Ondruch]

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: jkone...@redhat.com
* Name: Fedora Workstation SIG
* Email: desk...@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




OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

[Adam Williamson]

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.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

[Hans de Goede]

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 re

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

[Simon de Vlieger]

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/413007214f8f7f0dfbdff98431eee5789866e081/pyanaconda/ui/webui/__init__.py#L98

[2]: https://github.com/osbuild/osbuild-composer/pull/3440
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

[Hans de Goede]

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.
>> 
>>
>> 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/Hardware_Overview/
>>
>> "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 

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

[Jiri Konecny]

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.



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/Hardware_Overview/

"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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

[Jiri Konecny]

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  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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

[Adam Williamson]

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
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

[Adam Williamson]

On Mon, 2023-06-26 at 12:19 -0500, Chris Adams wrote:
> Once upon a time, Aoife Moloney  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.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

[Hans de Goede]

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.



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/Hardware_Overview/

"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


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

[Chris Adams]

Once upon a time, Aoife Moloney  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?

-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

F39 Change Proposal: Anaconda WebUI for Fedora Workstation by default (System-Wide)

[Aoife Moloney]

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: jkone...@redhat.com
* Name: Fedora Workstation SIG
* Email: desk...@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-wizard/
.


 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
planni