On 03/07/2020 03:52, Mayuresh wrote:
Fundamentally you would have the same problem with any web browser trying to keep up with modern web standards. They are amongst the largest applications in terms of dependencies and features that most people use on a daily basis.On Wed, Jul 01, 2020 at 05:34:11PM -0700, Greg A. Woods wrote:So, does anyone have a working mozilla firefox-74.0 on 9.0 amd64?I haven't upgraded from NetBSD 8 to 9 and news on firefox just adds to my inertia to upgrade. Just curious. Which factors have led to firefox being such a mess: - Is it firefox itself? Badly written, non portable code etc? - Is it the rust language or libraries? - Or is it the rust compiler? - Or is it LLVM / CLang etc. - Any other factors / combinations of factors.
The reason firefox looks bad is that its the goto browser for most people on non-Windows systems. If webkit or chromium has the same level of scrutiny you would see the same level of problems and the problem they both have is that they are really just the rendering engine and need wrapping with other code to produce a functional browser.
I think Rust makes it marginally worse but thats actually down to rust running into bugs in NetBSD (the ld.so lock bugs) rather than rust itself being a poor idea. The rust compiler is no more memory intensive than modern GCC or LLVM.
Rust does limit the platforms that firefox can be built for but the chances are the platforms rust doesn't support would lack the resources to run firefox (it and most browsers) have a memory footprint that makes GCC look frugal on memory. Yoo also have to bear in mind that in many cases modern GCC doesn't support all NetBSD platforms out of the box. Its only thanks to the NetBSD team keeping the code from older versions integrated that keeps those platforms alive.
A full featured modern web browser has to support: Rendering and layout engine supporting 2D & 3D graphics.2D layout is flexible enough that you can write entire applications in it (e.g googledocs, office365) with the same level of functionality as the native desktop versions.
3D rendering engine is capable enough for quite a few games.To support all that you have a complete javascript language environment. Because that environment supports downloading untrusted code in the internet it needs complex sandboxing to protect the local system. That language environment support JIT compilation and the core language library isn't small. On top of that you also have WebAssembly (not sure if firefox supports that yet). Which gives you another runtime and one that is supposed to be as fast as compiled code. Its a support LLVM backend which means you now have a runtime for compiled applications as well.
Sandboxing also bites again for actual web content the content it processes is untrusted it runs each tab in a separate process to prevent leakage between tabs. This would still be a requirement even if there
was much more limited scripting capabilityThere are many people that hate the fact that this level of development in a browser is possible but the is no denying its usefulness as its a cross system platform for writing applications that far outweighs anything else I've ever had access to. Its so powerful that you can actually incredibly common to build a web app, bundle it with a web rendering engine and ship it as a native app.
The size and scale of the browser runtime and its dependencies is something I spotted as browser runtimes became more common in embedded systems. When I first started making images of that type the toolchain was the slowest part of the system build. Once things like webkit or chromium crept in their build time (and their dependencies) dwarfed the time taken to build the toolchain and were the thing that took the majority of the time to build.
Mike