261–270 of 289 posts
Earlier quoted context omitted.
Rust crates can run arbitrary code at build time: https://doc.rust-lang.org/cargo/reference/build-scripts.html
> Build scripts communicate with Cargo by printing to stdout. Oh lord.
Earlier quoted context omitted.
It does support dynamic libs, but virtually all important Rust software seems to be written without any consideration for it.
Rust ABI (as opposed to C ABI) dynamic libraries are incredibly fragile with regard to compiler/build environment changes. Trying to actually swap them out between separate builds is pretty much unsupported. So most of the benefits of dynamic libraries (sharing code between different builds, updating an individual dependency) are not achieved. They’re only really useful if you’re distributing multiple binary executab…
Earlier quoted context omitted.
Rust does support C ABI through cdylib (as opposed to the unstable dylib ABI). This is used widely, especially for FFI. An example of this is Python modules in Rust using PyO3 [1]. [1] https://pyo3.rs/v0.15.1/#using-rust-from-python
Yeah but you can’t use the vast majority of crates that way. You have to create a separate unsafe C ABI, and then use it in the caller. Ergonomically, it’s like your dependency was written in C and you had to write a safe wrapper.
You get lucky when all assets have been compiled with the same toolchain (with the same options) but will lose your mind when you have issues caused by this thing neither you nor the package authors knew existed.
Earlier quoted context omitted.
[flagged]
Wild accusations considering this stuff still exists online as direct evidence: https://brave.com/blog/binance/ Also attacking the person instead of the ideas is really not in the spirit of HN.
These are non-tracking, carefully designed (including vetting by Brave), brand advertising images. They are not ads (we never did this) inserted into publisher pages, or (opt-in only) push notifications.
Brave has been working to find ways to sustain ourselves, and these sponsored images are still a good revenue line, although lesser now vs other lines. If you want, turn them off.
Free riding is always an user right, we don't try to stop it on principle, as if we ever could with open source. But there's no free lunch: if you use Firefox, you are Google's product. If you use a Firefox fork, you're free riding on Gecko which costs a lot to maintain. HTH
Earlier quoted context omitted.
lead what? https://archive.is/W0k4j (disclaimer: people remember how sketchy Brave is)
Don't forget when they took donations on behalf of other websites and kept the money unless the operator went to the "escrow account" to collect it
The issue which I found out about late, and fixed right away, was infringing on right to publicity, nothing to do with donations from users' own tokens.
Earlier quoted context omitted.
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.
It's so much cheaper to optimize now than before.
Earlier quoted context omitted.
A $130 Motorola smartphone has 8GB of RAM. This will save 0.5% RAM. It's fairly negligible on modern systems.
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.
Earlier quoted context omitted.
> auditing your dependencies is How do you do that practically? Do you read the source of every single package before doing a `brew update` or `npm update`? What if these sources include binary packages? The popular Javascript React framework has 15K direct and 2K indirect dependencies - https://deps.dev/npm/react/19.2.3 Can anyone even review it in a month? And they publish a new update weekly.
More useful than reading the code, in most cases, is looking at who's behind the code. Can you identify the author? Do they have an identity and reputation in the space? Are you looking at the version of the package they manage? People often freak out about the number of packages in such ecosystems but what matters a lot more is how many different people are in your dependency tree, who they are, and how they operate…
That doesn't necessarily help you in the case of supply chains attacks. A large proportion of them are spread through compromised credentials. So even if the author of a package is reputable, you may still get malware through that package.