cmurphycode

I suppose it would be interesting to think of this attack in a scenario.

Say you worked for a company that didn't require 2FA yet. Then there is a hack, and your co-worker's account is stolen. IT investigates, clears it up, and pushes out a policy that enables 2FA. "Ok everyone, all clear! No need to worry anymore."

A while later, your account is hijacked.

The short answer is that zstd is faster and better at compressing than zlib for most input data.

For more details, here's a comment I made a couple years ago:

There's a nice comparison of compression algorithms (including zlib, zstd, brotli, snappy, etc) here: https://quixdb.github.io/squash-benchmark/ It's nice because it uses many datasets and machine platforms. Unfortunately the graphs leave a bit to be desired, especially when you're trying to compare two algorithms. They provide the raw data, but it needs a little munging to make it workable.

For my day job I made the following graph to compare zlib level1 and zstd. This was using the "peltast" platform which is a Xeon based system, because that was most relevant for us.

http://imgur.com/a/0a3kK

(the original comment: https://news.ycombinator.com/item?id=12400503 )

I agree, but I don't have an alternative with the range/quality of guests he interviews. Any suggestions?

I suppose a nice compromise here would be to make an intelligent decision whether to bring up a prompt asking if you want to change the font size. For instance, if the FaceID detects that your face is farther or closer from the screen than normal, or that you're squinting.

One reason for du/df problems with ZFS is ZFS compression.

For the HTTP 100 vs 307 -

You're right, but in my experience, S3 does not send 307 on each request (which it would have to do, if it were load balancing, right?)

Isn't the same true of movies?

(On the other hand, I'm pretty sure more people skip going to the gym than skip going to a movie!)

Well, not a great start - the console is throwing Java exceptions, and when I ask for a code completion, it just spins for a while and eventually fails.

I'll continue to poke at this, I think. For me, the competition is Sublime Text with a bunch of Rust plugins. It took a while to set up and it's not super snappy, but it works decently. I would like to replace this setup with something more "out of the box" and better integrated.

For anyone interested in rust IDE, maybe check out https://areweideyet.com/

This is really interesting to me - I can't seem to reproduce this on a couple different platforms. In the past (and just now) I've definitely seen 100x differences with LC_ALL=C, but you used that on both, I'm sure.

How large was the 10 million line file, and do you know whether sort was paging files to disk?

Bitcoins are mined by a uniformly random process, which means even groups with a small amount of power can mine blocks, and even can occasionally mine more than one in a row. But instead of publishing that mined block immediately, there is a better strategy. Waiting on publishing makes a fork, and the colluders can keep mining on the fork until the strategy defines that they should publish - which is basically when the "honest" branch catches up to the colluding branch. Since the colluders don't have a majority, this will always happen, but that's ok.

Due to the way that the Bitcoin protocol works, honest miners will sometimes "help out" the colluding group by mining on that published fork. This basically amplifies the power of the colluding group, which is the goal. Worse, the paper proposes that the percentage of honest miners switching to the fork can be influenced cheaply, by choosing which blocks to forward along in the p2p network.

For an interesting take on this, read about https://en.wikipedia.org/wiki/Rajneeshpuram and consider watching the documentary "Wild Wild Country" on Netflix. I thought it was fascinating.

Here's a reduced example. I want to ask whether an incoming 16 bit number is in my set. I can make a bitmap that answers that question perfectly in 8KB :)

So I'm assuming what the parent meant by sparse is, things where the universe is much much bigger, and therefore the things in your set are a sparse proportion of the universe. For instance, in deduplication, we use at least 160 bit hash functions...and that bitmap isn't looking good for us!

Yes, you are right - you have to query each filter.

To keep the contract of the bloom filter, a "no" can only come if ALL filters return no. So if one of the filters return 0 and the other returns 1, the answer is maybe (i.e. a yes with some false positive probability). If we instead answered no, it would be a false negative as you stated, so we can't do that. This paper doesn't defeat this property of bloom filters.

The cool insight in this paper is that how you choose the new filter size allows for a relatively nice tradeoff of "wasted" size, and a target for the effective false positive ratio, even in the face of growth. We are increasing the probability for false positives, but depending on how you pick the sizes, you can do better than if you simply allocated another bloom of the same size, forever and ever.

(When I say "wasted" size, I mean the extra bits you need to get a certain false positive ratio, when you compare it to a properly sized filter from the get-go. In essence, you're paying some overhead when you get to a certain size. In exchange, you do not need to have guessed the size correctly / allocated all that memory from the get-go.)

Great idea! I ran a quick hashcat against the range00000 list on my laptop. In 1 minute I cracked 79 of them, and not too many of them look very odd - that is, they look sorta like normal cracked passwords.

I'm asking my friend to run a more thorough crack on his dedicated GPU, especially for hash value 000DD7F2A1C68A35673713783CA390C9E93:630 which does stick out to me!

Great thought, but it doesn't seem to be the case - as the number of unique suffixes is the large number here -- in fact, none of the values in the range are simply all zeroes.

https://api.pwnedpasswords.com/range/00000

I wonder if the hidden variable is something to do with how the passwords are leaked. First, let's suppose that a very commonly used broken password hash is plain SHA-1 (I think that's a valid assumption-- unfortunately!). Then, let's figure that amongst the many data dumps / extracts done by hackers, some of them are only able to extract part of the database, or save part of the database, or whatever....and they are fetched / saved / uploaded in lexical order?

Can't think of anything else.

EDIT: Ooops. The other thing is, that these actually are sha-1 hashes of real plaintext passwords. So it's definitely not a test-row in that sense.

It may be true that music listeners are currently much more annoyed when songs aren't available. However, I think it's wrong to say that TV and movie watchers were any different 5 years ago -- even today, people's number one complaint about Netflix is that famous movie X isn't on there.

Netflix worked hard to change that model by figuring out what people liked to watch and generating high quality content in the patterns they saw. Turns out, now everyone watches whatever show Netflix puts in front of them.

Do you think it's possible a similar phenomenon could happen for music?

I can tell you that since signing up for Spotify Premium, I've certainly been exposed to more new artists that I like, based on their recommendations. Since their library is currently still extensive (like how Netflix had a lot more movies back in the day), I'm very rarely looking for a song they don't have. I can imagine a world where the content holders get more scared (although that would be an impressively delayed reaction) and thus Spotify is pressured out of contracts (just like Netflix was). I'm guessing that Spotify is betting that if that is the case, they can rely on the fact they've been changing their listeners tastes to survive.

Having many filters is worse, but not hugely so. I believe the problem is reducible to the fact that you'll have many smaller filters thus the random distribution hurts you a bit more.

The key word to google is "blocked bloom filter" e.g. as proposed in http://algo2.iti.kit.edu/documents/cacheefficientbloomfilter...

Here's a nice paper with some improvements http://tfk.mit.edu/pdf/bloom.pdf

We use blocked bloom filters for a couple of reasons, but one major benefit is the memory locality (our "bloom filter" is 32GB or larger, so it's handy & fast to be able to address it with separate "pages" which are really just individual bloom filters.)

Yes, the ABV raises or lowers depending on temperature and humidity. The Stagg almost certainly went in at 125 proof (barrel entry proof), so it got a big boost during the considerable aging process.

I've heard descriptions (from the producers) of barrels that gained / lost proof depending on what floor of the warehouse they were stored on. Pretty neat.

Yeah, I think that's definitely part of it.

https://www.heart.org/idc/groups/heart-public/@wcm/@sop/@smd...

http://www.kff.org/other/state-indicator/opioid-overdose-dea...

I know it seems weird to have the "old" data change. But, it's not observed data, it's estimates made at a point in time. The estimate comes from the property itself as well as the algorithm. If they changed the algorithm, do you think it would be better to recalculate the old values, or show a huge swing in your home value, implying some sort of market trend or issue with your house? If I were implementing it, I think I'd have to change the old data. I'd like to think I could sneak in an explanation / comparison, but that might get nuked for usability/UI reasons.

I had the same reaction about Boston, and decided to look a little closer.

I am not sure how the city selection works. Tree House is more than 50 miles from Boston, so it doesn't get included. But if you move the selector to 1+ breweries and 50 miles, then Treehouse shows up, under Chicopee, MA. Which is an interesting choice, because Treehouse is less than 50 miles from Worcester, which is also less than 50 miles from Trillium (although barely), which would certainly show up.

So, maybe there are some details around the "grouping" that aren't clear. Maybe the brewery gets "pinned" to the closest city with more than 40K people?

it's also quite unclear how he used the Ratebeer data. "Data from RateBeer. Only breweries with 3+ beers that were reviewed 10+ times and 50+ total reviews were included. Restricted each brewery to its top 10 beers by review count (which accounted for greater than 90% of all reviews)."

And yet Santa Rosa, his primary example, lists the breweries Bear Republic Cooperage Fogbelt Henhouse Moonlight

...but not Russian River?! It's pretty obvious that Russian River is better rated than Bear Republic, especially by his extended criteria.

So, yeah, I guess I'd like to see his data and code.

I didn't - I just dropped the time factor out (since they both run their workloads for similar lengths of time).

Let's look at it a different way. The MacBook battery is 55 watt-hours, the Tesla battery is 100 thousand watt hours. They both run their respective workloads for a similar amount of time. So, less than a tenth of a percent?

I may not have parsed your question correctly, so I apologize in advance. Assuming you are asking about what happens to the "equal" elements-

Yes, there is a bug in this code. It doesn't handle repeated elements.

If you fix the code by including an equality in one of the two groups, then it works, but it degrades when there are many repeated elements. In the worst case, you can only shrink your groups by one each time, which means the complexity changes to O(n^2) :(

You can fix THIS issue using a 3-way partition. That is the algorithm I've used. With a good pivot choice (random or median of three), this gives you an in-place sort which is guaranteed to be O(nlgn). Nice!

Supreme Commander and Forged Alliance both have flow economies. Supreme Commander 2 works as you described, and indeed, is not worthy :)

Forged Alliance is great if you like TA!

Interesting - seems like I'm the only one without this issue so far, so I thought I'd comment.

Spotify launched 10 days ago, 127MB written, 1.29GB read.

maybe relevant, I'm running Mavericks.

You are correct that most compression algorithms are slower than their corresponding decompression, which means the writes tend to be a different tradeoff than the reads.

I do not agree with your statement that compress + write is always slower, though. The analysis for cost/benefit of compression is the exact same logic for both reads and writes, but with different formulas based on how fast you can compress/decompress and read/write blocks. Let's imagine that your disk takes 10ms to write 64KB and 20ms to write 256KB. Then if compression of a 256KB block down to 64KB takes 5ms, writing is faster with compression done first. On the other hand, if compressing it takes 50ms, then writing it raw is quicker.

I can confirm that that's what happens to your account when you dont have 2FA enabled. Can you double check your settings?

That's probably true for a lot of studies, but companies with legitimately useful products would still be interested in getting independent validation so they can advertise said study, right? We are jaded by Coca-Cola, but there are actually healthy things and useful medications in the world!

Of course, in reality, the escrow may not be enough to remove the bias, but it's an interesting thought.