1,329 karma · joined March 28, 2013
The drawback is it gets a lot more complex when using a token, because of the additional state, communication, costs and security.
A one shot proof of work can be very simple, but probably not effective enough, given that mobile users likely do not want to wait what may have to be many minutes and drain their battery.
Freezing a cent or a dollar for days seems like a better option. Might very well be that VISA/MasterCard figures this out before the crypto bros build anything usable. It will be far easier to do without decentralization and would also be great to spy on and control people.
Tor has such a feature for denial of service protection.
https://blog.torproject.org/introducing-proof-of-work-defens...
A benefit of a token is you can recycle previous proof of work by using a small amount of Bitcoin, which could be transferred using Lightning. The value could also be transferred back some amount of time after registration given no bad behavior, allowing for larger sums than a cent, which could provide better protection.
As for smugness and the format of posts, you sure don't live as you preach.
As for piracy, of course it's wrong, though far less serious than what I responded to.
> depriving the original owner of the use of the item
When someone invests to make a film, do you think the use of the resulting film to the owner is to watch it or sell it?
To break it down, did someone invest millions to make millions, or did someone pay millions to watch one movie?
You know the answer and thus we know that stealing a copy without paying does does in fact deprive the original owner of the use of the item, which was always to sell copies of it, that's the reason and criteria for its existence.
At small scale though the industry still makes do, so it's less serious than stealing for example, a company (e.g. their information). Every act of piracy also wasn't technically a stolen sale, because not everyone stealing would ever have bought it if stealing wasn't an option.
Which one is the central authority?
It contains no one else's code since everyone works on a branch. This is only holds if a single team uses a brach. That doesn't scale.
Open sourcing Erlang and it finding some success outside, meant it's no longer an in-house only language.
Systems:
- Lacks a GUI.
- There are technical details.
- Doesn't compete with applications.
- Memory pressure is an issue.
Applications:
- Has a GUI.
- Need to be responsive.
- Power usage is important.
- Memory pressure results in slowness.
I don't think we got any closer to a useful answer.
Of course it's fuzzy and unimportant, they're just words for categories we've made up, and didn't even make a very good job of it.
Even if we did make it clear which is which, what's the gain from being able to make a clear distinction? Is it any more productive than fighting over who got the best text editor?
Just like you don't have to and cannot read every book in your lifespan, you can't read every blog post. Your bookmarks doesn't have to be your todo list.
You might like Pocket or similar. Pocket specifically can sort your bookmarked articles in various ways, including popularity on the service, or just let it sit there knowing you have the possibility.
* Puts burden on readers to know or find out if something else already protects the bug from being exploitable, instead of just having a check in the code. That's trivia masquerading as an optimization.
* A bug or change in behavior in one program (the kernel) could cause a bug in another program (ping) due to assumptions, which may not even have been documented as never changing guarantees. Could make a bug somewhere grow into a worse bug elsewhere, as well as being harder to debug.
* It allows the program to be fuzzed or statically analyzed for any bugs without having to constrain what inputs are considered valid enough, adding maintenance costs and opening for accidentally limiting too much and hiding exploitable bugs.
* Another option to be clear that this is impossible and thus correct code would have been to assert that the user data never looks like this. A failed assert is better than an infinite loop, so this is an improvement. However this would make it blindingly clear that user input is trusted, making it too obvious to ignore the next improvement; to check and handle the issue, even if that input passed through another program first.