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.