Live data from Hacker News

We are still early with the cloud

erikbern.com

201–202 of 202 posts

Re: We are still early with the cloud

#201
post #195

Earlier quoted context omitted.

> The Linux kernel randomly kills processes when it starts exhausting memory. It's garbage. If you want to disable overallocation and the OOM killer, be my guest. You'll want to install some extra banks of RAM though. Or is there a better way, provided by other OSes?

Sure, you push the failure into the processes, and most OSes I've used do this. Thus (to use unix terminology) sbrk and fork() fail and it's the program's responsibility to handle that, gracefully or not as it wishes. You also degrade more slowly via paging. You shouldn't get to the point where a perfectly innocent process is killed to reclaim memory. A process can die, or even (in some cases) recover cleanly from ru…

Which OSes have you used that do that?

In Linux you can do that -- disable overcommit (although I'm not sure if that's 100% foolproof). But that's often not preferred because that way does lead to "perfectly innocent" processes being killed: whoever allocates the next page when memory has run out loses. And how do they get to decide? What if a failure path requires paging in one more page of code from disk? Or causes a store to a COW page?

Re: We are still early with the cloud

#202

Earlier quoted context omitted.

In the end, almost everything runs on some kind of OS. All those little functions in the void also have to run in an OS, but this is abstracted away from the user.

Congratulations on understanding what an abstraction is. Do I need to worry about the transistors or individual atoms in a computer? Why should UNIX be the right level of abstraction forever?

I didn't write to explain what an abstraction is, and I will assume you honestly meant to congratulate me instead of trying to be sarcastic. Thank you for that.

I have had two types of developers in my teams: one type that understands the underlying technology of the abstractions that they are using, and one type that only understands the layer/abstraction they are interacting with and blissfully clueless about anything underneath.

Neither group worries about transistors or proton decay in their hardware, and both can make 'things'. However, one group is much more capable of effectively building tools and understanding issues when something goes wrong in the chain, whereas the other group is regularly hopelessly lost because they have no clue of what is happening. I'll let you guess which is which.

This is not about worrying or even being bothered with details, but about understanding what you're working with.

Post reply on HN