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
Same reason cars crash.... people ;-)
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.
Crash? What crash?
radagast% uptime
8:56pm up 582 day(s), 12:45, 22 users, load average: 0.00, 0.00, 0.01
-fb Everything not expressly forbidden is now mandatory.
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
That's called job security man!
...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.
*0;
never follow the null pointer they said... what are they hiding there????
-judging another only defines yourself
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.
That sir, is a TRUE statement.
Everyone leaves some code that only they can fix...
My Standards for variables:
_needthis
_needthis1
_x
_uz
etc
Solid!
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.
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.
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 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?
In order to be immortal you must be organize
Scientific American actually had an article 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...
A Minesweeper clone that doesn't suck
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.
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".)
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!
Anyway remember, it's not a bug, it's a feature...
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...
Solid!
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.
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.
occultae nullus est respectus musicae - originally a Greek proverb
But eliminating bugs would take all the fun out of programming!
14% of all people know that.
--
the strongest word is still the word "free"
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.
-... ---
I'm sure it's harder to accomplish this for kernel level code (it's primarily OSes being pointed at right here) but you can think everything is working hunkey-dorey and not realize something is going wrong under the covers.
Most errors of this can be found with testing under tools like valgrind or Rational's purify. I'm sure there are others (I've heard of ParaSoft Insure++, ATOM Third Degree, CodeGaurd, and ZeroFault), but the quality of these tools really matters.
The issue is that tiny errors can cause crashes intermittently, and not immediately. For example:
uninitialized memory reads -- usually not a problem, but if this value is ever actually used, it will be.
array bounds reads -- never acceptable, but depending on the structure of memory, may not always cause an immediate crash.
array bounds writes -- like ABRs, may not be immediately fatal, but these are going to crash your code sooner or later.
Since they don't always cause an immediate crash, these errors are likely to creep in to released code without use of one of these tools. And if you want to know why we shouldn't always run programs in an environment that checks these kinds of things, try it once; you'll notice a speed hit of usually an order of magnitude. C/C++ is a perfectly acceptable language -- not all debugging has to be done by the compiler/interpreter or only after you notice a problem.
Anyway, hope that wasn't too pedantic....
The current issue of Scientific American states that 51% of crashes are due to user error. 15%=software error. 34%=hardware error. Refer to article for further info.
Any of the following reasons conspire to result in buggy software these days.. (a) clueless marketing departments, project managers, etc set unrealistic deadlines for completing code to an acceptable standard. shortcuts are taken to meet the unrealistci deadliens and buggy products are the end result... (b) to satisfy client demands for increased functionality (no matter how unnecessary) results in more compelx code.. complx code is harder to maintain and troubleshoot... i sometimes think IT peopel have forgotten the notion that a simple solution that achieves functionality is the best solution... (c) programmers are humans, humans make mistakes in code... (d) companies to reduce the time/resource necessary to complete a product put in place aenemic testing/load testing methologies... (e) people often compare a computer to a kettle, car etc.. why can't it just work like that... well kettles do one thing and that's it.. computers do many complex things from rendering a CAD diagram through to a large scale mail server... etc etc... cars do one thing by relative comparison too but even most cars get more maintenace than some IT environments i've seen and you don't see people rushing out to buy a no name no brand car (e.g. like pc clones etc etc)... and many more im sure... how many more faield IT projects/Buggy software have to occur before peopel realize these things?
In the world of games, especially console games, a crash immediately spoils the user's gameplay experience, and it's doubly so if you don't have a mechanism to patch games as in the PC world.
In the GameCube, crashes are alleviated by having only a thin OS layer between the hardware and the game, and restricting only a single task to be run in a single privilege level of the CPU, avoiding context switches and going back and forth between user and kernel mode which introduces complexity and can wreak havoc if malicious data is present.
Furthermore, we have a set hardware configuration, running a well defined consistent set of drivers, which are again, minimal, and this eliminates another factor that often leads to crashes in the PC world.
The most important thing though is robust software design. In our games, we all code exception handlers for the software, so that a single errant NULL pointer doesn't bring the whole thing down with a "Segmentation fault" message as PC users seem to experience with their software, but rather, we gracefully recover, perhaps immediately rolling back to the previous iteration in the game loop and "moving" the player a bit, for instance, in a FPS where the player might have entered into an area in a orientation that happens to create a divide by zero error due to numerical imprecision.
In the future with CPU and memory speeds increasing, we are investigating new designs, such as microkernel based architectures where individual game entities are separate protected "processes" that communicate via some fast IPC mechanism such as shared memory or a "tuplespace", so that a bug in one entity doesn't bring the whole universe crashing to a halt, and I hope that such techniques are adopted by the general computing world.
-- Samir Gupta, Ph. D. Head, New Technology Research Group, Nintendo Co. Ltd., Kyoto, Japan.
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
"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.
There are a lot of moving parts in a working linux system (I'm talking CLI here), however, it seems to be less prone to crashing. As someone previously mentioned, software that is larger and more complex is more likely to have a bug. The point I'm getting at is that the design priciples of *nix dictate many small programs to create a large working system. When a program is small it can be designed and developed with care. This leads me to my final though, modern Operating Systems with GUIs are less stable because they are generally designed as large monolithic systems.
I'm going to claim that the prime reason systems with GUIs (and I'm including everyone) are unstable is because noone has come up with a rock solid base for such a system. X is not solid, windows explorer, mac os x's application manager, no one has it right.
The one thing I am leaving out, is that drivers also tend to be a major cause of instability. I cannot run the nvidia driver on my gentoo box, certain usb events can bring a system to a screetching halt. What needs to happen is better design around the unstable interfaces, such that in the worst case scenario, things can still be recovered.
Fear trumps hope and ignorance trumps both
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.
... 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.
It seems to be one of the most popular things to do is to blame the software creators, or the human operators. Thats not the reason my computer crahes Why does my computer crash? Well, when you spend hours of your day looking at thigs you shouldn't be looking at (wink wink), and other memory consuming things, (chatting, all those programs that even though I disable from starting up [yes, using regedit] still manage to start) just eat away at my computer. And finally, the most important and Sane reason of all. The Underpants Gnomes. They finally figured out what stage two is. Stage 2 part a; Crash My computer, Stage 2 part c; Use the underpants to make profit. Thanks for listening to my rambling post.
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
My Windows XP box, which is my fileserver, has been up for 5 months so far.
My OS X box, which I use for web browsing and word processing, crashes about once every three days.
Now, I certainly have some bones to pick with Microsoft, but Apple is no better.
Best Buy can have you arrested
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
instability is inevitable for fast evolution. A stable system means its not evolving fast enough, or evolution is slow.
Many softwares have been evolving so fast that there's been no time to perfect the existing features before adding new ones. At some point in the lifetime of indivisual software, it reaches a point where it's somewhat "stable" in the sense that no more major features are needed. For example, TeX reached its relative maturity during 80s and IIRC, there's no known bug at this point.
If all softwares are given enough time, they will all reach that kind of maturity. The problem is not all of them can survive that long - usually they become obsolete before they become stable...
Use OpenZaurus and while crashes still appear (I assume 3.2 will eventually, though I haven't had a full crash since it first came out), crashes will not lose all your data, since it's written to flash.
Also, my Linux box hasn't crashed this year, and I can't recall any crashes last ye-- no, wait, there was one slew, but it was an icky driver which I got rid of. I'd say a pretty good track record for a system built almost entirely from CVS.
Can't remember any crashes this year or last on any other Linux boxes I manage that I can think of (8 boxes off the top of my head).
Accept it. It's a fact of nature.
Ah, but is user error defined as "well, you know it doesn't work, so why'd you try"?
When can we finally give up the FUD of "MS crashes all the time"? Anyone who has used a later MS OS (Win2k or XP) can easily see they crash very rarely. I have had my Redhat install have more problems than my Windows install in the past 6 months, and on the MS system most of the problems have been 3rd party software while on the Linux most of the problems have been the OS itself. The reason systems crash is that there are many pieces, written by many different people, interacting with each other. This is the same whether the OS is Linux of Windows. The harping on the instability of Windows does nothing but hurt the Linux cause, since anyone who actually uses a newer version of Windows knows that the person has no basis in reality.
"Information wants to be expensive" - Stewart Brand, the same guy who said "Information wants to be free"
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.
I think this is basically the right answer.
A couple of months ago, the company I worked for spent a lot of time and effort developing a robust testing methodology. We had a software product that through blood sweat and tears would not crash unless you basically blasted the hardware in some way.
But that led to two problems. First, we only had so many people working, and resources spent testing and bugfixing were not being used to add new features. Second, the time it took to get it that robust delayed the product's release beyond the point where we could recover the investment. [Time developing] * [Cost of operating] was greater than [expected number of units sold] * [price per unit].
What ended up happening was that we lacked the features to justify the price and number of units we needed to sell to cover the cost of developing it. We had no bugs -- and we could be certain of it -- that would crash the machine.
As of last month, the company could no longer afford to pay me. I'm not there any more.
The moral of the story is that trying to make a bug-free product will bankrupt your company, especially a startup. Software tools have improved, but the benefit largely goes towards adding new whiz-bang features that sell the product for more money, not to being able to fix more bugs.
What we should do as engineers and managers of software products is to not be afraid of getting the product out the door with a few bugs in it if we want our company to do well; this business reality is ultimately why bugs will a big part of software for the forseeable future.
I've got the solution: the TeXOS(tm)!
Slogan: Crash-free -- Donald Knuth guarantees it!
-Waldo Jaquith
I develop software at a small shop for a living. We're scraping by; money is extremely tight. As a result, anything we code is coded as quickly as possible. The boss always says "we need this done fast and we need it done right." This sentence is almost always followed up with statements like "don't build it for the ages" or any number of quotes that indicate he doesn't care how, just get it finished as soon as possible.
Welcome to the sorry state of affairs in the software industry today. Developers are too rushed (or don't care themselves) to come up with good designs and write solid implementations. Weaker coders are rewarded for their speed while stronger coders are degraded for software built to last.
Good engineering principles must be applied if software is to not: crash all the time, contain more than a fair share of bugs, contain security vulnerabilities, and not corrupt data. These engineering principles are complicated in practice, but not so numerous. I cannot be exhaustive here, but I am trying to convey a general idea.
- Build tiny, atomic pieces and make sure they work. It amazes me how my peers always come up with blanket solutions to problems. These solutions are remarkably complex and may work for most of the data, but not all of the data. Remember tiny pieces! The immediate question is how to make sure these pieces work. It's more than just testing here. You cannot just evalute a small number of pre and post conditions and assume something works. Prove mathematically that for all possible inputs/pre-states you receive correct outputs/post-states. Remember your discrete math class? Remember doing proofs? Apply it! Computers are fundamentally number crunchers and your input/output are fundamentally numbers and can be represented symbolically and in finite terms. Certainly cases exist where this principle cannot be employed, but those are rare. People working in the encryption field should understand this principle very well.
- Have clearly defined specifications for the software to be written. Strive to work out any questions or ambiguities in the specification before even embarking on the design process. If the specification is unclear or ambiguous, it is simply a matter of time before programmers do the wrong thing or begin to make incorrect or unreasonable assumptions. Another important note on this principle is the partitioning of specifications where appropriate. Do not let specifications for user interface mingle with those for the back-end. While they may be closely related, try to follow the Model Control View (MCV or MVC... it varies). This must be adhered to at the earliest stages of the specification, all the way up to the actual pounding of keyboards.
- Conduct frequent peer review! This is one of the strongest points of open source software development. I argue that it does not occur frequently in the commercial world because everyone is afraid of their peers negatively reviewing their code, placing their jobs at risk. Sadly, this only results in a suboptimal product. The more other people look at your code, the more likely your mistakes (and they do exist) are likely to be found. It's a shame work place environments are not geared to eliminate fear of failure, otherwise I think most software would be a lot better today if people were eager to do reviews.
Once again, this isn't entirely complete, but I think the point is clear. This was written on the fly and mostly off the top of my head, but I think I've got it right. In general, a lot of common sense needs to be applied. For example, if your input is for all intents and purposes random (it's coming from the user) then do extensive checking on it! If you want to encounter unexpected values in your data structures, make sure you hide as much as possible from the rest of the code. It amazes me how little the most basic computer science principles are followed in most software development projects. This is one of the biggest reasons software is so unstable.
Join Tor today!
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.
In C++, which a great deal of software is written in, an exception block [or the language or system equivalent] placed around the entire application will catch just about any recoverable error. This is how most of the windows blue-screens or 'your application has performed an illigal operation and will be terminated' messages are brought up. This is how Linux and other unixes generates a core dump.
The actual handling may be in a signal handler, try/catch block, or abend, but the functionality is present in every activly developed language I have ever worked with from cobol and fortran to c, c++, java, and object pascal.
The main reason for applications actually crashing is programmer lazyness.
The main reason for applications getting into a state that they can crash is improper complexity management.
When it comes to drivers, I'm much more forgiving, since it is quite difficult to manage both the hardware and software, and the communication between different programs.
Finally, the operating system itself, which is the layer between the drivers and the applications, I haven't seen any in the last 5 years that has been unstable. Even Windows ME, for all its faults, was very stable in the actual 'operating system'.
But that's just my 2 pesos.
frob
//TODO: Think of witty sig statement
My OS X box, which I use for web browsing and word processing, crashes about once every three days.
The Ti PowerBook G4 I am writing this post on is running Mac OS X 10.2.x. It goes in an out of sleep on an irregular basis, and not always when it is idle. I swap PCMCIA cards in and out. It hops from network to network. I do a lot more than browsing and word processing.
According to my Konfabulator uptime widget, I have 83 days, 23 hours, 20 minutes. My load average at the moment is 1.7. It has not been rebooted since I installed OS X (I did it myself after buying it just for messing around purposes).
You sir are either lying, have bad hardware, or you've severely corrupted your installation. This operating system (which is BSD) is solid as a rock.
Join Tor today!
The current issue of Scientific American states that 51% of crashes are due to user error. 15%=software error. 34%=hardware error. Refer to article for further info.
You made a little "user error" there yourself-- the article says that 34%=software error and 15%=hardware error.
Oh, and those figures are just for Web applications, not software applications in general.
It's an interesting article. Unfortunately, they're not very clear about what constitutes a "user error." I've filled out Web forms that gave me an "error" when I included hyphens in my phone number or credit card number. That's far from an error, it's just poor user interface design.
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.
Apple's Human Interface Guidelines are a nice introduction to user-fault tolerance, even if you're developing for other platforms.
Isn't that "restore him from backup?"
The Spoon
Updated 6/28/2011
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.
... doing dirty things with clay?
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.
Debian tested in every state, works good everywhere. I have yet to prove that it does not work anywhere in any way. I can not say the same thing for any other software I've ever run on a PC.
Friends don't help friends install M$ junk.
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.
Computers crash (and have any number of other problems) largely
...), and code
because almost all software is still developed using third-generation
("high-level") languages. These languages place on the programmer
the burden of such fiddly details as allocating and freeing memory
and checking the size of allocated memory to see that it's adequate
for the data being copied in.
*Most* of the time when an application crashes seemingly at random,
it's a memory allocation problem of one kind or another: a buffer
that was allocated to small and gets overrun, or a pointer error,
or something of that nature. When an application (or your whole
system) grows more sluggish the longer you leave it running, that's
usually a memory leak: something was allocated and not released
properly -- repeatedly. All of these problems result from a lack
of excruciating vigilence on the part of the programmers when using
a language that requires it. In a large project, maintaining that
ceaseless caution is a nightmarish prospect.
Languages (both interpreted and compiled languages) have been around
for over a decade that handle these things, freeing the programmer
to concentrate on developing the more high-level features of the
software, but because this checking imposes some overhead (in terms
mostly of CPU time and sometimes some memory footprint), they don't
get used for most applications. Yet.
The time is coming, though. The value of VHLLs is beginning to be
recognised, *finally*. When software is written in a language with
built-in memory management, problems like segmentation faults (core
dumps in Unix; in the Windows world these are known as Illegal
Operations, formerly known as General Protection Faults) and buffer
overruns go away entirely.
Add proper garbage collection (not reference counting like Perl5
does, but real gc, which I hope we will get in Perl6), and you
also dispense with memory leaks once and for all.
It's coming. Applications are *beginning* to be developed in this
next generation of languages, but it takes time, because all the
existing apps are mostly C and C++, and you have to throw them out
and start over, which nobody wants to do for obvious reasons.
There will of course always be room for a certain amount of
inherently low-level code written in C or one of its kin: code
that absolutely can't spare a nanosecond per run, code that has
to run on the bare metal (kernels, bootloaders,
needed to bootstrap the VHLL tools (compilers and whatnot). But
when C is no more common than assembly language is today, then
you'll be done with random crashes.
Applications will of course still have bugs -- circumstances
wherein they don't perform as they ought. And you'll still have
hangs, because nobody's figured out how to design a compiler or
interpreter that can detect an infinite loop, and nobody except
Mel[1] has coded up an implementation for completing an infinite
loop and passing on to what follows. Perhaps quantum computing
will one day change this, but that's outside of the forseeable
future. But crashes of the sort where the app suddenly terminates
should be mostly a thing of the past within twenty years, ten if
we're quite lucky.
[1] Google for "The Story of Mel, A Real Programmer".
Cut that out, or I will ship you to Norilsk in a box.
I'm willing to concede that the codebase was considerably smaller. It had to be, in order to produce an executable that would fit in 800K (the size of a 3.5" double-density floppy) and would run reasonably well on a 1-MHz 8-bit processor with as little as 128K of RAM...but I don't find myself doing sufficiently more advanced stuff in Word or Excel than I used to do in AppleWorks (actually, AppleWorks was probably doing more sophisticated stuff with UltraMacros added to it). I would be willing to wager that 95% of Office users use no more than 5-10% of its features. All that extra code that keeps getting added in with every new release means there's that much less time spent making sure the core functionality (and all of the chrome added in previous releases) is bug-free.
(I'll admit that I haven't had much trouble with Office...but then you've noticed that I don't push it particularly hard either.)
20 January 2017: the End of an Error.
...because we aren't willing to wait for, or pay for, software that has been adequately tested to any reasonable level of reliability.
/. articles and Ars Technica articles for weeks if a console game came out that crashed, but when PC games are released that have those kinds of problems, it's hardly news.
With something like Windows XP, no amount of testing could eliminate every conceivable bug, but there is no doubt in my mind that Microsoft, along with almost every other software company in the world, rushes poorly designed, inadequately tested products to market to meet customer demand.
Remember, a product's success is due largely to a check list of features created by the marketing people. A product with 90% reliability and 100 features will sell better than a product with 98% reliability and 10 features. Otherwise, how can you explain the success of Microsoft Office? OK, bad example, MS Office is successful because it's been bundled with so much hardware, but you see my point.
The bottom line is computers are now a commodity. They have become so ubiquitous and cheap that I can go down to the Salvation Army and purchase what would have been considered a supercomputer 10 years ago, for $50. Software is quikly reaching the same state. How much software can you buy for $10 or less? A lot. And not all of it is bad, though most is. On the other hand, you can drop hundreds or thousands of dollars on software that is just as quirky, hard to use and even just as buggy.
Here's the thing that always interested me. Why don't console games crash? I'm sure they do sometimes, but I've got a Dreamcast and about 50 games. I've seen a small bug here and there, but I've never seen the machine blue-screen or whatever DC's do when the OS lunches itself. I realize that the standardized hardware platform has a lot to do with it, but games are every bit as complex as other software, perhaps more so. So why don't these games crash? Well, if they did, they would never sell. I'm sure there would be
Kinda makes me wonder...
You are in a maze of twisty little passages, all alike.
My Win2k box plays games reliably and maintains more than a few months of uptime.
Please refer to this post for more information.
Thank you.
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.
These are true statements:
-In our server room, which, admittedly, is a little crowded, a Windows 95 box was disconnected from the network but accidently left running. It stayed up for more than a year. No load, of course, but it stayed up. It made the hair on my neck stand on end.
-In the same server room, a clone PC running Suse Linux 7.0 ran for just short of two years without a reboot. It would have gone longer had the old, 2 gig hard disk not died a clunking death. Fortunately, the web data was on a different disk. We loaded another system drive and had our departmental web/Samba server up in minutes.
-We have a Compaq Prosignia 200 running NT4 and Raptor 6.0 Firewall. It has seen uptimes exceeding 9 months on more than one occasion. Would have gone longer, I think, were it not for some memory leaks in the Raptor management console snap-in.
I point these things out so as to ask the question: how stable is stable? Hey, *nix has been my passion for years, but I've seen for myself that NT4 and, now, Windows 2000, can perform well if they are set up by someone who knows what s/he is doing. I believe impressive uptimes can be attributed to many things, but I do not always blame the OS code for the bad things that happen.We all know what bad firmware and drivers can do. I'll take NT4 on an Alphaserver over Linux on a Packard-Bell any day.
Of course, Linux on the Alphaserver is better yet . . . . : )
It's only funny until someone gets hurt. Then, it's hilarious.
Debian now has 8,710 applications. There are few things I'd like to do that I can't. I spend much less time "rebuilding" computers and more time doing those things now.
I mean, you can't do much except play back multimedia,
Hmmm, ever heard of film gimp? Sure, there are some hardware problems but those will go away as M$ dies. Hardware makers are already taking free software into account.
there's seldom any games you can play on it.
I'm not a game boy, quake II is good enough for me. More will come, in the mean time dual boot. Woody takes care of that auto-magically now.
I liken it to a rock in the middle of a field. Damned stable, that rock. It just sits there.
Yes that's the picture you drew. Reality is different. Think of it as a tremendous magic building, where everyone is invited to come and do as they please. Building materials are free, and so long as you follow a few basic guidlines, your changes and additions will be as sturdy as any piece and everyone can enjoy it at once.
Friends don't help friends install M$ junk.
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 don't remember having any games screw up my system since I stopped playing half-life. I built a new system a couple months ago and it hasn't crashed once. ;)
I had a win98 system last a bit past 30 days with regular use once and it was terribly hosed by the time I rebooted. Win2k or XP can last until your power goes out, you kick the surge protector, or you need to reboot to install drivers/software/hotfixes
For many megs of answers about why software isn't 100% reliable, read Risks Digest.
There is indeed hardware out there with this level of reliability (like an AT&T 5ESS/Lucent 7R/E phone switch) however it is highly expensive and very unflexable.
I don't mean to bash AT&T. In fact, the very infrequency of this sort of problem is a strong argument for their reliability. I had to go back to the pre-Lucent days for this one, folks. However, they do have some occasional bugs in their software. And it makes the news when they do:
Risks Digest, Volume 9: Issue 69, Tuesday 20 February 1990
The net will not be what we demand, but what we make it. Build it well.
Computer, Heal Thyself
"Systems inevitably fail. The key to reliable computing is building systems that crash gracefully and recover quickly."
One simple rule for its versus it's
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
Actually, "syntax errors" like this DO cause a problem for wetware systems -- they cause the brain (well, mine at least) to kind of glaze over and take the remainder of the sentence/thought much less seriously. Kind of like aborting/returning out of a subroutine.
Here in the Slashdot world of "definately" and "righting", I've learned that any posted comment that makes high-school-level grammatical or spelling errors is not worth my time and I immediately skip the post. I've been doing this quite rigorously lately -- blah blah blah "seperate" PAGE DOWN.
OK now, everybody nod and think I'm talking about someone else's posts ...
One simple rule for its versus it's
A lot of people are answering the question of why there are bugs at all, and it's an important question, but I'd like to take a different angle and consider why there are so many visible bugs. Why does a bug in a driver, or even an application, bring down a whole system? In addition to reducing the incidence of actual bugs, IMO, we should also do a better job of containing the bugs that will inevitably exist even if we all use the latest whiz-bang code analysis tools (which rarely work for kernel code anyway). Some of the semi-informed members of the audience are probably thinking that's the job of the operating system; I'd argue that our entire current notion of operating systems is flawed. There are way too many components in a typical computer system that "trust each other with their lives" in the sense that if one dies all die. Memory protection between user processes is great, but there should be memory protection between kernel entities, and other kinds of protection, as well. One of the basic services that operating systems need to provide going forward is greater fault isolation and graceful instead of catastrophic degradation.
The Recovery Oriented Computing project at Berkeley has gotten some press recently for trying to address this issue. Many here on Slashdot don't seem to "get it" because they've never worked on systems in which a component failure was survivable; they don't realize that rebooting a single component - perhaps even preemptively - is better than having the whole system crash. "Software rot" is a real problem, no matter how hard we try to wish it away. ROC isn't about saying bugs are OK; it's about saying that bugs happen even though they're not OK, and let's do the best we can about that. Another project in the same space, with more of a hardware/security orientation, is Self Securing Devices at CMU. There, the idea is to find ways that parts of a system can work together without having to share each others' fate. While the focus of the work is on security, it shouldn't be hard to see how much of the same technology could be applied to protect a system from outright failure as well as compromise. There are plenty of other projects out there trying to address this problem, but those are two with which I happen to have personal experience.
The key idea in all cases is that current OS design forces us to put all of our eggs in one basket, and that's really not necessary. Designing fault-resilient systems is tough - few know that better than I do - but that's only a reason why we should do it once instead of devising ad-hoc clustering solutions for each specific application. Lots of people use various forms of clustering as a way to achieve fault containment and survive failures, but the solutions tend to be very ad-hoc and application-specific. Do you think Google's solution works for anything but Google, or that a database transaction monitor is useful for anything that's not a database? Fault containment needs to be a fundamental part of the OS, not something we layer on top of it.
Slashdot - News for Herds. Stuff that Splatters.
You are acting like you can actually play a decent game on Linux. HINT: Some freeking penguin on a sled doesn't count as a decent game.
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 have a Microsoft reference driver for my soundcard (i.e. Microsoft made the driver and approved it themselves). I use it on my computer.
Unfortunately, two things cause it to fail.
1) It doesn't play nice with other drivers on the same IRQ.
2) Microsoft's advanced power management driver assigns it to the same IRQ as my USB port and my network card, and that can't be changed without a reinstall of Windows.
So basically, what happens is that the sound card will eventually crap out completely and never work again (until reboot) if it attempts to work at the same time either of the other two devices on that IRQ are working.
Keep in mind:
1) Microsoft knows about this bug
2) It causes system instability for lots of drivers - even certified ones
I should also mention that there is nowhere that this bug is reported by the OS; I had to find it through trial, error, and lots of research. Win2K is not as stable as you think
Mod me down and I will become more powerful than you can possibly imagine!
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.
About your sig: Actually, I currently write games on a machine with about 1.5K of memory and an 895kHz CPU. And I am grateful.
--JoeProgram Intellivision!
Windows 9x actually has a bug in it that would lock the computer after 46 days of uptime, but it took years to catch it because no one ever got close to that mark.
Bullshit, bullshit, bullshit. This urban legend deserved to die years ago.
I ran several Windows95 OSR2 systems with uptimes approaching 90+ days, and had no problems with them locking up. Sure, 9x wasn't HAPPY with this, and if you ran a lot of applications odds are you won't hit this, but I did it many times in my former employment.
When the '45 days' (as I heard it first) rumor started going around, I set up a bunch of idle 95 machines for fun, and on days 45-50 watched for anything going on. Not one crashed.
Hell, for all I know, Microsoft themselves are reporting this, just to cover their asses based on some average uptime limit they worked out, but I will swear on a stack of bibles that I've had Win95 machines go at least twice this supposed limit without locking up.
Endless arguments over trivial contradictions in books written by ignorant savages to explain thunder in the dark.
He dies.
Architects and engineers use extremely detailed drawings. Have you ever taken any drafting courses in Highschool or College? Every piece and even the size of every screw is accurately detailed as possible. It takes forever to get anything done because the precsion is more important. It drives some people like myself crazy.
The blueprint is the actual prototype of the product being designed.
The problem is if you document every step and algorthim in exact detail you will spend weeks, months, and yes years without a single line of code!
This is unacceptable in today's bussiness world where all the projects are due yesterday and your bosses demand percentage wise how much of the code is being developed. If you spend a month planning and not a single line of code is developered your canned.
My father took over a project where a clueless IT manager got because she slept with the CIO. Anyway she went to a seminar which talked about over flowcharting everything would be the wave of the future. She then had all the programers draft every single algorithm to the very if statements themselves on paper. After 4 months and not a single line of code my old man took over. From there he finished the project within 3 weeks!
My point is that drafting programs is too time consuming. In a way your drawing is the program and changes can be made as you go. Its essential to have good flowcharts and notes but they need to be generalized. If there is an error in it you can delete the line and fix it. In engineering you would have to dissamble the actual product and redesign it. Because they would cost time and money it is not accepted. In software that limitation is not there or as sevre.
UML tries to be the blueprint of all software programs but instead is only used to explain certain subsystems and algorithms. Mostly flowcharts are used so all the developers have a sense on how the program will work and how to invoke different pieces of the program.
I do not think this going to change unless there is a quick and easy way to debug UML charts. Logic errors are killer and if its perfect I suppose you can compile the uml directly into the language of choice.
Hmmm infact this might be the way to do it in the future.
http://saveie6.com/
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...
Interesting.
I play RTCW quite a bit on my WinXP box with no issues. RTCW occasionally crashes, and I have to hit CTRL-ALT-DEL to bring up task manager and kill it, but the system remains stable.
When I first built this box I had some issues, after a while it would lock up. Turned out it was because the video card was overheating. The system itself wasn't locking up, just the video card. Put the system in a new Antec SX-835II case with better cooling and haven't had a problem since.
Having spoken with Microsoft OS developers about this issue in some detail, they make risk / benefit choices all the time where they know one way will not crash ever, and the other way will crash but will be amazingly faster.
Guess which way consumers pay them to build it. When they choose the crash-but-fast method, they just put an astounding amount of QA into it to whittle the probability of a crash down to an acceptable level. And I agree with them about what an acceptable level is, because I know that when I crash my Win2k system, it's my fault.
They put more testing and research into their OSes than anyone these days. Maybe Sun used to have them beat there, but Sun isn't nearly as focused on those things anymore.
I would call anything that unnesarily foists a business rule onto the user an error.
" If this can occur, it is the developer who is at fault, not the user."
thank you. I have to combat 'stupid user' mentality at work every day.
from "the user will never do that, so don't worry about it" to "I can't be blamed if the user wont read the manual".
I try not to say it, but it is hell working with coders who got into code 3 years ago for the money. Whining about working 45 hours a week and not understanding things like pointer and user defined types. Normally thats fine, I don't mind mentoring, but when you explain it, to a developer, and there eyes glaze over until you tell them exactly what to write, for the 3rd time that day. I thought it was me, but I even gave the photo copies of very clear explaination, with very simple examples and diagram.
hmmm, sorry about that, I think work is getting to me.
The Kruger Dunning explains most post on
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.
Eliminate the user. That takes care of half of the problems...
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
While the constraints may be cost etc perhaps something I took from a PL/1 book - ;-0 years ago may be relevant.
'The Meaning of Correctness
1. The program contains no syntax errors that can be detected by the compiler.
2. As for 1 and it can be run.
3. There exists a set of test data for which the program will yield the correct answer
4. For a typical ( ie reasonable) set of data the program return the right answer
5. For a deliberately difficult set of data the program returns the right answer.
6. For all sets of data, valid with respect to the specification, the program restuns the right answer
7. For all possible sets of valid test data, and for all likely conditions of erroneous input the program returns a correct ( or at least reasonable) answer.
8. For all possible input the program gives the correct, or reasonable answers.
Most programmers work at level 3 or 4
Users at 8.'
(I am sorry but I have lost the reference to the original book)
In the vast majority of cases, it's simply not economic to release bug-free code.
1. Any programmer knows that 90% of the code is written in the first 90% of the time, and the other 10% of the code is written in the other 90% of the time. (no typo). That is to say, it takes a lot more time, effort, and hence money, to move a project from "working well" to "working perfectly".
2. Many software companies these days make very little profit on the 1.0 release of their software, and make huge amounts of money through ongoing support charges. Microsoft is a classic example of this type of company.
3. If you release a piece of software that works really well, does everything the users want, and never crashes or causes trouble, then you may as well pack up shop and go out of business quietly. The unfortunate truth is that nobody is going to buy version 2 if they can do everything they want with version 1, and they're not getting constantly frustrated by crashes. The only carrot you have in this situation is to think up some really great ideas for version 2 in order to encourage people to upgrade - In fact, some of those ideas may have been deliberately left out of version 1 just so that they could be added later. Version 3 is more difficult still, and version 5 is right out. By comparison - how many versions of office are we up to now ?
A notable except to this business model is the games writers. Companies like valve and id software consistantly produce very near to bug-free code that works well and generally impresses the masses.
In all the years since half-life was released, there have been relatively few patches and fixes, and many of those were to prevent ingenious new methods of cheating, or to add support for hardware that didn't exist when the game was first released. The unreal engine had a similar history.
People buy new games because they crave the excitement or challange of exploring and interacting with it. That's not something that could really be said about excel or word, so those sorts of products have to rely on the "draw out the profit over many releases" strategy described above.
Another (big) factor is people's expectations - most people expect that word will crash from time to time, and given microsoft's past history, they have little reason to expect that to change. On the other hand, gamers have an expectation that the latest game from id software will be as solid as a rock, and that the few problems that do crop up after the release will be fixed quickly.
If a games company didn't spend that "other" 90% on the last 10% of development, and released something that crashed as often as explorer, their reputation would be mud within days, and people would stop buying their games.
And lastly, choice.
People have a choice as to which games they want to buy. It's a competitive market out there, with many people having little disposible income to spend on games. On the other hand, despite what linux advocates (I can't believe I'm saying this on slashdot) say, most people use MS apps and operating systems because they don't have a choice - say due to corporate rules.
You might think that it is the end user that gets the sharp end of the stick here, but the people that really get screwed are the dedicated and talented programmers, who are working for companies that don't care too much if they release code before it has been fully tested.
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!
UNIX had the opposite philosophy. The hardware was expected to work perfectly. This led to situations where a DEC operating system would run reliably on a particular machine for months at a time and UNIX would crash within minutes on the same hardware.
Mea navis aericumbens anguillis abundat
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!
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!
I got fed up with just that sort of thing and changed computing platform. I'm not saying that the Mac never crashes, but it's certainly been a massive, massive step in the right direction.
A quick trip to the terminal reports my uptime as "11:35AM up 57 days, 12:42..." This is by no means a long time by Unix standards, but for a laptop (iBook 600Mhz) that I use everyday, sleeping, waking, starting and stopping multiple programs, working on all sorts of stuff, burning CDs, browsing the net etc, I'd say it was very good.
The longest I could go on my Windows 2000 box before I'd have to reset was about a week - it wouldn't crash, it would just get confused and start swapping icon images over, so Word would have the Excel icon, and so on.
The only time I reboot my iBook is for system updates. Very few programs "Unexpectedly Quit" on me (Camino used to do it occasionally, every 2 weeks or so, but I'm using Safari right now). I've never had a kernel panic in 10.2.x (I had two in 10.1.5, but I traced it to the well known Classic environment and a USB device panic bug that was fixed).
If you want your software to crash less, buy a Mac.
or something like that...
"Empathise with stupidity, and you're halfway to thinking like an idiot." - Iain M. Banks
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.
I agree completely... This is the same kind of thinking that people use to try to outlaw guns... "If someone can use it to commit a crime, we should just eliminate them!".
I would say that poor development, insufficient design, (obviously) insufficient testing and a focus on features rather than security are MUCH more to blame for software quality issues than which language was chosen for the implementation.
I still think we should be able to moderate the whole article as a Troll...
T
---- It puts the lotion on its skin or else it gets the hose again. It does this whenever it's told.
It's interesting how little has really changed in the past 5 years...
Best Slashdot Co
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.
>
Have you ever met a user? They will rip out IDE cables while an OS is being loaded. They're savage, man! They're beasts and there's no proper defense!
Impossible.
How can a "user error" cause a crash. Software should do proper bounds checking and should act appropriately (which may mean giving and error message) no matter what input it is given.
About the only crash due to user error that I can imagine really being due to user error would be the user killing the proicess with killall or pkill or its moral equivalent.
Other than that, its just bad bounds checking and blaming it on user error is really bad form.
Part of the problem IMNSHO is the commodity desktop. There are so many machines and they are all cheap and its more important to get the work done than it is to make sure the crash doens't ever happen again.
On real systems, if the system crashes, crash dumps are sent off to the OS vendor and they track down the problem and fix it. I know, we have had to collect and send off crash dumps in the past.
Each round of that makes the system more stable.
Thats one of the advantages of Linux, and why there are some systems that don't crash (my linux boxes pretty much only crash when the power goes out, and the UPS battery drains). That is, that these OSs like Linuxs and BSD are used in real enviornments and there are people commited to fixing the problems... so even the lowly common desktop user reaps the benefits.
See there is the differnce.. Windows, even the "server" versions grew out of a desktop OS with a desktop way of doing things. "Oh the server crashed, well lets reboot and hope it doesn't happen again", whereas Linux and BSD come from the land of the server down to the desktop "Oh the server cashed? get DEC on the phone" or "Get out those crash dumps".
-Steve
"I opened my eyes, and everything went dark again"
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
I think this brings up a good point. Hardware may have improved, software development tools may have improved, the people writing software have gotten much worse. A few years ago most people who were in the computer industry were there because they knew something. Now they are there because they wanted money, some HR droid picked their CV out of a pile because of the acronyms, and some manager does not know enough to fire them. Layoffs haven't helped either, generally the knowldegable people with higher salaries get booted first. Security vulnerabilities are up (including old stuff that has not been patched) and successful projects are down.
You got me into this! You were the ideologue! I'm only a poor assassin! - Twenty evocations, Bruce Sterling
" A correct program does not allow a user to enter erroneous data." Name me one program that will keep a user from using the CD tray from acting as a coffee holder.
It's x86 hardware, but it's powered through the video card. Looks pretty good at 800x600 too (it's a TFT display).
Unisys 10.5" LCD Monitor w/ 2MB PCI Video Card
It says 2MB video card, but the one I got was a 4MB video card. It happily supports dual displays with Windows 9x and higher, but it doesn't support video playback, so scrap the idea of getting it to watch TV or play movies on. But for what you're describing, a small monitor for a low-power system, I think this would be ideal.
Sadly, they don't have a Linux driver for the required 65550 video card, but there's always Google and the price is right.
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
In mentioning that gaming consoles are the exception to the rule, you're on to the critical factors in the differences.
Here are the key aspects that lead to system instability of PCs (Linux or Windows or whatever):
1. Chaos of hardware vendors.
There are thousands of pieces of compatibile hardware for your PC. No one can test all of the combinations and revisions and their various driver and BIOS versions with all of the other hardware and software. If the hardware came from one vendor, or was standardized (which isn't going to happen), then there could be better quality control on the hardware.
When software and hardware are from the same vendor and go through their joint QA, you get better quality and fewer surprises. It isn't perfect, but it is less chaotic. Sun Solaris and Sun hardware is an example of this, and there are many more in the server/mainframe world.
2. Low level of quality control and durability design in hardware engineering and manufacturing
There are more quality checks in how Heinz ketchup is made (tastes the same all over the world with tomatos grown in very different regions) than in how PC components are made.
As a result there are many more DOA hardware, and hardware that behaves flaky.
This is related to keeping prices for the hardware down. Up to now the performance has increased at such a pace no one is complaining if they have to ditch a 2 GB drive and buy a 100 GB drive, or toss out their 486 for a P-III. Contrast that with my Canon AT-1 camera, which is still working fine since 1976 (two minor physical repairs), and my Yahama stereo amp, which is working great since 1989. If computers (and other cheap electronics such as digital cameras) ever reach the point where we expect them to last for 10 years or more, the quality control and durability of the components will have to increase.
3. Chaos of software vendors
Again, there are thousands of software titles and dozens of operating systems and revision/patch levels. It is impossible to test all permutations together. It is usually impossible to test completely all permutations of software options. I was asked to QA a product which had over 8000 different ways the options dialog box could be configured. Of course it wasn't done. We tested only a single option by itself, and not very many combinations were tried before the server product was shipped. I've seen very specific interactions between software products and their DLLs in Windows. This has been mainly fixed by the way Microsoft Windows XP manages DLLs now, but there are still ways that memory and resource leaks can cause one application to poison another. I've also seen Microsoft intentionally leave a poison bug in Internet Explorer to keep a competitor from taking on a role they had planned for IE in the future. They do these things in a very innocent way.
Overall a very good read, highly recommended.
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.
As someone said before -- no product liability -- you have to pay money just to report a bug ...
Training of Software Engineers. With point and click interfaces you have people with an average reading ability of a 5th grader writing code. Even hinting that someone wasn't a good writer of code was considered "unprofessional" at some workplaces (i.e. -- you are not a 'team player').
Capitalism -- it's not cost effective to fix bugs until a customer finds them.
Even in code for Secure OS's under Common Criteria CAPP/LSPP, vendors aren't required to fix bugs that are not discovered by the independant evaluator or the customer. So even if the product manager knows of bugs in the OS that is intended for 'high security' government projects, there is no law saying he has to list them or fix them (unless they are found by a 3rd party or the customer). Spending time fixing bugs that are NOT found by the customer is not only not cost-effective, it is considered not working on "assigned priorities" and can be grounds for lower reviews.
This isn't pessimism -- it's reality. Quality doesn't pay when you can sell customers faulty products then charge the customers to fix the faulty product you sold them in the first place -- one might argue that it pays to have more bugs in the code -- you can charge more for service contracts and rack up more incidents that you then charge the customer, per incident, to handle.
When I was in college in Computer Science (how many programmers today have a formal degree in Computers, vs. say, a liberal arts degree?), Sophmore year, University of Midwest - CS201 - required for Computer Science majors -- beginning assembly language in Compass (CDC assembler).
The price of perfection is taught early -- an early lesson was when for a final project we were to work with 2-3 other people to make a final program. The deadline was approaching and our program still wasn't running. Turning it in late was a letter grade drop/day. Two of us felt we were close and didn't want to turn in a non-running program. The third wanted to turn it in. They also felt that they'd done their part and there were no problems in it.
The third turned in the project with his name on it. My partner and I spent another day cleaning up his code to get it to work and turned it in. We got a a "C" on the project, with a downgrade for bad coding practice in his section of the code and being a day late. He got a "B" even though it didn't work. In the final grade both he and my partner got "D"s while I got a "C", which sorta sucked for my major -- but it turns out that 60% of the class got "D"s and "E"s. Made a big stink about the course material being too difficult and the teacher made a public 'booboo' comment "It was the same material he'd taught before, it was just an exceptionally dumb class." Major ire of parents.
Anyone who got a "D" or "E" had it stricken from their academic record. It as the only "C" I got in my comp-sci curriculum (str8 A's in 300 level and above classes). But on that project, I learned that deadlines were more important than code quality.
Spin forward 15 years -- at small startup before Xmas. Deadline for demo approaching and I and other team member had parties to go to that evening. He was programming a DSP chip (he was a PhD wizard), and I was handling the drivers on the 286 DOS box. I checked my code backwards and forwards and he swore it couldn't be his stuff. Finally, I displayed output he was sending and it was 'wrong'. Unfortunately, my party had been out of town and I'd already missed the deadline for getting there because it was emphasized to me how important the project was to complete before leaving. When the problem was discovered in his code -- guess what -- he could't stay to fix it (I didn't
know anything about the DSP chip he was using) because, the VP told me, he was married and his wife was gonna leave him if he missed the party (I don't think he was serious, but maybe). I had no such excuse -- only a partner who went to the party alone.
Again -- what do I learn? Personal relationships take presidence over
product and code quality, so far we have code quality below deadlines and below personal relationships (though that has more disappeared in the modern
world).
more later...
-l
The core of the problem was delineated in the book "Weird Ideas That Work: 11 1/2 Practices for Promoting, Managing, and Sustaining Innovation". It it he makes the main point -- that those people who are most creative are the people who don't do things the "normal way". They are the 'loners' -- the 'slow adopters of company culture'. They aren't the team players and they are slow to be programmed with the company way of doing things. As a result, they see problems differently than those that have been trained in the "correct way" to do things.
Those who spend time going to lunch, drinking beer together, palling around together -- they begin to think alike -- they develop synergy -- but they also develop a closed system. The ones who don't pal around come up with the completely off-the-wall ways of doing things because they haven't been indoctrinated into the 'normal way' of doing things. Quite often these ideas are shot down because of their eccentricity. But Steve Job's personal computer idea he presented to HP -- shot down by corportate culture was a brilliant success. He gives countless examples of the most brilliant people generally not being very good with "people skills".
A correllary of this is that those who push for perfection far past the 'norm' are going to be unpopular outsiders -- they are the nit-pickers, the one's who aren't team players. Again, they might be the ones that would nit pick the code to perfection, given the chance, but the larger group says "enough" -- it's "good enough, it boots, let's ship it".
In both instances the people most likely to increase quality in software are those that have the least political clout and are often least liked by their peers. Their peers often feel like the 'nitpicker' has a prideful, superiority complex -- overly prideful and sometimes go out of their way to sabotage work that might otherwise have turned the company around and saved millions.
I specifically was involved in a group who had to choose between 2 vendors of Microsoft compatible software. I became the lone supporter of company B. I was adamantly opposed to "A" for reasons I coudn't articulate at the time -- my gut told me "A" was untrustworthy but I couldn't tell why. I was overruled and 4-5 months into the project "A" sued MS for non-cooperation effectively killing our project. It was too late to go with company "B" who's price had doubled now that they were the only game in town. It turns out "A" had been having trouble with MS all through the negotiations with us, but no one picked up on it. Reminding anyone of the decision made me decidedly unpopular. But it was precisely because I hadn't gone out and been wined and dined by "A" and hadn't formed a "Good 'ol boy" relationship with them that I could see something was amiss. It was precisely the fact that I wasn't a hobbnobber/ polical animal that I caught the 'off' vibes. Those who were "good team employees" went along with the majority decision and the 'friendly team "A" who came onsite to woo us. Its the same principle at work.
Those who make the world work -- are also those most likely to compromise and most likely to compromise quality. It's because of their willingness to compromise that they are liked by many but it's the same compromise that resultes in compromised code -- both in terms of bugs and security.
I sure as heck don't know the answer. Successful combinations are highlighted in the book mentioned above where one person knows the almost anti-personal nature of the 'idea' person, and handles the media and external interactions, but the it's rare to find groups that work well like that.
It has often been said that the best software doesn't come out of committee but out of 1 or a few people -- while companies like to think that 9 women can have a baby in 1 month, it ends up more often that the 9 women argue over who