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)