Honestly, as someone who uses Haiku casually I find the absence of a beastly browser to be a feature. There _is_ a browser, one featureful enough to read Wiki and such, but not featureful enough to blow away hours and hours on Javascript-heavy social web applications.

also, no Electron apps. all I see is upside

I ran minimalist Void Linux on a crappy dual-core Celeron Chromebox with 2GB (yes, two) of memory as a workstation for a few weeks last year.

It was impractical longer term, but really, as long as I didn't open more than a couple Surf (the Suckless browser, uses the Webkit engine) windows at a time it didn't feel slower than a tricked-out Mac or a beast of a Windows machine, for everything else. Amazing what running as little JS as possible can do. I had to run Docker and VMs elsewhere since they hog memory by design, but it was entirely fine as code-editing and command line workstation. A heavy IDE for, say, Java might have been painful if I'd needed that—which is kind of crazy, because those used to run just fine on well under 1GB of memory, too.

Using Void helped a lot because a bunch of the background garbage on something like Ubuntu, which is really getting out of control, wasn't hanging around eating memory and periodically waking up to burn cycles for unclear reasons. I imagine the benefits of Haiku are similar (big fan of BeOS back in the day, thing's UI responsiveness on mediocre hardware was downright magical)

That's interesting but GP points out that major applications like

> car console, tablet, media centre, info kiosk etc

would be possible but hard without a mainstream browser. Sure, one can develop a native application, but this is not how mainstream development is done these days. E.g. info kiosks basically are browsers that display whatever there is on a (frequently updated) server, and so there's zero maintenance for a kiosk.

There are plenty of companies that make desktop apps. Car consoles (generally) don't use browsers. I am sure that those applications would get on just fine without running Chromium. A car with a web browser is a nightmare.

Don't know about kiosks, but QML is quite popular in applications like in-vehicle infotainment systems.

There is no technical reason one could not port Chromium or Firefox at this point; it's simply that nobody has put the time in to do it (as you can imagine, porting a web browser is not an easy task.)

There's 600+ patches needed to build chrome on BSD, and upstream is constantly churning, which means they need maintenance.

Upstream refuses to import anything related to BSD support, so they need to be maintained out of tree.

And this is for a much more popular set of projects.

"Not an easy task" is a bit of an understatement.

The demise of TenFourFox is relevant: http://tenfourfox.blogspot.com/2020/04/the-end-of-tenfourfox... .

I've built Firefox on NetBSD. I wonder how many patches are required for it.

Presumably the use of rust is a dependency that needs fulfilled for building FF. Looks like there has been some work on getting rust to play with Haiku at both the Rust and Haiku ends:

https://docs.rs/haiku/0.2.0/haiku/

https://www.haiku-os.org/blog/nielx/2020-09-06_rust_on_haiku...

That much:

https://github.com/NetBSD/pkgsrc/tree/trunk/www/firefox/patc...

Some of those are for optional features like WebRTC, they are not all needed for a functional browser.

This thread is about fully featured browsers though. I think without WebRTC you can not call the browser fully featured.

Firefox 52 is the last version that can be built without Rust, it is kept in pkgsrc for that reason.

> as you can imagine, porting a web browser is not an easy task

I would imagine, but now I'm trying to figure out why; do they really use that much API surface? Network access should be simple enough, they need audio, keyboard input, and a canvas/surface to render to, but what else?

I think the problem is most modern browsers are a pile of open-source libraries at the bottom, any of which may use architecture-specific and/or compiler-specific native code. Also different systems have slightly different toolchains, for instance, compiling BSD on Linux can't be done because Linux GCC can't handle the divergent BSD GCC makefiles. D'oh! Wonder how that happened, surely they'll fix it soon...

HW accelerated audio/video encoders/decoders (eg for WebRTC), mic, camera, crypto, ...