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.
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)
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.
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.
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!
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.
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'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)
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.
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.
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.