4. července 2023 0:44:41 SELČ, Neal Gompa <ngomp...@gmail.com> napsal: >On Mon, Jul 3, 2023 at 6:36 PM Jiří Konečný <jiri.ko...@pacse.eu> wrote: >> >> Hi, see my replies below. >> >> 2. července 2023 23:56:59 SELČ, Demi Marie Obenour <demioben...@gmail.com> >> napsal: >> >On 6/27/23 05:00, Simon de Vlieger wrote: >> >> On 6/27/23 10:40, Hans de Goede wrote: >> >> >> >> > Ok, so can you provide some instructions for how to make this work ? >> >> I guess it would be something like add the cmdline option + then start >> >> some systemd unit ? Can you please put some instructions for this in >> >> the testing section of: >> >> https://fedoraproject.org/wiki/Changes/AnacondaWebUIforFedoraWorkstation >> >> (with a note that this is currently not supported / recommended). >> >> > >> >> >> About the improvements on the Live ISO, that should be a question on >> >> Fedora Workstation SIG. Anaconda team is not in charge of the >> >> environment on the Live ISO. >> >> > >> >> > Well you are suggesting a change that is likely going to >> >> significantly increase the amount of memory needed to do a livecd >> >> workstation install and as mentioned above pushing the requirements >> >> above 2G would basically block this change since 2G RAM is currently the >> >> advertised minimum RAM requirement for Fedora workstation installs. >> >> > >> >> > So although I realize this is not entirely fair IMHO if you want to >> >> push forward with this feature then you may also be on the hook to look >> >> into reducing the memory footprint elsewhere so that the end result >> >> still fits in 2G RAM. I have some experience with tweaking the livecd to >> >> work with less RAM and I'm happy to share my experience in this, but I >> >> do not have time to actually implement needed changes for this. >> >> Hi Hans, >> >> >> >> it would indeed involve adding the `inst.webui` and `inst.webui.remote` >> >> kernel command line options and a systemd unit to start the relevant >> >> services (I *think* that'd only be `cockpit.service`). >> > >> >Remote installation is not a solution to the memory bloat. It only >> >pushes the problem to whatever machine the browser runs on, and it >> >has significant and negative security implications. A solution >> >here would be ensuring that the web UI uses no more RAM than the >> >GTK UI that preceded it. >> >> Please, take into account that we are not an application which stays open on >> background for hours (usually), so you can't put this to the same level as >> music player or similar apps. >> Anyway, I'm pretty sure that every usable machine as desktop PC, is able to >> open one web page for the installation process. >> >> From the other point, I wonder how much memory the VNC client (solution >> right now) is taking. And security point with VNC is (based on my >> understanding) maybe worse than HTTPS browsers. >> >> >> Hard to say what technology has the same memory footprint as GTK3. I think, >> there are not many options. From the other point, using this logic in the >> past, we would still be using ncurses based installations. Don't take me >> wrong, I see your point and memory footprint is important. Just saying it is >> not the only point you should take into account. > >I would also note that the work being done here does not obviate the >future return of a community-developed graphical frontend for >Anaconda. For example, the previous architecture made it impossible >for anyone to consider developing a Qt based frontend for Anaconda. >That option is now open for the first time in Anaconda's history. > >And the GUI could run unprivileged while the Anaconda services run >privileged in the background, which is required for a Wayland-based >application anyway.
Good point Neal. That is correct, if anyone would like to have the ncourses frontend again, you can create it yourself. 😃 Jirka _______________________________________________ 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
