(Both www/firefox and www/firefox68) There's an interesting story to this one. Multiprocess mode never worked properly on NetBSD. When we finally implemented the necessary goo (processes-shared semaphores) it was leaky and would eventually run out of file descriptors and crash. Unfortunately, as of the most recent release, they broke non-multiprocess Firefox, so an urgent fix was required. We couldn't keep it disabled by default. maya and thorpej eventually discovered that the problem was Firefox attempting to destroy semaphores in processes that hadn't created them, which would fail and leak. But apparently, macOS has the same restriction! I was able to find the code that avoids cross-process semaphores on macOS, and we unconditionally enabled it on NetBSD. Now Firefox on NetBSD is using an oddball rendering mode normally only used on macOS - but it's fast, stable, and multiprocess. You get all the added robustness you normally would.

@"nia"#p2699 Thank you, Maya and thorpej for this.

@"nia"#p2699 This is great news. Thank you, Maya and thorpej 😊 🚩

Here's a dumb and completely unrelated question but I thought starting a new thread wasn't necessary... Where the userChrome.css found on NetBSD? Or rather where should custom userChrome.css files be placed ? I've looked in `/usr/pkg/lib/firefox68/chrome/` as well as `/usr/pkg/lib/firefox68/browser/chrome/` but cant locate it. NM, i'll make a new post

Firefox is now multiprocess by default on NetBSD

MWS

For those running FF with lower amounts of RAM, if you want to reduce memory usage, see this link:

https://support.mozilla.org/en-US/questions/1247528

It has instructions on reducing your content process limit to prevent Firefox from hogging all the RAM.

pfr

nia So for the noobs like me, is there anything I need to do besides update firefox?
I'm on firefox68 and its slooooow on my x230 with 8gb of ram.

MWS I'll do this, see if it helps. Thanks!

pfr for the esr-version, it will come whenever you get firefox68-68.9.0nb1

nia

pin I'll likely pull it up to the stable branch when 68.10.0 is released (the 30th, I'm usually a day late on Firefox ESR updates so let's say the day after). Unless someone wants to do some serious testing on NetBSD 8 and 9 - that would be helpful.

nia Unless someone wants to do some serious testing on NetBSD 8 and 9 - that would be helpful.

I would but, I don't have a free machine. I'm running it now on 9.0-STABLE but that won't help you much.

nia

pin 9.0-RELEASE would be helpful. To be honest I have a -current kernel and a 9.0-RELEASE userland (I should probably upgrade that to -current).

nia Disclaimer: OOT
I couldn't stop thinking about this... I just had to,
HEAD-kernel from yesterday + 9.0_STABLE userland + pkgsrc-current. Thanks for the hint 🙂

nia

pin Very nice. I think all you need to use 9.0 packages on a -current userland is libcurses and libtermcap from 9.0 (briefly tested with the aarch64 packages on a Pinebook Pro). The libraries have differing major version numbers, so this involves copying the versioned library from base.txz into /usr/lib...

The -current kernel has had some pretty amazing optimization work on it, so there are significant performance improvements over 9.0... but, playing with locking is hard, so there's been some instability, particularly earlier in the year. 🙂

nia Thanks for the new hint 🙂

pfr

@nia I was trawling through r/NetBSD today and found your old posts about NetBSD on the PineBook Pro. The only reason I bring that up is, it looks like you were using vimb at the time. Do you still use it or are you using firefox now?

I'm also quite interested in a review of NetBSD on the PineBook Pro (or and RockPro64 Board) if you get time to write up your experience and any quirks. 😃

nia

pfr The pinebook pro arrived last week, I was (and am still) using a thinkpad, mostly with firefox

I don't have anything to complain about, the hard work has already been done and netbsd runs really well on the pinebook pro.

pfr

nia Ahh must have been your thinkpad then (from about 6 months ago).
I was just hoping for an excuse to ditch firefox and use vimb 😆

nia

pfr I prefer luakit, I was only using vimb because webkit-gtk browsers work in swc, and at the time it didn't have a bug that luakit did

Still waiting for luakit to make a release...

pfr Why? Not to save dependencies, I guess...

$ pkgin show-full-deps firefox68
full dependency tree for firefox68-68.9.0nb2
	py37-expat-[0-9]*
	py37-cElementTree-[0-9]*
	libgpg-error>=1.13
	libgcrypt>=1.6.0
	gobject-introspection>=1.62.0nb1
	jpeg>=9
	jbigkit>=2.0
	pcre>=8.30nb1
	at-spi2-core>=2.35.1nb1
	libuuid>=2.18
	libpaper>=1.1.22
	python37>=3.7.0
	graphite2>=1.2
	libxslt>=1.1.34nb2
	p11-kit>=0.23.15nb1
	nettle>=3.6
	mozilla-rootcerts-[0-9]*
	lzo>=2.01
	libunistring>=0.9.4
	libtasn1>=4.9
	libcfg+>=0.6.2nb3
	gmp>=6.0
	harfbuzz>=2.6.4nb2
	enca>=1.9
	xmlcatmgr>=2.0beta1
	libogg>=1.1.2nb1
	dbus>=1.8
	xvidcore>=1.1.0nb1
	x265>=1.1
	x264-devel>=20180224
	speex>=1.2rc1
	libxml2>=2.9.10nb2
	libvpx>=1.6.1
	libvorbis>=1.1.0nb1
	libva>=2.3.0
	libtheora>=1.0alpha3nb1
	libopus>=1.1
	libbluray>=1.2.0nb1
	libass>=0.14.0nb4
	libaom>=1.0.0nb1
	lame>=3.98.2nb1
	gnutls>=3.6.13nb2
	python27>=2.7.1nb2
	py27-expat-[0-9]*
	wayland-protocols>=1.17
	wayland>=1.17.0nb5
	shared-mime-info>=1.0nb1
	pango>=1.44.7nb2
	libxkbcommon>=0.4.0nb1
	libcups>=2.3.3nb3
	libXft>=2.3.2nb2
	hicolor-icon-theme>=0.9nb1
	gdk-pixbuf2>=2.40.0nb1
	fribidi>=0.19.1
	fontconfig>=2.13.0
	cairo-gobject>=1.16.0nb4
	cairo>=1.16.0
	atk>=2.33.3nb1
	at-spi2-atk>=2.34.1nb1
	glib2>=2.64.0nb1
	tiff>=4.0.3nb5
	png>=1.6.0nb1
	giflib>=5.2.1nb4
	nss>=3.44.1
	nspr>=4.21
	libwebp>=1.0.2
	libv4l>=0.4.3nb2
	libffi>=3.3nb1
	libIDL>=0.8.14nb5
	icu>=67.1
	gtk3+>=3.24.14nb2
	gtk2+>=2.24.32nb13
	ffmpeg4>=4.2
	desktop-file-utils>=0.10nb1
	dbus-glib>=0.110nb1

$ pkgin show-full-deps vimb
full dependency tree for vimb-3.6.0nb4
	xmlcatmgr>=2.0beta1
	nettle>=3.6
	mozilla-rootcerts-[0-9]*
	libcfg+>=0.6.2nb3
	gmp>=6.0
	jbigkit>=2.0
	libgpg-error>=1.13
	p11-kit>=0.23.15nb1
	libproxy>=0.4.11
	gsettings-desktop-schemas>=3.4.2
	py37-expat-[0-9]*
	py37-cElementTree-[0-9]*
	hunspell-en_US-[0-9]*
	hunspell>=1.7.0
	pcre>=8.30nb1
	perl>=5.0
	orc>=0.4.6
	check>=0.9.5
	gobject-introspection>=1.62.0nb1
	libpsl>=0.21.0nb2
	glib-networking-[0-9]*
	giflib>=5.2.1nb4
	libgcrypt>=1.6.0
	harfbuzz>=2.6.4nb2
	graphite2>=1.2
	libffi>=3.3nb1
	brotli>=1.0.1
	at-spi2-core>=2.35.1nb1
	lzo>=2.01
	libuuid>=2.18
	tiff>=4.0.3nb5
	libunistring>=0.9.4
	libpaper>=1.1.22
	gnutls>=3.6.13nb2
	dbus>=0.91
	python37>=3.7.0
	libxml2>=2.9.10nb2
	wayland-protocols>=1.17
	shared-mime-info>=1.0nb1
	libxkbcommon>=0.4.0nb1
	libcups>=2.3.3nb3
	libXft>=2.3.2nb2
	hicolor-icon-theme>=0.9nb1
	gdk-pixbuf2>=2.40.0nb1
	fribidi>=0.19.1
	fontconfig>=2.13.0
	cairo>=1.16.0
	atk>=2.33.3nb1
	at-spi2-atk>=2.34.1nb1
	woff2>=1.0.2
	wayland>=1.17.0nb5
	png>=1.6.0nb1
	pango>=1.44.7nb2
	libxslt>=1.1.34nb2
	libwebp>=0.6.0
	libtasn1>=0.3.0
	libsoup>=2.70.0nb2
	libsecret>=0.20.1nb1
	libnotify>=0.7.9nb1
	jpeg>=9
	icu>=67.1
	gstreamer1>=1.16.2nb1
	gst-plugins1-base>=1.16.2nb1
	glib2>=2.64.0nb1
	enchant2>=2.2.8nb1
	cairo-gobject>=1.16.0nb4
	webkit-gtk>=2.28.2nb2
	gtk3+>=3.24.14nb2
	desktop-file-utils>=0.10nb1

Be aware this is not all, vimb will require extra plugins to play video 😉

pfr

nia Still waiting for luakit to make a release...

Doesn't look like its been updated in a while. I liked it when I used it a few years ago. I'd use it again if it was updated.

pin Not to save dependencies, I guess...

Valid point.

nia they are basically operating systems now.

A bloated web requires a bloated browser.. unless you hang out in gopher holes.

nia

eh. A lot of that you will end up having installed on a desktop system regardless, it's a lot of reference libraries for image/audio/video formats, basic stuff for TTF font rendering, etc. By far the biggest component is the actual browser, they are basically operating systems now.

yeti

pfr A bloated web requires a bloated browser.. unless you hang out in gopher holes.

You can have HTML pages that are as simple as Gopher or Gemini stuff. Nobody forces you to use more CSS and JS than real text with HTML.

I cannot switch to G&G completely because I cannot give up in document links and in-line links in many of my pages and sometimes a picture in the text really helps more than having it pop up in an external application because G&G delegate that to other helpers.

But I definitely want my old style browser back! I really cannot understand why dropping Gopher in browsers did not start a shitstorm, and some newcomers don't even include FTP any more. :-(

The browser should be the dispatcher between lots of protocols and lots of viewers. It should be highly modular and should learn new tricks instead of dropping good old friends.

yeti

Did I mention speed at all?

MWS I think you answer to
pfr A bloated web requires a bloated browser.. unless you hang out in gopher holes.

I just don't think browsers should be divisive: Not HTTP/HTML or Gopher or Gemini, all in one is the way to go.

MWS

yeti You can easily return to the days of the fast internet by disabling JavaScript. NoScript is a great extension for Firefox and Chromium based browsers. By default, it will disable JS on every site. You can also easily enable it on a site-by-site basis.

The other nice thing about disabling JS is that you never have to worry about ads or malicious JavaScript. I use it on all of my browsers. Works great, especially on older hardware with less RAM since Firefox is so much more bloated than Blink-based browsers.

nia

FTP is a more complex protocol than HTTP/1.1...

yeti

nia FTP is a more complex protocol than HTTP/1.1...

...and then the end fell off?

Top secret: It always was, but that did not stop FTP being supported by the 1st browsers.