Live data from Hacker News

Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%

brave.com

171–180 of 289 posts

Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%

#171

Earlier quoted context omitted.

RAM is cheap mmmkay? Or at least it used to be when they designed the thing…

Is it a RAM problem though? My understanding is that each process loads the shared library in its own memory space, so it's only a ROM/HDD space problem.

If you stop using shared libraries each application will have its own copy in ram…

Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%

#172
post #105
post #96

Earlier quoted context omitted.

And yet Rust ecosystem practically killed runtime library sharing, didn't it? With this mentality that every program is not a building block of larger system to be used by maintainers but a final product, and is statically linked with concrete dependency versions specified at development time. And then even multiple worker processes of same app can't share common code in memory like this lib, or ui toolkit, multimedi…

> And yet Rust ecosystem practically killed runtime library sharing, didn't it? Yes, it did. We have literally millions of times as much memory as in 1970 but far less than millions of times as many good library developers, so this is probably the right tradeoff.

C++ already killed it: templated code is only instantiated where it is used, so with C++ it is a random mix of what goes into the separate shared library and what goes into the application using the library. This makes ABI compatibility incredibly fragile in practise.

And increasingly, many C++ libraries are header only, meaning they are always statically linked.

Haskell (or GHC at least) is also in a similar situation to Rust as I understand it: no stable ABI. (But I'm not an expert in Haskell, so I could be wrong.)

C is really the outlier here.

Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%

#173
post #160

Why don't Mozilla make or use such engine in its browser? Make something really native for dealing with ads and annoyances. The irony is Brave smartly uses Rust which were forsaken by Mozilla. I know Mozilla seems to have something for ads but honestly I don't even know what it really does, beside its shield icon.

Mozilla wants Firefox to be a mainstream browser that anyone can use. Ad blocking introduces the risk of site breakage, and the majority of the population don't have the knowledge to deal with it.

This is what Firefox blocks by default: https://support.mozilla.org/en-US/kb/enhanced-tracking-prote...

Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%

#174
post #151

Earlier quoted context omitted.

Isn't this what Helium is doing? I have been using it as daily driver for half a year, works a charm. Only would like better 1Password integration.

Helium is based on ungoogled-chromium. It enables manifest v2 by simply reverting some code changes made by google. So, if google decides to remove manifest v2 wholly, helium will also lost its ublock original support.

Removing all manifest v2 support is also a code change that can be reverted. Of course, the larger the change, the more work it's likely to require to maintain it in the future.

Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%

#175
post #24

I am surprised there does not exist a community fork of Brave yet that strips out all of the commercial stuff (rewards, AI, own updates), making it suitable for inclusion in the repos of mainstream free/libre Linux distros.

This. I use Brave because it has a great, fast adblocker and is fast generally. Unticking all the wallet/AI crap upon install is an acceptable price, but if somebody is going to release Braveium I'm going to use it right away.

Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%

#176

Brave's adblocking engine is a neat example of open source and the ease of sharing lbraries in Rust. It uses Servo crates (also used by Firefox) to parse CSS and evaluate selectors, and is then itself published as a crate on crates.io where it can be pulled in by others who may want to use it.

So brave has two CSS engines? One for rendering and one for blocking?

Yes. Since for blocking you can afford to have a less mature CSS engine. A tradeoff for performance.

Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%

#177
post #45
post #26

Earlier quoted context omitted.

There is quite a lot of costs associated with running a browser (at scale). Brave is looking to offer something that does what you mention called Brave-origin. Brendan talks about this a bit more here: https://x.com/BrendanEich/status/2006412918783619455

This is good news, but I am confused by the following: """ Brave Origin is: 1/ new, optional, separate build (stripped down, no telemetry/rewards/wallet/vpn/ai); 2/ free on Linux, one time buy elsewhere. """ So the stripped down version (at least the non-Linux one) will not be open source?

That seems pretty reasonable proposition IMO.

As other people have mentioned you can resell open source software. I have a big box Linux distro on my shelf here.

Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%

#178

Earlier quoted context omitted.

You can hide bat with one click as soon as you install brave

Linux distros won't host the code for the commercial bits. It doesn't matter if you can hide it, it's the fact that it's there at all

Most distros have a way of installing proprietary software via enabling additional repos after install.

Re: Brave overhauled its Rust adblock engine with FlatBuffers, cutting memory 75%

#180
post #105

Earlier quoted context omitted.

> And yet Rust ecosystem practically killed runtime library sharing, didn't it? Yes, it did. We have literally millions of times as much memory as in 1970 but far less than millions of times as many good library developers, so this is probably the right tradeoff.

Static linking is still better than shipping a whole container for one app. (Which we also seem to do a lot these days!) It still boggles my mind that Adobe Acrobat Reader is now larger than Encarta 95… Hell, it’s probably bigger than all of Windows 95!

Whole container or even chromium in electron
Post reply on HN