It's far less studied and didn't exist (to any usable degree) at the time it was made. And it's extremely different, organizationally, so it's a difficult migration to pull off. And it has different incentives. And most miners have a lot of costs (e.g. hardware) that won't be recoverable if it's changed, so there's a fairly strong incentive to not change it.
Ethereum uses proof of stake now though (since 2022). Which happened in part because Ethereum is effectively centralized, or at least significantly more-so than Bitcoin.
>This is a deliberate design decision. lock_tree uses a DAG, which lets you declare that branches A and B are independent — neither needs to come before the other. Sounds great, but it has a subtle problem: if thread 1 acquires A then B, and thread 2 acquires B then A, and both orderings are valid in the DAG, you have a deadlock that the compiler happily approved.
Would it be possible to build one at compile time? Static levels seem like they won't let you share code without level-collaboration, so that might be kinda important for larger-scale use.
I don't know enough about Rust's type system to know if that's possible though. Feels like it's pushing into "maybe" territory, like maybe not with just linear types but what about proc macros?
I can definitely see why it's easier to build this way though, and for some contexts that limitation seems entirely fine. Neat library, and nice post :)
(Author here). Early in development I did exactly this with a macro. It was confusing when you wanted to refactor the code to change lock orders, harder to make clear error messages, and so on. Forcing the user to assign in a level means that it's clear(er?) to users what's happening, we don't need fancy (and difficult to debug) macro magic, and users can still do the linearisation themselves. That's the HOPE at least.
IMO compile time locking levels should be preferred whenever possible... but the biggest problem with compile time levels is that they, well, check at compile time. If you need to make mutexes at runtime (eg mange exclusive access to documents uploaded to a server by users) then you need to be able to safely acquire those too (provided in surelock with LockSet).
I can definitely believe explicit levels has more actionable errors. Type-shenaniganry without identifiable names can be pretty awful to unravel.
On that note though, I haven't found a whole lot of documentation or blog posts around trying to make better errors in macros or other compile-time checks. Have you looked at that/do you know of any decent detailed sources? I haven't looked too hard yet, but also I just don't have any good place to start, and Google's kind of garbage at the moment.
Some proxies, iptables extensions, and OS-provided tools exist - there's almost certainly a combo that would work for them. What platform?
Unless it's for a custom physical device, then uh. idk. Probably something, proxying through another computer that is hosting a separate wifi network? But likely a lot harder.
- "It can: Read and change all your data on all websites"
It's not alarming sounding enough for what that implies, but "it can trigger requests under its control" seems fairly obvious from that. The permission it uses to inject ads can be used to inject ads (or block them).
Why a JSON formatter needs any permission at all is something anyone installing it should be asking themselves.
---
This is not meant to imply that I think the permission model of extensions in chrome or firefox is good, clearly it is not. But it's significantly better and more fine-grained than every single other widely-used permissions system in consumer apps. Ideally there should be more carve-outs for safe niches like a "read a JSON file, rewrite it into something that does not need javascript or external resources" could use, but also that kind of thing is likely to be nigh impossible to make "complete".
"Read and change data on all websites" does not, to me, imply "make network requests on the user's behalf". Yes, I can put on my developer hat and surmise that, under the hood, the extension's injected payload can make network requests by adding <script> elements to the DOM. No user will ever understand this, no matter how much you try to educate them through the permission prompt.
This ends up being significantly worse than any other widely-used permissions system, because injected scripts act as the website, not the extension. If you've already granted location permission to a website, then it is effectively granted to the extension. There is no other ecosystem that works like this.
And to do basically anything worthwhile, including certain types of content blocking, you need this God permission that essentially disables the WebExtension permissions system. This should never have been greenlit in the first place.
>"Read and change data on all websites" does not, to me, imply "make network requests on the user's behalf"
Yeah, I don't like this phrasing either, I think it downplays the risk to a dangerous degree (which is "it can see and do literally anything on any site you visit", which is GIGANTIC). It's one of the worst permissions to request, but it doesn't look like it.
But other permissions systems don't have per-site controls, or the ability to turn things off until activated, or isolate everything, or... the list is huge, others generally have permissions like "can access this folder [and others we haven't told you] [and folders you give it access to, which you can't revoke later https://news.ycombinator.com/item?id=47719602] [and only for applications which opt into this, normal ones can do anything anywhere any time]...." which is much worse.
If there's no downside to leaving the ladder in place, then I would think yes - there's a reasonable expectation that people will die due to your actions. You'd likely have to argue about "involuntary manslaughter" vs something more intentional though, depending on circumstances.
If there is a reasonable downside, probably no? You have a right to try to keep yourself alive, in nearly all contexts.
Anecdotally, bells have always come through fairly clearly for me. They filter out lower tones, not higher + sine waves. Nothing about this adds up to more than any normal $5 bell, especially rotating ones which hammer repeatedly.
I've seen more than one half-joke-half-serious chunk of code that would "encode" arbitrary info into stack traces simply by recursively calling `fn_a`, then `fn_s`, `fn_d`, and `fn_f` before continuing with the actual intended call, giving you a stack trace with (effectively) "asdf" in it.
They've also been useful more than once, e.g. you can do that to know what iteration of a loop failed. There are of course other ways to do this, but it's hard to beat "stupid, simple, and works everywhere" when normal options (e.g. logs) stop working.
They're kinda like high-effort shitposts. Which are my absolute favorite kind. The worse the effort/reward payoff, and the more it makes you ask "WHY??!!?", the better.
Ethereum uses proof of stake now though (since 2022). Which happened in part because Ethereum is effectively centralized, or at least significantly more-so than Bitcoin.
reply