Freaky

There's something I find really off-putting about a tool that's going to be managing private keys having dependencies that point to the master branch of various third party git repositories.

It also unconditionally tries to listen on ports 80, 402, 443, 552 and 4402 whenever it completes a challenge, even if you have absolutely no intention of using any of these verification methods, so there's a lot of moving parts most of which you don't want.

I made a FreeBSD port, but thought twice about submitting it: https://github.com/Freaky/ports/tree/master/security/acmetoo...

And with more data:

After nearly 8 hours:

    rngtest: bits received from input: 6762248
    rngtest: FIPS 140-2 successes: 156
    rngtest: FIPS 140-2 failures: 182
    rngtest: FIPS 140-2(2001-10-10) Monobit: 182
    rngtest: FIPS 140-2(2001-10-10) Poker: 174
    rngtest: FIPS 140-2(2001-10-10) Runs: 160
    rngtest: FIPS 140-2(2001-10-10) Long run: 0
    rngtest: FIPS 140-2(2001-10-10) Continuous run: 0

rng-tools includes a command for testing random number generator output. I tried this with a FreeBSD port from https://github.com/waitman/rngtest

Results aren't great:

    rngtest: bits received from input: 300032
    rngtest: FIPS 140-2 successes: 0
    rngtest: FIPS 140-2 failures: 15
    rngtest: FIPS 140-2(2001-10-10) Monobit: 15
    rngtest: FIPS 140-2(2001-10-10) Poker: 15
    rngtest: FIPS 140-2(2001-10-10) Runs: 15
    rngtest: FIPS 140-2(2001-10-10) Long run: 0
    rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
    rngtest: input channel speed: (min=236.690; avg=245.396; max=251.742)bits/s

"I recovered my original music files only by using a backup I made"

Yep, shouldn't have second-guessed myself. Teach me to comment at 4am.

http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/s...

JRuby uses Java's java.security.SecureRandom, which (by default on OpenJDK 8) uses /dev/random, mixed with its own SHA1PRNG (this so setSeed() can be guaranteed to actually do something).

Rubinius copies MRI circa 2014 via rubysl - https://github.com/rubysl/rubysl-securerandom

The Design and Implementation of the NetBSD rc.d system - http://www.mewburn.net/luke/talks/auug-2003/

Does anyone guarantee anything about any hard disk after 5 years? :)

Yes, it's MTBF, which is what the comment I was responding to asked for.

The warranty is 5 years, and from the datasheet the AFR is rated at 0.35%.

http://www.seagate.com/www-content/product-content/enterpris...

Either it would have negative mass and imaginary energy, or it has negative energy and imaginary mass - http://math.ucr.edu/home/baez/physics/ParticleAndNuclear/tac...

At a flying height of <10nm.

They're rated for 2.5 million hours.

> The real reason is that the space-time curvature does simply not provide a way for the light to go back. Same reason you can't go to the end of the universe if the universe would be a sphere.

Or the same reason you can't travel to yesterday - there are simply no directions in which to point yourself in order to get there.

du -A for the "apparent" size.

The complaint isn't about blocking before you've been seeded, it's blocking afterwards because you've generated some random numbers and feel like you've somehow "used up" your entropy pool in doing so.

At Newzbin we used a simple partial quicksort for returning paginated results from our custom search engine - it worked really well for our needs.

It was implemented as a plain old C macro: https://github.com/Freaky/pqsort

Needs a digital signature to verify that neither the data nor the code to decrypt it has been modified.

.. and that signature can't really be verified by unverified code.

Looks like it's part of the UNCODE theme[1], and can be disabled by dropping smooth-scroller from the body class.

Your personal blog is much more readable, thanks :)

1: http://themeforest.net/item/uncode-creative-multiuse-wordpre...

We got a more readable alternative link to use and the author's now aware that the original was difficult for some people to read. What exactly is the problem?

Not sure what's going on with the weird scroll speeds, but for me the problem is motion sickness from the smooth bouncy scrolling.

Browsers have options to disable smooth scrolling for a reason. Please don't force it back on.

You have your arguments swapped. 30 bits for 8^10, 26.6 for 10^8.

https://www.google.co.uk/search?q=log2(10%5E8)

Nope. I increased the limit from 5000 to 10000 a while back and not seen any noticeable difference in performance.

Arq is like Tarsnap/Attic/Borg in that it uses shift-resistant block deduplication - it can efficiently cope with small modifications to existing files, where rsync would have to clone the entire file for each new version.

https://spideroak.com/features/private-by-design - "SpiderOak uses AES256 in CFB mode and HMAC-SHA256."

mosh only supports reattaching from the originally started client - no attaching from different machines, no resuming sessions after reboots, etc. Also no splits, and no scrollback.

It's also extremely slow. Fullscreen terminals on my 30" display are borderline unusable with mosh.

It's the difference between, say, length(foo) and foo.length() - any difference in cognitive load should be lost in the noise next to "this variable can be null".

And given most languages in use today use = to mean assignment instead of equality, it's hardly "no reason".

> Opening a new shell can take ~5s with oh-my-zsh

Heh. I remember when zsh first got its fancy completion system, compinit would add so long to zsh startup on the dinky little machines of the day that people literally started adding progress bars and the like to their zshrc.

I stuck with the old-style completion for a long time.

> It's not unreasonable to be afraid of what might happen when you throw new chemicals into the mix.

... "new" chemicals are already in the mix. Criminalization is ineffective in reducing usage, it's especially ineffective in reducing harm, and on top of that it creates substantial additional harms.

I'm running a pair of L5639's in my main server. Perfectly usable. Yes, the cores are relatively slow, but you get plenty of them.

> OVH has the Kimsufi outlet which is cheaper and better hardware

I see one dual socket Westmere Xeon that's actually slower than the two you're complaining about (1/3rd as much cache, 5-20% slower clock), and a bunch of similarly ancient consumer-level junk.

I even spy an i7 920 in there. A 2008 first-gen Nehalem. That's a 130W CPU with terrible power management, how on Earth is that economical for them to deploy?!

> If all models are identical and have been purchased at the same time, one would expect that the same firmware will allocate the same writes to the same cells

Not really, you'd expect them to diverge over time as the cells aren't going to be all 100% identical - they'll have different failures, different error rates, and different read patterns will result in different read-disturb errors, all of which will effect even completely deterministic block allocation.

Regardless, as I said, you monitor endurance. Drives are unlikely to just silently wear out out of the blue unless you've been completely ignoring their SMART readings, in which case, more fool you.