well, matter for what? For building software that seems to work, sure, no. But for being able to speak to its capabilities -- or even know what they are, especially in the case of distributed systems it's definitely important.
this is why so many of the new DB offerings have docs that are either misleading or wrong -- often the doc writers or even the devs themselves don't know what invariants their system can guarantee and assume several that it can't.
map takes a function and returns a function that takes a list and returns a list. It has a type like: (a->b) -> [a] -> [b] (I take a function from type a to type b and return a function from list of a to list of b)
> Or is it more like you pass the multiply function the first operand (2 in this case) and it returns a function multiply-by-2 which you pass the second operand
The responses that amounted to "You did nothing wrong!" "We don't need to talk about this!" were what made the thread heated -- outside of that it was just a couple of posters realizing they made an incorrect assumption, what need was there to _debate_ that?
First of all he called himself an asshole for making that assumption. What about others that made the same assumption but didn't feel the need to derail the thread? Are they assholes too? Maybe people felt the need to chime in since there was an insult implied and they wanted to make it clear that by having the same assumptions about the author, they did nothing wrong.
Second, his post has NOTHING to do with the original article, it's just off topic noise.
I agree that too much has already been said about it, but I'd say too much was said about it when it was simply posters calling themselves assholes and sexist for making a simple mistake. On that note, I'll step away from this topic :) It would be nice if this entire comment tree was removed from the thread, it detracts from the actual subject at hand.
You're here fighting against the _grave injustice_ that someone ... felt a little bad about an assumption they made?
Having that "oh shit" moment isn't a bad thing. Realizing that these assumptions aren't necessarily true is important -- If you just subconsciously know computer people are dudes exclusionary behavior is really hard to notice.
> You're here fighting against the _grave injustice_ that someone ... felt a little bad about an assumption they made?
The problem is that they insulted everyone who made that assumption.
Edit: Downvote? Look at the wording. It wasn't swearing from making a mistake, it was saying that the mistake was shameful to make, as a general statement.
It's snake oil -- entropy isn't "depleted" in any meaningful way; once your kernel PRNG has accumulated enough entropy that you'd be comfortable using it to generate a crypto key it is not going to cease being suitable for that just because you continue asking it for random numbers.
that means it will block when it estimates that you have "used up" all of the available entropy
you can check how many bits of entropy your kernel thinks are available easily
cat /proc/sys/kernel/random/entropy_avail
edit: i should have mentioned that there is some reason to argue against this behaviour but that doesn't change the usefulness of haveged for existing systems
Yes, but that's a reason not to use /dev/random, not a reason to install snake-oil products.
The random(4) manpage is unfortunately exceptionally misleading, and has sadly led to a small but non-zero numbers of products that try to use /dev/random rather than /dev/urandom.
Sadly, gpg --gen-key doesn't even give you this option - but that's (as noted above) another flaw in GPG.
It's not possible for the pool to hide what chain it is working on from its miners. If you're connected to the ES-pool when it is working on the mainline chain and you see it start working on top of a block that is not on the main chain, that's a good indicator that it is a block ahead of the main chain.
If you see it work on top of yet another block that is not published, it's probably two ahead, and so on.
You of course, can't just connect and immediately know, but if you watch the pool (as a miner) you can figure it out.
> The receiver device runs a scaled-down Chrome browser with a receiver application that receives data over Internet Protocol and transmits it to the television via HDMI.
Very cool, though incredibly surprising (a browser is an intensive, complex thing, so will people have to constantly be patching their Chromestick?), especially given that once you add the cost of synchronizing all interactions, it seems so much easier to simply video grab the tab.
If anyone has this device, what is CPU usage on the source like when tab-casting?
A while back I put together a doodad to collect and plot this sort of data over reddit (both as a whole and at a subreddit level), see http://reddalyzr.com/#/all The banner is there as I built it as a demo/dogfooding app.
Right now it only has a few days worth of data in it as the database backing it got blown up earlier this week.
this is why so many of the new DB offerings have docs that are either misleading or wrong -- often the doc writers or even the devs themselves don't know what invariants their system can guarantee and assume several that it can't.