HN user

billnapier

26 karma

[ my public key: https://keybase.io/billnapier; my proof: https://keybase.io/billnapier/sigs/18kIVdNjNmmKIBntLXeqSFYfW0pWXfOgBhmwis4yx1I ]

Posts1
Comments10
View on HN

Overcommit was a design decision that seems wrong at first, but when taken with a wide viewpoint makes some sense. The motivating reason for overccomit is to make fork cheap. (the article even briefly touched on this). It's a trade off between the speed of spawning new processes (and threads) and ease of understanding how your system will behave in low memory situations. I think they made the right choice.

Another thing to note. The systems in the article were in trouble regardless of the overcommit, it's just that overcommit hid the problem and made it occur in a non-obvious place.

I don't see any really compelling reason to have all that functionality shoved into one device. I like the idea of separating playback/record from storage.

I like the idea even better when the storage is in the cloud (with a possible local cache, would be nice).

HashMap (unlike treeset) itself doesn't provide an order guarantee. So can't you just grab the first element from the entrySet and use that?

But I think the bigger problem is trying to use a Map in the first place when maybe a different data structure will solve the problem better.