5 ms·

No. Although your point about the youth of the system involved being a critical determinant to it's reliability is correct, you make an error in naming that sy

No. Although your point about the youth of the system involved being a critical determinant to it's reliability is correct, you make an error in naming that system as "computers". "Computers" are reliable these days. We rarely have design problems with the actual hardware (ok, sometimes we have higher than desired failure rates, but most of the time, computers these days are very reliable). They function pretty much as we expect them to. As proof, they are so reliable that when we have a bug in our programs, we no longer even think to point the finger at the hardware. Instead, we point the finger at the software (though in too many cases devs still tend to point the finger at other people's code, when they should look at their own code first - it is the youngest, and hence least reliable, as a general rule). The problem is software. I seem to recall pg writing an essay about this - we aren't making copies of something that already exists, we're making new things, things that have never even been dreamt of before. Of course we're going to have problems. I've watched in amazement as Rails has gone from a not-particularly-reliable framework to something relatively solid and flexible in a matter of years. MacRuby has gone from a dream to one of the best ruby implementations out there over the same sort of time frame. The list could go on and on. But getting reliability out of a system takes time. As a rough heuristic, I think you could say that you need about a year of catching and fixing bugs in a product from the time that you stop adding features for every year that the product took to develop. If you add features, the new parts won't be right until another year has gone by (although hopefully unit tests should prevent regressions in the existing code). Of course, in a shop with sloppy coding standards, you may never get a stable product out the other end, but I think that most competent engineers these days know the techniques that will give a reliable system - verifying inputs to APIs, Unit Tests, documentation, specs.

RyanMcGreal 16y ago
>We rarely have design problems with the actual hardware Hard drives, still the main data storage hardware in most computers, are utterly unreliable.
- blasdel 16y ago
  But not for the reasons you'd think -- mechanically they're incredibly reliable these days, even when violence is done to them. What sucks now is the software running on the embedded drive controller, especially on the most recent highest-capacity drives available at any one time -- the most common bug is for the whole drive to just stop responding for several seconds. There is still one type of hardware error causing problems -- single-bit corruption errors. They're much less likely than they used to be, and the drive will catch them with a checksum when read back, but capacities are so high that the probability of hitting one when reading back a full drive is nearly %100. This makes RAID-5 and other parity-based striping systems almost completely unviable these days -- you'll never be able to rebuild the array from n-1 drives without hitting a single-bit error. And because of the software bugs in drives, they drop out for no reason all the time forcing you to rebuild the array (which then fails because a cosmic ray caused a single-bit error). SSDs won't save you either, they have even more classes of software bugs present in their embedded controllers.
- demallien 16y ago
  No, you're missing my point. Consumer hard drives are unreliable because consumers would rather save a few dollars rather than pay for a reliable system. That's one end of the spectrum. The other end is, say a bank, where databases are backed up remotely in conjunction with high-reliability RAID drives to achieve a very high level of reliability. It's not that we aren't capable of designing systems that are reliable, but rather that we don't value the reliability as much as it costs. And that's because even a crappy consumer drive is 'good enough' for most people, unreliability and all. If it's not, we put in some sort of a back-up system to mitigate the risk. In the early days of computers, that just wasn't so. If you're old enough, you probably remember having a C64 game on a cassette that you just couldn't get to load. Or a floppy disk that became corrupted because it got heated to over 50°C and some bits got jumbled. Go back even further when only prototypes of these devices existed in labs, and the situation was even worse. Well, most software is more akin to the prototype in the lab than a product on a shelf. It hasn't been thoroughly tested, it is still under development, we don't understand the limitations of the system, etc etc etc.
ori_b 16y ago
> We rarely have design problems with the actual hardware Hah. Spoken as someone that has clearly never written drivers. Take a peek through driver code some day - you'll see workarounds for bugs on different implementations of the same standard. You'll see heuristics to, say, filter out spurious monitors reported as connected by video cards. You'll see poking random values into registers with comments like /* this shouldn't fix things but it does */. More or less, you'll see dozens of workarounds for hardware bugs. Hardware is buggy.
- demallien 16y ago
  Actually, there's nothing 'clearly' about it. I spent three years of my life doing nothing but writing drivers for NT 4.0 and later on linux. I'm not saying that hardware these days doesn't generate errors, I'm saying that the errors they produce are understood, and can be corrected/handled in such a way that the system doesn't fall down. You just don't see incorrect values being read in from memory or from disk, because we have error correction systems in place. You don't see the value in a register in a CPU changing for no reason. You don't see uncorrected cross-talk errors on the CPUs data buses. You don't see dodgy values being read off buses due to reflection off incorrect bus terminations. These are all problems that existed at various stages in the development of computers, but these days, it just doesn't happen any more because designers know the problems exist, and engineers are taught how to avoid them at university.
mechanical_fish 16y ago
I started the clock at the birth of the first computer because, obviously [1], one could not begin to solve the practical problem of developing methods for writing error-free software before one had hardware to test it on. I'll concede that we seem to be better at controlling the error rates in hardware than we do in software. There are lots of reasons for this; the biggest, ironically, is that custom hardware is very expensive. Therefore, there is little market for highly unstable custom hardware built by high school students. The cost/benefit ratio is all out of whack. It pays, if you're going to build hardware, to take your time and do it very carefully. --- [1] On the one hand, at this point I expect mathematicians to jump out of the woodwork and claim that their illustrious predecessors were able to theoretically predict the future existence of buggy software as early as the nineteenth century. On the other hand, I have a gut feeling that very, very few computer programmers realized how hard it was all going to be before they actually tried it. Nobody ever does, even today. Gedanken software never has bugs.

RyanMcGreal 16y ago

>We rarely have design problems with the actual hardware Hard drives, still the main data storage hardware in most computers, are utterly unreliable.

blasdel 16y ago
But not for the reasons you'd think -- mechanically they're incredibly reliable these days, even when violence is done to them. What sucks now is the software running on the embedded drive controller, especially on the most recent highest-capacity drives available at any one time -- the most common bug is for the whole drive to just stop responding for several seconds. There is still one type of hardware error causing problems -- single-bit corruption errors. They're much less likely than they used to be, and the drive will catch them with a checksum when read back, but capacities are so high that the probability of hitting one when reading back a full drive is nearly %100. This makes RAID-5 and other parity-based striping systems almost completely unviable these days -- you'll never be able to rebuild the array from n-1 drives without hitting a single-bit error. And because of the software bugs in drives, they drop out for no reason all the time forcing you to rebuild the array (which then fails because a cosmic ray caused a single-bit error). SSDs won't save you either, they have even more classes of software bugs present in their embedded controllers.
demallien 16y ago
No, you're missing my point. Consumer hard drives are unreliable because consumers would rather save a few dollars rather than pay for a reliable system. That's one end of the spectrum. The other end is, say a bank, where databases are backed up remotely in conjunction with high-reliability RAID drives to achieve a very high level of reliability. It's not that we aren't capable of designing systems that are reliable, but rather that we don't value the reliability as much as it costs. And that's because even a crappy consumer drive is 'good enough' for most people, unreliability and all. If it's not, we put in some sort of a back-up system to mitigate the risk. In the early days of computers, that just wasn't so. If you're old enough, you probably remember having a C64 game on a cassette that you just couldn't get to load. Or a floppy disk that became corrupted because it got heated to over 50°C and some bits got jumbled. Go back even further when only prototypes of these devices existed in labs, and the situation was even worse. Well, most software is more akin to the prototype in the lab than a product on a shelf. It hasn't been thoroughly tested, it is still under development, we don't understand the limitations of the system, etc etc etc.

ori_b 16y ago

> We rarely have design problems with the actual hardware Hah. Spoken as someone that has clearly never written drivers. Take a peek through driver code some day - you'll see workarounds for bugs on different implementations of the same standard. You'll see heuristics to, say, filter out spurious monitors reported as connected by video cards. You'll see poking random values into registers with comments like /* this shouldn't fix things but it does */. More or less, you'll see dozens of workarounds for hardware bugs. Hardware is buggy.

demallien 16y ago
Actually, there's nothing 'clearly' about it. I spent three years of my life doing nothing but writing drivers for NT 4.0 and later on linux. I'm not saying that hardware these days doesn't generate errors, I'm saying that the errors they produce are understood, and can be corrected/handled in such a way that the system doesn't fall down. You just don't see incorrect values being read in from memory or from disk, because we have error correction systems in place. You don't see the value in a register in a CPU changing for no reason. You don't see uncorrected cross-talk errors on the CPUs data buses. You don't see dodgy values being read off buses due to reflection off incorrect bus terminations. These are all problems that existed at various stages in the development of computers, but these days, it just doesn't happen any more because designers know the problems exist, and engineers are taught how to avoid them at university.

mechanical_fish 16y ago

I started the clock at the birth of the first computer because, obviously [1], one could not begin to solve the practical problem of developing methods for writing error-free software before one had hardware to test it on. I'll concede that we seem to be better at controlling the error rates in hardware than we do in software. There are lots of reasons for this; the biggest, ironically, is that custom hardware is very expensive. Therefore, there is little market for highly unstable custom hardware built by high school students. The cost/benefit ratio is all out of whack. It pays, if you're going to build hardware, to take your time and do it very carefully. --- [1] On the one hand, at this point I expect mathematicians to jump out of the woodwork and claim that their illustrious predecessors were able to theoretically predict the future existence of buggy software as early as the nineteenth century. On the other hand, I have a gut feeling that very, very few computer programmers realized how hard it was all going to be before they actually tried it. Nobody ever does, even today. Gedanken software never has bugs.