Freaky

https://github.com/restic/restic/issues/21

> Uses aggressive de-duping on their backend (ZFS based I think?)

Err, I hope not. Pretty sure they sync a database of seen blocks between clients and they collectively dedupe based on that - their backend simply shouldn't have the information necessary to dedupe itself.

There's also restic, which works similarly, but has native support for cloud storage: https://restic.github.io/ - sadly it's claims of being efficient are rather undermined by the continued lack of compression support.

    m = ceil((n * log(p)) / log(1.0 / (pow(2.0, log(2.0)))));
    k = round(log(2.0) * m / n);

http://52.24.230.241/bc/password_generation.php

This produces memorable passphrases pretty close to that limit, as described in http://www-scf.usc.edu/~mghazvin/papers/marjan15.pdf

> *) HTTP/2 support no longer tagged as "experimental" but is instead considered fully production ready.

~/.muttrc: alternative_order text/plain

http://i.imgur.com/uz2inSy.jpg

I encountered this going through a copy of my photos stored on a pair of WD Greens using NTFS 3-4 years ago. The original copy on a ZFS machine was fine. I found a few others, and promptly stopped using those drives.

Two years ago I had repeated bursts of ZFS checksum errors from a pair of SanDisk SSDs. Evidently TRIM didn't quite work perfectly 100% of the time, and caused data corruption - luckily ZFS was always able to repair it, and it being detected meant I could do something about it early - I updated firmware and the issue went away. Last year it came back after an OS update, and I just turned TRIM off completely (I guess it was sensitive to TRIM patterns and those changed).

Last year I also had a Toshiba HDD forget how to IO properly, and got a constant stream of ZFS checksum errors from it until I yanked it from the hot-swap bay and reinserted it. It resilvered and scrubbed fine.

These aren't the only times I've seen checksum errors and silent corruption, they're just the most recent. ZFS lost a file once, and was very noisy about it - the status message for the lost metadata stayed until I recreated the pool. NTFS, UFS2, ext2, all were completely silent on the fact that they were showing me data that was clearly wrong.

I don't trust disks, or IO controllers, and I don't trust filesystems that do. Neither should you.

    -% zsh -f
    voi% echo $ZSH_VERSION
    5.3.1
    voi% autoload -U compinit
    voi% compinit
    voi% git checkout <tab><tab>\$\(./pw3n\)
    Already on '$(./pw3n)'
    Your branch is up-to-date with 'origin/$(./pw3n)'.
    voi% git checkout com<tab>plete_\$\(./foo\)
    Switched to branch 'complete_$(./foo)'

Use noerror, but forget sync? Corrupt output file if there is an error. Use a bigger bs so it's not slow as treacle? A single faulty sector blows away a whole bs of data, and your output image may get unwanted padding appended to the end. Recoverable error? dd's not going to retry.

Use ddrescue or FreeBSD's recoverdisk(1). They're faster, they're safer, they're more effective, and they're easier to use.

And of course you can click on a galaxy and fly to it with a press of the g key. Watching thousands of galaxies zip by like stars in Star Trek is pretty mindboggling (also note that high warp is somewhere around 20 AU/sec using the TNG scale...)

Example I made a few days ago: https://imgur.com/a/xyZe8

System-driven space colony simulation, with a particular emphasis on maintaining breathable air.

And a nice fluffy white one with very stubby legs: http://www.jumpingspiders.co.za/images/main/187.jpg

Via https://www.reddit.com/r/awwnverts/comments/5o7nmg/my_favori... and https://www.reddit.com/r/awwnverts/comments/5lar18/floof_spi...

ddrescue or recoverdisk (part of FreeBSD base) will both skip over unreadable blocks, then retry with smaller block sizes along the damaged areas to save as much data as possible.

799 open tabs. 8.5GB. Restarted in around 10 seconds and it's currently using around 2GB. "Delay loading of background tabs" is checked, which I believe is the default now.

Not had any serious responsiveness problems. The browser extension I use to give me a list of tabs on my sidebar is a little slow when opening a new window, that's about it.

The hash is there to ensure very long passwords contribute entropy to the final hash instead of being truncated. It also ensures the entropy is evenly distributed - every bit of the password affects every bit of the hash.

> the "security" code only needs to handle 64-byte random strings

You can't feed any typical BCrypt implementation a raw SHA-512 hash because it's not binary safe - it truncates at the first NULL byte.

Well, you can, and it'll appear to work, but it'll be laughably easy to break. It's a pretty stupid sharp edge IMO.

> which are truncated to 54-byte strings for `bcrypt`

72 bytes, because that's the size of the key array. 56 bytes is just where extra entropy helps less, because the last 16 bytes don't affect every bit of the output.

> That removes all sorts of stupid edge cases that come with variable-length strings.

It's just treated as a circular buffer. And what are we doing here, implementing our own version of BCrypt? Yeah, that certainly simplifies things :P

Huh? BCrypt works by stuffing the password into a 72 byte Blowfish key and using it to recursively encrypt a 24 byte payload. Either it's truncating, or it's pre-hashing the password to fit much like they are.

The link they use to justify it is funny: http://arstechnica.com/security/2013/09/long-passwords-are-g...

That's just a naive PBKDF2 implementation that's pointlessly reinitializing the HMAC context each iteration instead of just doing it once at the start. The difference between storing a 1 byte and a 1MB password with PBKDF2 should be on the order of a couple of milliseconds.

> On the HGA we expect ≥18 kilobits per second (kbps) (≥12 kbps during Grav passes due to power required for carrier signal), and ≥10 bps on the MGA.

HGA = High Gain Antenna, MGA = Medium Gain Antenna. HGA activity is limited to when the spacecraft is precisely aligned towards Earth:

> Due to the nutation of the spinning spacecraft following any maneuvers, we will need to allow several hours for nutation damping following Earth-point maneuvers before using the HGA.

> Currently we allow 8 hours prior to most DSN tracks and 16 hours prior to the 6-hour MWR or Grav perijove science passes that start at PJ – 3 h.

So it's not necessarily any slower than your modem once it gets going, it just has terrible latency and dialing the connection can take the better part of a day.

> As for the Starshot thing, that sounds like a reboot of Robert Forward's Starwhisp idea from the 1990s. The real problem with that is, how to get any data back from it. (Not to mention how to construct a continuously operating gigawatt laser array in space).