Slashdot Mirror
Why Do Computers Still Crash?
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?
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.
History will be kind to me, for I intend to write it - Sir Winston Churchill
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.
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.
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.
OMG OMG OMG WTF OMG WTF BBQ STFU RTFM, OMFG OMG OMG OMG ROFL LMAO OMG WTF STFU ROFLMAO
...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.
I belong to the ______ generation.
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.
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).
I don't care if it's 90,000 hectares. That lake was not my doing.
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.
...but humankind has not.
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.
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.
Read "No Silver Bullet: Essence and Accident of Software Engineering" by Brooks. A copy can be found here.
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.
---- El diablo esta en mis pantalones! Mire, mire!
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.
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.
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
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.
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.
I'm lazy so I haven't bothere to read what others have said. At the risk of repeating what others may have said:
Isn't this just a matter of economics?
I bet if you get everyone on the planet, and every company to purchace software solely by merit of stability, you'll start to see a lot more stable software. But as long as people are shopping for *featureful* apps, *fun* games, and eye candy, it's not going to happen.
-... ---
What exactly is the purpose behind this? Why was it put in here? People are going to need to grow up if people in "our" circle want to be taken seriously. I've used Windows 2000 and Windows XP both. They crash as much as my Red Hat and Debian boxes do. Never. They are all rock solid.
I work for a public school system. We have a class at the High School that teaches and certifies for A+ (I know, I know). They have all sorts of problems getting stuff to work and to get a system stable. In Windows and Linux.
It isn't because they are high schoolers.
It isn't because they are "just learning".
It's because they buy really shitty hardware. They look for the best cost, and they get their hardware from some loser manufacturer that has fucked up drivers and horrible quality control.
Properly maintained boxes with quality hardware in them just don't crash anymore. Programs maybe, but not systems.
Christ, people, this has been beat to death! Microsoft has a great product for an OS now! Get back to making something better than them instead trying to convince yourself that Microsoft is delusional.
Mod me Flamebait, I don't care.
Qualitas edurus commercium, nullus penitus net rimor, nullus deus beneficium
Crash? What crash?
:)
up 582 days
Reboot? What reboot?
Now, when was the last time you tested those init scripts?
-= Stefan
"Can of worms? The can is open... the worms are everywhere."
"Time To Market". For commercial software developers they are always trying to "balance", quality and getting into the market ASAP. Unfortunately MS (and others) have made it acceptable to release service packs after the "final" product has already shipped. Get it out there now, fix it later is commonplace.
Massive complexity (even for simple apps) + enless possibilities of user interactions + rush to market + no sliver bullet = likelyhood of crashing
Back in the Middle Ages, when the Catholic Church wanted a Cathedral built, they would pay a bunch of Freemasons to do it. The Freemasons viewed themselves as creative artisans, and they closely guarded the secrets they used to construct these impressive houses of worship.
The method they used, however, was less than impressive. Typically, they would start with a general design, and piece together stone and mortar until something collapsed, which happened quite often. Then they would patch the section that collapsed and keep on going until something else fell down, or they finished. Given the level of understanding with regards to Physics and Material Science, those Freemasons has no other choice than to build them this way.
Now fast forward to the 21st century. The engineering disasters on par with those medieval collapses can be counted on one hand (Tacoma Narrows Bridge and the Hyatt Regency walkway collapse are the only two I can think of). This is directly due to the fact that a civil engineer can determine if a design is structurally sound before they build it.
Contrast this with modern day software development. We can't even tell if a system is flawed after we build it, let alone before. So software gets written, deployed, and put into the marketplace that has no assurances whatsoever of actually doing what it's supposed to do (hence the 10,000 page EULA).
You can't have Civil Engineers until you have Physics. And you won't have 100% bulletproof software until you have Software Engineering. And you won't have that until someone can figure out a way to prove that a given peice of software will perform as it's supposed to. JUnit is a step in the right direction, but there's still a long way to go. It's going to take a breakthrough on the order of Newton to make Software Engineering as reliable a discipline as Civil Engineering.
(Digging through my pile of vulnerabilities...)
Say, could we get an address on that box? Muhuahahahaha
My uptime is largely limited by kernel upgrades and the fact I cycle the power once per month to prevent the drive head from sticking.
"Learning is not compulsory... neither is survival."
--Dr.W.Edwards Deming
... is deadlock. Lets say you have two IO devices, for ease we'll call them disk drives, which give exclusive access. Process A grabs one disk drive, then loses their processor turn (happens many times per second). Process B grabs another disk drive, then requests the drive Process A has, and 'blocks'. Process A then requests the drive Process B has, and 'blocks'. This is a very simple example of deadlock. Now if one of these processes is an OS process, well too bad.
There are mitigation strategies, but in short the all suck. You can constantly monitor every piece of hardware to see who has rights to what, and flat out deny access to people when a deadlock may occure. This is slow and isn't very nice to processes who now have to trap twice as many errors for many IO operations.
Another method (in avoidance) is to require all processes to request hardware in a certain order. This prevents all deadlock, but is unrealistic to how a program may function, and may require a programmer to hold onto a hardware device for much longer than actually needed.
The last method is perhaps worst of all: restrict every process to one hardware device at a time.
Can you think of a better strategy? Patent it and make a few billion. The strategy taken by *nix, Mac and Windows is... well to completely ignore it because it very rarely happens, but as processors in the future become faster and faster, they are more apt to run more and more processes at once, increasing the problem significantly.
Note this problem only occures for hold-and-wait devices. Usually any number of programs can read a file for instance, and there is no conflict at all. I find that Operating Systems Concepts (Silberschatz, Galvin, Gagne) covers this topic well, and plenty of other hotspots.
Except for a restricted set of cases, you can't prove that a given piece of code works or doesn't work. A truly exhaustive set of tests would be impractical to perform, and formal proofs of correctness place strong limits on the type of code you can write and the environment in which you can write it.
The result is that code is assumed correct when no bugs are found. This only means that there probably aren't _many_ bugs left. Thus, it may still crash (or have a security hole, or what-have-you).
Software has been complex for a long time. It just tends to be bigger now. A larger system has more opportunities for unexpected high-level interactions between components, but even a smaller system will have enough twists and turns that formulating a really good test suite, or checking the code by inspection, is very difficult. Bugs will be missed. As was discussed above, many of these missed bugs will slip through testing and reach the world.
As more effort is applied, you can get asymptotically closer to a bug-free system. However, this is far past the point of diminishing returns on the cost/benefit curve. For sufficiently constrained systems, you can even try proving it correct, but this tends to lead to cutting out a lot of functionality, speed, or both.
In situations where reliability must be had at any cost - aerospace control systems, vehicle control systems, medical equipment - the money will exist to produce near-perfect code, but even then there are bugs that occasionally bite. With commercial software, the buyer would rather have an application that crashes now and then than an application that costs ten times as much and comes out several years later.
Free and/or open software avoids some of this by staying in development longer, which allows more of the bugs to be caught, but even free and/or open software evolves. Every change brings new bugs to be squashed. As long as there are new types of software that we want, it isn't going to end.
Software crashes because it's complex, yes, but that's just part of it.
Jets are complex too. So is the Space Shuttle. Cruise ships. CARS are pretty complex.
While all these things do suffer catastrophic failure from time to time, it is far from the norm. Defective cars get recalled. Space shuttles ALL get grounded at the mere possibility of defect.
If Q/A as stringent as this was applied to software, Microsoft - and in fact most of the software industry - would be out of business. Can you imagine a Windows recall?
There is software out there that does not fail. Mind-bendingly complex software of the sort that "drives mere mortals mad" to boot. It is tested and retested, through all possible situations - not just the "likely 80%" of them. It is proved correct, and then verified again.
COTS software is crap because neither the market nor the regulatory forces (such as they are, but that's a separate discussion) do not require it to be. Nor could they.
A 747 Jumbo costs a whole lot, and while much of that cost is in the manufacture of the "big and complex thing" that it is, a significant chunk of that cost is also due to the design process, the testing, the modeling and simulation of it.
Software is easy to scale, everyone can have a copy of the product once one is built. Cake. But spread out the cost of an error free design - tested to exhaustion, passed through V&V and so on, and you have a completely different market landscape with which to contend.
Consumers, in the COTS context, don't mind "planned obsolescence" in their software. The current state of things proves this. People would rather have pretty features on a flaky system, than a solid system.
The REAL jabber has the user id: 13196
What you do today will cost you a day of your life
Wait a second. You're saying that because you can't get a modern game that was designed to run on a damn near infinite number of hardware configurations plus a wide variety of software configurations and have that game always run perfectly every time that the programmers are sloppy?
You can't expect that programmers predict every condition of every system that their software might run on. It would take decades for a new package to be released and even then it would be huge.
How can you compare a Super Nintendo where all that games written for it are within very strict guidelines to a PC game where the programmer knows next to nothing about the systems that the game is going to be run on? The PC programmer can only try their best to quash the bugs that they can find. And there is no way that they can stop them all. I don't think that this is due to laziness on their part, it's more due to the fact that they're being expected to ship the product on time. If consumers would tolerate longer development schedules and higher program costs, then I think that software would get more stable. But everyone wants newer, faster, better *now*. Oh, and cheap too.
The only way you could have complete software stability is to ensure that every system is exactly the same, down to the RAM manufacturer and the library versions. And you're never going to get that. Not everyone wants the same computer as Bob next door.
No it's the need to keep costs low and time to market pressures that is preventing the use of reliable software design techniques.
If all vendors had a large number of programmers and could select their own timeframe for releases, code would perhaps get more reliable.
But on the other hand, Microsoft does have a large number of programmers, and they pretty much decide their own release schedules. So the above obviously doesn't hold for Microsoft. I guess that's because all their releases add new features, which introduce bugs...
That's true for other vendors and other platforms too, isn't it? If all feature enhancements to say RedHat or SuSE Linux were stopped overnight and all future releases were only bug fixes, then said distro would be 100 percent bug-free at some hypothetical point in the future. But they have to add features to compete and evolve, and alas, said distro will never be bug-free.
The low barriers to software updates also make software a less rigorous practice than hardware design. In hardware design, it takes millions of dollars to tape out a new rev of a chip to fix a bug; not to mention all the bad publicity the vendor gets (Intel fdiv bug, anyone?). Hence rigor in design and validation is much higher for hardware when compared to software.
I'll paraphrase a comment that was said before, don't remember where i read it:
"We've been building bridges for thousands of years, but only started writing software for a few decades."
To combat increasing bugs in increasingly complex software, we need better tools. From the low level (more reliable memory handling) to the high level (more abstraction to reduce human programming errors) in software languages and compilers.
You can't expect to build the Golden Gate with shovels, without expecting it to fall apart do you? (no, i'm not a terrorist)
VIVA1023.com | Political Fashion.
Software crashes because: Software is an immature field. Good software takes time. Software is unobvious to business managers who want the job done yesterday.
Businessmen generally do not understand the internal workings of software. They are in a "big-picture" sort of world where software is but one pesky detail that will be taken care of. A computer crash that causes so many thousands of dollars in damages is no different than a truck crash. There is simply a risk to every element of business. If the risk is relatively low, the big shots don't care about it. Grocery stores in earthquake prone areas continue to place glass jars on the edges of shelves. Sure, there will be an earthquake one day, but it's a calculated part of business risk, and the risk is relatively low (the Earth doesn't shake every five minutes).
Software bugs are a similar risk. It needs to look like it works. It needs to crash (and lose data) infrequently enough that the software will still sell. The business is not concerned with stamping out software bugs. It is concerned with releasing the software and making money. If the need arises, the business will improve the software and make more money. More often than not, this means adding features and shiny graphics. Fixing bugs is not very important to companies because customers do not pay for bug fixes. By the consumer, bugs are viewed as defects and their fixes should be free. By the company, bugs are viewed as a minor risk and fixing them would cost too much to justify. So you'll reboot once in a while or lose an hour's work once in a while. If it fries your hard disk, well, you should have backed up your data.
Software is also one of the newest fields of human endeavor. Buildings have been built, ships have sailed and farms were farmed, all for thousands of years. No matter how much progress happens in these fields now, they have come so close to "perfection" that continued improvement serves to lower cost, improve safety and increase convenience. It's not a matter of, "Gee, how can we make buildings that actually stand without falling down three times a week?" It's just a matter of, "How wide, how deep, how tall and what color glass do you want on the outside?" You pay X dollars, wait Y months and voila, there is a building. But programming has been around for how long, 50 years? It's an increasingly important but very immature field.
Buildings, bridges, ships... they're obvious. Everyone knows that if enough lifeboats aren't put on an unsinkable ship, it'll sink on purpose, just to piss you off. Everyone knows that if a 100 story building is going to stand, it has to take 10 years to build it. Everyone knows that a dam has to be pretty damn strong or it'll break and flood half the countryside. The building, shipyard and dam businesses aren't progressing at light speed. It is easy to justify 10 years for an outrageous building design because people KNOW what is involved. But software... Now that's totally unobvious. Software is an idea. It's abstract. It's a bunch of curse words that look like gobbledygook to the uninitiated. A bunch of "noise" characters on a broken terminal. Something done by a bunch of skinny, pimply faced geeks who got beat up in high school, took the ugly girl to prom and didn't have any friends. Why should a manager bother to care that fst_jejcl_reduce() causes a possible NULL pointer in the outer loop if case 32 is activated, which happens if the previous re-sort encountered two items with similar Amount fields, all of which will take a whole day to find and fix and will only happen, say, 2% of the times this particular feature is invoked by the user, which isn't that often? Why should anybody justify spending 2 years to develop some bulletproof program that can be banged out in 3 months, with bugs? What's the problem? Constructor workers are risking their lives, moving heavy things, sweating all day in the hot sun... While geeks are sitting in offices just punching crap on a keyboard. How difficult could it possibly be? To
Face it -- if our cars broke down as frequently as Windows (or Linux or whatever), we'd be suing the auto industry out of business.
If our VCRs ate every tenth tape and only played tapes from the same manufacturer as the VCR with any quality, they'd all be returned to Circuit City.
But for software, we grit our teeth and say, well, I just don't understand computers, and reach for the power switch.
Until we, as consumers, start fighting for software that works without crashing, we'll continue to get the lowest possible quality -- just as we have for years. Once the customer starts demanding a quality product, the quality (and whatever software development practices, languages, testing procedures, etc., are needed) will follow.
Bottom line -- there's no real incentive. Microsoft makes billions with buggy software, the increase in profit for selling non-buggy software is pretty small.
Let's hear it for the "wannabes". I'm not a highly trained engineer by a long shot, but I've got computers that don't go down except for power outages. Then they come right back up. As ERS is so fond of pointing out, complexity kills traditional software. Cosed source can't keep up.
Free software has the answer. Debian has 8,710 packages available to do anything a comercial comercial software does, mostly better. Not just one or two pieces of it, every piece. My systems never crash under their stable release and I run all sorts of services. How is this? It's easy. Free code get's used, fixed, improved and reviewed all the time. The pace of improvement is astounding. I could go on and on about things free software does that common comercial code does not. Code that never sees the light of day is dead.
Friends don't help friends install M$ junk.
It's never the user's fault. No matter what the user does, the program should recover gracefully. Code that crashes is pathetic. Take my wife. She's managed to uncover all sorts of bugs and flaws in software, but she and my baby girl have had a hard time busting Debian.
Friends don't help friends install M$ junk.
A lot of the posts here have posited answers to why computers crash (people, complexity, unsafe languages, etc.), but most everyone seems resigned to it.
It should not be acceptable that they crash.
Personally, I'm shocked every time I use a computer as to how primitive they are and how little has changed. Is it, or is it not the year 2003?
All of these posited problems are solvable.
Unsafe Languages? Stop using them. Someone please design hardware and an OS that disallows their use and disallows unsafe behavior.
There are safe languages that compile and provide performance today (Lisp comes to mind, perhaps C#, Java's getting faster everyday, and there are safe subsets of C++). Start using those. And then someone go write something better.
I earnestly believe that if the hardware/OS had good protection at the lowest level then performance would not necessarily have to suffer. If the OS is written in a language where the API is solidly contracted, then _true_ safety can be enforced at compile time, and not slow down the system at runtime.
People? Users should _never_ be able to crash their machine. The person riding the elevator should have _no_ way, no matter how contrived, of making the elevator crash. And if the problem is programmers, then kick them out of the loop by forcing them to use safe languages, libraries and tools.
Complexity? Well, this is the kicker isn't it? "you can't foresee all the possible conclusions". But we don't need to see all possible conclusions to stop crashes. And if we lay a foundation of solid transactions on solid APIs with solid languages, then complexity will be reduced, there will be less dark "unknown" spaces. Maybe it'll even be easier to write software with fewer bugs.
I'm afraid if a user error causes the program to crash, I've got to call it a software error. It's not that hard to write the error handling handling routines, it's just never in the budget. And the users are invariably able to discover new frontiers of errors the programmer(s) never dreamed of. No matter. If clicking the wrong box, entering the wrong data, plugging in the wrong mouse, or installing the wrong screensaver causes a program to crash it's not the users fault (bless them, for they know not), it's the programmers and design engineers fault.
Hardware errors are another problem altogether. Luckily, it's usually quick to diagnose, and it's usually cheaper to replace hardware than software. It's great how I've been using Microsoft error reporting for about 6 months now, and it's never been their fault. They must be getting better. \snicker>
Everything I've ever learned the hard way was based on a statistically invalid sample.
Software crashes because it's acceptable and information about how to make programs that don't crash is sometimes hard to come by.
There are programmers out there who have spent years coding and learned how to avoid buffer overflows, check return codes, and fail safe if something unknown happens. But these things are not taught in school and even if they are, someone is going to make a mistake.
Software Engieering never advances. We don't follow the blue prints, we send out the constructions workers and makes sure something is standing ASAP so it looks like were working. Boss is coming, put some drywall up - we'll wire it later. Some guys worked on a really safe way to build the stairways, but his last company patented it so we'll have to do something else this time.
As an industry we don't learn from our mistakes. We reinvent the wheel time and time again but this time it's transparent, chrome and glows in the dark and square. Things are moving too fast and the old can't teach the young to avoid their mistakes because they are considered dinosaurs after a few short years. So we make the same mistakes on the "new" systems over and over.
Plus the system feeds itself this way. This software sucks, I better upgrade.
We would need something like standard Building Codes and Inspectors. When real buildings fail people could get hurt or die, but when a computer fails you reboot. It's just not worth it economically to make a program that never crashes. It would be obselete by the time it's done.
- race conditions. From the FreeBSD Developers' Handbook: "A race condition is anomalous behavior caused by the unexpected dependence on the relative timing of events. In other words, a programmer incorrectly assumed that a particular event would always happen before another."
- deadlocks. Deadlock occurs when multiple processes compete for limited resources. From Sun's Java Classes: "The simplest approach to preventing deadlock is to impose ordering on the condition variables." Sometimes, it is difficult or impossible to guarantee cooperation among competing resources.
- unsafe application environments. An operating system can establish limitations upon applications, such that those applications never exceed certain safety boundaries (e.g. access to areas of the filesystem, system resources, etc.)
- unsafe hardware architecture. A computer's hardware consists of a primitive architecture that is unable to guarantee proper operation. The current PCI bus and "IRQ" interrupt scheme is particularly susceptible to computer crashes, if hardware drivers are programmed incorrectly.
- third-party software and hardware. The support for third-party software and hardware results in an operating system environment which is open and generalized enough to be susceptible to crashes. For example, if you allowed anyone to come into your house and plug any manner of devices into your power outlets, you could conceivably experience a power outage as the circuit breaker kicks in to prevent electrical damage. That's the danger of exposing your outlet to strangers.
- application complexity. Regardless of how smart a developer is, the developer's ability to guarantee the functional correctness of a system decreases in proportion to the complexity of that system. Simple systems therefor are much less likely to crash than complicated systems. Whether they do, or not, depends on the safeguards that were put in place to augment the developer's ability to guarantee the functional correctness of a system. NASA's procedures for programming misison-critical systems relies on any number of safeguards to ensure functional correctness of those systems.
That's a good starting point, for now.Race conditions are particularly difficult for developers to address, since they propogate at many levels within the system (hardware level, OS-assigned resource level, application instruction level, etc.) Also, only realtime operating systems or simple embedded systems guarantee the relative ordering of certain events. Complexity has a direct correlation to the inability to guarantee timing.
Most operating systems that thoroughly employ these limitations are considered "user-unfriendly." More user-friendly operating systems, such as Microsoft Windows, inherently eschew these safeguards by default, allowing applications to perform actions that potentially result in a crash. Application environments such as Sun's Java do a good job of "sandboxing" an application's access to resources, such that system crashes are unlikely.
In order to create a system that enables applications to perform tasks as complex as controlling the entire computer (e.g. screen savers, hotkey programs, power toys, etc.), applications must be given the theoretical power to perform tasks that can crash the computer. The result is that the computer crashes when the application works improperly.
Now that Microsoft has been marketing fragile products for 20+ years, it should be no surprise that we have Comp. Sci. faculty with a tolerant view of instability. Some of them grew up with this stuff. If M$ "state of the art" is really good enough, then maybe software has become so commoditized that we just relegate everything to the H1Bs and let it go at that.
True story: My wife was in the hospital maternity ward. This is a modern US hospital, not some third-world tent. For about 24 hours, they had her connected to all kinds of sensors which were connected to a Dell PC running a data collection/graphing program on what appeared to be Win 2k. The application was a joke. The nurses fumbled and bumbled with it; crashed at least once. Fortunately, the important things went well (it's a boy), but no thanks to our friends in Redmond. Had there been a problem that those sensors were supposed to detect, we would have been screwed. As an expectant father, my primary job (at delivery time) is reassure Mom that all is well. Seeing this Windows app sputtering along made my job a bit tougher. Let's hope things are a little better in the ER or ICU.
The issue here is that we're talking about a product sold in stores to a large number of customers. And not a particularly cheap product, for that matter.
Customers have every right to expect value for their hard-earned dollars. If the customer's computer meets the specs printed on the box, the game should install and run. Period.
The publisher should give refunds to anyone who bought the game in good faith and couldn't run it.
One of the biggest barriers to stability for something like Linux (or Windows) is the fact that it must accomadate new software and hardware configurations all teh time. If you take a Lucent 7R/E phone switch it will run on a given hardware (the 7R/E) hardware. IT will run Lucent's OS, it will do only what it was designed to (switch phone circuts). There is no putting new hardware in it, less it be Lucent approved, there is no loading of new apps to make it do things, less it be Lucent approved, and so on.
IF you want an open OS that will run with hardware by whoever happens to want to make it and software by whoever hapens to want to write it, you cannot have a verified design that is 100% reliable. Unforseen interactions WILL happen and crashes or other malfuncations will result.
I used to leave all sorts of machines running 24/7 in my apartment. Several Suns, a couple PCs running Linux and BSD, an SGI, blah blah blah. I did take care to turn monitors off though. I kept this up until I turned off all my systems (except the mail server) for a two week vacation: I was shocked to discover the next electric bill arrived a good $80 cheaper. I've since cut back to a single machine which I turn off at night. No more crazy uptimes, but honestly - I'll take the money. I wish there was consumer demand for low power destop computing. I guess I'll just have to migrate to a good laptop for the low power option. But you're absolutely right: a few computers can suck up a lot of power, with damaging results to one's electric bill. --M
You could never write software that was perfect, because you can never account for every situation.
The solution most non-CSci people ask next is "Can't you write a program that checks for errors?" Intriguing to think about if you've never actually pondered it, but the answer unfortunately is no. You can't write a finite-state machine that can detect or correct an infinite number of states.
To do so would be similar to calculating the "best" route from NY, NY to LA, CA. You could choose any number of roads and paths from coast to coast, with or without loops (finding them would be quite a bitch) possibly traversing every road in the US. If you don't understand why you can't calculate this, ask your neighborhood CSci major.
The best we can instead do is safeguard the software we write as well as possible, which requires time (and therefore money) and computing power to do things like bound-checking on arrays; handling interrupts properly; and managing memory throughly, to name a few major problems in any software. Languages like Java come a long way in some respects, but are very slow. But this isn't a good enough solution, and frankly, most programmers aren't good enough to produce fully error free code.
As revolting as it may sound to the hacker-coders out there, great programmers, software engineering, business processes, documentation, and management of the whole product are necessary to produce truly good software.
Linux: The world's best text-adventure game.
I think the issue with crashing software is a combination of problems. Obviously cost is the biggest issue. Economics is another. And time is never on the developers side. Fact is, it is not economically advantageous to write rock solid code. Why?
First, it costs a lot of money to test and it is very difficult to keep your new code under wraps (from competition) and still offer a truly well tested system. Open source solves this problem by somewhat reducing competition since the code is free and can be tested by many people in various stages of testing. (Probably why Open Source is more stable)
Don't forget boredom. Once a developer gets something "working" he or she doesn't want to continue to stare at the code for hours contemplating its every possible flaw. We'd rather be reading slashdot.
Second, if your software was 100% bug free, people would never have a reason to upgrade. Guaranteed, if Windows 98 didn't crash so dang much I would never have installed Win2k. My dad had an old Compaq Presario with Windows 3.1 on it and it never crashed. He reluctantly had to upgrade to experience things like MP3's and AOL. (and crashes) I did downgrade from WinXP (Piece of doggie doo) back to Win2k.
Third, time is of the essence. Many times I am pressured to get the code done. It is better to have a software application that works pretty good and start using it than to have it absolutely perfect and never use it. This is an expontential scale. It takes more and more time to make the software a fractionally more stable. And sometimes you find a rewrite is in order. There is a balance to be obtained.
Some other things to consider: Scope and Methodology. The comparison was made between cars and code. I think this is an unfair evaluation because the scope of a car is well defined. You know certain parameters such as the size of the road, the speed it can travel. You have certain benchmarks it must meet, safety regulations. Software on the other hand has few of these. Operating Systems run on an incredible number of hardware and can be configured in infinite number of ways. I've found that PCAnywhere when installed with some other, unrelated software can just blow up an machine. The problem is that scope is not, and most noteable cannot be contained WITHOUT limitations. This is the reason why a Linux server running in Terminal mode with two daemons on it can run FOREVER. The scope is well defined, crap is not compiled into the kernel.
Lastly, methodology is the best answer. The comparison of computer code to legal code is a very good one. The reason why good lawyers write good legal docs is because they have a good methodology. They know how to cover their bases. Programming language developers should consider a development methodology and set up limitations. Java and other type-safe language set up these limitations and the result is safer code. Consider narrowing this even more. But realize that limiting what the developer can do has economic effects. What good is the worlds tightest coding methodology if VBScript still exists and can do the same thing? (and break)
In all, we are held in the balance. Yin and Yang. We cannot have one without the other. You add features, you add bugs. You create limitations, your code doesn't get used. You increase your time to market, you watch your competition buy you out. This is the way of things. A chasing after the wind.
Well, I've actually caused my PS2 to crash quite a bit, such as playing gauntlet with 4 players (tries to reference negative ram addresses or something like that...
/ex
But in general, you're right. It's very difficult to recall a console game...
However, it only has to run on one (few at least) set of hardware. It's the reason macs seem to never crash-- If they had to program for every piece of hardware out there, there'd be a lot of "crap" that happens, and things get messy...
If PCs were uber-standardized-- this proc. this amount of ram, this and that, then there would be no problem. I'm working tech support (for a *gag* foxpro program) and one in 100 customers gets extreme slowdown (like running a report can take 72 hours when it's supposed to only take 10ish minutes) all the time. We have been hunting for it for the past months, and it isn't the data... It seems possibly hardware related, but there's so much hardware out there, and so many different layouts for it (win9x v. me v. 2k vs. nt v. xp)
It's a nice belief that they try it on a bunch of systems, but chances are, if it's anything like the jobs I've run, you've got one guy that collects all the files, then at the end, he runs it around the office, and maybe to a "test room" with generic pcs of varying speeds and makeups, which he tests it on.
Did you ever look at sierra's help stuff? I never had a problem installing their stuff (microprose on the other hand, cost me six months allowance because it hard killed win31, and I had to bring it to the store to get it reinstalled (you know, when your parents didn't trust you to touch the damned thing, even though you can't do any more damage than you already did? Ahhh, memories...
Uh, that's all I have to add. Good points, just a bit more insight...
This is one point (and a good one), but the truth is that games get a lot more testing than other software. The main reason for this is that most games could be considered a realtime system, whereas your spreadsheet program is not.
What I mean by this is the fact that a program that needs to respond instantly to user input while at the same time spewing out millions of triangles a second of 3D graphics data has a much lower tolerance for error than your spreadsheet program that spends 90% of its time just sitting there as you type stuff into cells.
Spreadsheet fubar'ed because of some odd value you input? Oops. Oh well, reload from the autosaved copy and try again.
Your game fubar'ed because of some object collision detection glitch? Arrggghh, my character got killed!! I had the game's ultimate superpowered megaboss down to 1 friggin' hit point!! NOOOOOO!!!
Perhaps this example also makes a statement about the priorities we place on how excited we get over games vs productivity software :)
Karma: Frotzed (mostly due to the Frobozz Magic Karma Company)
Besides the harware production flaws, the software coding flaws, and the shipping process (every atom is manufactured, man-handled, assembled, and shipped somewhere), let us not forget end user abuse.
Who is guilty of smacking/kicking the PC or mainframe? I bet this helps stability alot.
Looks like it is time to replace your Personality Module. You are a bit to clingy, guess I better replace your fuser to
I've been using computers a few years longer. Heck, I've owned computers a few years longer (yes, that makes my first one prior to the 8080 micro chip). But even 25 years ago I saw Data General systems with a lot less raw power than a Pentium that ran a multi-user OS and supported an office full of users, and routinely ran without crashing or even being shut down from year to year, and were only rebooted when the tech came around to give them a scheduled prevenative maintence. Sure, some systems did fail (and some in quite interesting ways), but it was the exception, not the rule. The thing that I see as having changed is that Bill Gates became the richest man in the world, while at the same time giving us an OS that crashed so regularly that it just can't stay up. And somehow people accepted it. How he got away with it I don't understand.
I'm an American. I love this country and the freedoms that we used to have.
See, that's the thing. I like Apple's OS because at surface level, you can't get access to those features that could really break things if you screwed with them too much. If you really want to muck around with those settings, they are there and ready to be played with through various means (Terminal -- it's a freaking BSD system, Third-Party, and power-user know-how). I would like to respectfully disagree with your statment and say that by default they don't offer the option of defining settings that may cause malfunction, but in OS X they have left almost complete wiggle-room to in fact screw EVERYTHING up; if you know what you're doing. I think it's more genius than anything...
It's only when we've lost everything, that we are free to do anything...
The Super Nintendo used a 3Mhz Motorola 65816, the same processor used in an Apple IIgs. I can't find it's transistor count on the web, but it could not have had less than 5000 (the 6502) nor could it have had more then 68,000 (the 68k). Compare this to a modern AMD Athlon 3000+, which has about 54.3 million transistors. The Super Nintendo might be less likely to crash than a PC because there are at least 54 million fewer things to break.
Also, his claim that you don't find similar problems in modern hardware is incorrect. Just search Google for "intel errata" to see what I mean.
I bought my Gamecube last week and a copy of Metroid Prime. Ironically, it runs on an IBM PowerPC chip (the IBM branding is right on the box) and it's crashed twice since I've owned it. (I <3 my Gamecube regardless).
Industry professionals that produce glib, ignorant assertions such as this one might be part of the problem. :D
"People with opinions just go around bothering one another." -The Buddha
Why is it that people are always using Windows98/ME that was basically written in 1997 and 1999 and then compare it to their *nix installations that are the current versions and running the latest *nix patches?
If people want to compare MS and Windows to their *nux, at least use WindowsXP as the base line.
It would be just as silly to compare WindowsXP to a 1997 version of any *nix out there.
Or if you are going to use an 'old' MS OS, at least base it on WindowsNT4.0 which is at least in the same class line as *nix. Our clients have had high usage NT4.0 installations run for years without failures.
Windows9x is a grand extension of the DOS architecture, NT on the other hand is just a completely different ball game by design.
Crashes are a rather ambiguous topic..
A lot of computer crashes depend on what you're doing with it.
The machine I'm working on right now running Win98 or Win2k crashed on a regular basis by itself. I was tempted to blame bad hardware. Under Linux with a similiar workload (OS, GUI, browser, mail client) it never crashes.. That I can blame on the software being run.
Identical machines with completely MS software behave the same, so it's hard to blame non MS software for the crashing.
My Compaq iPaq with WinCE would lock up or shut itself off about twice a day under virtually no load and no 3rd party software. (I hadn't really figured out what to do with it yet). I was ready to return it to the store. I opted to call it a part-time paperweight, and "try" Familiar Linux on it.. Hasn't crashed since..
Well, that's not completely true. I've done some rather silly OS upgrades (hey, lets change all the libraries while it's running, and see what happens), so the crash was user failure.
But not to make Linux sound perfect, I've crashed machines with poorly written software. I've sent them into huge loops, and had software running that managed to suck up all the memory and hang the machine (a packet sniffer monitoring a 100Mb/s connection). Even my favorite web server, thttpd, had a poorly written beta version once that would upset the server after a couple days of running.
Is it always the OS? Nope. I've had a set of 10 machines with "generic" memory in them.. After a few years of running, they all began crashing mysteriously about twice a day.. Swapped the memory out for name-brand memory, and the started working perfectly.
We have a big industrial looking Dell on the network. Memory flaked out in that. Machine was dying about once a month. Swapped that out for a larger quantity of Crucial memory, and no more problems.
In a computer store I worked in years ago, we bought the cheapest hardware possible. The motherboards didn't come with boxes, and the manuals never made a reference to a manufacturer. Most of the hardware I couldn't even track down a manufacturer name through the vendors. About 1 in 10 parts wouldn't behave properly when we turned it on. About 1 in 30 machines came back for repairs for bad hardware within a few months.
So, it is really up to everyone involved if the machine will work right. I use Asus motherboards, Crucial memory, and Western Digital hard drives, and rarely have a hardware problem. The last problem I had was a bad IDE cable. There's always something that can fail.
The software has to run well, and we've very very happy with Slackware's distributions, with Apache and thttpd.
The biggest problem we have is user software or simple misconfigurations.. What happens when you have a heavy traffic web site, and the web server logs never rotate or get truncated? The drive fills up fast, and you end up with 2Gb logs.
What happens when you write a program that ends up sucking up all the memory and CPU time? Makes it not run right (I've done it myself a few times. Oops.)
People constantly bring their home machines in to work for repairs, for various reasons. About half are software misconfigurations (how many 3rd party applications do you really need running at boot time?). The other half, dying hardware.. The CPU fan made noise for 6 months and then stopped making noise, but you let it go? Ya your CPU is burnt. Cheap fans do that faster than most.
Can they build a crash-proof computer? No. Just like they can't build a crash proof car.. Cars typically crash due to user failure (users including other drivers), or compontent failure (Ford tire blowouts). Not really the car's fault. I had a car in a parking lot crash. A driver missed the highway and broadsided it.
So, you can strive for perfection, but there are always going to be circumstances that can cause failures, usually attributed to users. (those damned users.).
Serious? Seriousness is well above my pay grade.
I would agree. Properly and well written code will gracefully handle runtime errors.
Translation: Short of the user fubar'ing the program or data files themselves, the program should handle all user input in a graceful way.
The problem though is that to do this would require quite a bit of extra work.
Progammers are caught in a situation of getting something ready for market at a time dictated to them by a department which doesn't understand the underlying issues or saying "Screw it" and making the code solid.
That only describes one way in which the problem is caused.
The bigger problem is the attitude people have about computers which allows for this kind of shoddy programming. People are, for the most part, okay and even expectant of their computers to crash at some point in time.
This in turn makes it okay to release bad code which will be "fixed later".
I say that whenever we get a crash or a problem, we report it to the company and we post it to our websites and to review sites.
I say that the users should make it a big fat noticable problem to the companies whenever their software breaks.
why? because it means that whenever someone who's never used the software before searches on Google for that software or software company's name, they will find page after page of complaints, dissuading them from using the software.
the flip side is, if the software works, post to your sites and review sites. Give the people and companies who produce good software credit when it is due.
As users and consumers, we should find ways to encourage the producers and companies to produce solid code.
Solid stable code shouldn't be the exception to the rule.
Winged Power Photography
I think you loose alot (and I am sure you will quickly ignore my posts).
The poster may not be a native english speaker.
The poster may have my problem (dyslexia, learning disability, etc) and still be quite competant in what they are trying to express.
So, I can't spell. I have a physical problem (dyslexic - actuall medical diagnosis), I also don't have time to spend putting every post through a spell checker. It still doesn't change the fact of the content of my posts being correct or incorrect. Then again - it is only damaging to you to ignore any wisdom given by someone who doesn't speak english well or has a disability.
------- Sorry about the spelling, I suffer from two problems. Dyslexia makes it difficult to spell well, lazy makes it
Have you ever heard about a company which is bulding houses without any plans?
Software companies are growing too fast, and they want to make more and more and more...
there is no time to make good requirements and no time to make a plan..
People, and mostly managers, are not "safe thinking".. Thay want everything as fast as possible. This is the reason why software companies need to use software to controll they process.
But in the other hand, the hardware is looking the same.. i dont remember any C64 which has wrong memory, or motherboard.. it was just good at all! But if I buy a new memory modul to my computer it could be wrong, or it is incompatible with the others!
So, what I belive, we need to use programs to controll the all software designe process, a program which dont let me go around a problem. But I am sad, because we sould use it since 80's!!!
There is only one good solution: The simpliest!
who's gonna buy the product? who's gonna install it?
That was classic intercourse!
Are we to understand that Apple is good, or that Apple users are particularly stupid?
Personally, I've never used a Mac for work (I've only dealt with them when setting networks up for others), but the UI has always seemed a few steps ahead of the competition in terms of ease of use, so I'd applaud Apple for taking the time to think of the user and making the interface easy to use.
oh brave new world, that has such people in it!
My take is that there are problems with the process of creating software.
... process is far to often ignored. How many software managers out there believe that the sound of keys clicking is indicative of "progress"?
My first belief is that there are no "user errors" that cause software to crash. Hitting ctrl-s should not cause the word-processor to crash, taking out your thesis.
Secondly, the software design, develop, test, redesign
Third, there are an aweful lot of extremely bad software-designers out there. These are people who fail to understand how to compartmentalize their design. Compartmentalization should always be done with a view to minimizing software complexity and reducing the number of failure cases. A simple elegant well-thought-out design almost always performs better than a complicated over-engineered for speed design.
Finally, programmers are people - subject to personal problems and limitations in what they can do. I've had the pleasure of working with several very arrogant egotistic project leaders who's projects consitently fail. Nothing pisses people off faster than having their code removed from the CVS and replaced with the bosses' that doesn't work and fails to handle special conditions, esp. when the check-in is done after office hours and the e-mail states "it works, its staying".
Bottom line: hire good designers, technical writers and programmers. Never hire idiots to save money. Carefully screen project managers, and choose only those ones with success under their belt.
When I buy software and pay good money for it, failure is not an option.
-Brett
People are so used to unstable computers nowadays, a crash is considered normal.. people EXPECT computers to crash, and couldnt imagine one that doesnt.
This means that unstable software sells just as well as stable software, but is much cheaper to produce since you dont need to test it so thoroughly. Now any commercial vendor will realise they can save a lot of money while only very slightly damaging their sales, the money they save on testing more than makes up for the lost sales so they just continue writing buggy software.
If the average computer user would boycott products for being unstable, and stand up and say "this really isn't good enough", and it seriously hurt software sales, then something would swiftly be done about it.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
This could ofcourse have been a single bit that failed on the medium you got your copy on.
McD's doesn't make food that's good for you. But they make lots of it and they profit by it.
M$ doesn't thrive on quality software, just software with lots of bells and whistles, marketed well to the masses. And they profit by it.
Unfortunately, MickeySoft sets the BAR.
It IS possible the write qality, bug-free, software that doesn't crash. Just nobody has found a way to profit by it.
In most software companies you get promoted for political aptitude with little or no regard to yoru knowledge of how to create software and just as important how to organise software development teams well and how to get a mutually benefitical relationship with the clients during and after the project.
Such people tend to beleive urban legends such as in bygone days, in a country far from here, there was a software project that used the waterfall process and finished on time, within budget and with a happy customer.
They do this despite the reasons why waterfall processes leads to nowhere pleasent having been throughly documented in everything from scholary texts on organisational theory to excessive numbers of first person narrated horror stories. And who can blame them. They got promoted to middle or upper management, not because they knew a thing about organising software projects, but because they were better politicans than the next guy, so it would not further their carear if they were to sit down and read their first book on software project management throry.
Windows 2000 Server, SP3. Up for 55 days, 15 hours, 53 minutes. And that's only because I moved into my flat 55 days, 17 hours ago :) In that time it's been used extensively for C / C++ development, plenty of Quake 3, CD burning, watching DVDs, Kazaa, you name it. And it also serves my website (half a million hits over the 55 days), email, internal DNS, DHCP and file server. It's transferred over 150Gb of data to either the internet or LAN, and has never crashed. Who says Windows 2000 isn't stable? I don't even need to reboot when I install patches - restarting services to trigger the updates is relatively easy on Win2K if you know your services well.
Windows in general cops a LOT of shit for instability that it really doesn't deserve. Before you criticise Windows for being unstable, I suggest you try debugging a crashdump - 99.9% of the time it's caused by a third-party driver. Cheap sound card? Old graphics driver? Hell, maybe even you've not installed the 4in1 driver for that Via IDE controller on your motherboard? Drivers are the single biggest source of crashes and reboots in Win2K. If you want a stable system, spend some money on your hardware, and get it from a company that provides decent drivers.
Admittedly, that's the reason why *nix is generally perceived as more stable than Windows - if a driver is bad in Windows, you're screwed. If a Linux driver is bad, you can fix it, recompile the source, and bye bye instability.
Don't blame Microsoft for instability. Blame the third-party hardware vendors who can't be bothered to spend the time and money properly debugging their drivers.
Hm. Yes, but when you're coding, you're dealing with the task in hand, which is never to write code that handles all possibilities of user interaction. Ultimately, it's testing that should find the bugs.
Yes, there are bad coders, or coders who are simply over-worked and managers who want everything yesterday. But if enough testing is planned into the project, then there will ultimately be less bugs.
All software has bugs. That's inevitable. It's minimising the number of bugs and their impact that's important, and that, ultimately, is best done when testing.
When was the last time someone crashed their Super Nintendo?
Actually, my game cube has crashed on several occasions with SSX tricky and other games.
nohup rm -rf ~/. >& zen &
In my opinion, something the user does should never cause a program or operating system crash. If this can occur, it is the developer who is at fault, not the user C:\WINDOWS> del *.*
"In wine there is wisdom. In beer there is strength. In water there is bacteria." --Old German Proverb
Twentyfive years ago I worked for a database and application vendor doing internals (Amcor in case anyone cares). Filtering for correct input and preventing long scale logical errors was a major fetish. Much of this was not difficult, just a group agreement to use library routines for all user interaction that had input validation and condition handling. Programs were built from shells that had standard condition handling embedded -- you added custom branches as needed. What made the whole approach successful was an agreement on standards of program behavior and a willingness to share common code. Errors like the ever popular buffer overflow just didnt happen because moves into buffers checked first, etc. The move to RISC processor architecture attenuated synchronous error handling, to be sure. But in the large, it is the obsession that in IT, experience is a handicap (just ask any recruiter about experience that is not 110% matched to what they want NOW) -- so junior programmer mistakes become institutionalized. The budget is a convenient excuse, but I think the real root is the inexperienced lack of appreciation for what matters.
Of course, there's no need to mention Microsoft's inability to create a stable system.
You know, my win2k machine -- the one that has been up since our last power outtage, and had been up since the power outtage before that -- has never crashed. It might be because I don't overclock it, used a retail processor, Intel networking, four fans, whatever. But it has not crashed or needed a reboot since I installed Jetico BestCrypt last year, March or something. I use it every day, have played pretty hardware intensive games on it, and even used it as a server.
I think the problem here isn't with Microsoft and their inability to write a stable OS. If it is stable anywhere, that means the kernel isn't leaking ram or occasionally polling hardware that doesn't exist. The problem therefore lies with Microsoft's inherent trust that driver manufacturers and software engineers will handle their own damn errors. Linux doesn't do that. The kernel is so "low" that it recovers from just about everything. The software on top of it, that's another story. Many of the applications I've used in Linux crash after a single parsing error, bringing down anything reliant on them. Tell me you've never had an X server crash on you, taking down your entire GUI. To the average user, who isn't running a bunch of services or daemons, losing the GUI is the same thing as crashing. So what if bringing it back up is faster than rebooting the machine -- it's also more complex to support.
Besides, hardly anybody buys a Windows installation because they wanted a more stable system. They bought it because they wanted cooler toys and a snappy GUI. People "buy" Linux, BSD, et al. for stability.
Hey freaks: now you're ju
Its a well know HCI concept that people learn by trail and error so its really a design flaw in the program if user error causes a crash
In order to be flexible enough to do everythign a computer can do, computer languages have to be allowed to crash the computer. Otherwise you are severly limiting what they can do and slowing thigns down.
Most computer crashes are caused by an INTERACTION of two pieces of code that did not know about each other and were never tested.
If you want a system that never crashes than all you have to do is:
1) accept a restricted operating system that will never be able to compete with a commercial system like Windows.
2) Never install a program that was not A) created by the same company/group that wrote your operating sytem, B) specifically designed for your particular computer, and C) designed to be used with and thoroghly tested against all the other software that is currently installed on your PC>
That is what companies do when they make non-pc computer equiptment (cars have tiny computers) and is the reason why such things do not crash.
excitingthingstodo.blogspot.com
Why Do Computers Still Crash?
So, he's used computers for 30 years, apparently not programmed them.
Other important questions:
Why do computers still cost money?
Why do computers still require power?
Why can't computers yet read my mind?
Why don't computers smell pretty?
Well, back to the crashing... it's all my fault. I'm sorry. I won't do it again.
Yes I have 30,000 lines of code and not one crash in over a year. It is multi-user and multi-threaded and is used ALL DAY everyday at my office. I will not say that it has never had any issues but it has never crashed. Most of the issues seem to have to do with the DDE link to our contact managment program. Sometimes they seem to stop talking to each other.
The truth is this is more about the OS then apps. An app should not take down a computer if it does then the OS has issues.
I will say that a lot of OS crashes and app crashes has to do with shoddy coding.
What if we could bill the HW, OS, and apps vendors for our lost time due to crashes? I'm sure systems would improve in a hurry!
What's needed is legislation making vendors liable for losses due to faulty computer systems. Remember, carmakers cared more about styling than safety until Ralph Nader's book Unsafe at Any Speed alerted the industry and consumers to the need for things like safety belts. Now we have federal safety standards for automobiles.
I'm sure the libertarian-leaning tech community will freak out as soon as they read this. But "self-regulation" will only take the computer industry so far towards total reliability. As computer systems govern more aspects of our modern lives, government regulation seems inevitable in my view.