449 karma · joined September 16, 2014
The key is that the contracts need to be minimal and analyzable, so its ~100 lines of code you can manually analyze. Documented separately all the edge cases, or ideally removed through good design so they simply don't exist. A bunch of problems I've seen in the real world of crypto are annoying edge cases that you can fix with an if statement, or ideally change the design to remove them completely. It's actually a surprisingly hard space because you're trying to make terse, complete and secure code.
In normal web/systems programming you have layers of security; internal services, external services, firewalls, access controls, vpns, security by obscurity, etc etc etc. In crypto you have none of that. Everything is 100% public, the code probably should be published, or else it is trivially decompiled. If there is a problem someone will find it if there is value in finding it.
You can make powerful systems with simple correct independent components. You can not make complex secure monolithic systems. It gets even worse when you look at contracts with delegation.
The problem with most "smart" contracts is they have abstractions, delegation and scope creep.
No interrogation of why it spread was investigated. It immediately made me wonder, maybe people just thought "false" information was a whole lot funnier, and hence sharable.
The problem with misinformation is it vaguely doesn't exist. There's parody, non-orthodoxy, true things people disagree with for political reason, unproven things, urban myths, rumors, etc etc. These are all classes of information people blame all the ills of society on.
Mixing your distribution systems with references to each other seems like a recipe for confusion and anger. And it looks like they got the expected outcome.
% rm /tmp/test.sh ; echo $'#!/bin/sh\necho Hello' > /tmp/test.sh && chmod a+x /tmp/test.sh
% time bash /tmp/test.sh && time bash /tmp/test.sh
Hello
bash /tmp/test.sh 0.00s user 0.00s system 83% cpu 0.004 total
Hello
bash /tmp/test.sh 0.00s user 0.00s system 77% cpu 0.003 total
vs the one from the article:
% rm /tmp/test.sh ; echo $'#!/bin/sh\necho Hello' > /tmp/test.sh && chmod a+x /tmp/test.sh
% time /tmp/test.sh && time /tmp/test.sh
Hello
/tmp/test.sh 0.00s user 0.00s system 2% cpu 0.134 total
Hello
/tmp/test.sh 0.00s user 0.00s system 73% cpu 0.004 total
(edited for formating)
This implies a shocking high R(effective) for that population. In 2 weeks we'll have super interesting data one way of the other on the CFR.
tl;dr: gunicorn doesn't know how to multiplex listeners and green threads will ruin your request latency.
The thing is, that post isn't very useful nor interesting. The point here is that the "simple" python architecture doesnt scale well at all so you might not want to use it if you're planning on scaling ever.
So we're basically having people make themselves sick by watching the news, its a brand new pandemic!