On 03/07/2020 03:52, Mayuresh wrote:
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.
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.
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 capability
There 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