nathan7

Awesome! The one thing that turns me off a little is `ModTime`. I generally avoid incorporating modification times into my build (generally I force them to 1970), but a hash for the ETag would be very welcome.

https://golang.org/x/crypto/nacl for the Gophers among us (it provides only box/secret_box, though)

https://medium.com/@sdboyer/so-you-want-to-write-a-package-m... would be a good start

I'm assuming you mean vdevs — you can resize zvols (virtual block devices) just fine. (and you can even grow disk-type vdevs, though they'll be somewhat unbalanced)

SSLmate (https://sslmate.com/) actually makes things similarly simple — I've been using them for a few months now.

You can't prove the hash function is correct, no. But you can prove the hash function is implemented equivalently to its definition. That's what the article is about.

MaidSafe (http://maidsafe.net) and Skylight (https://skylight.io) are both written in Rust, Maidsafe having recently moved to it from C++.

It's worth noting that KVM doesn't allow remapping the APIC base address at all: https://github.com/torvalds/linux/blob/49d7c6559bf2ab4f1d56b...

I haven't been back home (Amsterdam) for most of this year, but I find that surprising — I usually have trouble coming up with more than three ice cream parlours off the top of my head. Where's all this great ice cream I've been missing out on?

This article wasn't written by Steve Klabnik — merely "reprinted".

Recently, it was brought up on Proggit that Chris Smith's "What to Know Before Debating Type Systems" was no longer online. This is a really great article, and in an effort to make sure it survives, I've grabbed the archive.org cache and am 'reprinting' it here. If you're into programming languages, read this and level up!

By all means not an official statement, but Isaac is quite committed to making sure that the long-term safety of the npm registry doesn't rely on the future benevolence of npm Inc.

I'd argue that they all derive from, and are quite similar to Portage's USE flags.

Awesome to finally see Gun on here, Mark! What still worries me is the reliance on external storage services, although a good local storage service could be built for Gun. Other than that, I'm glad to finally see docs!

Also among them: https://github.com/facebook/rebound-js https://github.com/facebook/rebound

I'm writing an HTTP reverse proxy in Rust, and my main gripe so far is that I have to roll my own async I/O. Binding node's HTTP parsers over is going well, but also takes a bunch of effort. Safe-by-design and close to the metal are proving very enjoyable to work with for this, however.

These days, I find using MD5 absolutely inexcusable. SHA-1 is available pretty much everywhere, SHA-2 algorithms are quite readily available too. BLAKE2 (https://blake2.net) is slightly faster than MD5, and significantly more secure. It's based on the SHA-3 finalist BLAKE. Additionally, there are versions of the algorithm that parallelise using SIMD, and there are both 32-bit and 64-bit optimised versions too. It also gives you the possibility of customising your hash, using it as an HMAC at no extra cost, salting it, or adding a personalisation key to effectively have different hash functions for different purposes. As a nice extra, it also uses a third less RAM than SHA-2 or SHA-3. If output length is a concern, truncating the output (with a corresponding increase in the likeliness of collisions) is perfectly fine with any good hash function.

I think you'd be quite happy in Rust, if you substitute trait methods for multimethods too.

Most of these slides are about patterns that are provided for as functions by the language, or are otherwise obsoleted by the more powerful abstraction features of FP languages. The writers of this presentation are very much aware of the smell that is patterns.

I'll miss Ezra and his outgoing spirit. Goodbye, old friend.

I'm guessing that mitigating this at the Rust level isn't doable, because its memory model has the same properties with regards to zeroing. To change that, LLVM support would be needed. This does make me wonder — how do you integrate this into a type system? Rust has already done a pretty awesome job at integrating memory-safety into the type system, but memory-secure type systems seem fairly unexplored.

The key can be generated on the smartcard, and it's not possible to transfer it out of the smartcard by design. (anything that calls itself a smartcard but allows this isn't a smartcard)

What you're describing is called a smartcard, and readily available on the market. I keep my PGP key on one.

I'd say that many of the issues surrounding accidentally using mutable state are fairly moot in Clojure. Blocking still remains an issue, though there's core.async/thread for go blocks that block so that they're executed on a thread of their own.

The flawed assumption is "and therefore 21 million Bitcoin addresses". Generate an RSA keypair, and give out the hash of the public key (encoded in a Bitcoin-specific way). Anyone can send you Bitcoins there now.

Hawala has fascinated me to no end, as essentially an anarchistic peer-to-peer web-of-trust banking system. It has existed for a long time, and keeps functioning even where traditional banking systems have broken down. As cool as Bitcoin is, I have more hope for a system akin to Hawala than some proof-of-work based system. Guerilla banking that depends on having more (computational) power than your enemies isn't too realistic. PGP'd remittances are much more cryptographically robust, and depend just on the one factor that any real monetary system relies on anyway: human trust.

The visualisation means next to nothing for proving it's good. But the visualisation seems to show patterns, which says plenty.

Accepted, but they seem to be on either side of a dividing line — I'm doing my best to straddle it, but I'm still held back by a wall of language that is too often entirely impenetrable to me. I'm a very functionally-minded programmer, and I'm rapidly adapting to Clojure now (coming from rather functional JS, and having spent a rainy week on Haskell, which taught me basic type theory and such) — but I still often hit the wall of impenetrably abstract things too :(

The best guess I've come up with is that anyone who is sufficiently mathematically inclined becomes a mathematician. I'm curious if anyone has any points/counterpoints in that direction.

There's no node involved in the registry itself. This is purely CouchDB.

npm is pretty much the prime use-case for CouchDB. REST API out of the box, replication is a core feature and not just a scaling feature (multi-master, MVCC) and the validation/access control is pretty much made for it. The npm registry is implemented as a CouchApp for a reason.