Slashdot Mirror
Calling Software Reliability Into Question
phillymjs writes "CNN is running a story on software reliability, and how the lack of it may cost more and more lives as technology creeps further into everyday products. It appears a debate is finally starting amongst everyday (read: non-geek) people about vendor liability for buggy software. Some opponents of the liability push are unsurprising: Says the story, 'Microsoft contends that setting [reliability] standards could stifle innovation, and the cost of litigation and damages could mean more expensive software.' The article also says, however, that consumers' favortism of flashy products over reliable ones is partly to blame for the current state of software."
I like what Microsoft has been doing qith security these days, quite frankly. The new security features in Windows Server 2003 look innovative and very modern, and quite easy to use.
Linux may be secure when configured correctly, but Windows Server 2003 looks to be the most secure OS out of the box at the moment.
Abortion is advocated only by persons who have themselves been born.
--Ronald Reagan
Remember, one thing M$ does well is pay lawyers.
Why can't there be a "cutting edge" in reliability?
Because software needs to be thoroughly tested before it can be called reliable. "Cutting edge" software tends to be poorly (relativly speaking) tested, since it hasn't had that much time in the real world.
Therefore, for instance, Debian stable still uses kernel 2.2 by default (alltough there's a 2.4 installation flavour), because it's well tested and reliable. As a result, I've never experienced inconsistency or crashes with a Debian stable release.
(Now, if you want cutting edge Debian, there's always Debian Sid (also known as unstable)).
Because software needs to be thoroughly tested before it can be called reliable.
/. contributors have consistently ignored the role played by trusted components such as VMs and safe compilers. Bottom line is that we all need to get away from the mindset engendered by years of Unix and C hacking and recognise that not all problems are going to be solved by employing programming whizzes or spending a fortune on testing.
This is not strictly true. I know that my Java program will never have a buffer overrun because it is impossible for me to produce JVM instructions that corrupt buffers or alter pointers. Therefore, I can download and run any Java program to my Java smartphone without invalidating the phone's network certification.
Throughout this discussion, I've noticed that