Live data from Hacker News

Redis crashes - a small rant about software reliability

antirez.com

1–10 of 112 posts

Re: Redis crashes - a small rant about software reliability

#4

Perhaps using safer languages (and languages with better error reporting) would be a solution to these kinds of problems.

Not really. We get all the same sorts of errors in our very high level C#/Asp.Net/VMware deployments and it's a shit load harder to debug with all the extra baggage that a VM and hypervisor throw on top as well...

A better solution to all the reliability problems is better quality hardware i.e. not X86. X86 has very few reliability features built in past ECC. If you look at UltraSparc based machines, they can predict failures and offline chunks of the hardware (CPUs, RAM regions, IO devices) so they can be replaced without disrupting the system.

Prevention is better than debugging :)

Re: Redis crashes - a small rant about software reliability

#5

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?

Re: Redis crashes - a small rant about software reliability

#6
post #2

This is an interesting post, especially the part about memory testing. We have a simple policy: ECC memory is required to run our software in production. Failure to do so voids the warranty.

This.

For desktop computers, Intel charges a premium on any ECC-capable gear (their Xeon line), so it's really only available in workstation class computers. Most AMD gear (AM2/3/3+ sockets, not A-series) can take ECC RAM, if there is BIOS support.

ECC RAM costs about 10-30% more per DIMM, but as memory is so incredibly cheap these days, its probably the cheapest safety net you can buy.

Re: Redis crashes - a small rant about software reliability

#7

Perhaps using safer languages (and languages with better error reporting) would be a solution to these kinds of problems.

Um, no. C is a perfectly valid language and some of the best, most robust systems in the world are written in it (Linux, Git, etc.) Some languages are even built to run atop C (Cython.) Even the JVM deals with pointers, memory allocation issues, and such so you don't have to but it's still there!

So using a higher level or "safer" language isn't going to stop these kinds of problems.

Re: Redis crashes - a small rant about software reliability

#10
post #7

Perhaps using safer languages (and languages with better error reporting) would be a solution to these kinds of problems.

Um, no. C is a perfectly valid language and some of the best, most robust systems in the world are written in it (Linux, Git, etc.) Some languages are even built to run atop C (Cython.) Even the JVM deals with pointers, memory allocation issues, and such so you don't have to but it's still there! So using a higher level or "safer" language isn't going to stop these kinds of problems.

Sorry if I'm breaking your bubble, but Linux and git are not "the best and most robust systems in the world". If they were, the state of the art of safe and reliable software systems would be quite pitiful.

edit: that doesn't detract your point however that C is used nowadays on "robust systems"... in terms of popular robust kernels though you'll want to look at something like L4 or QNX Neutrino. There's a kernel that is actually formally verified (seL4) that was first written in Haskell, then verified, then translated to C (for speed).

Post reply on HN