31–40 of 112 posts
Earlier quoted context omitted.
What if your customers want to run on EC2 instances?
It is covered in the blog post. (This is not a critique, just an hint, I understand that reading a very long blog post is time consuming).
Perhaps using safer languages (and languages with better error reporting) would be a solution to these kinds of problems.
Such languages also allow you to write code much faster which can lead to more mistakes. Edit: huh. 2 downvotes. Why not explain why you think I'm wrong, rather than just downvoting because you don't agree?
Earlier quoted context omitted.
It is covered in the blog post. (This is not a critique, just an hint, I understand that reading a very long blog post is time consuming).
I did read the whole post. It was very informative. I wasn't aware that EC2 did not have ECC RAM. My question was directed at shin_lao's policy about not providing a "warranty" for his customers running on non-ECC hardware.
Perhaps using safer languages (and languages with better error reporting) would be a solution to these kinds of problems.
Here are my additional two cents: At least on X86 systems, to check small memory regions without effects on the CPU cache can be implemented using non-temporal writes that will directly force the CPU to write the memory back to memory. The instruction required for this is called movntdq and is generated by the SSE2 intrinsic _mm_stream_si128().
Perhaps using safer languages (and languages with better error reporting) would be a solution to these kinds of problems.
Earlier quoted context omitted.
Rust isn't production ready.
I never claimed it was. I'm just thinking that perhaps the approach it (and Haskell, for that matter) takes is better.
http://en.wikipedia.org/wiki/No_Silver_Bullet
Basically, making reliable software is hard. Changing the language doesn't bring anything. There are a lot of tools to make sure your C/C++ programs doesn't have obvious errors. The problem are non-obvious errors, and these errors exist in all the languages, with different forms.
Another way to put it: "You cannot reduce risk, you can only replace it with another".
Earlier quoted context omitted.
I never claimed it was. I'm just thinking that perhaps the approach it (and Haskell, for that matter) takes is better.
I think you're falling in to the "silver bullet" trap. http://en.wikipedia.org/wiki/No_Silver_Bullet Basically, making reliable software is hard. Changing the language doesn't bring anything. There are a lot of tools to make sure your C/C++ programs doesn't have obvious errors. The problem are non-obvious errors, and these errors exist in all the languages, with different forms. Another way to put it: "You cannot red…
In my experience in more 'agile' firms - startups, web dev shops and so on - it would be very hard to make a scheme like this work well, because of all the grinding bureaucracy, fiddly spec-matching and endless manual testing required, as well as the importance of controlling - and deeply understanding - the whole stack. Nonetheless, for infrastructure projects like Redis, I can see value in having engineering effort put explicitly into making 'prettier crashes'.
His point about logging registers and stack is interesting. Many years ago I worked on some software that ran on Windows NT 4.0 and we had a weird crash from a customer who sent in a screen shot of a GPF like this: http://pisoft.ru/verstak/insider/cwfgpf1.gif From it I was able to figure out what was wrong with the C++ program. Notice that the GPF lists the instructions at CS:EIP (the instruction pointer of the runni…