111–120 of 289 posts
I just found out Brave supports Vertical tabs, https://brave.com/blog/vertical-tabs/ I might have to try switching from FF...
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.
You can hide bat with one click as soon as you install brave
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.
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!
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…
Dynamic libraries are a dumpster fire with how they are implemented right now, and I'd really prefer everything to be statically linked. But ideally, I'd like to see exploration of a hybrid solution, where library code is tagged inside a binary, so if the OS detects that multiple applications are using the same version of a library, it's not duplicated in RAM. Such a design would also allow for libraries to be update…
This way we'd have no portability issue, same benefit as with static linking except it works with glibc out of the box instead of requiring to use musl, and we could benefit from filesystem-level deduplication (with btrfs) to save disk space and memory.
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.
I like Brave but the only thing that keeps me from using it on mobile is the lack of extension. That's why Firefox is my daily driver on Android
Earlier quoted context omitted.
Now multiply that across all apps/services/extensions/profiles and it adds up. This kind of lazy thinking is why today’s software is so bloated and slow.
It adds up but it would require to rewrite all software, which would be pretty costly. I agree with the sentiment but it's a bit too late now. The problem is with how software is designed around being cheap to write.
Earlier quoted context omitted.
But that's what Linux distros are for, package maintainers watch the CVEs for you, and all you have to do is "apt upgrade"
Not sure I follow. Suppose you tore out a portion of libxml2 for use in your HTTP server. A CVE is filed against libxml2 that is related to the subset you tore out. Obviously, your server doesn't link against libxml2. How exactly would distro maintainers know to include your package in their list?
Earlier quoted context omitted.
I think the broader point being made here is that the C-style approach is to extract a minimal subset of the dependency and tightly review it and integrate it into your code. The Rust/Python approach is to use cargo/pip and treat the dependency as a black box outside your project.
Advocates of the C approach often gloss over the increased maintenance burden, especially when it comes to security issues. In essence, you’re signing up to maintain a limited fork & watch for CVEs separately from upstream. So it's ultimately a trade off rather than a strictly superior solution. Also, nothing in Rust prevents you from doing the same thing. In fact, I would argue that Cargo makes this process easier.