ring leader
anon dissenters
| #!python | |
| """OpenSSL enc compatible script by Python. | |
| """ | |
| """ Based on: | |
| https://gist.github.com/chrono-meter/d122cbefc6f6248a0af554995f072460 | |
| Added: base64 | |
| Need: python3-crypto | |
| # Encrypt | |
| python3 ./aes256-compat-openssl-enc-dec.py -in <filein> -e -salt -aes-256-cbc |
This is a proposal for lightning talk at Reactive Conf. Please 🌟 this gist to push the proposal!
Hi, I am Andy, creator of leakage - the node-powered memory leak testing library.
Instead of manual debugging it provides a structured approach to fix or even prevent memory leaks.
warning: ignoring broken ref refs/remotes/origin/HEAD
➜ ✗ g symbolic-ref refs/remotes/origin/HEAD refs/remotes/origin/develop
➜ ✗ g fetch --prune
➜ ✗ g gc
| /** | |
| * Base contract that all upgradeable contracts should use. | |
| * | |
| * Contracts implementing this interface are all called using delegatecall from | |
| * a dispatcher. As a result, the _sizes and _dest variables are shared with the | |
| * dispatcher contract, which allows the called contract to update these at will. | |
| * | |
| * _sizes is a map of function signatures to return value sizes. Due to EVM | |
| * limitations, these need to be populated by the target contract, so the | |
| * dispatcher knows how many bytes of data to return from called functions. |
When Swift was first announced, I was gratified to see that one of the (few) philosophies that it shared with Objective-C was that exceptions should not be used for control flow, only for highlighting fatal programming errors at development time.
So it came as a surprise to me when Swift 2 brought (What appeared to be) traditional exception handling to the language.
Similarly surprised were the functional Swift programmers, who had put their faith in the Haskell-style approach to error handling, where every function returns an enum (or monad, if you like) containing either a valid result or an error. This seemed like a natural fit for Swift, so why did Apple instead opt for a solution originally designed for clumsy imperative languages?
I'm going to cover three things in this post:
| import java.io.FileDescriptor; | |
| import java.io.FileOutputStream; | |
| import java.io.IOException; | |
| import java.io.OutputStream; | |
| import java.io.PrintStream; | |
| public class HelloWorld{ | |
| private static HelloWorld instance; | |
| public static void main(String[] args){ | |
| instantiateHelloWorldMainClassAndRun(); |
Hi guys! Since I started to write Bluebox-ng I've been tracking the different security projects I found written in Node.js. Now we've published the first stable version we think it's the right moment to speak among us (and, of course, everyone interested in it :).
| #!/bin/sh -e | |
| hostname=$1 | |
| device=$2 | |
| file=$HOME/.dynv6.addr6 | |
| [ -e $file ] && old=`cat $file` | |
| if [ -z "$hostname" -o -z "$token" ]; then | |
| echo "Usage: token=<your-authentication-token> [netmask=64] $0 your-name.dynv6.net [device]" | |
| exit 1 | |
| fi |
I say "animated gif" but in reality I think it's irresponsible to be serving "real" GIF files to people now. You should be serving gfy's, gifv's, webm, mp4s, whatever. They're a fraction of the filesize making it easier for you to deliver high fidelity, full color animation very quickly, especially on bad mobile connections. (But I suppose if you're just doing this for small audiences (like bug reporting), then LICEcap is a good solution).