FlatBuffers was definitely the majority of the improvements here!
On 64-bit systems, pointers themselves can really start to take up a lot of memory (especially if you multiply them across 100k+ adblock filters). Switching to array indices instead of pointers saves a lot of memory that's otherwise wasted when you don't need to address the entire possible memory space.
I guess code bloat is proportional to schema complexity, and performance improvement is proportional to volume, so in ad blocker with many large block lists the latter dominates.
The biggest improvement for us was deduplication by using generators an referencing already emitted objects. Don't run flatc on a JSON, it doesn't do that.
I opened an issue based on the discussion here and it didn't take much time or effort.
(It was one of those form-based issue templates that requires you to explicitly list out Steps to Reproduce, Expected behavior, Actual behavior, OS version, etc. which IMO causes slightly more friction for anyone who knows how to put together a good bug report, but I've also seen enough poorly-specified issues to know that it's necessary sometimes)
Funnily enough, I'm on a British Airways flight right this moment. I'm only using a basic Wireguard tunnel after enabling the free messaging plan. I get the sense they didn't design the firewall to block everything comprehensively.
If you want to find devices that still need hardware support under Linux, I highly recommend trying to get a mobile Linux distribution to work on an old smartphone or tablet.
postmarketOS in particular has a really good devices page [1] showing missing feature support at a glance, as well as guides for porting to new devices [2] and porting features from an outdated vendor-provided Linux fork to the upstream kernel [3].
I genuinely want to work on postmarketOS but I don't have the technical know-how right now but one day.
I would prefer a sort of dual-boot or just a simple ability to run linux in "android phones"
Like, if we were to build a linux phone somehow hacking it through a raspberry pi or the alikes, they would be so much more costly and subpar.
Android phones have whole globalization working on it and the only reason why they don't work is lack of drivers support/software side, something which can be worked on.
I think if society rewards something like PostMarketOS more/make it easier to install it, then things can be so great as well.
I know I can run a terminal inside android but till now it was only possible through qemu which had its issues...
I am not sure but I have never really appreciated having linux run inside a vm, I'd much rather run something like waydroid in a postmarketOS phone than linux inside android in an ideal world technically speaking from strictly performance but we don't live in one and installing waydroid on postmarketos or even installing postmarketos can be a very huge issue whereas installing linux on android can be a single step with termux or userLand.
It's possible to dual-boot. My favorite method is to have a device with a SD-card slot and have android on the eMMC but PostmarketOS on the SD-card.
Currently only do that on one of my older devices, would love to do it on my main device but when I bought it I was in a hurry to get it going and did not have time to unlock the bootloader. Unlocking the bootloader now means having to factory default the device but I simply have too much important stuff set up that it's not worth it. Apparently there's also no great way to backup all partitions of the Android device which I find to be quite strange.
You could also look into running mobile Linux on top of libhybris - it's a proprietary compatibility layer, but some people use it to get support for mobile Linux runtimes on more recent devices.
I'm actually trying this right now, but it is becoming much harder than I expected. The fact that I keep needing to recompile kernel and rebooting device doesn't help. I'm trying to make the display and touchscreen work consistently on a qualcomm soc.
Are you referring to the Manifest V2 extensions supported by Brave? The original extension creators were made fully aware of those plans ahead of time and have been in contact with Brave since then, e.g.:
I'm not sure how you can interpret forking open source codebases as a "shady" behavior (it's one of the most important reasons to use open source in the first place), but in this case there is a high demand for said extensions and Brave has provided the only way to continue doing so on a Chromium rendering engine.
(I am one of the devs who worked on the spec for this feature)
No, I am not talking about continued manifest v2 support. What I referred to took place a few years earlier when extensions where first implemented in Brave.
Open source has the best kind of coordination. If there's a real use-case for two things to work together, you or someone else can implement it and share it without anyone's permission. Meanwhile in proprietary land, people sometimes build things that nobody wanted, and also leave out features with high demand. Proprietary optimizes for the profit of some individuals; open source optimizes for maximum utility.
Thus far, open source has optimized for maximum utility for individuals who can write code... but AI may be changing that soon enough.
I am a fan of open source, but it’s definitely not for the coordination part.
Proprietary, money driven development, is top down and has coordination in general. In very large software, it starts failing sometimes (I’m looking at you Oracle)
Open source handles conflict by forking. I wouldn’t call that good coordination.
But, at the same time, I don’t see a better (or less worse) solution so I shut up and I take their code =)
> Open source handles conflict by forking. I wouldn’t call that good coordination.
Forking is far from the first step in conflict resolution; it is the ultima ratio between projects in the open-source world, when all dialogue breaks down. In other words, the worst outcome is that people agree to disagree and go their separate ways, which is arguably as good a solution as is possible.
In the corporate world, coordination mostly exists within companies through top-down decision-making, as you said. Between them, however, things look much grimmer. Legal action is often taken lightly, and more often than not, a core business goal is to not just dominate, but to annihilate the competition by driving them out of business.
Coordination between corporations, such as through consortia, is only ever found if everyone involved stands to profit significantly and risks are low. And ironically, when it does happen, it often takes the form of shared development of an open-source project, to eliminate the perceived risk of being shafted.
>
Forking is far from the first step in conflict resolution; it is the ultima ratio between projects in the open-source world, when all dialogue breaks down.
You also do a fork if you simply want to try out some rather experimental changes. In the end, this fork can get merged into the mainstream version, stay independent, or become abandoned. People wanting to try out new things has barely anything to do with all dialogue breaking down.
You may also fork from having different goals or ideas about some mutually incompatible requirements without an communication or coordination issues. Friendly forks happen all the time.
Right. In this case I am talking about a "hard" fork, where core contributors disagree on where a project is headed and split up with no intention of collaborating further. Of course, forking with the intent of merging back contributions does not apply here, as is a cooperative and coordinated process. In that case, the "fork" really only serves as a staging ground for contributions.
Often there's a great use case for two things to work together but you have a chicken and egg situation. You need a top-down edict to get everyone on the same page.
Wrong. Take the LSP example: a) I don't have time to add LSP support to Vim, Emacs, KDevelop, etc. and write language servers for Python ok n, C++, Rust, Go, etc. and b) those projects would not accept my contribution if I tried. They would say "what is this LSP thing that nobody uses? Come back when it's popular".
The latter is where you need the coordination. In a company someone high up can say "we're doing it's like this" and everyone has to fall in line.
In a company, yeah. LSP is a Microsoft initiative. Swap your open source examples to proprietary editors from different vendors and it's otherwise the same story, but now you can't provide both the chicken and the egg yourself.
As someone who's been building an adblocker for the last 6 years: yes, there's plenty of proof in the devtools console on more websites than you'd think.
Fingerprintjs [1] is a well known one that gets a lot of use. And if you check EasyPrivacy, you'll see the rules to block it [2] have been in place for a long time.
