codahale

Shamir’s is one of my favorite little crypto schemes. I’ve implemented it over GF(256) in a bunch of different languages just for fun:

Haskell: https://github.com/codahale/hs-shamir Go: https://github.com/codahale/sss Rust: https://github.com/codahale/sss.rs Java: https://github.com/codahale/shamir

XML parsing is notably an even larger minefield: https://www.owasp.org/index.php/XML_Security_Cheat_Sheet

Those safeguards were added by Travis CI folks as one of their remediation action items: https://github.com/DatabaseCleaner/database_cleaner/pull/521

"You know the law: two men enter, one man leaves."

While it’s definitely the case that there are more concise domain-specific examples, as you’ve pointed out, the article’s point stands: in Clojure, a Strategy is simply passing a function as an argument to another function.

Obviously, those are monoliths in dire need of decomposition.

3.1.x is a development branch and not intended for production use. When they release 3.2, MongoDB will support it.

MongoDB doesn't track this information, unfortunately.

And that 'nice' used to mean 'foolish'? http://www.etymonline.com/index.php?term=nice

And that 'fizzle' used to mean 'fart quietly'? http://www.etymonline.com/index.php?term=fizzle

And that 'wench' used to mean 'child'? http://www.etymonline.com/index.php?term=wench

And that 'meat' used to mean 'food'? http://www.etymonline.com/index.php?term=meat

Etymology is fascinating (a word which itself may be related to the Latin 'fascinum', or penis).

Taubes breezily dismisses the Hall paper, which is, methodologically speaking, pretty conclusive. If you're curious about the paper and its implications for Taubes's obesity-insulin hypothesis, I'd recommend these two blog posts by Stephan Guyenet, an obesity researcher:

http://wholehealthsource.blogspot.com/2015/08/a-new-human-tr...

http://wholehealthsource.blogspot.com/2015/08/more-thoughts-...

800-273-8255

National Suicide Prevention Lifeline

24 hours a day, 7 days a week

or www.suicidepreventionlifeline.org

If you want your reads to ever work, then they need to be synchronized. Reading from an unfenced address during concurrent writes is undefined behavior for any CPU architecture you can think of, which means you’ll get stale reads _in a best-case scenario_. You can also get garbage reads (e.g. as your CPU interprets your read of a 64-bit pointer as two 32-bit reads), crashes, bees, etc.

The code you write is either thread-safe, used in a single-threaded context, or a pinless grenade.

It’s worth noting that not only do you need to synchronize access to the singleton, you need to synchronize access to the singleton’s state as well. And even if you manage that at a fine-grained layer, you’re still setting yourself up for all the problems associated with singletons: http://c2.com/cgi/wiki?SingletonsAreEvil.

If you have a bunch of immutable state, then build unexported package variables in the package’s `init` func and export funcs which use those variables.

If you have a bunch of mutable state, then don’t use a singleton.

Two things:

First, you're describing RSA signatures. "Encrypt X with your private key" means "X^D mod N" which is how RSA signatures work. In the context of RSA-based cryptosystems, it's clearer to just say "signed".

Second, the ghsign library uses the `RSA-SHA1` signer, which runs the message through SHA1 before signing it. The reason it does this is because "textbook" RSA (i.e. RSA on arbitrary messages) is vulnerable to chosen-plaintext attacks.

I really really really don't recommend outsourcing your security architecture to interested passers-by if that's going to be a core feature of your project.

Apparently so. It uses DTLS, but I'm not sure where the certificates for that would come from or how their authenticity is verified. If it's all self-signed, then your best solution is TOFU (trust on first use). Otherwise your confidentiality and integrity are completely dependent on your network position.

* No confidentiality. All communications are sent plaintext. They plan to "add support in the future when solid approaches emerge".

* Non-repudiable. Everything you send is signed with the public key on your GitHub account.

* Uses SHA1. (via the ghsign NPM module)

* Uses mDNS and BlueTooth LE and a gossip topology algorithm, so I'm not sure what would prevent a random third party from eavesdropping.

I would hesitate to market this as "secure".

Postgres: https://aphyr.com/posts/282-call-me-maybe-postgres

That said, the ergonomics of the mutex design and the ownership system would probably eliminate most of the race conditions I've seen. Lock ordering can be effectively established by nesting mutexes: e.g. `Mutex<(X, Mutex<Y>)>` allows you to establish that any locking of Y has already locked X.

Use bcry—ah, fuck it.

I didn't do this in my spare time.

I did this in rough a week and a half of full-time work.

That was not the path taken by Amazon as they made their nearly 40 different APIs. Engineers from there could certainly speak to the circumstances behind their choices.

As for aws-go, I had some APIs I needed to use and a machine-readable description of those APIs. The choice was pretty clear.

The irony here is that your jaded insight is a retread of Fukuyama's 1992 framing of liberal democracy as a Hegelian end-state in _The End Of History_.

(Apologies for the self-promotion, but it's at least on-topic.)

I just opened up this repo yesterday: https://github.com/stripe/aws-go.

It's really raw, but it uses the JSON API descriptions from botocore to generate Go clients for all 40 public AWS services.

Some LinkedIn job titles from current GitHub employees:

  * VP, Business Development & Services
  * Head of Technology Partnerships
  * CIO
  * VP, HR
  * Vice President, Strategy
  * Vice President, Marketing
  * VP Communications
  * Director of Outreach
  * Director of Sales

Marc's definitely the best.

I think it is funny that the author manages to blame everything and everyone except bad software.

What would that accomplish? It's an article about the CAP theorem, not safety engineering or Byzantine fault tolerance.

It's almost as if bad experimental design makes a blog article not worth reading.

You separate your load generation tools from your system under test to eliminate confounding factors of shared resources like CPU, thread scheduler, memory allocator, disk, etc. This benchmark doesn’t do that, which means it’s impossible to distinguish between a queue system which is being saturated with work and a queue system which is out-competing the load generators for CPU. Also, it’s a laptop running OS X. Do you plan on fielding a queue system in a DC built out with Macbooks? No? Then this benchmark might as well be on a phone for all the inferential value it provides to people running Linux servers.

A single producer and single consumer means zero contention for either for most implementations. How well does this scale to your actual workload? What’s the overhead of a producer or a consumer? What’s the saturation point or the sustainable throughput according to the Universal Scalability Law? It’s impossible to tell, since this is a data point of one, which means it can’t distinguish between a system which has a mutex around accepting producer connections and a purely lock-free system. And that’s a shame because wow would those two systems have very different behaviors in production environments w/ real workloads.

Finally, measuring the mean of the latency distribution is wrong. Latency is never normally distributed, and if they recorded the standard deviation they’d notice it’s several times larger than the mean. What matters with latency are quantiles, ideally corrected for coordinated omission (http://www.infoq.com/presentations/latency-pitfalls).

This is not a benchmark, this is a diary entry.

I'm not here for debate club, Johnonymous. Like I said before, I'm here for the pearl-clutching.