mmalone

46 ms·

181.
by mmalone 10y ago
You have to be able to filter for credibility. Right now Facebook makes that hard. They could build tools and adjust their UI to make it much easier.
182.
by mmalone 10y ago
And Facebook emphasizes the headline keeping the person who shared it and the actual source relatively obscured. 99% of people only see the picture and the headline.
183.
by mmalone 10y ago
Yes. This is what I came to say. Big-O assumes a model of computation. Typically people assume a random access machine with certain constant time operations like arithmetic. In some models arithmetic might not be O(1) (e.g., in a pure lambd
184.
by mmalone 10y ago
Interesting that you mentioned pattern language. My brother is an architecht, I'm into tech. I remember asking him about Alexander / pattern language after reading GoF, et. al. and he hadn't heard of him. He looked into it an
185.
by mmalone 10y ago
The linked TOC is long and I've only skimmed it, but I wouldn't call Erlang a data parallel language per se. When I hear "data parallel" I'm thinking of a language with abstract data types (ADTs) for lists, and mayb
186.
by mmalone 10y ago
The short answer is that there is really no good general purpose way to deal with asynchronous communication in a "restful" HTTP API. All solutions have major drawbacks. This is one of the biggest shortfalls of rest/http in m
187.
by mmalone 10y ago
Personally, I consider it metaphysical because it says something about provability (since, deep down, proofs and programs are the same thing). Truth beyond proof (or at least beyond what's feasible to prove) is bizarre and mysterious.
188.
by mmalone 10y ago
Interesting that he was a systems theory guy. My dad was a civil/mechanical engineer and was way into systems theory in the 60s and 70s. The idea, from what I've gathered, is to apply an engineer's toolkit to natural / s
189.
by mmalone 10y ago
This is a topic I researched a long time ago. I don't trust my memory enough to summarize any findings or recommend specific papers, but here are a couple of bookmarks I've kept around: - http://www.cl.cam.ac.uk/te
190.
by mmalone 11y ago
Oh, one more thought since I didn't really address state leak. Let's pretend we're in a C-like language that is not memory safe. You're not reseeding and you don't have forward secrecy. Someone finds a buffer overfl
191.
by mmalone 11y ago
The simpler design is probably to just fill a pool of entropy from urandom in user-space and give out numbers from that pool, thus amortizing the syscall overhead. Even that would be not-quite-as-good-as-urandom (still more that could go wr
192.
by mmalone 11y ago
Incorrect. You may be thinking of the "/dev/random vs. /dev/urandom" argument, which says it's stupid to _block_ on reseeding based on some arbitrary heuristic (and which I agree with). However, that doesn
193.
by mmalone 11y ago
Yep and with the new SplittableRandom they seem to have opted for a more subjective definition with a guaranteed minimum cycle length and passing marks on Diehard. Seems like a happy middle ground.
194.
by mmalone 11y ago
It's not just the initial seeding, you also need correct reseeding, you need to make sure the state doesn't leak somehow, and you need to make sure you're actually getting the seed data securely. If you're doing somethin
195.
by mmalone 11y ago
Eh, I'm not sure where you're getting your numbers. Here's a quick test using node 0.10.40 on my machine: mmalone$ node > var f = function() { ... s = Date.now() ... for (var i = 0; i < 1000000; i++) {Math.ran
196.
by mmalone 11y ago
It's complicated. For starters, if you're looking for a _secure_ PRNG most practitioners would strongly advise _against_ the system you described[1]. There's a difference between a cryptographically secure algorithm and a sec
197.
by mmalone 11y ago
The algorithm that V8 chose to replace the current generator, xorshift128+, passes BigCrush and can produce a random uint64 in just over 1 nanosecond on a modern processor (that's ~7GB/s). Seems like a good choice. Not sure how it
198.
by mmalone 11y ago
You don't need to check for duplicates with UUI4s if you have a good source of entropy. I'm not sure where you're getting your information, but here's what Wikipedia has to say, for instance[1]: "To put these number
199.
by mmalone 11y ago
There are legitimate reasons to have / not have some form of node id, and/or a timestamp, in an identifier. One reason to have them is that you don't need as good a PRNG. However, with a good PRNG the collision probabilities
200.
by mmalone 11y ago
Applied Cryptography is a good book. I first read it more than 15 years ago :). Schneier actually designed the CSPRNG that is used by OS X. It's called Yarrow and is SHA based. It does more or less what you suggest, but with many subtl
201.
by mmalone 11y ago
Meh. You should just use all of that random unique-ish stuff to properly seed your PRNG. You're trying to improve the generator "randomly," which is generally dangerous and can be counterproductive. Better to rely on sound th
202.
by mmalone 11y ago
Just familiarity. Mostly I just can't recommend something I don't know much about. The SIMD variant of MT is architecture specific, I thought? Other newer variants of MT/WELL generators and PCG are probably all good options.
203.
by mmalone 11y ago
In other words the code itself is, in principal, fine. The PRNG it used was not fine. Had it used a CSPRNG there would not be a problem, and generating identifiers in this manner is perfectly safe and not an anti-pattern. Hashing the output
204.
by mmalone 11y ago
Sure but I don't immediately see how that equates to a proof of its ability to produce every combination of, say, 52 consecutive numbers... Just that it will produce every possible individual number. In PRNG-parlance it shows 1-dimensi
205.
by mmalone 11y ago
Ok, I get the seed/state space vs. cycle length bit. So it can theoretically generate all of the permutations of a shuffle if you re-key/re-seed periodically. But you can't guarantee that it actually will, right? It is po
206.
by mmalone 11y ago
Good idea! But it looks like you re-invented a SHA/counter based CSPRNG :). That's not necessarily a bad thing, but there are probably library CSPRNGs that work as well and hide some details. Also, it's not generally any more
207.
by mmalone 11y ago
1. In this case we're arguing semantics. Fine, it's not broken, but it's still bad and there are better alternatives with no drawbacks. Arguing to keep it is sort of like arguing to keep an O(n) algorithm that has an O(log n)
208.
by mmalone 11y ago
I generally trust peer reviewed formal mathematical proofs that show something won't "fail" in a particular, relevant, way. If you don't then you probably shouldn't be on a computer. The code I'm relying on mak
209.
by mmalone 11y ago
MT only fails LinearComp systematically. It is not a bad generator, it is a very good generator. The biggest problem is the "escape from zero-land" stuff where it's biased towards zero for a while if its seed is mostly zero
210.
by mmalone 11y ago
You're generating a random number (the UUID) then you're hashing it. It can't possibly have more entropy, and there's a chance two inputs to the hash will collide thus reducing entropy. Hashing a counter is actually a va

More ›