×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Why Do Computers Still Crash?

Cliff posted more than 10 years ago | from the shouldn't-this-have-been-fixed-by-now dept.

Software 1533

geoff lane asks: "I've used computers for about 30 years and over that time their hardware reliability has improved (but not that much), but their software reliability has remained largely unchanged. Sometimes a company gets it right -- my Psion 3a has never crashed despite being switched on and in use for over five years, but my shiny new Zaurus crashed within a month of purchase (a hard reset losing all data was required to get it running again). Of course, there's no need to mention Microsoft's inability to create a stable system. So, why are modern operating systems still unable to deal with and recover from problems? Is the need for speed preventing the use of reliable software design techniques? Or is modern software just so complex that there is always another unexpected interaction that's not understood and not planned for? Are we using the wrong tools (such as C) which do not provide the facilities necessary to write safe software?" If we were to make computer crashes a thing of the past, what would we have to do, both in our software and in our operating systems, to make this come to pass?

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

1533 comments

Computers don't crash (1, Informative)

UndercoverBrotha (623615) | more than 10 years ago | (#6003275)

People write sloppy code that makes them...

Re:Computers don't crash (3, Funny)

BoomerSooner (308737) | more than 10 years ago | (#6003303)

That's called job security man!

Re:Computers don't crash (3, Funny)

UndercoverBrotha (623615) | more than 10 years ago | (#6003330)

That sir, is a TRUE statement.

Everyone leaves some code that only they can fix...

My Standards for variables:

_needthis
_needthis1
_x
_uz

etc

And (1)

cscx (541332) | more than 10 years ago | (#6003349)

What happens when you get hit by a bus?

Re:And (2, Funny)

UndercoverBrotha (623615) | more than 10 years ago | (#6003381)

I never thought of that...although I do confide in my DBA who does the same thing with his procs, derived tables and jobs...he would handle it, I would come back like Swayze and help him out...

Re:And (0)

Anonymous Coward | more than 10 years ago | (#6003382)

His unmaintainable code get replaced by a better implementation. Good riddance.

umm... (-1, Flamebait)

craenor (623901) | more than 10 years ago | (#6003277)

blah, blah, blah...Bill Gates!!!..blah, blah, blah.

That's why!!

W2000 sp2, no crash here (0)

Anonymous Coward | more than 10 years ago | (#6003410)

W2000 sp2, no crashes here. 18 hour days. 7 days a week. 400 days a year.

linux (-1, Troll)

Anonymous Coward | more than 10 years ago | (#6003280)

Doesn't crash. hundreds or thousands of days in uptime. Same thing with FreeBSD. (probably others as well - but these are the two I work most closely with)

Simple ... (4, Insightful)

Vilim (615798) | more than 10 years ago | (#6003281)

Well, basically as software systems get more complex there is more things to go wrong. That is why I like the roll-your-own-kernel of linux. Don't compile the stuff you don't need and fewer things can break.

Re:Simple ... (4, Insightful)

Transient0 (175617) | more than 10 years ago | (#6003316)

More specifically... As hardware gets more complex, software gets more complex to fill the available space. More complex software not only means more things to go wrong but also means that the hardware never really gets a chance to outpace the needs of the software.

Also, as I'm sure someone else will point out, it is very hard to right code that will not crash under any circumstances. Even if you are running a super-stripped down linux kernel in console mode on an Itanium, you can still get out of memory errors if someone behaves rudely with malloc().

Re:Simple ... (1)

seinman (463076) | more than 10 years ago | (#6003352)

it is very hard to right code that will not crash under any circumstances.
And I bet it's even harder to write the same code.

Re:Simple ... (5, Interesting)

The Analog Kid (565327) | more than 10 years ago | (#6003377)

Yes, on my parents computer, which has 2000 on it(tried Linux it didn't work for them). I set most of the services to manual that aren't needed. Disabled Auto-update. Put it behind a router ofcourse. The only problem remained was Internet Exploder, well I just installed Mozilla with an IE theme, haven't noticed a difference). I think killing most of the services keeps it up. Haven't had a problem with it. This was done before KDE 3.1.x so who knows Linux might work after all.

Re:Simple ... (0)

Anonymous Coward | more than 10 years ago | (#6003403)

Pullin' a fast one on the parental units, huh kid? The old switch-em-out Windows with Linux trick, huh? You saw what happened when they replaced Taster's Choice with that other shit coffee, didn't you? Ahh, too young I bet.

Re:Simple ... (1)

stefanlasiewski (63134) | more than 10 years ago | (#6003432)

This time, he switched Win2k with Linux and it didn't work out so well.

In a few years, he'll switch his parent's vodka with water. Hope that deal goes over better.

Re:Simple ... (2, Insightful)

MikeXpop (614167) | more than 10 years ago | (#6003384)

Exactly. I expect that when I enter in [9], [+], [3], [=] on my calculator it will respond with "12", not "ERROR". I expect if I do the same thing on the calculator.app it will do the same thing, agains sans-crash. However, if I'm trying to download a huge file while opening and closing lots of windows, programming some web pages, uploading them to the web, listening to some tunes, talk to 80 different people on AIM, and enjoying a flash animation at the same time, the computer might crash. After all, those are two very different things.

Re:Simple ... (5, Funny)

orbbro (467373) | more than 10 years ago | (#6003434)


And, when the cocaine that let's YOU do all these things wears off, you'll crash!

Re:Simple ... (5, Insightful)

fishbowl (7759) | more than 10 years ago | (#6003436)


"However, if I'm trying to download a huge file while opening and closing lots of windows, programming some web pages, uploading them to the web, listening to some tunes, talk to 80 different people on AIM, and enjoying a flash animation at the same time, the computer might crash."

Was it, or was it not, designed to be used in this way? If it was not, why does the system let you try it?

Obvious Slashdot Answer #1 (-1, Flamebait)

Anonymous Coward | more than 10 years ago | (#6003286)

Computers don't crash, just Microsoft operating systems!

fp (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#6003289)

?fp!

Not to point out the obvious, but (0, Troll)

Anonymous Coward | more than 10 years ago | (#6003291)

but my shiny new Zaurus crashed within a month of purchase (a hard reset losing all data was required to get it running again). Of course, there's no need to mention Microsoft's inability to create a stable system.

Let's point out two facts that this jerk-off missed:

1. Zaurus runs Linux.
2. You've obviously never seen Windows 2000.

Re:Not to point out the obvious, but (1)

pixelite (20946) | more than 10 years ago | (#6003392)

I use windows 2000, and i have to say that it is pretty stable. I have not seen one BSOD. IE on the other hand crashes all the time, and if I have an explorer window open as well a browser window, the death of one kills the other. Besides that windows 2000 is very stable, except for the few times my system was rendered useless to the point of requiring a fresh install. Although I think one of those instances was caused by AOL and IE 6

Re:Not to point out the obvious, but (0)

Anonymous Coward | more than 10 years ago | (#6003422)

and if I have an explorer window open as well a browser window, the death of one kills the other.

Cilck Tools->Folder Options->View tab and check the box "Browse in a new process"

Re:Not to point out the obvious, but (2, Interesting)

KentoNET (465732) | more than 10 years ago | (#6003427)

Windows 2000 crashed just as much as most modern Linux distributions. Zaurus's problem is more likely due to the crappy GUI they decided to use (Qtopia). I'd be willing to bet that the jerk-off never attempted pinging the Zaurus to see if it actually crashed. Mine has had no crashes yet, after 11 months of use. It's WLAN capabilities are quite nice, too.

C and C++ are the problem (3, Insightful)

zedge (133214) | more than 10 years ago | (#6003295)

Don't allow people to use languages that allow you to access memory not assigned to you or to access array positions that don't exist. This would fix 95% of software problems.

Re:C and C++ are the problem (0)

Anonymous Coward | more than 10 years ago | (#6003328)

This would fix 95% of software problems.

Any hard evidence to back that up, or are you just pulling "statistics" out of your ass?

Re:C and C++ are the problem (0)

Anonymous Coward | more than 10 years ago | (#6003351)

Also. that lack of strong pre/post condition built into the language and input validation.

If only people used Eiffel....

Re:C and C++ are the problem (3, Insightful)

Anonymous Coward | more than 10 years ago | (#6003360)

I'm writing thas as anon because I refuse to enter passwords on a computer I don't trust (internet cafe). But if you must know, my nick is TheMMaster.

I think you misunderstand the problem, using pointers in C/C++ to unallocated memory only occurs with sloppy programing. It is not a "feature" of the language itself. You could easily do the same with visual basic even, if you wanted to. I DO admit that doing stuff wrong is easier with C/C++ (think of a copier in the wrong place).

People that write bad code will always write bad code, the point is that C/C++ gives you more power to create better code than other programming languages do, because they are much more flexible.

thanks for your time

Re:C and C++ are the problem (0)

Anonymous Coward | more than 10 years ago | (#6003367)

So you are stating we should use Java or PHP as the programs on a Operating System?

Hmm let me know how that works for you in the productivity department.

QBasic is the future (0)

Anonymous Coward | more than 10 years ago | (#6003417)

You can't access memory directly when in the QBasic environment. That explains why QBasic never crashed. Hell, I say Linux should be rewritten in QBasic, scrap all that crusty ANSI compliant high-performance 32bit code and cross-platform scalable capability.

Shit doesn't happen in QBasic, that's why it's stable. Ignore that QBasic is written in C, use QBasic. And ignore Perl, it's a verry laughable impersonation of QBasic except with more scalability.

Re:C and C++ are the problem (1)

VTS (673706) | more than 10 years ago | (#6003441)

But all that is up to the programmer, and are there languages where you can't try accessing an array at runtime with a subscript greater than the size of the array ?

Whose computers still crash? (4, Funny)

fishbowl (7759) | more than 10 years ago | (#6003296)

Crash? What crash?

radagast% uptime
8:56pm up 582 day(s), 12:45, 22 users, load average: 0.00, 0.00, 0.01

Re:Whose computers still crash? (5, Funny)

Anonymous Coward | more than 10 years ago | (#6003358)

load average: 0.00, 0.00, 0.01

easy to keep a computer up if you never use it ;)

Re:Whose computers still crash? (0)

Anonymous Coward | more than 10 years ago | (#6003383)

Fuck you slashbot.

Re:Whose computers still crash? (0)

Anonymous Coward | more than 10 years ago | (#6003385)

Must be a SCO machine. Afterall... they are UNIX and can sue the world to prove it.

Re:Whose computers still crash? (0)

Anonymous Coward | more than 10 years ago | (#6003421)

Check out the load average, an idle computer is far less likely to crash than one that's in use... maybe that's the reason.

AS LONG AS YOU CAN TEST EVERY STATE... (5, Insightful)

drink85cent (558029) | more than 10 years ago | (#6003301)

As I've always have heard with computers you can't prove something works, you can only prove it doesn't work. As long as there are an almost astronomical number of states a computer can be in, you can never test for every possible case.

Human Error (5, Insightful)

Obscenity (661594) | more than 10 years ago | (#6003302)

All programs (for the most part) must be written by people. People crash, they're buggy and they dont have a development team working on them. Computers crash because people cant catch that one little fatal error in 10,000 lines of code. Smaller programs are less succeptable to errors and big scary warning messages that make even the most world-hardend geek worried about his files. Yes, it's getting better with more and more people working on something at once. Mozilla (www.mozilla.org) has a feedback option to help them debug, many software companies are including this. But even with that in place, there is always that small human error, that will screw something up.

Where is "Billy Gates" to answer this? (0)

Anonymous Coward | more than 10 years ago | (#6003306)

Billy, is it because computers are using too much memmory?

-Bobby, in his parents' basement

It's bugs! (4, Insightful)

madprof (4723) | more than 10 years ago | (#6003317)

Applications are getting bigger. Code is growing in size. As computing power grows so does the complexity of the code that is written. This means there is a greater chance of bugs.
You can write in any language you like, but bugs will still get through. Lack of proper planning, non-anticipation of working conditions etc. all combine.
If you can make all programmers perfect then you may eliminate this problem. Otherwise I'm afraid we're going to be stuck with bugs.

Speed (5, Insightful)

holophrastic (221104) | more than 10 years ago | (#6003318)

Why spend time testing and debugging and designing for situations which are too rare to be profitable?

I program my applications as properly as I can. But when the client wants to save money by testing it themselves and ignoring non-fatal bugs, they save money and are happy doing it.

So in other words, economy.

Re:Speed (-1, Flamebait)

Anonymous Coward | more than 10 years ago | (#6003412)

Fuck you, homosexual slashbot.

In my CompSci class.. (4, Insightful)

ziggy_zero (462010) | more than 10 years ago | (#6003320)

...I remember my teacher saying "Computers do exactly what they're told, not necessarily what you want them to do."

I think the root of the problem is time. Microsoft doesn't have the time to spend going through every possible software scenario and interaction, or every possible hardware configuration. If they did do that, it would probably take a decade to pump out an operating system, and by that time hardware's changed, and it's a neverending cycle.....

We just have to accept the fact that the freedom of using the hardware components we want and the software we want, all made by different people, will result in unexpected errors. I, for one, have come to grips with it.

Re:In my CompSci class.. (1)

c0dedude (587568) | more than 10 years ago | (#6003373)

But Linux, by its nature and the lack of a need to pay programmers/testers, allows more time to test it, and thus Linux crashes less than windows. A decade doesn't matter, a decade of man-hours do.

Re:In my CompSci class.. (1)

gregmac (629064) | more than 10 years ago | (#6003430)

Microsoft doesn't have the time to spend going through every possible software scenario and interaction, or every possible hardware configuration.

But this shouldn't be an issue. If your HAL is done properly, there is no possibility of crashes with different software/hardware combinations, because the hardware doesn't matter. If libraries etc are managed properly, and memory space is isolated properly, then there should be no software-software issues.

Hardware is a harder one to control, although with modern PCI and USB components, conflicts are becoming very rare. I don't remember the last time I had to deal with IRQ conflicts. (Although I do have an MSI motherboard that can't get past the memory test if a USB smartcard reader is plugged in...)

Yet another... (0, Offtopic)

apophenia (653913) | more than 10 years ago | (#6003321)

"oh no! i just lost my data! what can i do to avoid that in the future" ask slashdot post.

How about backing up your information?

Re:Yet another... (0)

Anonymous Coward | more than 10 years ago | (#6003365)

Fuck you, slashbot.

because someone was very curious and decided to... (4, Funny)

null-sRc (593143) | more than 10 years ago | (#6003324)

*0;

never follow the null pointer they said... what are they hiding there????

Re:because someone was very curious and decided to (0)

Anonymous Coward | more than 10 years ago | (#6003433)

Shut the fuck up, slashbot.

OS X (0, Redundant)

mysterious_mark (577643) | more than 10 years ago | (#6003325)

Rarely crashes, have yet to see ir crash, a stbale OS is possible just not by M$. MM

Re:OS X (1, Interesting)

aarondyck (415387) | more than 10 years ago | (#6003389)

I've crashed OS X. It wasn't even that hard, really. I just did a bit of extremely intensive stuff with Adobe InDesign and it died. I found that it was also far more resource-intensive than most other Operating Systems I use. Perhaps it's just the way I use it, but I think that the only OS I haven't been able to crash is DOS.

Dur, i r retard (0)

Anonymous Coward | more than 10 years ago | (#6003402)

nt, dur

The Reason (-1, Troll)

Anonymous Coward | more than 10 years ago | (#6003326)

is a total lack of quality control. Well, except for OpenBSD...

Reliability and complexity (4, Insightful)

woodhouse (625329) | more than 10 years ago | (#6003327)

Because reliability is inversely proportional to complexity. Systems these days are generally a lot more complex than those of 10 years ago, and in complex systems, bugs are much harder to find. The fact that you say stability hasn't changed is in fact a pretty impressive achievement if you consider how much more complex hardware and software is nowadays.

It's not the need for speed (5, Insightful)

Jeremi (14640) | more than 10 years ago | (#6003331)

It's the need for new features. Every feature that gets added to a piece of software is a chance for a bug to creep in.


Worse, as the number of features (and hence the amount of code and number of possible execution paths) increases, the ability of the programmer(s) to completely understand how the code works decreases -- so the chances of bugs being introduced doesn't just rise with each feature, it accelerates.


The moral is: You can have a powerful system, a bug-free system, or an on-time system -- pick any two (at best).

Computers don't crash because of bad ethics (0, Funny)

Anonymous Coward | more than 10 years ago | (#6003333)

Atoms! Look! Atoms are everywhere! They're causing the struction of all we hold dear to us! Atoms are to blame!

-Montgomery Burns

Don't forget the hardware... (5, Insightful)

MightyTribble (126109) | more than 10 years ago | (#6003335)

Some crashes aren't the fault of the OS. Bad RAM, flaky disk controllers, CPU with floating-point errors (Intel, I'm looking at *you*. Again. *cough* Itanium *cough*)... all can take down an OS desite flawless code.

That said, some Enterprise-class *NIX (I'm specifically thinking of Solaris, but maybe AIX does this, too) can work around pretty much any hardware failure, given enough hardware to work with and attentive maintainence.

crashes? (3, Interesting)

Moridineas (213502) | more than 10 years ago | (#6003338)

Well the computers that I manage we've got an OpenBSD server hat never crashes (uptime max is around 6months--when a new release comes out) and a FreeBSD server that has never crashed--max up time has been around 140-150 days, and that was for system upgrades/hardware additions.

On the workstation side they are definitely not THAT stable, but since we've switched to XP/2K on the PC side, those pc's regularly get 60+ days of uptime. Just as a note--I had a XP computer the other day that would crash about two or three times a day. The guy that was using it kept yelling about microsoft, etc etc etc. Turned out to be bad ram. After switching in new ram it's currently at 40 days uptime (not a single crash).

For some reason the macs we have get turned off every night so their uptime isn't an issue, but from what I hear OSX is quite stable.

My experience with crashing servers (-1, Troll)

Anonymous Coward | more than 10 years ago | (#6003342)

I used to work as a consultant for a Fortune 500 company (more than 10,000 employees). As an expert in the field of IT consulting, I think I can shed a little light on the current climate of the open source community, and Linux in particular. The main reason that open source software, and Linux in particular, is failing is due to the underlying immaturity of the technology and the perception of the viral GNU license.

I know that the above statements are strong, but I have hard facts to back it up with. At the Fortune 500 company that I worked for, we wanted to leverage the power of Linux and associated open source technologies to benefit our server pool. The perception that Linux is "free" was too much to ignore. I recommended to the company that we use the newest version of Linux, version 9.0. My expectations were high that it would outperform our current solution at the time, Windows2000, which was doing an absolutely superb job (and still is!) serving as web, DNS, and FTP servers.

I felt that I was up to the job to convert the entire server pool to the Linux technology. I had several years experience programming VB, C#, ASP, and .NET Framework at the kernel level. I didn't use C, because contrary to popular belief, ASP and VB can go just as low level as C can, and the latest .NET VB compiler produces code that is more portable and faster than C. I took it upon myself to configure and compile all of the necessary shareware versions of software that we needed, including sendmail, apache, and BIND. I even used the latest version of gcc (3.1) to increase the execution time of the binaries. After a long chain of events, the results of the system were less than impressive..

The first bombshell to hit my project was that my client found out from another consultant that the GNU community has close ties to former communist leaders. Furthermore, he found out that the 'x' in Linux was a tribute to the former Communist philosopher, Karl Marx, whose name also ends in 'x'. The next bombshell to hit my project was the absolutely horrible performance. I knew from the beginning that Linux wasn't ready for the desktop, but I had always been told by my colleagues that it was better suited for a "server". As soon as I replaced all of the Windows2000 servers with Linux servers, the Linux servers immediately went into swap. Furthermore, almost all of the machines were quad-processor x86 servers. We had no idea that Linux had such awful SMP support. After less than 1 day in service, I was constantly having to restart servers, because for some reason, many of the servers were experiencing kernel panics caused by mod_perl crashing apache! The hardship did not end there! Apparently, the version of BIND installed on the server pool was remotely exploitable. Soon after we found that out, a new worm was remotely infecting all of our servers! We were not expecting this, because our IIS servers running on Windows2000 had never experienced a worm attack. Microsoft has always provided us with patches in the unlikely event that an exploit was found. It took us hundreds of man-hours just to disinfect our Linux servers! After just 48 hours of operating Linux servers in our server pool, we had exhausted our budget for the entire year! It was costing us approximately 75% more to run Linux than Windows2000.

Needless to say, I will not be recommending Linux to any of my Fortune 500 clients. In the beginning, we thought that since Linux was such "old" technology, it would be more mature than anything on the market. We also found out the hard way that rag-tag volunteer efforts responsible for Apache and BIND simply are not able to compete with the professional operations of Microsoft. I guess the old saying is true; "You get what you pay for!" Needless to say, I will be using Microsoft's "shared license" solution for my enterprise clients, rather than the communist GNU license.

As it stands now, I do believe Linux has some practical uses. I think it will be useful in a University setting for first year computer science students to compile their "Hello World!" programs on (provided that gcc won't kernel panic the machine). Simply put, Linux just doesn't handle the rigors of a real-world work environment.

Touchy subject (5, Interesting)

aarondyck (415387) | more than 10 years ago | (#6003346)

I remmeber years ago having a conversation with an IT manager at IBM. We were talking about the inability of computer programmers to make their code foolproof. His point was that we don't see problems like this with proprietary hardware. When was the last time someone crashed their Super Nintendo? Of course, with a PC platform (or even Mac, or whatever else) there are problems of unreliability. His idea is that this is because of sloppy programming. The reason we were having this conversation is that I had a piece of software (brand new, I might add) that would not install on my computer. You would think that a reputable software company (and this [sierra.com] was a reputable company) would test their product on at least a few systems to make sure that it would at least install! The end result was that I ended up never playing the game (not even to this day), nor have I purchased another title from that company since that time. Perhaps that is the solution to the root problem?

Re:Touchy subject (1)

JJahn (657100) | more than 10 years ago | (#6003418)

Hmm last time I crashed my Super Nintendo was when my dog stepped on it and made it completely freeze up. (But that was quite a while ago, I have since upgraded a few times)

Scientific American... (4, Interesting)

Hanji (626246) | more than 10 years ago | (#6003347)

Scientific American actually had an article [sciam.com] on a similar topic. Basically, they seem to be accepting crashes as ineveitable, and were focusing on systems to help computers recover from crashes faster and more reliably...

They also propose that all computer systems should have an "undo" feature built in to allow harmful changes (either due to mistakes or malice) to be easily undone...

Re:Scientific American... (0)

Anonymous Coward | more than 10 years ago | (#6003394)


>They also propose that all computer systems
>should have an "undo" feature built in to allow
>harmful changes (either due to mistakes or
>malice) to be easily undone...

A rollback of a hundred table join on a distributed db hardly fits in the same spectrum as "undo"...

Because they are complex systems (0)

Anonymous Coward | more than 10 years ago | (#6003350)

How often does your 4 function pocket calculator crash? Never? That's probably because they are simple systems. It isn't that hard to figure out.

Re:Because they are complex systems (1)

repetty (260322) | more than 10 years ago | (#6003386)

"How often does your 4 function pocket calculator crash? Never? That's probably because they are simple systems. It isn't that hard to figure out."

I'd mod you up, if I could.

You're absolutely right: it's that simple.

Geeze...

--Richard

Re:Because they are complex systems (1, Interesting)

Anonymous Coward | more than 10 years ago | (#6003420)

"How often does your 4 function pocket calculator crash?"

Well, maybe never, but...

My calc professor once put a question on an exam that was designed to crash a TI-89.

Re:Because they are complex systems (1)

AvengerXP (660081) | more than 10 years ago | (#6003416)

You're laughing, but I've had calculators turn "ERROR 3" when doing simple things. Nothing's perfect.

complexity is increasing (0)

Anonymous Coward | more than 10 years ago | (#6003353)

the overall complexity of computer systems, both hardware, and software, has increased substantially over the years. This complexity increase has been matched by tools (hardware simulation, purify-like memory checkers, etc) so the overall stability rate has remained good.
Windows2000 definitely is more reliable than win3.1.
Freebsd 4.X is definitely more stable than Freebsd 1.x. Progress is being made.

There are a surprising amount of bugs in anything: computer related or not. The industrial design of your car probably has something you'd consider a 'bug'.

Perfection is the brass ring to strive for. Commercial expediency is the balance.

It's expected. (3, Insightful)

echucker (570962) | more than 10 years ago | (#6003361)

We've lived with bugs for so long, they're a fact of life. They're accepted as part of the daily dealings with computers.

New features are more important than stability (2, Interesting)

IvyMike (178408) | more than 10 years ago | (#6003363)

People upgrade for new features. That computer/OS/gizmo you have today does a lot more than the one from 10 years ago. That's a lot more code that needs to be written, and thus a lot more opportunity for errors. It's that simple.

(I'm actually ok with that. I'd rather have a moderately crashy Windows XP box capable of playing GTA:Vice City than the hypothetical alternative: a super-stable Windows95, capable only of playing "Doom 2".)

Complexity, my dear Watson (5, Insightful)

T5 (308759) | more than 10 years ago | (#6003364)

It's all about the bits. There are just so many more of them now, and a great deal more pressure in the marketplace to bring ever newer software and hardware to market. Back in the day of the IBM 360 and the VAX, even though we were mesmerized by the capabilities of these machines, they were years and years in the making, debugged much more thoroughly than we can hope for today, and much, much simpler.

And let's not forget that this was the exclusive realm of the highly trained engineer, not some wannabe type that pervades the current service market. These guys knew these machines inside and out.

Essence of Software Engineering (5, Insightful)

Zach Garner (74342) | more than 10 years ago | (#6003366)

Read "No Silver Bullet: Essence and Accident of Software Engineering" by Brooks. A copy can be found here [berkeley.edu].

Software is extremely complex. Developed to handle all possible states is an enormous task. That, combined with market forces for commercial software and constraints on developer time and interest for free software, causes buggy, unreliable software.

Not always the softwares fault: (2, Insightful)

bravehamster (44836) | more than 10 years ago | (#6003368)

I've found in my years of repairing pc's that the majority of software problems have their root cause in hardware. A bad stick of memory, corrupt hard drive sectors, overheating components, cosmic radiation causing bit flips-all of these things cause random, bizarre errors. It's pretty easy to tell the difference too. Software errors are repeatable. The exact same situation should produce the exact same error. So all I'm trying to say is that I doubt we will ever reach the point that computers won't crash, because at some point there has to be interaction with the physical world. And no matter how perfect your program is, it's not going to survive a two year old stuffing pennies into the back of the power supply.

Re:Not always the softwares fault: (4, Insightful)

Jeremi (14640) | more than 10 years ago | (#6003442)

I've found in my years of repairing pc's that the majority of software problems have their root cause in hardware.


Wow, your experiences are much different from mine, then. I'd say 95%+ of my computer problems are caused by software bugs.


Software errors are repeatable. The exact same situation should produce the exact same error.


For a significant percentage of software errors, that statement is false (at least misleading), because it's nearly impossible to reproduce "the exact same situation". For example, take any multithreaded program with a race condition bug -- the chances of the two threads getting the exact same time-slices on two different executions of the program are approximately zero. The result: a crash that happens only sometimes, at random, even given the exact same starting conditions.

Simple Answer (0)

Anonymous Coward | more than 10 years ago | (#6003371)

Multi-process OSes, and deadlock. No one has figured out a solution that prevents it, so we just hope it doesn't happen.

Switch to vector strings and not null-terminated (1)

scorp1us (235526) | more than 10 years ago | (#6003380)

The null-termination thing is without bounds checking. A simple
strlen[strlen(str)]=0;
is enough to crash a computer. What's more is it takes O(n) time to fins strlen

Vector based strings strlen is O(1), and you get bounds checking and all that.

The other reason is because DLL exports don't match up between versions. They match up enough to get the link done, but a small change of a return value semantics ina function is enough to send most programs into a GPF.

That solution is to do away with libraries, and link to functions only. Rather than have glibc, allow a program to call out to any version of any glibc function in existance.

Modern Electronics (0)

Anonymous Coward | more than 10 years ago | (#6003387)

If my Qualcomm 3035 crashes every few months or so of
continuious uptime what makes you think even more complex computers and PDA's would be anybetter.

Entropy is a natural part of exsistance even for elecrtonics. You can try to avoid it, but eventually something will be out of order.

Microsoft (5, Insightful)

eht (8912) | more than 10 years ago | (#6003388)

Microsoft has made an extremely stable OS, it's called Windows 2000, as long as you use MS certified drivers the OS should never crash, individual programs may crash under Windows, but you can hardly blame Microsoft for that. I have had Windows machines with months of uptimes and no problems, went down 8 days ago due to power failure too long for my UPS's to handle, which also took down my FreeBSD machines, uptime is matched for all of them, and will one day again be measured in months.

Yes I should probably patch some of my Windows machines, but I have my network configured in such a way that for the most part I don't need to worry and you don't have to worry about my network spewing forth slammer or other nasty junk.

Economics? (5, Insightful)

iso (87585) | more than 10 years ago | (#6003395)

While it's not the whole story, something definitely has to be said about the fact that while people are willing to pay for features, they're rarely willing to pay more for stability. Quite frankly there's little economic incentive to make software that doesn't crash.

If your market will put up with the ocassional crash, and never expects software to be bulletproof, why bother putting the effort into stability? Until people start putting their money into the more stable platforms, that's not going to change.

Economics (1)

VTS (673706) | more than 10 years ago | (#6003400)

Its all about money, why spend twice as much (or more) money to develop your product when your competitor wont and it will only increase your sales 5% ?

And there is no point bashing C again, yes it may be less forgiving of errors but any tool is only as good as who uses it. Paying more attention to the architecture and design of a program will eliminate 100 times as many bugs as changing the language.

The ultimate solution (4, Interesting)

dsanfte (443781) | more than 10 years ago | (#6003401)

The ultimate solution to the problem is to let computers write the software themselves. Give them a goal, set up evolutionary and genetic algorithms, and let them go at it on a supercomputer cluster for a few months.

Of course, you'd need to make sure the algorithms that humans wrote aren't flawed themselves, but once you got that pinned down, you would be more or less home-free.

Even if you didn't take this drastic a step, another solution would be computer-aided software burn-in. Let the computer test the software for bugs. A super-QA Analysis if you will. Log complete program traces for every trial run, and let the machine put the software through every input/output possiblity.

Get a Calculator (0)

Anonymous Coward | more than 10 years ago | (#6003413)

My HP48gx never crashes. They should make computers out of 48gx material.
The same way they should make an entire airplane out of black box material.
I'm drunk.

Extra jabs at MS? (1)

Monkeyman334 (205694) | more than 10 years ago | (#6003423)

30 years of computing and we can't get rid of flamebait? You'd think we would have settled this all by now.

Well... (1)

syzme (584270) | more than 10 years ago | (#6003426)

I'm going to have have to take the nutty philosophy card here.

All language is inherantly flawed in trying to express abstract concepts, even in a fairly limited set of concepts, as is true within a given programming language. This inherent flaw just becomes more obvious to you and me when we objectively see a language implemented, as with computers.

Fortunately for us, human brains are to the level where we are --for the most part-- able to filter out flaws. Computers can't do this, thus they crash.

actually both (1, Insightful)

Anonymous Coward | more than 10 years ago | (#6003431)

First complexity is an issue. Today's systems are multiple orders of magnitude more complex than those of yesteryear. This by it's very nature causes problems. Also the complexity of today's programs means that large teams are required to get the work done. Every additional team member introduces a new variable into the equation bringing with him (or her) his own set of propensities for certain types of bugs until you have a whole universe of different bug types appearing in your product.

Second the capitalist market rewards the "just good enough" software. In a pure economic sense stability is not near as important as new features, ease of use, time-to-market, etc. This may horrify engineers and software architects, Lord knows it horrifies me but it's the practical truth of the matter that ROI is largest on systems that are fast to market as long as crashes are completely catastrophic. Also we've solved the problem of crashes in more cost effective ways at the enterprise level. Rather than spending tons of money fixing all the small bugs we advocate backups. As a "backup" they make sense but all to often we use them to cover problems that could/should? be fixed in code. Again the economics say it's cheaper to buy hardware storage than to pay a skilled coder/architect. I don't know if it's "right" or not but at a very practical real-world level economics have to outweight perfect design/production. At least I hope the companies I hold stock in see it that way.

There are many reasons that software sucks but you've nailed 2 of the biggest...complexity and economics. Let's hope the economics one holds...I don't want my rates coming down like the price of RAM any time soon ;-).

The bar isn't set very high. (2, Insightful)

joshtimmons (241649) | more than 10 years ago | (#6003440)

Sure, hardware is complex and today's software is huge, multi-featured, multithreaded, and event-driven and all of these factors make writing good software hard, but I think that the reason we don't see higher quality OS's is simply that the bar isn't set very high by the market leader. We tolerate applications that freeze, computers that need to be rebooted, or crash, etc. That low bar sets consumer expectations and the result is that companies (and programmers) only work to a certain level of reliability - then they work more on more features instead of more work on stability.

For those who are willing to pay... (5, Insightful)

PseudononymousCoward (592417) | more than 10 years ago | (#6003445)

The number of bugs is smaller. Think of the systems used by the telcos, or NASA. Are they perfect? No, but they are much, much more stable than Win32, or Mac, or Linux. The reason is simple, the owners demand them to be.

There are costs associated with fixing bugs and reducing crashes. The more stable an operating system is to be, the more time and money that must be devoted to its design and implementation. PC users are not willing to pay this amount for stability, either in explicit cost, or in hardware restrictions or in trade-offs for other features.

As Linux evolves over time, its stability will always improve, but it may still never reach the stability of, say, VMS. Why? Because even with the open source model of development, there are still tradeoffs to be made, tradeoffs between new features and stability, mostly. And successive bugs are harder and harder to fix, requiring greater and greater amounts of time. At some point, the community/individual decides that they would rather spend their time going after some lower-hanging fruit.

Just my $0.02

Actually, IAAE.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...