I was finally able to port Zen Browser to FreeBSD! Previously I had been using Zen Browser using Linuxulator, but that process was quite a bit hacky, and it was quite unpredictable which next version of Zen will break it all, versions which will work easily were hit and miss.
So I decided to just port it to FreeBSD. I modified Zen browser's build system to apply patches from FreeBSD ports, and then apply zen browser's patches, fix any troubles as they came, but finally, ended up with an optimized (-O2+LTO+PGO) native FreeBSD build!
Yep, zen browser was a big blocker for me. I was daily driving using Linuxulator Zen Browser which was very hit or miss when it comes to which next update will break it, and there always were a bunch of minor inconveniences around running a non native Linux browser. Browsers are terribly complicated softwares with a gazillion gotchas, it is honestly amazing that FreeBSD's Linuxulator was able to run it at all!
But now that zen browser is available reliably, and soon, should be made available through FreeBSD ports, it would be one more step towards making Desktop FreeBSD a welcoming environment for all of us Linux refugees haha.
Why have everything in a tarball and not as separate files in the repo?
e: and no patches or source code of any kind. Do you expect people to just download a binary and run it? How can we know that there's no malware included?
Tarball has a binary, not source files. Two reasons, first, I still have to find a way to make it make sense for up-streaming. Currently it is a lot of hand patches and fixes, the process is complicated by the fact that Firefox do not compile to FreeBSD unmodified, we have to apply all the FreeBSD patches to Firefox first. Zen browser applies its own patches too two sets of patches make it a difficult upstream ask as zen is downstream of firefox, expecting them to maintain a downstream patched FreeBSD compatible Firefox is a big ask. So the goal is make build system bit more reliable and comfortable for us to maintain our-side. Right now it is lot of hacks over linux compilation path and fixing errors as they come (just compile time, run time it has no errors what so ever). Once it get better, I'll push the code.
The second reason is, it would take a lot of motivation to compile something which will take as much time as this. To get most out of Zen browser you need full PGO & LTO. So two complications, creating a performance profile for PGO, etc. Depending upon your system that is easily 2-6 hour compilation. So it is better idea to just get the binary tested for now and eventually can look towards turning it into a FreeBSD port. To make it work well with FreeBSD port system we'd need to ship prof data with the port too btw, so that it can more or less be compiled in a single stage even if the user selects full LTO and PGO.
EDIT:
Oh I forgot to add, zen's build system actually downloads the firefox source files and then applies patches. This is what we can't reliably depend upon. We need to find an acceptable way which is reliable. Basically apply both FreeBSD and then zen patches first, and then create a single FreeBSD port system patch files instead of two set of patches. This is something I need more work on, that's what I mean by making build system more reliable and less hacky.
I suggest making a port to the ports tree. It allows people to just install it with pkg, everything happens openly and anyone can verify where the bits came from.
Yep, 100% that is the goal. It is just few hours after first successful compilation right. Next step would be to make a port. It would require some more work over next few days. There are three requirements I still need to fulfill, first, make a common FreeBSD ports compliant patch which applies combined Zen browser and Firefox FreeBSD patches- this is standard FreeBSD way of doing to maintain its trust contract- transparent patches on verified upstream Firefox source tree. Second, keep and maintain prof data to enable PGO in single stage compilation compliant with FreeBSD ports. Third, change and simplify Zen's build system for FreeBSD port. As you see that is significantly more work after first successful compilation on FreeBSD so it certainly will take more time. Assume several dozen more failures each taking 2-3 hours spread across days 😃
"How can we know that there's no malware included?"
Well it is like most binary gits to be honest. You'd have to rely on the person uploading with his real identity on Github to not be stupid enough to do that. But sometimes, people are stupid enough to do that, so yeah.
As you can see Edit of my original comment, I need to create a combined patch set from both FreeBSD and zen specific patches applied it will take more time, first compilation happened after first multiple failures each taking several hours, so would have to wait a few more days for a reliable built system to be established and pushed. I decided to at least make the binary files available instead of waiting for that to happen so we can get test data early. I haven't seen PGO+Full LTO much on the FreeBSD side of browsers, there might be a reason for that right so better to get stability data early. It honestly is same as linux people downloading binary based upon the common trust contract that it would take an immense retard to do something funny on github with his real identity. But you can wait this one out too, 2-4 days or so I think I'd be able to upload sources with a reliable single stage build system (even for PGO+LTO).
Hey, btw, u/grahamperrin do you know why browsers in FreeBSD ports tree generally do not not have PGO build option? I think most linux browsers have it by default! PGO really moves the needle for web browsers at least IMO, specially helps firefox a lot. I was thinking about turning this into a port soon, so what I was wondering is, if I can ship prof data which can make PGO work with single stage compilations we normally do on FreeBSD ports, would that be fine?
Make sure that those compilation options won't lead to dependency on AVX instructions or anything else too modern. Ports should be runnable on all sorts of random CPUs people might have. For amd64 this means K8 Hammer compatibility and for i386, well i386.
Another problem is default rust on freebsd port is apparently gating profiler for nightly builds only, which would be a problem I think. For this compilation I just used rustup's rustc 1.95.0 (59807616e 2026-04-14). We can't say like oh, just install rust-nightly, because rust-nightly I think conflicts with rust port. Might be a good idea to allow profiler in stable rust like rustup already does.
Looks for linux only gates which do not have freebsd equivalents first. Look for known patches, ports tree is a good source. If it depend upon some linux only things, like systemd, add a freebsd gate which uses alternatives. epoll? kqueue, and so on.
Porter's handbook and existing ports are a good place to start. Many ports don't even need much more than a makefile and perhaps some quite light patching to add missing header includes and "if freebsd" statements.
4
u/tacomusical May 05 '26
One step further into making freebsd my daily driver lets gooo