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?
People write sloppy code that makes them...
Solid!
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
Billy, is it because computers are using too much memmory?
-Bobby, in his parents' basement
...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.
How about backing up your information?
*0;
never follow the null pointer they said... what are they hiding there????
-judging another only defines yourself
Rarely crashes, have yet to see ir crash, a stbale OS is possible just not by M$. MM
Because reliability is inversely proportional to complexity. Systems these days are generally a lot more complex than those of 10 years ago, and in complex systems, bugs are much harder to find. The fact that you say stability hasn't changed is in fact a pretty impressive achievement if you consider how much more complex hardware and software is nowadays.
Worse, as the number of features (and hence the amount of code and number of possible execution paths) increases, the ability of the programmer(s) to completely understand how the code works decreases -- so the chances of bugs being introduced doesn't just rise with each feature, it accelerates.
The moral is: You can have a powerful system, a bug-free system, or an on-time system -- pick any two (at best).
I don't care if it's 90,000 hectares. That lake was not my doing.
Atoms! Look! Atoms are everywhere! They're causing the struction of all we hold dear to us! Atoms are to blame!
-Montgomery Burns
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
What happens when you get hit by a bus?
How often does your 4 function pocket calculator crash? Never? That's probably because they are simple systems. It isn't that hard to figure out.
the overall complexity of computer systems, both hardware, and software, has increased substantially over the years. This complexity increase has been matched by tools (hardware simulation, purify-like memory checkers, etc) so the overall stability rate has remained good.
Windows2000 definitely is more reliable than win3.1.
Freebsd 4.X is definitely more stable than Freebsd 1.x. Progress is being made.
There are a surprising amount of bugs in anything: computer related or not. The industrial design of your car probably has something you'd consider a 'bug'.
Perfection is the brass ring to strive for. Commercial expediency is the balance.
...but humankind has not.
Who equates computer with Windows(tm)
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!
... cars still crash? ... planes still crash? ... etc.
They're run by computers?
Multi-process OSes, and deadlock. No one has figured out a solution that prevents it, so we just hope it doesn't happen.
The null-termination thing is without bounds checking. A simple
strlen[strlen(str)]=0;
is enough to crash a computer. What's more is it takes O(n) time to fins strlen
Vector based strings strlen is O(1), and you get bounds checking and all that.
The other reason is because DLL exports don't match up between versions. They match up enough to get the link done, but a small change of a return value semantics ina function is enough to send most programs into a GPF.
That solution is to do away with libraries, and link to functions only. Rather than have glibc, allow a program to call out to any version of any glibc function in existance.
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
If my Qualcomm 3035 crashes every few months or so of
continuious uptime what makes you think even more complex computers and PDA's would be anybetter.
Entropy is a natural part of exsistance even for elecrtonics. You can try to avoid it, but eventually something will be out of order.
Microsoft 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.
Its all about money, why spend twice as much (or more) money to develop your product when your competitor wont and it will only increase your sales 5% ?
And there is no point bashing C again, yes it may be less forgiving of errors but any tool is only as good as who uses it. Paying more attention to the architecture and design of a program will eliminate 100 times as many bugs as changing the language.
--- No 16-bit support in Vista? Half of our modules still use it! ---
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
nt, dur
But eliminating bugs would take all the fun out of programming!
My HP48gx never crashes. They should make computers out of 48gx material.
The same way they should make an entire airplane out of black box material.
I'm drunk.
You can't access memory directly when in the QBasic environment. That explains why QBasic never crashed. Hell, I say Linux should be rewritten in QBasic, scrap all that crusty ANSI compliant high-performance 32bit code and cross-platform scalable capability.
Shit doesn't happen in QBasic, that's why it's stable. Ignore that QBasic is written in C, use QBasic. And ignore Perl, it's a verry laughable impersonation of QBasic except with more scalability.
14% of all people know that.
--
the strongest word is still the word "free"
30 years of computing and we can't get rid of flamebait? You'd think we would have settled this all by now.
I'm going to have have to take the nutty philosophy card here.
All language is inherantly flawed in trying to express abstract concepts, even in a fairly limited set of concepts, as is true within a given programming language. This inherent flaw just becomes more obvious to you and me when we objectively see a language implemented, as with computers.
Fortunately for us, human brains are to the level where we are --for the most part-- able to filter out flaws. Computers can't do this, thus they crash.
First complexity is an issue. Today's systems are multiple orders of magnitude more complex than those of yesteryear. This by it's very nature causes problems. Also the complexity of today's programs means that large teams are required to get the work done. Every additional team member introduces a new variable into the equation bringing with him (or her) his own set of propensities for certain types of bugs until you have a whole universe of different bug types appearing in your product.
;-).
Second the capitalist market rewards the "just good enough" software. In a pure economic sense stability is not near as important as new features, ease of use, time-to-market, etc. This may horrify engineers and software architects, Lord knows it horrifies me but it's the practical truth of the matter that ROI is largest on systems that are fast to market as long as crashes are completely catastrophic. Also we've solved the problem of crashes in more cost effective ways at the enterprise level. Rather than spending tons of money fixing all the small bugs we advocate backups. As a "backup" they make sense but all to often we use them to cover problems that could/should? be fixed in code. Again the economics say it's cheaper to buy hardware storage than to pay a skilled coder/architect. I don't know if it's "right" or not but at a very practical real-world level economics have to outweight perfect design/production. At least I hope the companies I hold stock in see it that way.
There are many reasons that software sucks but you've nailed 2 of the biggest...complexity and economics. Let's hope the economics one holds...I don't want my rates coming down like the price of RAM any time soon
Shut the fuck up, slashbot.
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.
"As an expert in the field of IT consulting, I think I can shed a little light on the current climate of the open source community" ... "I recommended to the company that we use the newest version of Linux, version 9.0."
I juct checked kernel.org and the lastest kernel version is 2.4.20. Where the hell did you find Linux version 9.0? How can I get a copy? Loser.
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.
-... ---
They're not the same thing.
Bugs are where your software does not do what you expected it to do. They seem to be unavoidable, with complex systems. Only by long-term term exhaustive testing can you increase your confidence that your software is bug-free.
Crashes are where your software catastrophically and unrecoverably fails, to the point where it cannot gracefully recover. Those should be avoidable, with the right tools. There are also crashes caused by unavoidable hardware failures, but that's a different problem.
Correct programming practices do of course reduce crashes (and bugs), but it seems to me a well-designed language could make it impossible to write code that crashes, only code that is incorrect (and occasionally even correct ;-) e.g. Java eliminates pointers from C, since bad pointers are a major cause of crashes. By using only references, you cannot read or overwrite random or out-of-date memory.
I'm hardly an expert on language design, but it seems to me that while bugs may never be completely eliminated, crashes could be.
Why would anyone engrave "Elbereth"?
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....
I love how everyone seems to ignore the fact that huge OSes like windows typically work in conjunction with third-party software.
While a good OS should protect against anything that isn't always possible because occasionally buggy-like behaviour is warranted. For example, you may want a thread to hog cpu time from everything including the gui. [e.g. making a BSP based map or something, want it to finish quickly].
However, that could just as easily be a run-away thread that isn't supposed to run.
And to those that think this is Windows only try writing a 1GB file from memory in linux kernel 2.4.20 [or so]. And watch as the system crawls to a halt as the cache is emptied...
Tom
Someday, I'll have a real sig.
thanks for the laugh, after all of the stress i've under lately, i needed one.
>>Sig under construction
Companies deliver what people will buy.
If automobile braking systems just stopped working as often as Win 98, or 737 ailerons froze as often as my CD ROM driver, or missile silos accidently launched a nuke as often as a PocketPC resets, then billions of dollars would change hands in the lawsuits and people would go to jail.
Get software failures as costly to the manufacturer as the above failures are to their manufacturers, and you will see some changes. Delaying product launch by 6 months won't seem that bad, and investing 2 man-decades in final QA will be seen as reasonable.
Until then, companies (generally) won't invest the money and time into QA -- especially if their competitors are not.
I don't know about the software or hardware being at fault. My computers crash when I throw them off the fifth floor because they blue screened again...
How come Slashdot never gets Slashdotted?
This is so funny, now if only you had a bit of real knowledge you'd rewrite this to be a bit more believable...
Its amusing that there is a mathematical way to prove that a piece of code (or any program) has absolutly no errors. However, it takes exponential time to do. So the code for, ex, msword, would take many many years. (factoring two large prime numbers falls into the same group... which, apparently, means that if you can factor two large prime numbers in reasonable time, then there exists a method to fix in reasonable time) *shrugs*
Nice try Ballmer..
You really need to get your "facts" straight. I won't even mention the numerous areas in which you have absolutely no idea what you're talking about. I find it hard to believe that you worked for a fortune 500 company in such a role as you say. This sounds more like a troll post than a factual insightful explanation of real experience. Nice try, if you came out and said you were paid by Microsoft to say this stuff, I wouldn't be surprised at all.
-> Sometimes, you just gotta break free from the shackles of proprietary code.
You want quality. Which of the other two are you willing to sacrifice?
strlen[strlen(str)]=0;
is enough to crash a computer.
In other words, another good example of why C is not suited to modern interactive application programming.
Speak before you think
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.
Computers crash because they are not designed otherwise.
Why do cars need to be replaced after 5 years? Why are there disposable contact lenses and disposable cameras?
Breakdown is inevitable--only impressive engineering can counter it for appreciable amounts of time and like it or not, most people don't seem to care enough. Also, impressive engineering is very expensive because only a handful of people are actually capable of pulling it off. As a matter of fact, it is far more likely that the by-products of our engineering will far outlive the products of our eengineering (think: NYC grabage dump, spent uranium, etc.)
If you look at a class in most CS degrees called Theory of Computation, you will study a phenomenon called the halting problem...while we have some very good toolsets, we are still faced with the same problem of logic errors....if you think about it, the sorts of bugs that plague us now, are the same sort of logic errors that plagued many of the developers from the time of yore...
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.
linux.
My application server (the most active server in the company (serves ~450 records/second for Goldmine (contact mgmt sw), along with >100MB graphics files, and runs as primary domain controller) has been up 411 days as of today.
Anecdotal evidence, sure, but absolutely true. If you ask me, it speaks volumes.
Our AIX, Solaris and HP-UX development boxes don't really crash very often. These uptimes would be longer but for some power problems.
smokey:/tmp % uptime
6:04pm up 294 days, 4:42, 29 users, load average: 0.79, 0.76, 0.82
# uptime
6:04pm up 219 days, 8:31, 84 users, load average: 0.16, 0.24, 0.29
# uptime
6:05pm up 228 days, 23:44, 156 users, load average: 0.43, 0.34, 0.34
patty:/tmp % uptime
6:06pm up 266 days, 19:27, 3 users, load average: 1.01, 0.83, 0.68
# uptime
6:06pm up 246 days, 1:17, 92 users, load average: 2.09, 2.05, 2.35
maggie:/tmp % uptime
6:06pm up 480 days, 23:14, 28 users, load average: 0.02, 0.02, 0.03
# uptime
6:05pm up 201 day(s), 5:42, 1 user, load average: 0.01, 0.01, 0.01
# uptime
6:07pm up 480 days, 23:54, 27 users, load average: 0.06, 0.11, 0.15
# uptime
6:08pm up 481 days, 16 mins, 13 users, load average: 0.00, 0.00, 0.00
# uptime
6:07pm up 242 days, 6:36, 14 users, load average: 0.01, 0.02, 0.03
rodan:/var/log % uptime
6:07pm up 377 day(s), 4:29, 14 users, load average: 0.02, 0.04, 0.05
I generally don't get into topics like this but it would seem to me that the 'quickest' way to improve software quality is to make any company that sells software liable for the flaws they put in it. If I buy a car and wrap it around a tree no one blames GMH, unless it turns out they were "saving money" by halving the volume of my brake cables that year.
I know it's not a 'geeky' solution, but the bottom line is that in *ANY* field where people don't have to back up their product, then you're going to get people peddling crap and suckers buying it because it is supposedly 'cheaper'. And in the long term, companies will love it because it would reduce the attractiveness of piracy since most medium to large companies would rather pay a bit more for a guarentee than go in blind (and customers would love it because it would actually be useful to purchase a copy of X).
Everyday is a troll-day, bitches.
I've found out over time that the reason computer equipment crashes in general is lack of maintenance. Would you drive a car without changing it's oil for 5 years straight? Then why should a computer be any different. It's much more complex than a toaster, and yet the average toaster doesn't last much longer than a CPU. I think it's time people start treating things as they do with themselves. Take care of it/them.
Sure, theres the occasional hardware malfunction, but of all the malfunctions I've seen at home are either the result of my own damn manipulations (Sorry, can't help to tweak here and there) or that the component's life expectancy had ended. How many years do you think you can run on 66MHz First Gen SD-RAM anyway? I'm not defending faulty hardware manufacturers, but I've RMAed a faulty memory or processor once or twice knowingly that it was *my* fault. I'm getting offtopic here, so in conclusion let's just say that Star Trek like computer systems are far from being tommorow's technology, some people don't even have *1* computer let alone a completely dependant second backup computer!
Trolls dont like to be Flamebait, because they burn so well. Protect our Troll heritage!
Even a simple 'hello world' program can crash for a myriad of reasons, like if the sysadmin removes a shared library, if memory is corrupted, if the process swaps onto a bad disk sector ....
...
I get 'bugs' reported when requirements change, when people move databases around, add network security devices, and so on.
Upgrades. I once had a bug because we upgraded Oracle and there was an incompatibility with the Sun kernel we were using.
I could rant on
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
The ultimate solution to the problem is to let computers write the software themselves.
Coming soon... "Microsoft HAL". This updated version of "Microsoft BOB" writes his own code and decides what's good for you.
Are we using the wrong tools (such as C) which do not provide the facilities necessary to write safe software?
There is NO language that can avoid stupidity.
Shutup, motherfucker.
If your program never crashes, then you will never need to create patches/service packs/etc, which is usually an incentive for people to buy support contracts from you.
Are we using the wrong tools (such as C) which do not provide the facilities necessary to write safe software?
Absolutely. People should write in Modula-3: safe, efficient and productive. But that doesn't impress your average hairy-chested programmer who needs to prove how smart he is. For him, programming was meant to be hard and bugs can't be avoided. Both are untrue. They just feel more secure in concrete representations rather than constrained abstract models. They'd rather have control than efficiency becuase they have a psychological need for (total) control.
Most programmers are pathetic, inadequate human beings really.
Reliable, Great Value Hosting: $7.95/mo 2.4G/120G
Of course, there's no need to mention Microsoft's inability to create a stable system.
Sure, this would have made sense 5 years ago. Why didn't you just go for the gold and conclude with "Why can't everything be as rock solid as Linux?"
Grits in the morning, Portman at night.
We don't need no steenking crashes!
WHoops thousld be ..=1;
(Anything BUT 0)
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
I'd bet it would get modded down as a troll. :)
Bugs (that cause crashes, etc.), actually...are cool .
Oh, and users are 'Luddites'. So, it's the loose nut behind the wheel, not the CPU or the software that is the root cause, after all.
Massive complexity (even for simple apps) + enless possibilities of user interactions + rush to market + no sliver bullet = likelyhood of crashing
I work as a QA Specialist, and am appalled at the state of software that I see out in the wild. Either there is no testing, not enough testing, or those testing are simply doing an insuffiecient job. I suspect a bit of all three. Testing helps a ton in catching those mistakes that are inevitable.
a subsystem making sure the main system can't crash (such as the sandbox architechure of java) requires so much overhead that we would be going back a lot in terms of computing power.
and god forbid the subsystem has a few errors, or the entire forfeit of speed for reliability was for naught.
just don't install bonzi buddy and your shit will be fine.
MARIJUANA, SHROOMS, X: ONLINE?! - E
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.
There will never be a computer that will never crash. As systems get more complex, the possibility for crashes increase. There are just too many things that can go wrong.
Bill Gates: 'My computer crashes too' December7, 2001
Most computers are like that, yet some still have to be restarted every day and "rebuilt" every month. Go figure, my computers go down when I want to change hardware, take them to a friend's, or the power goes out. They never crash, despite the worst efforts of some mail clients to add nasty stuff to mail I get. Debian stable is stable.
Friends don't help friends install M$ junk.
Shut the hell up, you dirty homosexual slashbot.
Computers are fundamentally flawed, as with most mathematically modelled systems.
Godel's Incompleteness Theorem (yawn, I know) shows us that no mathematical system can be complete or provable if it has the ability to self-reflect - i.e. can describe aspects of itself or abstractions of other systems within itself.
The fundamental flaw in computer software is that we stupidly assume that our programming languages are complete, provable and are running on an idealised machine capable of reliably repeating instructions ad infinitum.
Computer software is merely a final layer of abstraction on top of a teetering tower of already leaky abstractions. We cannot possibly expect software to run reliably when we do not understand how an abstraction at one level affects an abstraction at another level.
E.g., Silicon designers make decisions that impact on application programmers. A CPU speed stepdown to conserve energy on a mobile PC could cause a time-critical event to be delayed, causing a program to fail. The programmer has no knowledge that this is the root cause, as he/she only thinks at the level of the programming language and assumes (has to assume for sanity's sake) that the language is running on an idealised computer.
How do you check for bugs when you cannot even identify a problem as being within the domain of the abstracted layer with which you are dealing?
This path leads to fudges, fixes and kludges.
That is why our software doesn't do what it says on the label. And the bigger it gets, the harder it falls.
Current finite-state automata based computing is fundamentally doomed. It is time for more radical approaches to how we abstract and map real world problems on to machine hardware.
Q-bits anybody?
Norton has a little program called CrashGuard for Windows which supposedly can detect crashes, and somehow "recover" the program, at least enough so you can do a "Save As..." of what you're working on. Does anyone know how it works technically?
Perhaps by somehow taking "snapshots" of program state in memory, and then "rolling back" when a crash is detected? (It's the only way I can think of without having application-specific knowledge about internal data structures, etc.)
There's 10 types of people in this world, those who understand binary and those who don't.
I think that's related to capitalism. We're not working to make stable hardware that never needs to be replaced. We're working to make money and provide consumers a product they can purchase over and over again. Products and simply widgets. And if your widget is broke then we recommend you buy a replacement.
:)
We know that its possible to design an OS, for example, that can update itself by downloading all patches over the net. XP has a similar feature. But do you think it would ever be in Microsoft's interest to give you an OS that would continually update itself over the net without requiring some form of payment?
I just upgraded my linux kernel among other things using apt-get. But the only reason I can do that on Linux is because Linux developers often care less about money than they do their own products.
But this is all my opinion. So please ignore everything I just said. Its not important. Be happy.
Hi,
:).
This is very much a mathematical problem. There are actually systems that prove that a system does what it should do. These are even being build into automated systems nowadays.
Unfortunately not every mathematical proposition can be proved. It also takes a lot of time to do the actual proving. And last but not least: if the end state is wrong (human error again, for instan ce), you still have a problem. You might even break working code
Another problem is that the computer does not know what the developer wants it to do. So if it is programmed to do something wrong, it can never tell that it's wrong.
The imperfect solutions are to use the latest techniques (e.g. process based rights), to create a good design first, to not forget a good security design within that design (IE anyone?), and not to focus on performance before good programming practices (like, use bounds checking, buffer overrun anyone?).
Warper.
Pointers are as bad as the goto statement...
unforseen uses. hardware problems.
While it seems least likely for most computers, PDAs are a differnt matter. It is not at all unusual for a PDA to be being used in situations the developers and designers do not expect. This may include dusty, hot, or cold environments, or operating at less than optimal battery power levels.
Unforseen uses does not simply mean use in the harsher situations noted above, it also applies to software libraries. Array manipulation works fine as long as the array being manipulated is what the library was designed and tested for. If the address book was tested with a couple of hundred addresses, it may not perform as expected with a couple of thousand entries.
This also applies to interaction between applications. It would be great if my GPS would work with my address book, telling me either how far the address of interest is away from me, etc. The word processor or notepad app should allow me to pull down a list of addresses from the address book and insert those fields that I want (e-mail, url, street address, phone number, etc.) likewise for to-do lists, spreadsheets, etc. However if the feature isn't tested, it will all too often perform in an unexpected manner, including crashing.
Also there are some features of the OS that get used more often in palmtops than in desktops. PDAs are much more likely to be in and out of "sleep" mode several times a day. Most desktops are turned on and stay that way all day, and are less likely to be put into sleep mode interactively.
Those are just my observations.
-Rusty
You never know...
... 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.
That's the reason software sucks. You bought it, right? Sharp got their money so to them their software is 100% on the mark. Could things be better? Oh hell yes! But they don't "need" to be better because the industry is making money off their shoddy software now. It's good enough for 90% of all purposes though so it's marketable.
I'm not surprised really -- can you name ONE single market that's widely adopted where people demand the utmost of quality all the time? I can't think of one single thing I purchase that's "high end" because not doing so would be insane.
Less than perfect cars? That's the norm, though they are getting better over time. The cost/benefit ratio though of buying an Audi vs. a Ford just doesn't justify that extra cost (assuming you agree that Audi makes nice quality cars -- I'm working for Germans so I'm biased and I drive a VW).
Lets drop the price way down: fast food. We don't really buy it because it's the best out there. It's cheap, it's quick, and it fills the job. You want a nice home-made Gyro made fast? It'll cost ya. Some will pay, most won't. It's a niche market.
Heck... beer is the same way, at least in the US and Canada. I'd say around 90% of "beer" drinkers in my area wouldn't know a good porter if it jumped down their throat. They could grab a 12 pack of good porter for 16 bucks or a 24 pack of rice water for 20... they go with rice water. Reason: value per dollar.
Is Cherry Coke the best damned cherry flavored cola in your town? I'd wager it isn't, as long as you live in a decent sized town. Yet, we still all buy it.
Business shoots for the lowest common demoniator. If you can't live with it, well, make yourself a business that caters to people that really want the best. Once your name picks up though you'll have to start mass-producing things at sub standard quality to make a really good profit margin -- unless you gouge your customers.
Do I dislike it? Yes... of course, especially when it comes to technology as that's 'my thing' and I know it can be done better. Somebody running up to me with a spiffy new Zaurus that crashes is like driving up to your mechanic buddy and beaming about the brand new Kia you just bought. "Hey -- it's got cool cup holders!". Oh brother.
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.
He's talking a lot of sense. Wish i had mod points today
Last.fm - join the social music revolution
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
"if a program has n 'parts' and each part has "probability of correctness" c, then the probability that the while program whill work is c^n" so (am I reading this right) while a program may be large, once decomposed into its basic parts, you can show prob. of correctness of each part, thus allowing you to work out the correctness of the whole? And if you can decomposed each, can't you make each the probability of correctness 1? (completly correct?) Again, I'm arguing that its not possible in a realistic time frame.
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
Right off the bat, my first response is "feature bloat." Might not be the most accurate response, but I'm a knee-jerk reactionary anyway, so gut feelings are uber. Anyway, take a word processor, for example. Not much going on there, when it gets right down to it. Besides the actual processing code, there's the thesaurus, grammer and spell checker--and an absolute avalance of features. It got this way because it's new features that get people to upgrade (and the occasional semi-FUD about how even a word processor might have potentially fatal security exploits that can only be fixed by--surprise--paying full price for the next version). So, in short, feature bloat means cramming new code on top of old, which creates a lot of problems. Second: Feature evolution. First-gen hardware has its share of failures and serious glitches. From the GeForceFX 5800 Ultra Wind Tunnel of Doom on down to early hard drive cables. As a new feature is introduced, problems will crop up as the product is distributed into computers containing a wide and wild variety of parts. Conflicts are bound to emerge, because no PC product can approach the streamlined QA you'll find with, say, a console game or an SGI box. Third: Feature creation. Creating software isn't just a matter of honing previous code. Every time you add new code, you create potential problems and conflicts.
I find Windows XP to be quite stable, I find in the year or so that I have been using it I havn't had a non hardware related system crash. Overall I would say my XP system is quite the example of stability.
Any coder here will know that weird little feeling inside when a shortcut has to be made to make deadline. A comment in the code, or a note in the documentation to come back to it later. You know the assumptions you made. You can hope the situation won't come up, but you know that it will.
http://pcblues.com - Digits and Wood
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.
In the process you have also probably generated a segmentation fault. Hmmm. Nirvana in a core dump...
Of course it the application is the inittab it is still subject to the endless cycle of crash an restart.
"Learning is not compulsory... neither is survival."
--Dr.W.Edwards Deming
mistakes are made when people rush and don't think things through correctly. this is a problem with microsoft, and most other companies, who are trying to be the first to get their products out before other companies. in the case of microsoft, they have next to no competition for windows compatibility (right now) and can rush as they see fit. "getting products out quickly makes the users happy they think. and it puts more money in my pockets" --Bill Gates (thought, not a quote)
I write code.
"Programming" some "web pages."
Anyone with a little rigor can write software that performs as expected and only crashes on hardware anomalies. It's just discipline and structure. I've been developing 15 years and I would say that in that time I've worked with less than a half-dozen developers who understood what they were doing, people who could tell you *why* to write a certain way, the advantages and disadvantages. The others just go through the motions and justify stupid habits like mid-function returns with lame excuses like "I've always done it this way."
Want to be taken seriously? Then don't write like a sixth-grader.
As asked by a taxi driver who has never seen snow before: "Do want to get to the airport FAST or SAFE?"
--jeff++
ipv6 is my vpn
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
say "cosmic rays" or "quantum anomolies".
Slashdot Journal on Monopoly News
While it is true that there are languages that don't allow you to directly access memory, banning those can do wouldn't of much help really. Like most problems, computer crashes are usually because of human error. Hardware based crashed are caused by someone involved with the original design, manufacture or assembly of the hardware. Software based crashes are the most common and are caused by sloppy programming or incomplete desing/testing phases. The language you use can affect the amount of freedom the programmer has but if the programmer is good and is given adequate time to throughly test and debug then it really shouldn't matter that much. There's the rub. Management usually wants software produced within a specific time frame because time is money. Not every programmer is at the top of their game. Most are average programmer's at best. It's just another typical case of asking too much for too little.
Slashbot, fuck off.
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.
what about microsoft causing crashes? i knoew everyone else here hates them, but i cant remember the last time my windows 2000 machine crashed... i dont know that it ever has o_0 ... all you have to do is keep track of what programs crash your computer and never run them again or figure out why they crashed...
the problem is most people just dont know what they are doing or dont care...
Software and hardware companies are always trying to make their systems do something that the previous version could not do. In Windows XP versus Windows 2000 for example, Microsoft adds hundreds of features (many have to do with multimedia) to try and convince the end user to sell their product. A majority of home users know that computers are not perfect but want those bells and whistles that they didn't have before.
what would we have to do, both in our software and in our operating systems, to make this come to pass?
Reboot one more time for the change(s) to take effect?Removing bugs from software is like removing bugs from anything else - the effort expended gives you diminishing returns. 100% effort removes 50% of the bugs, 200% will remove 75%, and so on.
Cars still break down. They are generally a lot more reliable than they used to be, but new models still tend to have problems. It's the same with software. The more mature software breaks down a lot less often per clock cycle than it used to. Newer software is more likely to have bugs in it - probably the same number as in the old days. It's just that the number of clocks per second has exploded and the code is being run many many times more than before.
Order is approximate, but more bugs should be found at the start of this list, less towards the end - becoming more and more subtle to track down:
(1) Programmer taking due care.
(2) Programmer being given adequate time.
(3) Programmer experience.
(4) Stepping through all code paths.
(5) Paired (or "extreme") programming.
(6) Group code reviews.
(7) Ample QA testing & bug fixing in a feedback loop.
(8) Public beta tester bug reports.
(9) End-user bug reports.
Not all software developers are that rigorous, although a few are more strict. Until some basic standards are applied to all software, the proportion of bugs in software will be reduced.
I do believe this is a well-known troll. Mod accordingly.
Software is unstable because it is designed with the wrong things in mind.
If you are doing some plumbing and what you think you are doing is running water from point A to point B you are in deep trouble. What you are actually doing is keeping water out of the rest of the room.
A computer doesn't need our code to run; it will happily execute what ever random garbage is on its data lines. What you are actually doing when you program is controlling all the things you don't want the computer to do. Until we realize that by far the most important thing in software is preventing code leakage software will continue to be an unstable mess.
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"
Computers are deterministic systems in a non-deterministic world. This makes only simple, well-understood problems approachable by computers in a 100% reliable manner. As complexity goes up linearly, the level of effort increases exponentially. This will always be the case until something revolutionary changes. Give it another 30 years.
% cat strcrash.c
#include
int main()
{
char *str = "fucking slashbot";
strlen[strlen(str)] = 0;
return 0;
}
%export PS1=%#
%export PS1="%# "
% cat strcrash.c
#include
int main()
{
char *str = "fucking slashbot";
strlen[strlen(str)] = 0;
return 0;
}
% make strcrash
gcc strcrash.c -o strcrash
strcrash.c: In function `main':
strcrash.c:6: subscripted value is neither array nor pointer
make: *** [strcrash] Error 1
%
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.
The software/system -buying public has been conditioned that the proper response to buggy software is to wait for and often pay for a new 'upgraded' version.
Speaking as something of a software/Internet industry veterann, given the habits that we've instilled in our customers, it's no surprise that we now feel it's apporpriate to focus on time-to-market as the most important criteria for new software.
-Mark
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.
There is no accountability in the software industry. As soon as software companies are forced to take some responsibility for the code they write, they will write stronger code. Unfortunatly this will also raise the cost of software development even more, along with the barrier to entry.
I'm tired of hearing this. There is nothing unsafe about C. There are only unsafe API's available for you to use. If you're dumb enough to use them and then give the world access to your software, you deserve to be beaten senseless with a dead salmon. It's ignorance and laziness that causes unsafe code, not language X. Let's not forget that most of those 'safe' languages out there are implemente in C. Of course, that doesn't make C the right language for any given project, but the old 'C is unsafe' chant is nothing more than a poor excuse. If you can't use it properly, don't use it.It's not that people are lazy or inherently faulty. A team of moderately skilled individuals can build some incredibly sophisticated equipment that they don't know anything else about, and do it without bugs as long as they verify their requirements are good, that their design flows down from the requirements, and that the code implements the design (and nothing but the design), and that you have tests to prove that the code works. This is standard practice in any industry that makes life critical software. It doesn't take geniuses. Just the Will to do so, and the time/effort/money to apply to its implementation.
I don't have much to add other than to say that I have worked with computers for over 30 years also and the statement that hardware hasn't gotten much better is completely counter to my experiences.
"Of course, there's no need to mention Microsoft's inability to create a stable system."
;]
I guess i've heard this demonization of windows too much lately.. guess i have to respond this time.. the two whisky's help
I'm presently working at a print house where i operate a xerox docucolor and a docutech.. The docutech is operated by a sun running solaris and the docucolor is operated by a dual 700 running nt4. That solaris flakes out so damn easy.. I have to reboot it at least once a week.. and then there was that time that it totally crashed when all i was doing was adding icons to the control panel.. The nt4 machine has only needed rebooting every few weeks for very specific reasons like a power outage and the power supply going bad. And I'm not even touching on the ease of use and breadth of use issue, which the nt4 machine would win hands down of course..
so.. allow me to take a deep breath. I got it out of my system.. time to move on with life.
btw.. trash bill gates all you want (i do).. but if you're gonna trash windows, be specific about which windows version and be relative.
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
But, are there supposed to be lightnings in my power supply?
char *j;
//snip
char i[15];
for(int x=0;x<51;x++){
i[x]=j++;
}
cd /usr/local/src/kernel-sources/linux-2.5.69
make mrproper
make allyesconfig
make -j
Tim
I'm shocked when an application dies. I've never had an OS crash since moving to Debian two years ago. I never turn my computers off. They just work and everything should be like that.
Friends don't help friends install M$ junk.
I know not everyone has time to read all the comments so I'll summarize the comments:
* Microsoft sux0rz. They're software has lots of bugs 'cause they're not 1337.
* My system has been up for the last century running FreeBSD.
* M$ Sucks.
* All Software has bugs.
* Open source software has less bugs.
* First post!
-- Political fascism requires a Fuhrer.
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.
:-)
Sorry, I meant to write "If you don't want to encounter unexpected values...". Of course, I think it's clear what I meant to say, clarification never hurts.
Join Tor today!
"That assumes computer science is a functional engineering discipline. Its not, at best we are at the alchemy stage of progression. You put two things together it goes bang and you try to work out why." Alan Cox
Humans make very reliable aircraft carriers, jumbo jets, satellites, and mobile phones. I think this alone is sufficient evidence that the reason for buggy software is NOT any of the following reasons: tight deadlines, code complexity, industry immaturity, developer team organization, size of state machines, lack of time, customer impatience, or feature bloat. I think the problem is much deeper, viz.: the goals of the people who MAKE the software are not the same as the goals of the people who USE the software. Software developers have no INCENTIVE to make good software. In fact, the opposite is true. For example, if you look at the information systems in hospitals, you'll find that they are invariably awful; this is because the people who write and main those systems are paid based on their ability to minimize hospital expenditures, rather than paid based on their ability to maximize quality of medical care. Low-quality software is cheap to produce, provides recurrent income by forcing customers to upgrade in the future, and is usually just endurable enough to be usable (i.e. the bar is lower for software than it is for a jumbo jet or a mobile phone). The software developers therefore benefit by selling buggy software, simply because their goals differ radically from those of their customers.
What kind of asinine question is this? When it crashes you always blame the software. Could it be a powerspike that screwed around a few bytes in ram? Could it be bad hardware sure... but when it a glitch happens it is always blamed on the software.
Another reason software is more buggy than hardware is that hardware is an improvement on the next version not a whole new idea. How long has SCSI been around? How long has most end user software technologies been around?
And finally what are the limits of fault tolerance in software vs hardware. In physical engineering you are allowed a certain range of fault tolerance. In software it works 100% or it doesn't work at all. If there is a bug in the hardware that is discovered after production... it's up to the software to account and correct for it. THINK.
"Times may change, but standards must remain the same." - George Carlin.
Bashing MS for stability out-of-hand just paints you as an ignorant boob. Are they as stable as Linux and other Unices...no definitely not. But to say that they are unable to create a stable product is ridiculous. My home MS machines have excellent reliability, and places I have worked have also seen servers as old as NT 4 stay up for months.
Don't think I'm the MS evangalist here, I have as many problems with them and their insane methodologies as most people here. But implying that nothing has changed in the Microsoft stability world since 3.11 or that they do not make OSes stable enough for production use is just assinine.
Its at least getting better in terms of desktops and servers.
Windows2k is supprisingly stable as well as relatively bugfree. Maybe not as much as FreeBSD or any other Unix but it sure as hell better then Windows3.1, windows95, and even NT 4. XP is alittle flakey with certain things but quite good.
Infact I have only seen the blue screen on w2k once! This was due to a buggy sblive driver. If you play gxdoom or any program that play midi files you will notice creaks in the sound and if unrebooted will evenutally crash your w2k box.
I also remember shitloads of bugs in Windows. Do any of you remember Windows95/98, and office95 doing strange and bizaare things? Well I have not seen them at all in Windows2k.
I am not a pro ms troll here but I am just saying the situation is better. Also lets look at Unix.
If any of you read the Unix haters manual they will mention unix as a flaky, unreliable and unstable os full that is cryptic and impossible to adminster. They critize the UFS quite heavily. This was written in the late 80's and early 90's.
From what I read about Unix history is that during the early 80's, Berkely Unix had terrible memory holes, the original tcp/ip stack was not good, and it had to be rebooted every few days and the vm was flakey.
Today the situation has improved by leaps and bounds. Unix is very stable. BSD leads the others in terms of reliablity. But this came out a price from education about software reliability.
With UFS2, most assembly code being moved out of userspace, hot swapable hardware support, volume managment with raid support, as well as more mature versions of the BSD tcp/ip stack, and vm code, Free/Open/Net bsd is one of the world's most stable operating systems. Also most bad versions of Unix cough SCO cough have vanished. These versions of unix had no memory protection so they could run on early hardware like 8086 and 286 chips.
Infact have your computers in your car ever crashed? They are quite stable and have been for years.
Most computers today from micro-controllers to Mainframes are quite stable.
http://saveie6.com/
That's extremely useful, because it might have taken one of us two hours to pin-point this problem. But not more. I'd think that these tools can save you maybe 5% or 10% of the time you need to spend debugging. (And this is a lot, since debugging takes so much time.)
But the important is still good testing. Think of obscure ways to test your function just after you have written it. Think whether you have tested all code paths that you added. Think about corner cases causing unexpected interactions with other code.
It's as easy as that, and as hard as that.
With most software, most crashes are, at worst, merely frustrating. A crash in your car's ECU might cause it to spew out black smoke, but it will still run. A crash in the ABS firmware on the other hand...
With software like that, you pay extra for bug-free, and you should expect to get that. But for most of us, if my word processor goes kablooey, my girlfriend and I won't end up as a messy blood splotch on baked asphalt.
This allowance for bugginess is perfectly reasonable in almost all circumstances. ABS brake controllers and other similar "someone's life or livelihood is on the line" products are obviously exceptions. So although the industry may have conditioned people to expect a bit of bugginess, before the expectation came about there was a bit of common-sense weighing of priorities, and perfect software stability is all the way up there with, well, figuring out if my dress socks are black or navy blue in weak lighting...
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!
No way. My MCSE at the office told me he is using Linux 9.0.
http://saveie6.com/
Thats one of the primary reasons nVidia dominates ATI. Hardware wise ATI gets ahead once in a while, but their drivers might as well be copied and pasted out of a slashdot discussion thread.
give this guy some credit moderators--real good post
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.
they want quick and sloppy instead of slow and reliable code. It is the "Fast Food" mindset that creates unreliable software. Managers don't want programmers to take their time and do it right, they want results as fast as possible. So programmers don't get the chance to make sure that memory used is unallocated once unsed and they forgot to close out recordsets and files once they are finished with them.
I was let go from my past two jobs because I wasn't quick enough. But my programs ran reliably, and didn't have as many Help Desk calls.
What the managers want is "Good Enough" code, as in good enough to work and do what they want. They don't care if it crashes the system several times a day or more, as long as they can ship it to the customer.
Remember, Slashdot does not have a -1 disagree moderation, and no, troll, flamebait, and overrated are not substitutes.
they're not gamers at least not at school and neither are you presumably
tell me when your windows box reliably plays games and maintains more than a few days at best of uptime
try pushing hte machines.. word processing doesn't hurt anything, hell windows 95A could probably last 30 days if all it had on it was notepad open
I read through most of the replies, and skimmed through the rest...none seemed to touched on the subject that the companies that sell the software (haven't really payed attention to hardware) immideately release themselves from any harm their software causes. They state that they are not liable for any data loss, etc. in result of use of their software. It really ticks me off that it is so easy for them to do that. I would like to be able to have the DMV accept a terms and agreement stating since they granted me the drivers lisence I (the driver) can not be held responsible if I crash [waiting for soembdy to show how this analogy is not so good]. I would imagine if software companies could be held liable they would clean up their code a bit more, make it less likely to crash, etc....Afterall they're making money from this. I could understand programs released under GNU GPL to have "as is" notices. It's free! :)
At the other end...people do crazy stuff with computers and applications they run on them. It's tough to account for every single little point-and-click a user can possibly think of.
I would also agree with AvengerXP's statement: I've found out over time that the reason computer equipment crashes in general is lack of maintenance. Would you drive a car without changing it's oil for 5 years straight? Then why should a computer be any different. It's much more complex than a toaster, and yet the average toaster doesn't last much longer than a CPU. I think it's time people start treating things as they do with themselves. Take care of it/them.
I've come across many computers that don't have the most recent drivers or software upates a ka-jillion programs (and spyware) installed, no anti-virus app. (or if so, waaaaaayyyyyy out of date), yet the woner wonders why their computer is so sluggish. They just dont seem to maintain them at all.
How about to a stack overflow?
If your using RedHat 9 you will not have proper mod-perl for apache out of the box.
This is because rh decided to install apache 2.x as standard without even the old apache 1.3x daemon. It also comes with Perl 5.8. Many perl programs will not work with perl 5.8 or will run unproperly.
This was really stupidon RH's part. This makes it useless for its own hardcore market which is webservers. I feel ripped off by it. At least Suse provides both versions of apache.
I also do not think you are serious since mod-perl with apache2 will probably not even work unless you downloaded an alpha version. I now use FreeBSD for this reason since it comes with more conservative package versions and with the ports so I can upgrade the packages I want without rpm hell.
Also what kind of person writes kernel level code with ASP or Vb? I do not think its possible. With Basic you can peak and poke and insert assembly but I do not think you can do that with VB.
http://saveie6.com/
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.
Has there been a study, or some site that tracks a certain group of computers of varies systems/OSes and their crash counts/types?
My 2000 machine at my work has more problems with power spikes than it does crashing, and my XP at home has only crashed due to a driver failure on a 5-in-1 flash card reader.
That's just those 2 systems of course, I've had nasty crashes on many other windows systems and NT 4 was nasty too.
I've worked with several embedded systems and find such systems as LynxOS fairly reliable also, however I've not been in the field so much with it as continued development testing.
Are these crashes design based, or framework based? Give a weird problem, and some Linux/Unix based systems will simply die due to file corruption repeatedly. Windows will crash from internals a lot, and stuff like driver plugins(depends which flavor) which should be caught more, but can recover decently on basic crashes(xp more it seems).
Just a thought if these kinds of stats are anywhere.
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.
This message has no text. This page intentionally left blank. This sentence no verb. :)
Heh. Develop a way to write requirements for software easily and in a way understandable to both humans and computers. I'd give you a medal for that.
From my experience, broken requirements are often the reason for poor project quality. And management doesn't seem to get that.
Writing the goal function for genetic algorithms would be the second task, and also in the problem complexity I call 'impossible to solve'.
--Coder
We have 1,000,000 bugs in this program. From those, we do a statistical modelling to rank them based on their severity and frequency. As you might have guessed, we have only enough time to fix about 1,000 of those before release. The rest remain to our faith that chances are, these bugs won't appear to anyone, or if they do, it will only be a 1:1000000 case. That's why the bugs remain, that's why we all get crashes, yet not always the same.
You may have the single most unreliable Mac OS X box I can imagine hearing of. Seriously, I've got an iBook with 2 kernel panics over 26 months, a dozen cubes and Bondi iMacs with month-long uptimes. And that's with a hundred kids roaming all over them on a daily basis in some sort of quest to break anything they can imagine. Apps (and 99% just the beta ones) may quit unexpectedly, the non-beta ones are typically 3rd party conflicts - but no system crashes.
Something needs attention, but it's prolly not Apple's QC in your particular case. Now, if your "OS X box" is an unsupported, g3 conversion with all sorts of third party stuff crammed into it, then you're on your own - Apple prides itself on end-to-end integration and this goes a long way to create OSX's new reputation for robustness.
In fact, OSX shipped on an Apple system is the first mainstream setup I would label "robust" (in the engineering sense as inspired by Rev. Woody Flowers' diatribes from my FIRST days)
"Win treats sysadmins better than users. Mac treats users better than sysadmins. Linux treats everyone like sysadmins."
> my Psion 3a has never crashed despite being switched on and in use for over five years
Heh, reminds me of this story, which never surprised me in the least after having worked for a university.
Thanks for thinking of me.
Well, first off I would like to say that they are features!
Second, I would also like to point out that we sell products that we think they will sell. All these things you see that you called bugs are really features and if you know what they hell you were doing you would not have them!
http://saveie6.com/
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.
Go Nets!
...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.
Honestly, we all owe MS a huge debt. What would we have to bitch about if computers didn't crash. Worse, the computer dweebs might grow up, get lives and gasp find girlfriends, thereby exerting demand pressure on a commodity more already valuable than DRAM. So I say, bring on the bugs!!
It's not just software complexity that causes crashes, it's *real-mode* complexity.
It's an unpleasant fact that real-mode (unmapped) code runs faster than protected-mode code. Therefore, to get that extra speed for their application, designers try to move as much code into real-mode, kernel mode, or whatever the particular OS calls it. Result is that the errors that sneak in are errors that can crash the OS, rather than just crash the application. To make it even worse, real-mode bugs tend to be things like race conditions that are monsters to debug.
Solution -- don't use real-mode code unless you're actually stuffing bits into device registers. Ideally, you can get your whole kernel (technically, a microkernel or exokernel) small enough to use formal verification techniques.
This will happen in the Windows, Linux, and BSD worlds sometime after hell freezes over. It is, however, common practice in the embedded computing industry, and has been for some time.
Application crashes? Assuming it's not just sloppy programming (all too common, alas!), usually it's an undocumented initialization problem somewhere down deep inside a library (MFC is notorious for this).
Welcome to the Turing Tarpit, where everything is possible but nothing interesting is easy.
ziggy ... .... ....
the Matrix has you
follow the penguin
knock knock ...
Friends don't help friends install M$ junk.
Signed,
The guy that reboots the windows server.
Now, things have changed. It's a huge job making sure something is reasonably bug free, and a failure can be very costly indeed. The problem is that most of the computing models we're using are fragile. C, C++, Windows, UNIX, MacOS, some are better than others, but they're all fragile and brittle. It's so easy to step on your toes, it's no wonder we have all these problems. But the cost of rebuilding everything with reliability in mind is huge, and no one is willing to do it. It's too big a project for most academics or free software hackers, and no major company is willing to spend the money on the project, instead focusing on the short-run prospects of getting the application out the door.
And yes,I am that numbnuts some days.
"Learning is not compulsory... neither is survival."
--Dr.W.Edwards Deming
...why don't they boot up within 30 seconds? It's the same thing as having cars in the 60's that still need someone to turn a crank in front to get them going. Totally ridiculous...
But I've been using my w2k box and previously my win95 box and previously my dos 1.1 -> dos 6.2 box to play games and the w2k box *never* crashes. The win95 box sometimes crashed. The dos boxes only crashed if the game hung the whole system, because hey, dos is only a program launcher anyway. Sigh... I miss dos....
Anyway....
The linux boxes at work? They crash with kernel panics.
The sun boxes? They crash with ecache errors.
From w2k onwards, MS has made a pretty solid OS comparable to any of the common *nix's available for stability.
Put the Bible down. It's ok. Even MS is allowed to get it right sometimes.
My Linux machines *never* crash. On occasion though, a few programs, like Mozilla and some Gnome applets, *do* crash. But it is seldom a real problem
Isn't it amazing how free software costs less to get and own, yet works better too? It's like people are paying extra money to have infexible and unreliable software. I've got more features that I know what to do with under free software, yet I never have to "restart" my comouters. Don't worry, the invisible hand will soon correct things.
Friends don't help friends install M$ junk.
more code == more bug potential == more crash potential
... I figure, open source coders don't get paid for what they do, so if they don't want to do it AGAIN, they're gonna do it right the first time...
As far as open source having less bugs
Who doesn't like free music?
It used to be that I would switch off my computer every night when it ran Windows 98 and below. Why? Because in the next day or two it would continue to needlessly fills its memory until crashed. Now I run things like Linux and Windows 2000 and I can leave them on all week.
Think of all the power I waste.
What is the inverse of the Matrix?
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.
Every Software project that I've been a part of has always been a battle between adding more features or just keeping things stable as possible. The problem you run into with just keeping everything stable is that your competition is usually willing to sacrifice stability to add more features. When the consumer goes to buy a peice of, the first consideration is the number features is claims to have. You don't find out how stable it is until you break the seal and try it out.
- 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.
But of science in general. It is know as the doctrine of Strong Inference and is our currently accepted doctrine for scientific proof. Proposed by Karl Popper in his book The Logic of Scientific Discovery, it does a good job of solving the problem of induciton.
The problem with inductive proofs or arguments is that, unlike deductive proofs, even if the argument is valid, you can still never be sure that it is true. For example if I say that all ravens are black and I claim this is so because every raven I have ever observed is black. Well fine, but the possibility exists that the next raven I observe will NOT be black, so I can't be certian I am right.
The argument often given for induction was kind of a circular one. We believe induction will work in the future, becuase it has worked well in the past. Ok, great, but that is ALSO an inductive argument.
Well Popper said that what we do is NOT prove things ture, but prove them false. So we propose a theory, and then test it in every way we can to try and prove it wrong. We try and test all the alternate theroies, all teh things that could invalidate our theory. Well, if we do that and our theory stands up, we can then say with a great deal of confidence that yes, our theory is correct. Not 100% certianty, but good enough.
Computing is extremely layered now-a-days. Think OSI model. But really - when you write a program, how many layers does it go through that you never even touched?
Hardware (obviously), BIOS, Operating System, Drivers, APIs, Libraries, Compilers, etc etc. It's no wonder that along the way something will break. Part of it is just a matter of thinking differently. APIs are often not written in a way that is very logical to me, and thus I would be more inclined to make a bug using one.
As computers and operating systems continue to get more advanced, the likelihood of bugs and crashing increases. Error handling throughout layers is not good at all. Hopefully new higher level programming languages will evolve that make things like that more simple to implement.
Really. If you think about it, just when system x starts to get matured, and stable, WHAMMO, the company releases a brand new system, back to bug hunting and instability, and just slapping a stable label on something is that-a label. Consumers MIGHT want a stable system that did the bulk of the normal stuff they wanted to do, IF it was sold/pushed in mass quantities. Who's tried it? Where is it? If all you see on the road is belchfires, you might not know there were other brands out there.
Next question is, which OS company would be willing to make a good system, then quit! Just build it good, leave it simple, then just.. stop. Stop adding bells and whistles, make it once, make it correct, charge what you need to charge, then stop. would people buy it? I don't know, maybe. People buy luxury cars sometimes because they feel they are getting reliability as much as class and comfort.
The reasons why we have cycles of instability are marketing and profit pressure for the most part, there's little profit in something that works quite well, you sell it once, then lose a customer. There's a huge and artificially created market in "works well enough, figure out the shortest psychological human annoyance time between releases, then release". Who really wants to put themselves out of business? And as it applies to OSes, the drive for new apps, which *could* be somewhat improved actually if the world class stable no bugs no improvement needed OS was developed that coders could code for without having to change all the time. Some closed propietary OS could do it, open source I am not sure, someone would fork it, go on, change things enough that the old stuff didn't work on the new version, which would mean back to the cycles. And the pressure of stopping the company would be immense, it would almost have to be written into the incorporation papers and contracts from day one. A voluntary corporate time-out and dissolution on completion of the task.
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.
My friend has brown hair. He also won the state lottery.
Clearly, brown-haired people are more likely to win the lottery. I suggest buying some hair dye today!
Seriously though, I've got a Zaurus, and while I haven't spent that much time scanning the hardware specs, I doubt that there's very much error correction packed in there.
As a proof of concept, I suggest overclocking your PC's memory, or up the PCI bus speed about 10Mhz.
Anyone care to guess that's part of why true UNIX hardware costs so damn much? Sun, for instance, implements CRC and stuff on the RAM, the memory bus, and the I/O bus. And I can definitely count the total number of times my Ultra 10 has crash in the last 5 years on 1 hand. Not including the thumb.
Oh, dude, you must be using MS Office! ;)
You know what?
Now that Microsoft has been marketing fragile products for 20+ years, it should be no surprise that we have Comp. Sci. faculty with a tolerant view of instability. Some of them grew up with this stuff. If M$ "state of the art" is really good enough, then maybe software has become so commoditized that we just relegate everything to the H1Bs and let it go at that.
True story: My wife was in the hospital maternity ward. This is a modern US hospital, not some third-world tent. For about 24 hours, they had her connected to all kinds of sensors which were connected to a Dell PC running a data collection/graphing program on what appeared to be Win 2k. The application was a joke. The nurses fumbled and bumbled with it; crashed at least once. Fortunately, the important things went well (it's a boy), but no thanks to our friends in Redmond. Had there been a problem that those sensors were supposed to detect, we would have been screwed. As an expectant father, my primary job (at delivery time) is reassure Mom that all is well. Seeing this Windows app sputtering along made my job a bit tougher. Let's hope things are a little better in the ER or ICU.
You could NOT be certian that your product would never cause the system to crash. Why? BEcause it must interact with other problems not under your control. Suppose that your product made a call that was fairly uncommon, only 1 in a thousand programs use it. Now suppose that the given call then interacts with a given driver for a subsystem, say graphics. Suppose then further tha a given manufacturer releases a buggry graphics driver, but only buggy on taht one given call. Your program would then, when it made that call, indirectly cause the system to crash. Though not your fault, your program would be identified as part of the cause since the call is a rare one.
That is what really kills the reliability thing, the interaction of different leves of components written by different people. Given a hardware configuration one company with enough time could produce a system that, barring hardware failure, would never crash and verifably so. 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.
If you still get the same amount of crashing that you got 30 years ago, you must be using horrible software. I've had builds of Win 98 that stayed up, without a reboot, for over two years, but the same applications were always run on that computer and those applications didn't crash it. As a software engineer, yes ENGINEER (I do math, not silly database work), I test all my code and make sure each piece works. Problems occur, and sometimes it's the users who catch them, but I've never crashed a system. I've corrupted the memory, but who that has written a great deal of software hasn't?
Well, yes, kind of.
1. You're absolutely right that there is no substitute for good testing. Test, test, and then set up a test suite, and then run that test suite every night. Maintain and add to that test suite as you write more code. But I don't think that's a complete solution.
2. It's hard to test everything, even if you are religious about it. The bugs I was describing are nefarious in that you can use the program, even with testing, and not realize they are happening until someone uses your program or library in a way you didn't think about.
3. For my schoolwork, my assignments are on the order you describe -- maybe 5-10 thousand lines on average. For these, I have almost never needed it. For my full time job, I work on projects ranging from 0.5 to 2 million lines of code. Those are the situations where it's really, really helpful. Why? Because:
4. For one reason, in large projects you didn't write most of that code yourself, and it's not always obvious where to start looking and what the code you're looking at is supposed to be doing.
5. In addition, those kinds of bugs are the ones that don't usually crash your code right away. You might get a segfault thousands of lines of execution later.
6. Even worse, these bugs will sometimes trash the stack, and you can't even get a good core dump. A good memory checker will find the problem where it started, not where it caused the crash.
7. Lastly, I've never used valgrind, but I have used purify; it may be that valgrind is less complete. (It is, however, thousands of dollars less expensive, and that makes it accessible to most everyone.)
The issue here is that we're talking about a product sold in stores to a large number of customers. And not a particularly cheap product, for that matter.
Customers have every right to expect value for their hard-earned dollars. If the customer's computer meets the specs printed on the box, the game should install and run. Period.
The publisher should give refunds to anyone who bought the game in good faith and couldn't run it.
Over time, the size and complexity of the problems we can solve with computers has increased because of two factors. First, hardware has become faster, more reliable, and tailored to our use. Secondly, the software tools we use have increased the number and scope of things we can abstract away. Thus, we continue to work at the boundary of our capabilities, or not terribly far from it. The demands of scientific curiousity and the marketplace will continue to drive that.
Up to a point, we demand reliability. For all that Windows has a reputation for crashing, Microsoft has improved it over the years. Whether Windows XP is more or less stable than Linux or *BSD can be debated endlessly. But there is no refuting the fact that it is more stable than Windows 95 was.
Beyond a certain point, additional reliability cost more than it is worth. This is true even if we are talking about the most demanding uses. When the cost of additional reliability makes a technology unaffordable, compromises will be made. The point at which extra reliability is too expensive differs from user to user and application to application.
It is not clear that it is possible to write software that is provably bug-free. What is clear is that reducing the number of bugs while holding the development methodology constant will tend to increase the cost. Extreme Programming and other similar disciplines have argued, convincingly, that in the long run, this can reduce costs over the life of a product. But when you are trying to hit a market window, or launch a product before your venture capital runs out, corners often get cut.
I think that the long term trend is for each lower layer of abstraction to become more reliable over time. At the same time, more is added at the leading edge. New development, especially in uncharted territory, has new bugs.
I can't confirm this with statistics, but I suspect that the reliability of software as an aggregate has either varied around a constant, or has improved slightly over time. What I wonder is whether the reliablity measured against the total amount of code has been slowly improving.
The net will not be what we demand, but what we make it. Build it well.
Why do people still run windows?
If your theory is different from practice, then your theory is wrong.
It's a good question, but is complexity the reason? Surely someone could benchmark increasing complexity vs "time to failure" of a bunch of systems, some mentioned already. Seems cars are much more complex today than the original Model-T. Do they fail more often or less? Ditto for airplanes. I would imagine that a plot of increasing complexity of these sort of systems vs "time to failure" would be relatively flat, or at least no where near as sharp as a similar curve for software systems.
I would conjecture that it's the "virtual" nature of software that makes the interactions difficult to predict and what allows systems to fail. My favorite example of a non-software failure is the situation that lead to someone becomming the President of the United States with out ever being involved in an election. This president was Gerald Ford. For those too young, Nixon's elected VP resigned, Nixon appointed Ford, then Nixon resigned. Frankly I consider this a failure of the US Constitution, and the sequence of events that led up to this an "unforseen interaction". Surprisingly this "bug" in the US Constitution still remains unfixed.
My belief is that hardware carries baggage with it. People build things with hammers, nails, wood, brick, steel, and etc. These things place design restrictions on the designers and that these restrictions help with stability. In software, or anything virtual, the analogous "building blocks" are all in our minds and the features of these virtual components are less well understood that physical ones.
Another possibility is mere familiarity. People have been building stuff with real components for a lot longer than they have been building things with virtual components. Perhaps it's merely that length of time that is the difference. Once we've had a sort algorithm in our tool kit for as long as we've had a nail or a lever things will start to improve on the virtual front.
So you have found a particular configuration of software, hardware and usage that doesn't cause any crashes. Ok, so I can do that with closed source too. Our DCs at work have never crashed either.
Now, let me come play with your system. Let me try new software and hardware. I promise to use only open source apps and drivers, but I'll quickly find a combo that will crash your system, even if I use only stable releases. I'll eventually hit on a combo that interacts in an unforseen way and causes a crash. For that matter, I'd give good odds that I could cause a crash simply by misuising the system. I give it enough kinds of input it isn't prepared for in enough ways it didn't think of, it'll crash.
That's how security exploits happen. There was an exploit in BIND a while back. IT affected basically every version EVER. Years of opensource code, yet there was an exploit. When you used it in an unintended way, you could cause it to malfunction.
Now I don't intend to debate specifically wether OSS is more or less secure than CSS, that just turns into a stastics game that is useless. I am just pointing out that OSS isn't perfect. The code can be open, widely reviewed, used often, and still an unforseen interaction can happen.
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.
Well, on AIX they hide a "". Gotta love IBM
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.
No, I've found many combinations of sofware that work on many platforms. I've built up everything from a 33MHz 486 terminal machine for email to a Soyo Dragon. I'm currently running six computers and a P90 thinkpad. I've used them for everything from particle transport and fluids calculations to ripping CDs. None of them has ever just crashed. I use one of them everyday for email, browsing and the usual stuff. Sometimes applications flake out, no big deal.
Now, let me come play with your system
I doubt you could be as random as my 18 month old daughter. Oh yeah, I'm sure you could do something nasty so just stay away. Normal and abnormal use has caused me no problems. Malicious use is something I'm not willing to put up with.
There was an exploit in BIND a while back. IT affected basically every version EVER.
I remember that. It did not affect the then currently stable Debian bind and no harm came of it. There is no comparing the world of M$ exploits to the few free software rabbits you might pull out of your hat. The game is not useless, the results are real.
Friends don't help friends install M$ junk.
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
Windows XP is incredibly stable for something that runs on such a huge variety of hardware. "Inability to create a stable system?" Please.
my playstation 2 is still broken. sony manufactured them with shitty quality lasers to save costs and gaurantee that people will need to either shell out almost as much to repair them as it would cost to replace them.... ...what? Soul Calibur 2 will be out soon? Aw, god DAMMIT!
now if you still need me to spell it out, it's entirely possible that some propiatary software is flawed intentionally for job security...imagine the hit that tech support would take if software suddenly worked all the time!
But no new playstation for me! I refuse to fuel this evil business model that sony has deplayed. And I've got graduation money sitting in the bank just waiting to be spent...
Gentlemen...BEHOLD!
-Dr. Weird
2. Testing. Recently, I started writing unit tests for my applications, and I can tell you that this is something that should pushed more! They can definitly help discover bugs in your application. I think schools should teach unit testing and encourage students to always use them.
These two points could help make applications somewhat stabler. Also, using "safe" languages (Lisp, Python, Ruby, ML, Smalltalk, etc.) is another step in the right direction; let the compiler/interpreter worry about low-level details, you just make sure that your code does what is expected.
we would all be using identical computers with identical hardware, no input or output devices and running unix
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
www.thelinuxshow.com live interviews on streaming it is pretty cool.
In the early days of networking the mathematicitian Benoit Mandelbrot had his attentions drawn towards a problem in a stability found by the engineers. He proved that the amount of distortion and therefore computer error (crashes) is always a proportion of the total time studied and that crashes can never be eliminated. Quantum effects, current bleed, malformed chips, and other factors will forever combined to make crashes occur at random intervals. Any software/chips currently made are simply better at compensating for these perturbations.
further reading == Gleick's Chaos
The magic words are "single input queue clashes".
I believe the bulk of crashes in the OSes of choice I've run since '95.
Back when you wrote programs for the Apple ][e, you know what hardware you were writing for. Every machine pretty much had the same thing. Yet even on the early IBMs you had to take into account that they could be running mono, cga or (rich people) ega and all from different manufacturers who has varying degrees of "compatability" in a young environment and young dev tools.
Fast forward to today and multiply this by the hundreds or thousands of different pieces of hardware all from different manufacturers all writing "drivers" with different levels of compliance and reliability stacked on top of the myriad of 3rd party/OS APIs that you use all based on standards (or not) that are open to interpretation...add other variables ad nauseum
Sometime I find it amazing that things work as well as they do.
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
Of course, there's no need to mention...
Why is it that whenever this phrase appears, you always know that the unnecessary reference is about to make a guest appearance? You can at least correct it a smidgeon, to "No need to elaborate on/expound/extoll/etc."
Sheesh.
Any spoon would be too big.
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?
;-)
You would have to use Scheme.
P.S. I'm serious.
Real programmers can write assembly code in any language. -- Larry Wall
There's a law as to why things crash/go wrong/develop new 'features' (not bugs) - but I forget the name of it, but here's the gist:
Consider a very simple logic problem:
An ant is standing on a white tiled floor. He must abide by 2 rules - as he travels across tiles, if he steps on a white one, he turns it black, turns left and steps forward one tile. If he steps on a black one, he turns it white, turns right and steps forward one tile. Now regardless of the size of the floor (once there are enough tiles) - the ant's motion will appear random for a period of time (eg 10,000 steps) - but eventually it will settle down into some pattern - usually somewhere above the 10,000 iterations mark. And now you have a new feature.
Now consider applying this theory to a computer program - which has many more than two simple rules. It's no wonder that new things will pop up.
This doesn't entirely condone the stability (or lack of) in many programs and OS's - but it does give some insight into the difficulty in achieving the holy grail - a perfectly stable, well behaved system.
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 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.
Software is not always hereditary - each project, whether it be a browser or an OS or an office suite, is often a fresh start. Unfortunately you need to use software for a while in order to discover its bugs, so as long as there is new software, there will be new bugs.
Inevitably when software becomes bug-free it will also be close to obsolescence.
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!
A) 95% of the people in the software industry suck at doing their jobs. They should be making fries, sacking groceries, mowing lawns, etc. They think they're good at it and just plain aren't. Remember, bad coders can write bad code faster than: 1) good coders can write good code; and 2) good coders can fix the bad code.
B)Look at the June issue of Scientific American; cover story: "Computer, Heal Thyself", (An End to Disasterous Crashes?)
"After the Columbia was lost, NASA officials said that just one missing tile could mean that safety blanket could be compromised."
One of a billion mishaps could kill people. But consumer hardware, let alone software, is pretty safe...
"One hundred forty four manned flights in space and only two failures," he said in an ABC interview about the shuttle program. "That's a pretty amazing safety record."
That's a quote by John Glenn. He forgot to account for the failure of apollo. Imagine if 1 in every 48 times you used a computer it blew up? Now imagine a billion computers being turned on and off simultaneously. About 48 every month.
Still, no accident!
So even a software catastrophe on a personal computer is no big deal (E.G. hard drive crash) and is preventable in many ways from physical and online backups to multiple hard drives with RAID configurations.
However, that 1 in 48 figure is for EXPLOSIONS.
Minor things happen in software that are just annoying, that you wouldn't know about if they did on a space shuttle.
Maybe a velcropad is missing, etc. Minor annoyances must happen. A repetative annoyance in Windows, noticed by millions of users, would be public, even if it's a minor thing like a spelling mistake. But a job-slowing mistake on a space shuttle would be a fact of life for the 5 astronauts, wouldn't it? You would never know about it.
So space shuttles are extremely dangerous and failure prone. They are more likely to break down than personal computers, not less.
Cover your eyes and click this link!
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.
Because Al Gore invented the Internet.
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!
If you've had a windows system up for 5 mos. then you certainly aren't patching (and rebooting) the system and are adding yet another vulnerable windows system to the internet... Unfortunately, I think this is common as we have seen with code-red/sql-slammer/etc.. propagating long after patches were released. Heck, even MS has had that problem (not willing/able to keep up with the system patches they release).
=-=-=-=-=-=-=-= - The Celtic - =-=-=-=-=-=-=-=
Anyway FreeBSD or Linux will still work without a reinstall by changing this setting.
http://saveie6.com/
I think it says a lot about religion and spirituality that computers crash when they achieve enlightenment. Namely, that's it's a load of hogwash that I wouldn't dare bathe my dear pet pig in.:)
Is this a sigs-optional kind of place? 'Cause I am totally down with that if you know what I mean.
If you wish to write a system that is stable, firstly follow some standard engineering practice. For example (albeit contrived):
Select a hardware platform that is stable and has not had to be patched EVER for for at least 10 years.
Select an OS that has not had to be patched EVER for the last 10 years.
Select Databases and tools that have not had to be patched EVER in the last 10 years.
Select tools/methodologies that have a long history of successful results in similar projects.
Employ only QUALIFIED specialists to design/configure/code etc.
Heinous mistakes are punishable by fines (jail time is also possible).
This will make computer solutions much more expensive. This is the cost that the user base must pay if they wish to have computer solutions that do not crash. Is this all a tad extreme? Well, let's examine bridge building for example. The materials used have known properties that are thoroughly understood. ONLY qualified professionals may design bridges. No IFs not BUTS no "I've xxx years experience - I know what I'm doing - trust me". (Incidentally, Mr xxx years experience MAY know what he is doing - but that's besides the point). Designers and builders are given the time required to do a good job. In fact, there's plenty of legislation mandating certain building practices that forces companies to "do the right thing".
There are national standards for every singly part of bridge design, from the type of steel to use, to the colour and composition of the paint applied. There are NO national standards for software design.
Imagine how cheap it would be to construct a bridge if the builder could just 'slap it up'? This is what they would have to do if all the competition was also doing the same. This is actually just like the software industry. Other engineering disciplines are regulated and software engineering needs to be also.
With traditional engineering, failure is generally not an option. If a bridge falls over during construction, generally the building company is dismissed. The cost of failure is extreme. Everything MUST work the first time. In the software industry it's all too easy to retro-fit and patch. There's no perceived cost.
Now imagine this scenario; half-way through building a bridge, the project sponsor changes requirements. The bridge must now be suspension bridge at one end only. etc. This ludicrous situation happens every day in IT.
IT is such a young unregulated industry that there are no "tried and true" components - everyone is attempting to out-feature everyone else.
Projects are full of unqualified individuals. Also incompetent individuals.
Project sponsors change requirements during a project, in other words, everything is not set down in stone at the start of the project.
There are no national standards (certainly for tools and application development) to ensure that viscous competition cannot drop the end-product's quality below a certain level.
The end-user must be prepared to pay for such quality. This level of quality is going to be expensive. Compare a flight simulator to the space shuttle guidance system. The space shuttle's code is expensive beyond belief. Where did all the money go? Guaranteeing that the system didn't crash. Why are they running on dinosaur equipment? Because they know it works on that particular set of equipment.
Guaranteeing that a complex solution will never crash is a very very expensive exercise - will the market tolerate this. or is the market comfortable with cheap software that crashes now and then?
And lastly here's a plug for open source. The composition and properties of the materials used in bridge building are not proprietary. They are published, examined, tested, confirmed and quantified. You can draw you own software parallel.
"Why Do Computers Still Crash?"
Micro$oft.
Which is more expensive (not that I agre with your idea that XP is as stable.. but if it were).
=-=-=-=-=-=-=-= - The Celtic - =-=-=-=-=-=-=-=
People are imperfect, and therefor anything created by people will be imperfect. Thusly, hardware and software will always have bugs.
It is possible to write software that doesn't crash very often, but that depends on:
Stable hardware
All software layers under the program must be stable (such as the OS, system libraries, windowing system, drivers, etc.)
Knowledgeable programmer(s)
Good coding practices and the proper choice of programming language for the task (and yes, C can be a "safe" language, if people would just use "safe" library functions like snprintf() instead of sprintf(), fgets() instead of fscanf(), strncat() instead of strcat(), etc.)
A well-though-out design that is as uncomplicated as possible (i.e. not having a separate daemon to handle configuration info for programs *ahem* GNOME *ahem*).
A programming team that can resist the urge to add extraneous features. A program should do one thing and do it well.
Time. No program is bug-free right off the bat. Sufficient time for testing and debugging must be given.
Comment removed based on user account deletion
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.
Some aircraft are inherently unstable. When I say unstable, it means the aircraft doesn't have a preference for flying straight and level over flying straight down in inverted flight. This means that the aircraft does not resist the transition from level flight to turning or banking. It also makes them difficult to fly. Stable aircraft, on the other hand, are easy to fly straight but can't be used as a fighter aircraft because they bank slowly and they resist everything but level flight. Computers are kind of like this as well. Special purpose computers are wonderfully stable but totally inflexible. Things like analog fire-control computers on submarines never crash. The main problem with PCs is that they are so totally flexible that at any moment, just about any combination of software may be in use at one time. Combine that with an unpredictable action, and software with thousands of relatively unchecked features or controls, and you have a recipe for disaster. Especially since the programmer has no idea what combination of hardware the end user's machine will be running, he can't do anything to deal with other pieces of software trying to access memory space assigned to his app. (Or operating systems that seem to 'forget' who gets what, and prevent violations) Okay, so it's an imperfect analogy. I got nothing.
It costs a lot of money to use the proper technologies to verify and secure a system. It takes months/years to verify software for critical DoD use. And even if you could afford it, nobody else wants to pay for it, making it that much more difficult.
To some extent, the problem lies with the language (some languages have more secure features and software than others), but a large part lies with Microsoft's liscence to print money and Windows. Its a large code base, partially due to backwards compatibility. There's little financial incentive to work on the problem. It appears that people are convinced that crashes and viruses are a fact of computers, and put up with it rather than seek alternatives.
And its not just Operating Systems. How much would you pay for a web brower that didn't crash? IE crashes, Opera crashes, and even Mozilla can crash. At the software level, there isn't much one can do against random hardware failure (bits flipping in RAM). Sure, you could pretend to address the problem by operating on redunant variables, but what if the code bits are affected instead?
I Browse at +4 Flamebait
Open Source Sysadmin
I attempted to rip a bad audio CD with cdparanoia using my Plextor SCSI CD-ROM drive. When I say "bad" I mean, if you held it up to the light you could see a tiny hole in it. The system locked up.
The excuse for this, of course, is that it's a hardware problem. Why should the inability of the CD-ROM drive to properly read the disk cause the rest of the system to hang? The kernel should be able to handle this kind of error. What went wrong? Is a bug in the kernel responsible, or is it a hardware issue with the motherboard, or something else?
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
0.9999999999999997823.......
As an AMD user, I don't have to worry about such things.
Of course, I don't ever have to worry about heating my house, either.
BIGstan!
That's an easy one. Because their operating systems are written in C. Next question?
I watch Brit Hume on Fox News
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/
Isn't a programming language.
Why this won't happen:
would this be similar to a matrix with certain predictable irregularities?
*cough*just saw the movie, it rocked*cough*
--
|-_-| . o O ( bEef!)
Just something to think about, the gist being we will not have reliable computers until we demand them...
Your guy had a computer that crashed twice a day from bad ram. Why doesn't he have parity ram and some mechanism for the computer to hollar "hey, i got a parity error, my ram is bad"? SIMMs come in 64 bit chunks these days.
Parity will cost 2% or so. ECC adds 10% on 64bit ram. Why not? You've got a component that is probably the 2nd mostly likely cause of failure (power supplys being number 1, fan failure), is probably the most expensive failure to diagnose becuase of its random nature, and for a $5/computer cost (typical) you could identify and eliminate it.
Why don't people demand this? Why didn't you demand this on your workstation?
I know I've personally wasted more than 40 hours of my life debugging systems that turned out to be bad RAM in the end. $5/box RAM insurance is pretty cheap in those terms.
And then there's this old gem: "Intel--United We Stand, Dividing We Fail".
I think topics like these express a bit of naivite, because the root cause for most system failures are economics and human nature. As the universal goal for a business is "money for nothing and chicks for free", an academic discussion of creating a "perfect" commercial product is a bit like debating the existence of God, imho.
I think most commercial software is written with the minimum effort required to gain the largest chunk of market share. Bugs are expected and tolerated. If you can sell crap and get away with it, then it doesn't make sense to spend as much up front making a perfectly reliable program. It's better to wait until people are dependent on your system, then with the established customer base, go forward in making incremental improvements in reliability. Didn't we have this conversation about Microsoft before?
I think most products are done this way, using the cheapest components and the smallest amount of labor possible. If you can get your devices mostly working, then time-to-market and pretty packaging can be more important than having the best quality. It's all about whoring yourself properly!
I dunno about this--i agere that it is certaintly better to have more reliable parts, but I don't think you're right about memory being the 2nd most likely part to fail. I'd certaintly agree that power supplies are walking death traps of hardware failure, but I would say that hard disks, cpu fans, cd-rom/dvd/cdrw are MUCH more likely to die. Maybe I've been lucky, but I've never seen a computer with known good ram suddenly go bad--the case that I refered was a on a newly built computer that had 512mb ram in two ddr dimms and apparently only were bad somewhere high in the 2nd one so crashed sporadically during the day under heavy load (and somehow wasn't caught when built).
:)
It's not really hard to diagnose either I would say--try memtest86 is the name of the program i used to confirm bad ram. Believe me, from now on I will run it on all new computers before putting them into use
Last login: Thu May 15 17:26:31 on ttyp3
Welcome to Darwin!
[Adolph-Trudeaus-Computer:~] adolph% uptime
11:47PM up 22 days, 8:40, 5 users, load averages: 0.81, 0.65, 0.45
[Adolph-Trudeaus-Computer:~] adolph% time
0.020u 0.000s 0:11.86 0.1% 0+0k 73+4io 0pf+0w
[Adolph-Trudeaus-Computer:~] adolph%
The only reason to restart is to apply updates.
So thank your lucky bugs!
Computers > Programming > Languages > ML
cpeterso
127+1 = -128, 32767+1 = -32768, etc. Here, i+1 = -(i+1) (*see below), not i+1 = i. (Hex examples: 0x7f + 1 = 0x80, 0x7fff + 1 = 0x8000, etc. )
But you also forgot to add that something similar happens for unsigned integers. 255+1 = 0, 65535+1 = 0, etc. i+1 = 0. (hex examples: 0xff + 1 = 0x00, 0xffff + 1 = 0x0000)
(*) Here's a nifty trick: -0x80 == 0x80, -0x8000 == 0x8000, etc.
Why, you ask? -0x8000 == ~0x8000 + 1 == 0x7ffff + 1 == 0x8000.
Square electrons
Besides the harware production flaws, the software coding flaws, and the shipping process (every atom is manufactured, man-handled, assembled, and shipped somewhere), let us not forget end user abuse.
Who is guilty of smacking/kicking the PC or mainframe? I bet this helps stability alot.
Looks like it is time to replace your Personality Module. You are a bit to clingy, guess I better replace your fuser to
I've been using computers a few years longer. Heck, I've owned computers a few years longer (yes, that makes my first one prior to the 8080 micro chip). But even 25 years ago I saw Data General systems with a lot less raw power than a Pentium that ran a multi-user OS and supported an office full of users, and routinely ran without crashing or even being shut down from year to year, and were only rebooted when the tech came around to give them a scheduled prevenative maintence. Sure, some systems did fail (and some in quite interesting ways), but it was the exception, not the rule. The thing that I see as having changed is that Bill Gates became the richest man in the world, while at the same time giving us an OS that crashed so regularly that it just can't stay up. And somehow people accepted it. How he got away with it I don't understand.
I'm an American. I love this country and the freedoms that we used to have.
Not everyone has switched to Linux yet. It takes time for such a massive exodus, so expect crashes for a while yet.
I have a brand new PowerBook G4 (12.1"), running the very latest OS X. I had a kernel panic every couple of days for the first week or so that I used it. I still get kernel panics from time to time when disconnecting an external monitor.
Just because *you* didn't experience the bug doesn't mean the bug isn't there. I'm sure you'll claim you do some "hardcore shit" with your Mac -- pushing it to the veru limits (you can cook an egg on it it's so hot!), uptime for months on end, you can even walk into a bar with it and, in a single bound, pick up four hundred chicks before leaping off to save the day -- and therefore you can't possibly imagine how the OP could be telling the truth.
I doubt, however, that your use patterns are identical to his. And it's this sort of attitude that, "if I don't get the bug, it's clearly a user issue" that makes software the shit -- yes, it's all shit -- that it is.
It's especially bad in the Cult of Mac (I mean, it's conversely bad in the world of Windows--users blame Windows because "Windows" is the excuse, that's not any better at isolating causes). But, nobody wants to blame Apple--nobody wants to think that their only hope, the only credible hope against the oncoming Microsoftian hordes, is just as full of shit.
But, they are. If my Mac crashes it doesn't matter one lick if it's the hardware or the software or even if that's better than the competition -- it's still unstable, for my use patterns.
So, just put that self-righteousness back in your pants. OS X is more stable for some, less stable for others. There are terrible, crippling bugs lurking in it (alongside the more common, "plain irritable" variety) just like everything else.
Try to repeat after me: Just because Apple made it, doesn't make it perfect. Apple makes a good product from time to time, sure, and so does Sun, and so does SGI and: Just because Sun made it, doesn't make it perfect.
Simple answer: because idiots still use them.
No comment.
.. anybody would think that computers that multitask with a number of programs made from a number of different programmers running on a virtually infinite combination of hardware all operating under a variety of environmental conditions can work under the idea that a computer could be made that doesn't crash. Hell, all you have to do is shine a light on RAM chips and that'll cause stray bit flippings.
"Derp de derp."
I had to reboot the mirror in my pickup truck. Or, rather, I had to reboot the tiny computer inside my mirror. The mirror has a small window that displays blue-green letters to indicate which direction the truck is headed--N, S, SW,etc. One day last February I noticed that the mirror said simply "C". I assumed this stood for "Cold" and that the compass would return to normal functioning when the heater had warmed the cab up a bit.
I was wrong. Three days later, it still said "C". So I reached up and pushed the switch on the mirror to Off, then back over to On. The mirror successfully rebooted and has been working properly ever since.
So that's where we've gotten ourselves: mirrors that crash and have to be rebooted.
It's abnormal, especially if you have a good network monitoring system, for software, either the kernel or running processes, to cause things to crash. In my experience, 99% (maybe 100%) of the time this is due to processes causing disk, memory, or processor (or network) to get filled up, eventually crashing the system. If you have a decent network monitoring system and enough administrator person-hours to deal with it, you will rarely have problems on this side.
My previous job was at a Fortune 100 company where I was part of a team that administered thousands of machines, and I would say it takes being in a large environment like that to realize that hardware crashes occur a lot more often then software crashes, and software crashes are usually avoidable. In fact, hardware crashes are usually avoidable as well - unimportant development boxes were usually the only things that crashed due to disks or processors or network cards failing. A critical heavy-duty production machine would often be running on a Sun Enterprise 6500 with a RAID disk array, multiple processors, multiple network cards, and besides all that a spare 6500 with the same setup just sitting there on a veritas cluster server, waiting for the other machine to fail so it could kick in. That's pretty good hardware redundancy, and there is no real "crashing", just replacement of disks that go bad for which RAID5 automatically kicked the data to spare disks and so forth
There is a common enemy for all hardware crashes in all environments, no matter how small or deep the pockets of the company - heat. Servers piled on top of one another, row on row, cabinet to cabinet, can generate a lot of heat. And no matter where I go the cooling always seems to be inadequate, even in places with deep pockets. If the room is hot, the cabinet is hotter, the machine is even hotter, and the processor is hotter still. I had a machine room once where the temperature kept building and building and building, until suddenly in the space of one or two days, over half of the hard drives in the room crapped out. If your machines are having hardware problems, go around and feel if it is hot anywhere in your cabinets, and wherever it is hot put a thermometer there. However much the temperature is, remember that the processor is hotter, and that it is probably even hotter if it is in a cabinet and you later close the cabinet.
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.
Its true even the canadians think so. Listen to this funky mp3 by Three Dead Trolls in a Baggie, Our nerd buddies from up north eh?
OSDN
Neat article about self-repairing computers courtesy of Scientific American.
i cleID=000DAA41-3B4E-1EB7-BDC0809EC588EEDF
http://www.sciam.com/article.cfm?chanID=sa006&art
Neat stuff, interesting ideas.
I think we will have crashing computers until we have AIs (with real AI). One thing an AI should be able to do is self-heal.
1. "Get certified in three weeks, and make $$$ as a programmer!"
2. The market demands features above all else, and wants them *now*.
It's the old adage: Quick, cheap, good: Pick any two.
steve
Oh, you're not stuck, you're just unable to let go of the onion rings.
You seldomly hear about software in medical equipment or airplanes crashing. So i guess it's applied in places where it really matters.
NASA managed to load an old version of the software in one of their shuttles... that's what you call a usererror.
Too complicated tools (c++) for most jobs
Lack of garbage collection on system level
Lack of bounds check on system level
Increase in system size and complexity but still usage of the same tools
+ sometimes sloppy code
and you have the crashing symptom but the tools are the cause.
It's behind a firewall. NO ports are open to the outside world. It just serves files, runs my webcam, and streams MP3s in-house.
Best Buy can have you arrested
Actually computer software has gotten a lot more reliable in the last 20 years, it's just a different kind of reliability.
Software runs on two platforms -- one of them the user. Usability has -- in general -- improved in leaps and bounds (in large part owing to Apple, Xerox, et al) vastly reducing the tendency of software to crash on humans. Crashing on humans remains such an enormous problem, however, that fixing it is a far larger market differentiator than fixing relatively minor problems with crashes on hardware.
The reason for this is simple. A well-designed and easy-to-use piece of hardware, e.g. the mercedes seat adjustment control given as an example in Don Norman's "The Design of Everyday Things", is more expensive to manufacture than a badly-designed and difficult-to-use equivalent. So hardware design tends to offer a trade-off between design and price. Generally major appliances are cheap or well-designed, but not both. For software, usable software is more expensive to create, but less expensive to support, and no more expensive to manufacture.
The fact is that the cost effectiveness of hunting down bugs that cause software to crash hardware is much lower than the cost effectiveness of improving usability (i.e. reducing crashes on human beings).
Since everything is a computer nowadays, they seem to have also the right to crash. Mi Nikon CoolPix camera does it from time to time, and the only way to ctlr-alt-del is to take off the batteeries and leave it there for a while.
It's just a BloJJ
Our jobs, our toys, and our options are diverging from each other and increasing in numbers.
Computer crashes are annoying, although most of them are caused by buggy software, not faulty hardware.
The worst type of crash for me is when the operating system crashes, as opposed to an application crashing. My Windows 98 (fully patched & updated) crashes occasionally. Explorer (not Internet Explorer) crashes frequently, especially after deleting files. When deleted files go to trash, it doesn't crash.
No linux kernel has ever crashed on me. Occasionally an application will crash, but that does not bother me too much.
Applications that allow automatic saves ever X minutes are a great idea. It lessens the worry.
All you people who can't keep a Windows 2k or XP box running for longer than 2 days have something wrong with you.
Either you are lying, which I think is entirely plausible. Linus users generally seem to me to be about 60% as neurotic and obsessive as Mac users. You guy's should form a religion - you already have the frighteningly blind faith.
Or you are unable to learn how to install a driver correctly in windows, which has got to be something to the tenth magnitude easier than in Linux, which I think is implausible.
My Win2k box goes for weeks at a time without a reset. And yeah, I run applications on it; games, 3D modelling tools, CAD package, many other CPU and system intensive programs.
And furthermore, I by no means consider myself a technologically elite person. I can replace all my own hardware, install all my own software and keep that software updated, but I don't have the need or desire to learn how to use the Linus command line, or write custom assembly for my Radeon.
What I am basically saying is that if you are unable to run a stable Windows system, it is entirely yours, or the people who use your computers' fault. You cant blame MS, cause no one I personally know has had these problems since WinME.
I am a viral sig. Please copy me and help me spread. Thank you.
You've even set up the volley so that everyone can jump in and say "well, look at *nix".
Way to go slashdot, you've posted a Troll. And guess what, it's a hell of a troll, because it got 700 replies, and counting.
My troll of the day: dear slashdot, I just don't understand why there are traffic accidents. I mean, my father has driven the same car all his life to work without crashing once, and yet, my sister, who just got her car 2 months ago had a fender bender.
I mean, is it too hard to drive? Aside from the fact the Ford makes SUVs that tip over... is it not possible to make a safe car?
My answer to you is: yes, let's build a titanium car, that has 200 cubic meter airbags (constantly inflated) around it, with rubber that is 9 inches thick.
Pointless. Sigh.
> Janeway: Computer, triangulate the source of the weird stuff > Computer: Hold on, I'm going through POST
Discovering new things.... one beer at a time
Of course, there's no need to mention Microsoft's inability to create a stable system.
You did realise you were posting this toIMHO, any time a program crashes due to human error, it is the programmer's fault for not forseeing the event and thus a program error.
Yet another signature that refers to itself. The irony and humor is dead.
train your people on proper software methodolgy so they use the language properly.
C and C++ should not take the rap because dumb ass programmers can't be bother to use them correctly.
Designing a proper test method would do wonders.
The Kruger Dunning explains most post on
I had a rant about this in 1998 on my homepage... It's preserved in all it's glory on the Internet Archive.
. org/comment.html
http://web.archive.org/web/19980419075203/nuts.ml
-- The universe began. Life started on a billion worlds...
-- Except on one where stupidity was there first.
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.
We have a ton of JCL code on the mainframe. It was built years ago. It never crashes. Based on a solid language, if designed and written properly, it will last a life time.
One exception, the memory leak with VTAM. Once we upgraded to the newest version of OS/390 and our CICS LINKK migration. Not a single problem.
duh.
You see, C is also like a hammer in that it is totally unforgiving. Everyone makes mistakes, even "carpenters" and "OS experts". But both C and the hammer will smash your thumb (or stack) open regardless. I think what people are trying to point out is that sloppy coding is not necessarily the cause of programming errors. An unforgiving language is.
Note to M1-ers: a curt but otherwise insightful message is not "Flamebait" or "Troll".
Don't allow bad programmers to use sharp tools with which they may be able to hurt themselves or someone else. C and C++ are sharp tools. Perl and Python are blunt instruments.
now we need to go OSS in diesel cars
It's a matter of skill and cost... I'm sure if you had 500 programmers that had PHDs in Computer Science and Computer Engineering and code program in assembly then they could work together to make software that would never crash... but how much would it cost to employ that many people with that much skill?
Why do that when you could hire 500 programmers that just got out of college w/ CS Degrees that now let them know how to program MS Visual Basic really really well and make a program that can execute...
Plus on top of that... if it crashes once in a while, the computer is probably still helping you do something could never do by yourself.
Keeping your indexes inside the bounds of an array is like coloring a picture and keeping inside the lines or driving a car and keeping it on the road. There's nothing to stop you from coloring outside the lines (you won't die because of this) or driving off the edge of a cliff (you will die because of this). Yet we aren't calling for "bounds checkers" for steering wheels. Programming in a language like C/C++ or even assembly gives you all the power you need just like a car, along with the responsibility to stay on the road and not drive drunk.
now we need to go OSS in diesel cars
Erk, Psion EPOC16 machines (like the 3a) are anything but stable - it's quite easy to crash them, especially Agenda.
I've used 3, 3a, 3c and 3mx and they will all crash at some point for some obscure reason.
Agenda is worse, followed by Sheet.
.... useless code. It is easily visible in RTS games (Real Time Strategy. Like Command & Conquer). A small patch added to the game activates the use of a unit which was programmed into the game, but its use was removed during production for any numer of reasons. The same goes for Windows. It takes YEARS of work, millions of man-hours of programming done by different groups of people. Sometimes programmers simply dont take the time to completely remove a piece of code or a feature, and instead opt to remove the little "/" at the end which terminates its use.... yet the wasted alphnumerics still remain, taking up space. It serves no purpose. There was an article in Scientific American about the future of software. The fact that programmers and software companies should start taking pride and effort in having 'clean' code. The code used serves a purpose and nothign is wasted, it could really prove to be a thing of beauty if done properly. DNA is rather similar. For example, human DNA is full of useless (as far as we know) code. Old genes, genetic diseases and the like. However, a cold virus has a kind of beauty to it in that the RNA which makes up its genetic profile is only what the virus needs to live, reproduce and so on. Unfortunately, todays software has the equivalent gene quality of a half-dead 97 year old man.
Don't have a clue why I bothered to read past the second paragraph.
This guy either works for MS or has MS shares.
I've had computers crash in certain wallplugs, but working perfectly connected to others.
:)
First time i experienced this was when I got my second computer, a C64. Since then I've experienced this with Amigas, a Playstation 2 (running Linux) and a number of PCs (Both Windows and Linux machines.) The computer I'm writing this on would crash occasionally until I disconnected everything external and plugged it back in.
Also a PC refused to boot Windows while connected to the same wallplug as a cooling fan (the ones humans use on hot summer days.) I suspect the thingie created quite a bit of electrical noise
That is all.
- thorsten
Do you know what the "Event Viewer" is?
No?
Next time, learn how to troubleshoot!
Fancy trying just one version of one distribution and condeming all the versions of every distribution.
This is either an idiot or a blatant liar. I'd say the later as most professionals don't use Microsoft software for 24/7 applications. For example, how many Airlines use MS applications? Not one!
And as for a worm infecting his Linux servers...well this starts to sound like a joke rather than MS dribble. I think this person is just trying to annoy and waste time rather than inform.
Software will become more reliable when:
All these require a change of mentality: the today developers think about profit. They hurry to put something in the market, and security/safety may come later. Microsoft Windows is a prime example of this. Competition is good, but not in the expense of security/safety.
By the way, it is amazing that even with the primitive available tools, some developers do the job correctly. Most operating systems that I know of don't crash if the hardware drivers installed are good. That means that there has been a bunch of people that had burned their eyes in front of a monitor hunting and fixing bugs (and kernel bugs are extremely difficult to catch).
One thing not mentioned is the shere number of manufacturers/devices for the PC. It becomes impossible to test X piece of software, or X driver, or what have you for every combination of hardware that is out there with PCs. And, while it's less likely to happen with hardware, hardware vendors do sometimes do things, much like software vendors, that cause "buggy" or "flaky" hardware for the PC. And then you have mini power outages, brown outs, driver conflicts, a piece of software written for active X 6 and we're not on 9, etc. The PC has far and away more software and more hardware available to it than any other system on the planet. It is impossible to test your software or your hardware in all possible combinations.
The market has been (foolishly to some degree) accepting features over correctness.
What we need is for the major OS and application vendors to spend a few years doing nothing more than fixing bugs and finding security holes. As long as we have such a sloppy baseline, continued development will accidentally expose underlying bugs in unpredictable ways. Get your Finite State Machine books out, folks!
Stop the brainwash
I run OSX and Linux on a few different boxes. I can't remember the last time any of them crashed. Once in awhile a process will crash and if this process happens to be related to driving the GUI or keyboard/mouse IO stuff then the machine gets a little useless for awhile, but I can pretty much always ssh in from another box, HUP the offending process and away I go. A lot of people either wouldn't know how to do this or don't have another box handy on the network so they're stuck with a reboot. So ummm my experience is that some programs crash but modern *nix kernels are remarkably stable and the OS itself tends to kind of hang in there and keep on choogling I guess is maybe what I was getting at there. The End.
Now wash your hands.
I can't seem to remember once that my good old Commodore 64 has ever crashed. But I'm not certain if my good old Amiga 500 crashed either.
But my 386 SX 16 Mhz running M$-DOS 6.22 crashed a few times, but that was rarely.
We stop accepting them as a common thing, when manufactorers decide to give something a longer development cycle. Now its design, produce, sell and then test. Look at loads of firmware and software updates that are around.
;-)
Its normal that a company makes money on support instead of the products they are selling, so it should be crap, otherwise they cant deliver support and it should be just a bit better then the other supplier to make it sell, its better not ?
- Restrict debugger access. Either charge people for it or have only one team member authorised to run debugger sessions. If my code fails, I either get publicly humiliated ("please can I use the debugger?") or I sit down and think what went wrong. It reflects back onto coding styles themselves: after all, if I can't think my way through my own code just after writing it, what chance will anyone else have?
Of course, it would also help if we were writing for systems that, unlike Windows, were documented, documented by people who knew how to write unambiguously, and functioned more or less according to their own documentation. The major advantage of open standards is that the process of implementing them (by multiple independent software writers) debugs the documentation beautifully.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)
Add proper garbage collection ... and you
also dispense with memory leaks once and for all.
Garbage collection simply replaces the memory leak of forgetting to free() memory with the memory leak of holding onto a reference too long.
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
Video games and many other real-time applications are like that. Would you rather play a video game with 100 times the MTBF, or would you rather play a video game with 3 times the FPS?
code that has to run on the bare metal (kernels, bootloaders, ...)
There are several times more embedded systems in use on this planet than PCs.
The use of C(++) for document-oriented and database-oriented applications on machines at least as powerful as a PC has already begun to decrease as Java technology and its clones catch on, but C still won't be as marginalized as some claim.
Will I retire or break 10K?
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.
David Lorge Parnas have discussed the topic of software flaws from different angles. One I find very interesting is the one regarding our responsibility as sofware engineers.
Do we have a professional responsibility for not making software that a)We know will not work properly, b)Will harm people or the environment, or c)We lack the professionalism to produce?
At present the answer to these questions seems to be: NO!
I suggest reading one of Parnas' papers, SDI: A Violation of Professional Responsibility, where he presents the arguments for leaving the SDI (Star Wars) programme due to his belief that such a system could not be built properly.
-- Recursion n.: See Recursion. -- Random Shack Data Processing Dictionary
yes, I know there are a couple others, but I thought I'd show something more..
How many prime numbers are there?
There are infinitely many prime numbers. The oldest known proof for this statement is a reductio ad absurdum dating to the Greek mathematician Euclid. The argument goes as follows:
Assume that there are only a finite number of primes. If you multiply all the primes together, and add one, the resulting number, when divided by any of the primes, has a remainder of one. Therefore it cannot be divided by any of what were supposedly all the primes, and it must be another prime, or divisible by a prime that we have omitted from our list of all the primes. We arrive at a contradiction, so our original assumption (that there is a finite number of primes) must be false. So there are an infinite number of primes.
http://www.wikipedia.org/wiki/Prime_number
bananas like monkeys.
Trying to ssh/scp using kio_fish and konqueror, files from an underlying suse installation.
Fourth time I'm running down to the basement to push the damn reset switch on the box tonight.
I won't even mention not being able to get a 3com 509C card working on another box with knoppix.
The debian that crashes more often than a cheese eating surrender monkey!
Oh well, if you can't get pyDDR try "worm" instead. It will practice your vi movements. Put on some headphones and sync your hjkl pressing to the beat. That'll lern your computer to sing and dance.
Friends don't help friends install M$ junk.
C and C++ have templated containers -- Java's just now getting such genericity.
C does not, nor has it ever, supported either generics or standard containers. Yes, you can technically kludge something together with nasty preprocessor #defines, lots of void pointers and awful casts, but at that point you can say that C supports logic-based functional programming (ala PROLOG)... after all, with enough code any Turing-complete language can emulate any other.
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
imho because operating systems have got much more complex as the feature set grows and therefore so has the code underneath meanwhile humans havent got more intelligent. The time allocated to get stuff out the door has decreased especially in this desperate IT environment which doesnt help.
Theres ofc the biz incentive to ensure a fault rate. i.e I recently had to buy a new power supply for my HP printer, of course it had been price fixed to cost nearly as much as a new printer, way in excess of its actual production costs. A nice little money spinner and the odds are the average consumer will buy it vs. a whole new product.
So it's been running (and I'm logged in) since Dec 12.
Don't be fooled by the idle time, I'm logged on to the console only to start X
Beware of Programmers who carry screwdrivers. -- Leonard Brandwein
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!
Shouldn't affect the computer as a whole - should just segfault when that compiled program is run.
Get your own free personal location tracker
Like Agent Smith said: "Some believed that we lacked the programming language to describe your perfect world." Software crashes just like software has bugs, that simple.
You don't have to test everypossible input.
Each function can be proved to work by reducing it's functionality.
Lets say I have a simple function
increment(a){
a=a+1;
return a;
}
This function will work as expected for every value of a that is smaller than the maximum size of a, I can prove this and don't need to test every possible input.
I should really change the code to
increment(a){
if a == MAX_SIZE_OF(a) then error(OVERFLOW);
a=a+1;
return a;
}
thank God the internet isn't a human right.
My take is that there are problems with the process of creating software.
... process is far to often ignored. How many software managers out there believe that the sound of keys clicking is indicative of "progress"?
My first belief is that there are no "user errors" that cause software to crash. Hitting ctrl-s should not cause the word-processor to crash, taking out your thesis.
Secondly, the software design, develop, test, redesign
Third, there are an aweful lot of extremely bad software-designers out there. These are people who fail to understand how to compartmentalize their design. Compartmentalization should always be done with a view to minimizing software complexity and reducing the number of failure cases. A simple elegant well-thought-out design almost always performs better than a complicated over-engineered for speed design.
Finally, programmers are people - subject to personal problems and limitations in what they can do. I've had the pleasure of working with several very arrogant egotistic project leaders who's projects consitently fail. Nothing pisses people off faster than having their code removed from the CVS and replaced with the bosses' that doesn't work and fails to handle special conditions, esp. when the check-in is done after office hours and the e-mail states "it works, its staying".
Bottom line: hire good designers, technical writers and programmers. Never hire idiots to save money. Carefully screen project managers, and choose only those ones with success under their belt.
When I buy software and pay good money for it, failure is not an option.
-Brett
try this in VB, you'll get i + 1 = i
Dim i As Integer
i = 32767
On Error GoTo printi
i = i + 1
printi:
Call MsgBox("I = " + CStr(i))
thank God the internet isn't a human right.
There is such a thing as a reliable operating system.
KeyKOS was one. EROS is another. Check out www.eros-os.org for the details.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
The Meta-level Compilation groups Stanford Checker is doing the same thing for linux (and others). Faschinating tech in my mind.
Belief is the currency of delusion.
A-fucking-men dude!
Small pieces are the way to go.
That's how we overcome human limitations,
build the systems out of no more pieces than we can understand. If it needs more, make it into a two stage project where each piece is less than the managable complexity.
As an aside, people piss me off when they claim "but software is so much more complicated than a car!" Fucking whiny losers... Let's see them do the materials science to build a decent car tyre...
"But that's a problem that's already been solved" Yeah, well someone had to solve it... the genius was that we developed standards and concepts how to REUSE that knowledge. Building a new car? Make your wheels standard size and buy the tyres from Michelin or Goodyear (for "freedom" loving types).
RDBMS is an example of this in software, but there aren't many more good examples and that is part of the fucking problem. Software is as immature as we make it. Since we can't make good libraries, we can't make good software. The sad thing is, we seem too dumb to fix it.
And yet it continues to fly over your heads... sheesh.
It's like it's subconscious, or something.
/Hmm
I, too, practice what I preach. Oh, and btw, I have nothing but good things to say about the stability of Win2K. But maybe you're using Win98?
>>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 fastest route from NY to LA is computable, it takes sometime, but its small enough to be handled by anymonern computer with ENOUGH RAM to hold the graph of the roads. Have you ever heard of Dijkstra? With Djikstra you can solve single source shortest paths, even with your PC for large problem.
Also NP-complete graph problems are STILL computable it takes just takes LOTS of computing resources and time, (Travelling salesman) but its not infinite, like infinite state machine. NP-complete is still way beyond solvable with current computers but its in reach withing 40 years, for medium sized problems.
Its all how much computing resources you have vs size of problem. One grows 2^(sqrt n).
If we can make 2^30 processors each handling 2^40 elements per second and we could afford spending
2^30 seconds with it. The result would be 10000 element size travelling salesman problem would be solvable, as absolute manner. And making this happen well there is moore law, and with enough cash to get power, and chips it will be solvable.
The infinite state machine still is unsolvable problem, because its infinite. Finite data, with finite solving algorithm is solvable it just MIGHT take more computing resources than you have available currently, depenending on problem.
No I'm not compsci major but Electrical Engineering Major.
Emacs is good operating system, but it has one flaw: Its text editor could be better.
My last game was written on a machine with 640 bytes of work RAM (none of this luxury "K" malarkey). Although admittedly the CPU is a bit faster (3,375kHz). And yup, I'm grateful for 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!
Moron.
simply no.
Inaccurate history. Inaccurate on modern day civil engineering. And ignorant of principles of proving software - something that has received BILLIONS of dollars of study in universities and military establishments worldwide.
Google it and learn; or go on to the next Slashdot article and charm us with the crumbs of opinion you've gleaned from sundry sources and mistaken for actual knowledge.
and if you tell the young people of today that, they'll never believe you..."
time to program games??? sheeesh!.
"Empathise with stupidity, and you're halfway to thinking like an idiot." - Iain M. Banks
or something like that...
"Empathise with stupidity, and you're halfway to thinking like an idiot." - Iain M. Banks
that are violent and kill washington state law enforcement officials.
They prefer fancy features, cool theming, and they like to rave about new releases. They want to be able to read all the Word-documents they receive by email and they want to browse all the badly written web pages. And that is, what they get. Making a stable system would have meant significant redesign long ago, would have been expensive, would have meant long development time and even longer testing time. Who would have paid for this? You?
Calm down and stop putting words in my mouth. I didn't claim any of the things you manufactured - but I have a fair amount of data under varied conditions and the life of the OS - and he has one buggy machine. Do the math. I believe he's telling the truth - but I also believe he needs to get the thing looked at. What's your solution? The overwhelming user experience with OS X is that it is sterling compared to most other OSs. If it's unstable for you, dump it or fix it. But it is clearly possible to treat OS X pretty poorly and do a lot better than you are or the above poster is doing with OSX. Your 12" G4 has only two video outs - VGA adapter and S/Comp out - if disconnecting either of those is causing a kernel panic - get it looked at. It's obviously under warranty and you can make it better. Or continue to act like you are and post things like that.
"Win treats sysadmins better than users. Mac treats users better than sysadmins. Linux treats everyone like sysadmins."
Your DM was an asshole.
McD's doesn't make food that's good for you. But they make lots of it and they profit by it.
M$ doesn't thrive on quality software, just software with lots of bells and whistles, marketed well to the masses. And they profit by it.
Unfortunately, MickeySoft sets the BAR.
It IS possible the write qality, bug-free, software that doesn't crash. Just nobody has found a way to profit by it.
Here is a link to the guidelines.
Jumpstart the tartan drive.
Another way of looking at it is to look at top-end race cars (Formula 1 etc.) They cost millions and break down pretty regularly- for some it must be approaching 1 failure every 50-100 hours.
So now think about IT. We have an industry that is pretty immature running on cutting edge technology. It's like giving a modern day race car to a 1930's mechanic. It is simply not going to run reliably.
Ford made billions selling cars that were good for their day (they still broke down, you had to know where to put oil and water, you had to be careful not to flood the engine when starting) but now they just run and all you have to do is get them serviced once a year.
Bottom line -- its about market forces. At the time ford was selling the Model T, Rolls Royce were selling much more expensive cars. They both still sell cars of different quality to different markets.
If you want more reliability pay for it, if you want something that for all practical purposes does the job, go for the cheaper option.
Art is the mathematics of emotion
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.
The Freemasons were founded in the 18th century (although they are fond of claiming to be several thousand years old, and it's more fun that way). You are thinking of just plain masons, without the 'free' and without the capital letter.
Masons: build stuff from rock
Freemasons: walk around in rooms with checkered floors carring dividers and set-squares
Or, to put it another way:
Masonry: craft useful in construction
Freemasonry: last offshoot of neoplatonic philosophy (or at least symbolism) in mainstream western culture
OR, to put it ANOTHER way, you have inverted the 'learn, then teach' process that works so well when done in the right order.
Whence? Hence. Whither? Thither.
I can not over emphasize how vitally important it was to get something out the door - right away. They said their stuff was shipping weeks before development was complete.
The idea of thoroughly testing the software would have been a joke.
Still, if the OS (MS-DOS at the time) was more stable, at the computers would not have crashed.
I'm a career programmer with 20+ years of PC
experience. Here's my summary
1. Scientific American ran a study about the
fragility of systems (NOT computers). Their
conclusion was the more interdependencies there
were between systems the more likely a system
was to fail. There are more systems today and
much more interconnectedness.
2. In appropriate focus and lack of experience
by designers and managers. Too many designerd are
technophiles who put in features because they're
cool not because they're useful or good. Too
many managers (ATI graphics card drivers anyone?)
push product out the door with flaws because
of market pressures. Are you boycotting ATI
because they build awful software, or buying
their cards because they're 'cool'?
Those are the big ones, there are lots more
but those catch most of it.
It's interesting how little has really changed in the past 5 years...
Best Slashdot Co
Why Do Airplanes Still Crash? Why Do Cars Still Crash? Why Do Computers Still Crash? Why people always make mistakes? Because we are only humans.
that this post got moderated up so high, but this post, which is more on topic and well written did not. Moderators, please pay attention.
Join Tor today!
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 &
Another classic from egg troll. What a guy!
Then that is not your concern. Sad but true.
It is something that too many people overlook - you work for an easier time when you are not at work, business is business and NOT your life. Society is far too work focused when it really should rate extremely low in the big scheme of things.
Cheap web hosting from three shiney red pills a month.
I'd just like to point out the *BSD projects are "managed" with these principles in mind. A lot of the work going into BSD is the result of doctorial theses and other strict academic work. As a result, there's intense peer review, both immediate and those reading whatever journal you are trying to get published in, and a lot more consideration to provably strong design.
And I definitely agree that software is not more complicated than a car. Anyone who thinks software is more complicated has never popped the hood. Hell, cars also embody a lot of software these days. Plus, while most people can crank out a program, I doubt any of them could even draw out a design on paper for a vehicle that works.
Join Tor today!
Avionics software must be developed in compliance with RTCA DO178B to be used in aircraft certifed by the FAA. Creating such software is expensive and labor intensive. But, even then redundancy is need to provide the necessary reliablility. Flight control systems on large airliners have 3 or 4 computers that 'vote'their outputs.
Drawing conclusions are left as an exercise for the reader.
But if they did, and everything worked just fine, who whould continue paying to them for upgrades and patches?
Software is not reliable simply because there are enormous pressures to release it as soon as possible. Since you can't not develop the software and still release it, software companies are making up the time in QA. Honestly, I think most developers, given enough time, could write perfect code. That's the nature of them, they constantly seek to improve and refine their code. At some point, it would become "perfect" in the since that it would do everything as expected. Here in the real world, developers only receive a fraction of the time it would take to get to that point. So, we can assume that in most situations the code that goes into modern software programs is less than perfect. QA's job is to find where the imperfections are located, to hopefully speed up the developer's work. This system, without external pressures should work to create extremely stable software. Then marketing comes into the picture and chaos ensues. Marketing wants this software at such-n-such time. That forces QA to take risks in their role, and test only what's considered a "reasonable" amount, usually far removed from a complete test set.
So what's the result? Developers are forced to hurry their coding, tinkering, and refining. This passes some risk to QA. QA is usually even further behind the developers. Thus they are forced to test only a sample of what would be considered "complete". This adds to the risk already passed on from the developers. In the end the marketing department gets to release Microsoft Windows. Developer refinement and further QA testing occurs post-release and gives you the much-loved "Hot-Fixes" and "Service Packs".
In the end, the only one to blame is the End-User. We live in a world of instant gratification and expectation. Demand for things is immediate. Marketing's purpose is to meet those demands; thus they put the pressure on the rest of the cycle. And that, ladies and gentlemen is the circular prophecy of modern software development.
Flame on....
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?
The real question:
If we were to make computer crashes a thing of the past, what would we have to do?
Anyways, I'd say that *nix is pretty stable with uptimes of hundreds of years possible.
MAKE YOUR TIME
Timeliness|Price|Quality
This tradeoff exists in all facets of the economy. Turns out that in software (OS or otherwise), most are choosing the first two.
Support a few technologists in Washington.
Lots of people here are defending users and blaming programmers for computer "crashes".
I'm a network administrator and I have to deal with these users every day. The typical user will define a computer "crash" as anything the computer does that the user did not intend. That situation may, or may not, be a "crash".
Yesterday I had a user complain that Appleworks crashed on her while she was working on a document. It turns out the program threw an "IO error" when she saved the document.
Guess what caused that error?......a bad FLOPPY! I asked her if she kept a duplicate of her document on the server, but she said she didn't. It seems her floppy disk was 3 years old and it had just given up the ghost.
She thinks the computer crashed. In actuality it hadn't. How can you blame the system architects/programmers for that?
Some programmers may be lazy, but that's nothing compared to the stupidity of some users.
-ted
In answer to whether people would pay for something that's broken (ie. would people pay for a car that won't start reliably).
People do. All the time.
And you wonder why so many great author's say humans are stupid? We sell to the lowest common denominator. It's the few greedy, lazy or otherwise simply stupid people that ruin it for the rest of us. It will NEVOR be resolved. There's nothing to resolve. This is the way we are designed. Until someone fixes us, this will not likely change.
"Last one in is a rotten goblin!" - Kepp
...cometh great responsibility. He who cannot handle that power should not take on that responsibility. Thus it always was, and is, and for ever more shall be.
Here endeth today's reading, which was taken from 1 Life, verses 1-3.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I had read an article a while back where it came to the conclusion that software has gotten worse due to programmers not checking thier code before they compile it, but instead just bouncing it off the compiler until no errors pop up. Remember, you no longer have to schedule compiler time.
Now consider the difference between hardware and software:
Software can have millions of lines of code.
Hardware can have millions of transistors.
Software can usually be patched in the field.
Hardware can rarely change once sold.
To run a new batch of software, someone must only compile it, and then test it.
To run a new batch of hardware, someone must re-layout the PCB, buy parts, get the board stuffed, and then test it.
If a piece of software breaks, it can often be patched.
If a piece of hardware breaks, it has to be replaced.
Basically:
It costs big money when hardware screws up, so companies spend time making sure it's good. But software doesn't have immediately visible high costs. And it has more of a "black box" mentality.
-
If you think education is expensive, you should try ignorance -- Derek Bok, president of Harvard
Why do programs crash? There are two main reasons:
You also can have the problem of non-technical management that doesn't have a clue how to develop reliable software (or software period). Keep in mind that many people today have very low expectations with regards to the quality of software. If it doesn't need to be reliable to sell well, why spend the money to make it reliable?
Think about it. The commercial software vendors are making software to make money. Many times they couldn't care less about how well the algorithms were implemented, or that the architecture is solid, etc.
Quality software comes from people that are passionate about their art, not from a profit (at any cost) oriented corporation.
I got an error when I tried [9], [+], [3], [=].
It turns out that I was really supposed to do the following:
[9], [Enter], [3], [+] and it responded with the expected "12"
Reverse Polish Notation, really cool, is.
-CausticPuppy "Of all the people I know, you're certainly one of them." -Somebody I don't know
Are written in assembly. Have you ever taken down a VAX cluster with one wrong assembly instruction, you should give it a shot. Crashing PCs is for minor leaguers, try knocking off a machine that has 50-70 users on it at the time.
When you start building "fault tolerant" programs, you also risk having subtle bugs live for a long time and then all of a sudden explode in your face.
If we want to reduce the error rate, we should do it the right way: Spend more time in the design and fault detection/correction phases. That is boring, and it produces less revenue. But it works according to everything I've read about the subject.
Stop the brainwash
it's obvious isn't it? if the hardware is better, it MUST be the software! =D seriously though, it's crappy drivers and incompletely tested/badly written code. given that I manage/aid in managing 100+ 2000/NT servers, and half (if that many) netware servers (which work better), not to mention the toying I do with linux and *BSD's in my free time, I'd have to say that lazy programming is the reason that most problems occur. sure, a meteorite fragging your hard disk, or using it as bullet resistant armoring will cause errors, but not as often as bad code will. that was the whole reasoning behind OpenBSD, to ironically, shut that puppy up tight. by correcting bad programming they have built a very secure OS. maybe there's something for microsoft to learn here. perhaps instead of adding crap on top of crap, they could audit their code instead of letting 5kr1p7 k1dd3z do it for them...but I'm just one raving lunatic that will likely never progress past windows 2000 on the MS frontier. slackware for me!!!! =D
>>> Why do cars break down?
This hasn't improved for how many years??
Sven...just wondering
Software and developemnt strategies have changed, but the laws of economy haven't. The 80%-20% principle and all that is still there.
Which means that buggy, error-prone software will always be around since no companies think it pays off to fix bugs.
Are you crazy? Think how many security holes they're open to at this point.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
I don't think so. Try doing some "real world" work with a Windows box and see how long it stays up. Games and loads of other stuff you use are stable and well written and NOONE would buy them OR use them if they weren't. In the business world software sales is about making money not stability. Crappy programming practice should'nt bring a whole system down....and it does when it comes to Windows. Blame Microsoft for the culture they created that thinks it is OKAY to reboot once a week.
A VIA EDEN system can run on 20W of power. It'll run Linux happily, and fit in a box not much bigger than a CD-ROM drive. Will that do?
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
Time is money.... Money is time.... The software made more fast.. is more money... more fast .. small time to project the software... small time to project... error is founded.....
Programmer's have to deal with lots and lots and lots of undefined behavior. Language specifications contain undefined behavior, I know C++ does. APIs include lots of undefined behavior.
You can read "undefined behavior" as "may work fine in testing, but breaks in the real world." I've seen C++ undefined behavior that works fine in unoptimized builds, but crashes with the optimizer turned on. I've dealt with API calls that work fine under Windows 98 and crash in Windows 2000 (or was it the other way around).
Now a good programmer can make sure he doesn't do anything undefined if he's careful enough, but it sure makes the job harder. The amount of undefined behavior that software development involves makes it more like the medical profession than other engineering professions. Asking why computers still crash is like asking why, with modern medicine, people still get sick.
Of course, with new languages and new APIs, we may be able to escape this problem and make programming more like engineering.
What's a sig?
If software has always been about as reliable as it has always been, doesn't that mean that software is just not that reliable?
Take a risk analysis course.
-P
What the heck causes that? That is the single most screwed-up glitch I get from windows. It's bizarre-- instead of just failing, the code actually exhibits the rather complex random behavior of making icons for some programs look like icons for other programs. Utterly baffling.
The question is why do computers crash, not why
do programs not do what is expected.
Basically, people write programs to work, not to fail. If people wrote programs to "FAIL"
we wouldn't have all this crashing nonsense. What I mean by failing is, every command must be considered to fail -- and the program (or OS?) must recover gracefully. Personally, I'm so tired of open source programs that are written for exactly 1 instance of an OS (that of the author).
Secondly, programs need to be more resilient and graceful. That is, a program or programming language needs to ALLOW for commands to fail.
This about null pointers... these should not
cause a program to crash, the program should just go on. Code would basically be of extremely simple components, but with a completel level of reslience.
For instance... just thinking out, something like:
program command to do something (can't crash)
look for anything strange, if so, is it related
to me? does it affect me? if not, continue.
Think about what it takes to get you from your bed to the closest mcdonalds. That program alone is virtually impossible for many instances, but it should be trivial. Think about what you do as a human -- this is all a program has to do. Ya, if you *choose* to take a car and another car hits you, you could say that you crashed... but if you're not hurt and you continue to mcdonalds, then the accident wasn't fatal to the goal.
I'm sure people will not understand this, or people will claim it is already in place, etc.
It is difficult to explain this here in a short manner, but I wanted to put some fodder here for the kiddies to misunderstand and tear apart. The
responses will only hepl me make things better.
...but in ourselves. We don't take time to do the job right. We concentrate on trivial stuff like skins and ignore important stuff like does-it-work. We don't hang coders caught reading from a socket into an 'auto' buffer. We release undocumented products (which means we don't even understand our own creation) and stick the end user with solving a black-box problem. As customers, we continue to exchange good money for others' bad code and don't complain when it fails.
Incidentally, the reliability of million-dollar computers, which is what you were using 30 years ago, has improved *enormously*. It's the reliability of $299.95 computers you find at the supermarket which is questionable. You can get much better stuff if you're willing to spend a little more money and, more important, a little more time learning about the in'ards of the products.
Just shows how much you know about DNA & genetics... :]
The timing of the entering of input into a program may affect how it runs too.
Eat at Joe's.
.. there are many critical systems glued together with very badly written scripts (shell, etc). They work fine as long as there is not a problem or delay along the way, at which point they fall apart.
For example, we retain 60 days worth of logs and reports. The original script looked at the system date, and deleted any files older than 60 days. Simple, except for when the clock skewed wildly (to the year 2020). All history data was deemed more than 60 days old and deleted.
I altered said script to delete anything older than 60 days and newer than 61 days and the problem went away.
In another example we have several important EDI files that go up to a broker system each day. There was a plain old upload script, called from another script, that would upload the files and exit. The calling script would then delete the files. This was all fine unless of course the FTP failed, which it did fairly often.
Of course, because there was no error checking to see if the FTP succeeded, the files were erased regardless, and an administrator had to log in, rebuild the files, and run the upload script. Fine, but nobody knew usually that the scripts had failed until the broker called or e-mailed about it.
Seeing how much time this wasted I wrote a quick Perl script to do the upload, and report back by email to the administrators if it failed, along with why (couldn't connect, login info rejected, etc). On failure it queued up the files to go later, rather like a mail queue. Again, a little error checking goes a long way.
If you don't bother with error checking, it will almost invariably come back to haunt you.
--- Commission free trading & free stock up to $500 - use http://share.robinhood.com/kelvinp6
I have w2k sp3 and it has never crashed on me, although I have never tried crazy uptimes because the fan is too loud. However, I also have a 5-button optical intellimouse and back when I tried to install the stuff on the CD that came with the mouse, it said it had to reboot. That was ok until it told me to press ctrl-alt-del to log in. The new intellimouse software had somehow disabled my keyboard and mouse (both with PS/2 connections). The only solution I could think of was to do a complete reinstall of 2k.
As far as features vs. stabiltiy goes, I can forgive Opera7 the odd crash, IE is less stable and doesn't give me the lovely safari-style skin or tabbed browsing in multiple windows or mouse gestures or continue browsing from last time or only accept requested pop-ups. Go Opera!
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
Could it be because of management (see rules 5 and 6)? In case anyone was wondering about the ground rules:
Corporations 101
(for the new employee)
1. Management is not there to help.
2. If you actually understood what management was saying, you would quit.
3. Don't bother trying to understand what role management plays in a corporation. They don't know, and nobody else does either.
4. If you don't do what management says, everything works out just fine.
5. Excellence is the farthest thing from management's "mind." Uppermost is fooling people into believing that it is.
6. Management doesn't mind presiding over a corporation comprised simply of itself and a Human Resources department. And often they get by without the Human Resources department.
7. Stock price is the barometer by which one can tell how well management's retirement fund is padded.
8. The CEO never gives a f**k, and banks upon being quietly and summarily dismissed.
9. Every executive hopes to become CEO.
10. This is the best system the world has to offer.
While loading the first page of comments, my Zaurus ran outta memory and crashed. Figures.
hang brain.
When the software is buggy, the software developers can earn more money... by making you upgrade to a newer version... offcourse they implement new bugs there ;)
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
You can reference array elements that do not exist in Java too, and in any other language. The only difference is that Java will throw an exception, while a C program will crash. As far as the user is concerned, the result is identical - bye bye data.
damn lynx deleting my post. anyways ive crashed many a nes, snes, and otherwise... it is possible. while without a doubt dust 'forign objects'(dust/dog hair/etc) is the most common reason for a crash, hardware failures(*cough playstation*) and even design/software bugs do exist. though i didnt know it at the time for what it was, i remember finding with my friend a bug in Final Fantasy I that was repeatable in both our respected cartridges. and that was in the days before complexity of hardware/software really began to take off... i personally can imagine an 8 bit system that doesnt crash. 256/128 bit? thatl be the day... theres just too many things going on.
that being said i once said that i thought that the first ai(a very youthful me, innocent and naieve as i was) would be a next generation(from 98) windows machine that was left up too long and crashed -- and that this crash handling was the first stage of consiousness. why not? mabye crashes in the future will be used to accelarate our technology by giving it *depth*...a randomness(or so i thought before i learned of hardware clocks and random # genorators)...and uniqueness.
GENERATION 26: The first time you see this, copy it into your sig on any forum and add 1 to the generation.
Well, really it is simple. If you want everything to be more reliable you will have to pay more for it - development and debugging cost money and time. Time to market is often an important factor and hence the software will be released with testing only to ensure some mean time to failure, if that.
Software could be more reliable, but it would also cost more, and most consumers don't like that... (or know what software is!).
-- Mike
8-PP
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.
While i wont disagree that ms makes far too much money on second (or third) rate software, i must take issue with the analogy about "if cars were this flaky, we would.."
part of the computer problem is what people do *after* they turn the box on.. they install all manner of commercial software and other shareware.. they buy peripherals and upgrade their box with more memory, etc.. I liken this to if consumers were to attempt replacing their own transmission in the car, especially with non-mfg parts.. and then became upset that something doesn't work quite the same
if folks just set up their box stock and didn't go around mod'ding it with software/hardware all the damn time (i agree this is hardly practical, but for the sake of arguement..), they'd probably have a much lower failure/crash rate. They're no less complicated than a car, but computers are asked to be much more flexible in their task. That flexibility is going to introduce more potential problems..
It is trivial to add runtime bounds checking to a C++ class by putting an assert into the operator[] implementation. If you feel you need more information, you can actually throw an exception (possibly inside a #ifndef NDEBUG) and fill it with the crash context as you unwind the stack. Java did not invent exception handling. As for your problems with memory management, they result from a failure to adhere to the cardinal rule of memory allocation: delete allocated memory in the same scope where you allocated it. That's what Java enforces for you. Memory allocation is easy if you know exactly who owns each block, and if you ensure that this ownership is consistent and preferrably non-transferrable. Any memory management nightmare you encounter is always the error of a programmer who does not know who owns his objects; and there is absolutely no excuse for such irresponsible behaviour.
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.
Strangely, system crashes don't generally happen on video game consoles. There are a (very) few exceptions to this rule.
Of course, there are some reasons for this: video game consoles always have the same hardware setup (that is to say, every PS2 is functionally identical to every other PS2, software wise), and the user can only really input through a simple controller. However, as the systems become more complex, they start to resemble a full-fledged computer system more and more. So the question arises again: Why?
Standarization. You never have to download new drivers for an Xbox or Gamecube controller (even if it is 3rd party) because all such controllers conform to an interface standard. Multi-player adapters are always plug-n-play. To a computer developer, this sounds like a mythical la-la-land. To a console developer, this is a given.
Happiness is relative, Based upon the way we live.
NEVER ONCE have I had a problem with this OS made by the 'evil ones' except for when IT WAS MY FAULT. Either I overclocked my machine, installed beta drivers, or just did something very stupid. IT HAS NEVER crashed on its own. Might I note that through all of this i've been using a radeon32 then a radeon 8500 and i'm sure there are others out there that can vouch for me that radeons were never really supported by win2k at first, but then ATI got their act together and wrote some decent drivers, BUT EVEN SO, the drivers that were out there were stable enough to call my box a workstation.
but I'm going to have to disagree with you on most of the points here.
For one, I've got a Windows 98 box (se) that I've been running for about three years now with no crashes, no reinstalls, etc. etc. I turn it off now and then to deal with the memory leaks in IE but other than that, it stays up. The reason I've been able to keep it stable is because I closely monitor the software that's installed and running on it. In my experience, Windows only crashes if you gratuitously install every piece of crap software that's offered to you. And if you do that, really, you deserve to have it crash.
Windows aside - I've got a FreeBSD box that *never* goes down. That's with several dozen sandboxed accounts on it, each of which is running its own web services package - sendmail, apache, mysql, any custom perl scripts the users want to install, etc. etc. Unless you're a clueless sysadmin, running *nix can generally guarantee that your system will never crash. Individual programs, yes, but not the system as a whole.
Bottom line is that if your machine is crashing, you're either using crap for an OS, or you're installing crappy software. Keep your system clean and running only what you need it to run, and you should see your crashes go away.
--- 11 meters/second, or 24 miles per hour - the airspeed velocity of an unladen European swallow. Really.
that's like asking why do vehicles still break down? ahhh, the perfect world. we wouldn't know what to do. let's start out w/ the power going out & you are late for work.
but have you ever actually written any large piece of interactive software? What about any large piece of multi-threaded/multi-user software? The reason I ask is because it is *impossible* to predict, when you're writing the software, what bizarre combination of input your end users are going to come up with.
It's all well and good to gripe and moan about how the people writing software should write it to handle errors, (and you're right, they *should* write their code to handle errors, there's no excuse not to,) but I don't think you can safely blame everything on shoddy coding. There's just no way to predict every possible combination of input, particularly on a large or complex piece of software. And just writing good error handling code isn't going to change that.
--- 11 meters/second, or 24 miles per hour - the airspeed velocity of an unladen European swallow. Really.
Shit breaks, and that's all there is to it. Nothing in this world is perfect. Humans are not perfect, they do not make perfect things. Saying we should have computers that don't crash is like saying we should have cars that hit 200 mph in .01 seconds, generate 0 emissions, and never ever ever need repair or maintenance - esp cause we've had cars longer than computers. You are asking for perfection and that is not humanly possible.
I have to echo some sentiments already posted about increasing complexity and the ability to control the environment to prevent crashes (of which there are all sorts of kinds). I started in programming 20+ years ago but over the last decade have mostly been involved with systems integration and consulting, and so have run the gamut from designing programs to ripping out my hair over trying to use them and the systems they are supposed to be running on. Many different platforms have been mentioned in these posts, but I think there is a common facet to them all; the ones requireing limited hardware and software compatibility (and support fewer applications) are going to be more stable. It's easier to control the environment, and there are far fewer developers and customers to have to work with Microsoft is in a position unlike other OS vendors; They are providing and supporting a family of OS's that are trying to handle *every* kind of user from a single home user to small businesses to fortune 50 firms with tens of thousands of users, and at the same time are striving for interoperability with other operating\file systems, compatibility with probably tens of thousands of peripherals, hundreds\thousands of PC platforms, etc, and that finally have a huge installed base of somewhat computer illiterate customers.. And, they of course have a huge installed base of older OS versions that they have to support. I think any vendor in their position, with today's overall environment, is not going to be able to do much better in terms of limiting crashes. To the open source supporters - I think that if open source gets what it wants - reaching the masses - it's going to have the same problems the larger the number of customers it gains, the number of platforms\peripherals\software products open source will be asked to be perfectly compatible with will increase drastically, and those combinations will be "stressed" much more than they are now by the larger volumes of users. It seems like open source took a long time to support even some basic common peripherals in ways that typical consumers could deal with. If you took an open source platform like Linux and suddenly put it on the current platforms of several million end users with legacy systems, I would guess there would be widespread serious problems, and those users would have no one to go to for quick fixes. No "typical" user is going to be satisifed with being told that if they have a problem, they have to wait until a random user in similar circumstances with a *nix programming bent decides to poke their nose around and try to fix the problem in their spare time. That might work for a small core of very common platorms and products, but won't hold up to the thousands and thousands of hardware and software components out in the real world today. Which is why I think that while a LAMP server on a common platform might be extremely viable for businesses, the same OS\hardware setup might (probably would) fail miserably for the typical end user masses as it stands currently. All that aside, no matter what platform you are discussing- as a user of these systems, I find the basic architecture of the PC platform very frustrating, and ..ah .. crude considering all of the years of development there have been. Just look at even the basic hardware design - why are we still having to risk finger cuts to insert stubborn PCI boards into tight slots and having to try to screw the damn paddle boards in - why no boards in pluggable cartridges like a video game console, for instance? It's a small (stupid) point, but kind of shows that after all of these years, we still have a platform that has way too many individual component suppliers (hardware and software) and little standardization, quality, & error control. And I think that when OS vendors have to let all of these vendors play directly in the same sandbox, trouble is always going to happen.
It seems to me that we are never going to accept, en masse, complete proprietary hardware systems from sin
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
I know this is slashdot, but what about Win2000/XP? I've only had XP crash when I used old software drivers. Since then it's been fine.
Ok, I haven't read any of the comments, but this sprang to mind instantly: Have you ever tried to write a big program? I don't mean a measly 2,000 line program, but a BIG PROGRAM? One that spans at least 50,000 lines? Ok, if you have, then you know it ain't easy. Making a program this big, or bigger, is certainly possible. In fact, it can be done, and has been done. But most companies aren't willing to take the time to make sure it's bug-free. Profit-minded companies just want to rush their product out to the market.
Did you know that many companies out there consider a program with one serious bug "releasable"? It's true. If you take too long to work on a product, you lose money. And that's what's unacceptable in today's market.
It's not the people or the computers. It's the market that drives the standards.
I, once, worked with a very insightful Finnish software designer who told me that champion software is characterised by (1) high quality, (2) low development cost, and (3) low time to market. He added that any two of the 3 are achievable, and that it is impossible to achieve all 3.
That's a good point. A scooter is designed for short-haul, and does that very well. Win9* is designed with the idea that most users shut the machine down once a day, so long uptime wasn't exactly the first point in the design specs. Whereas NT/2K was expected to be a 24/7 server OS, and is designed and behaves accordingly.
5 739 (beware the /. space) [g]
That said, *I* think it's normal for Win9* to run for weeks at a time, often working its ass off -- before TurboTax forcibly installed IE5.5 and FUBAR'd resource management on this Win98 box, it routinely had uptimes around 6 weeks (usually ended only because I wanted to use it in plain DOS). And it crashes at worst only once or twice a year, and has *never* BSOD'd. (In fact, most of my WinBoxen, from Win3.1 to XP, have *never* BSOD'd, and crash seldom to never.)
Computers, unreliable? Well, some folks' systems, maybe. But if I had a computer that was crashing all the time, I'd regard that as a clear symptom that something was wrong -- most often cranky hardware or sheer lack of maintenance.
See also http://slashdot.org/comments.pl?sid=45941&cid=474
~REZ~ #43301. Who'd fake being me anyway?
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.
Why Do Computers Still Crash?
So, he's used computers for 30 years, apparently not programmed them.
Other important questions:
Why do computers still cost money?
Why do computers still require power?
Why can't computers yet read my mind?
Why don't computers smell pretty?
Well, back to the crashing... it's all my fault. I'm sorry. I won't do it again.
Computers still crash because your average use doesn't care that they crash. All the computers he has ever used have crashed regularly and he accepts this as a fact of life. Not to point fingers, but the dominant operating system for the past 15 years has created a culture where crashing is an accepted, even expected, part of the computing experience.
Most people use computers in a task-oriented way. As long as they can accomplish their task in a reasonable amount of time, they don't care if their machine crashes once or twice in the process. They are not interested in tweaking things or making things run more smoothly.
I think people have a sense of powerlessness when it comes to computers. I have seen people continue to use machines that crash constantly, everything is a mess, hard drive is full, etc. for years. Members of my family got infected with some windows pop-up message annoyware, and they just accepted the fact that they constantly had to close these spam messages popping up.
Dilbert's Salary Theorem states that Engineers and scientists can never earn as much as business executives and sales people. This theorem can now be supported by proof based on the following postulates: * Postulate 1: Knowledge is Power. * Postulate 2: Time is Money. As every engineer knows: Power = Work / Time. Since Knowledge = Power, then Knowledge = Work/Time. Since Time = Money, then Knowledge = Work/Money. Solving for Money, we get Money = Work / Knowledge. Thus, as Knowledge approaches zero, Money approaches infinity, regardless of the amount of work done. Conclusion: ... left to the reader.
Is that JVMs are complex.
All java does is move (some of) the complexity off the application programmer's shoulders and onto the JVM/JDE programmer's shoulders.
In theory, this is good software design practive:since the JVM is written and debugged once, and reused over and over, it should be less buggy.
But JVMs are written by people like Microsoft, so they're buggier than heck, because they're rushed out the door the same way Windows is.
"you keep using that word. I don't think you know what it means."
Since you're offering your observation, here's mine: I've seen damn near the exact same thing said about every version of Winders (and yes, I can't bring myself to type it, live with it), and time and time again, it has been proven to be at best, marketting hype.
A nice haircut and a nicer smile are no substitute for critical thinking, no matter what the teevee tells you.
Overall a very good read, highly recommended.
they buy peripherals and upgrade their box with more memory, etc.. I liken this to if consumers were to attempt replacing their own transmission in the car, especially with non-mfg parts..
Yeah, but the operating system is designed to allow this. The hardware is designed to accept new cards. Why don't all cards have standardized APIs (thus not requiring specialized drivers?) That alone would solve a LOT of problems.
I'd say that adding peripherals to a computer isn't so much like changing the transmission, but like changing the radio. Certainly, you wouldn't expect an aftermarket CD player to cause your windshield wipers to not work. But we seem to accept that adding a Soundblaster Live! card will stop your Zip drive from working.
I still say it comes down to the industry, as a whole, not being forced by the consumer to design their products properly, and that no amount of theoretical improvements in design or engineering methods will matter a damn if they aren't pressured by the marketplace to implement those improvements.
Senior admins are a small minority of software customers.
You had me up until that point. Are you overlooking the fact that senior admins essentially speak for a larger number of people? Or that senior admins recommend purchases from enterprise-side rollouts down to workgroup-level rollouts all the way down to answering questions for anyone they encounter socially (I.E. from telling the secretary what PC to buy so little Johnny can out-frag the other preschoolers to answering questions every time they go to a family function, church, a bar, or any other kind of social function where the question "What do you do for a living?" is inevitably asked?). Yeah, if you overlook those scenarios, then you can definitely say that senior admins are a small portion of software customers. Whatever, dude -- there is a reason ThinkGeek.com sells shirts that say "No, I will not fix your computer."
Even superheroes once were losers
I know, its too late, no one will ever read this but...
I run memtest86 whenever i suspect a problem. Sometimes it has to run through warm up for the problem to trip. I had machines that took as long as 8 hours of memtest86 before they generated errors.
So, add $5 to the cost of a new machine for a robust memory system, or set up each new machine and bench test it for 8 hours, then whenever it crashes mysteriously bench test it again?
The market consistently chooses not to spend the $5 on robust memory systems in their new hardware. Its the pocketbook vote that matters.
"Most computer crashes are caused by an INTERACTION of two pieces of code that did not know about each other and were never tested."
A majority of crashes are at the kernel level. How do you suppose one would go about "introducing" their code (drivers), and ensure compatibility. with an OS which is not open source?
"1) accept a restricted operating system that will never be able to compete with a commercial system like Windows."
Yep - unix, linux, OS X - they are all so "restricted" and shrouded in a veil of secrecy. Ha. Must be why they are not "commercial", right?
2) Never install a program that was not A) created by the same company/group that wrote your operating system, B) specifically designed for your particular computer, and C) designed to be used with and thoroughly tested against all the other software that is currently installed on your PC.
You highlighted this while reading your Getting Started with Windows XP booklet - didn't you?
"That is what companies do when they make non-pc computer equipment (cars have tiny computers) and is the reason why such things do not crash."
You are referring to what is called an embedded system - your reasoning/comparison is sorely invalid.
Computer still crash because consumers in focus groups (you know, those people who must have an average IQ of 11 who have their ideas intepreted by marketing types with an average IQ of 3) state that they want more features, not more stability.
:o)
Development time being finite, stability never gets worked on - hence Microsoft Clipart at the sake of a version of Windows able to hit decent uptime figures.
Thankfully free software has less of a problem with this as mostly it's designed by geeks for geeks, and users and focus groups can go p*ss into the wind for all they care
Beep beep.
Modern operating systems? I must have missed something.
All we currently have is a 40-years-old loader programm for spacewars, which has been extended and patched until FUBAR...
And then there's this DOS thingy... with the teletubby-GUI... know what I mean?
So please, if you know of a modern operating system, tell us!!!
Same reason my frickin' Nokia cellphone crashes; because computer programming is still science, not engineering.
no cramming features in weeks before ship
This reminded me of the fact that often times it is management and the "got to get things to market yesterday or we'll never be able to compete and then we're doomed so cram these other features in and don't worry about the bugs we'll fix those in a patch later" attitude that causes software bugs.
Don't get me wrong. Coding quality between coders varies dramatically. But even the very best coder can only do so much when his manager is telling him he's got four days to implement some whiz-bang feature before code freeze or else.
Free yourself. Everything else will follow.
We are only human. No one is perfect. Not even "god", if you beleive in that sort of thing.
Besides.. Most of the time its the hardware that is crap, and the software has to "support" the crappy hardware. I know from experience.
Modesty is one of life's greatest attributes
Do you know how to troubleshoot at all? If not, take your computer to someone who does before bitching...
One reality of software development (or anything development, really) is that a product will only be as good as the customer demands it should be. Our economic system drives manufacturers to produce what the customer wants, and not much more.
So, if we all expect that our windows software is going to crash fairly often, when it does, we aren't surprised, and we don't demand better. (And how could we, Often times there's no way to tell it had anything to do with the software in question) On Mac OS X, we don't expect crashes so much, and when the software we are working in crashes, we view it as bad software quality, but some of us remember OS 9 enough to excuse it for the most part. For linux and (insert Unix-OS here) we expect our server apps to be reliable, and when they are not, we look for alternatives. When our Linux desktops crash, we chalk it up to beta software or whatever... but still it's an abnormality... but we forgive, after all, it's a volunteer project (most of the time.)
The crash-resistance of software increases proportionally with our expectations. Simple economics, really. Supply and demand, if we demand stable software more than whiz-bang software, we are going to get it. The majority of people don't. They expect computers to act that way. They are still 'technology' after all. People expect new technology to be problematic. We won't put up with half the problems on our home phones (not 'technology' in most peoples minds) that we put up with on our cell phones.
As someone else pointed out. NASA and The U.S. Navy do not run on unstable systems. The systems they run on have different levels of reliability because if they didn't, they would have bought something else in the first place.
Regarding languages and the quality of the code different languages produce, there is no correspondence.
A programmer who understands both the syntax and the programmatic idioms of, say, C, can produce code that is just as unlikely to crash as another programmer who has the same level of ability and experience with, say, java.
All to often people think that because they know the syntax of the language well they know how to program in the language well. This is simply not the case. There is much more to programming than being able to write code. A programmer who understands the idioms of the language, and uses them them during the design phase (yes there is a whole phase where you just think about how to solve the problem) tends to produce higher-quality code than someone who does not.
For example, if you understand pointers and you know how to safely use them, they will not cause you problems in your code. If you are not diligent about managing your pointers, you will have problems. If you don't know to use bounded string operations, you can have buffer overruns, is that the languages fault? no.
The complexity of systems is bunk too. Yes, systems are more complex. However, as long as interfaces are well defined, and the developer follows the rules of the api, you will not have problems. Once again, there are more than syntactic rules here. For example, the Cocoa APIs on Mac OS X (and gnustep) have very well-defined rules about who 'owns' objects. It is very easy to ignore these and produce working code. If you do, though, you will have problems with object leakage in your programs at best, and outright crashes at worst.
(yes,there can be bugs in system libs, but they occurs less often than bugs in joe developers code, in my experience, and are usually fixed more quickly.)
In short, I think there is no technical reason that applications and computers crash. The 'bad software' problem lies mainly with people, what they will accept and won't accept, and programmers who believe that because they can write a program in a language they know the language. There's a big difference between the two.
...we had total control over the hardware and drivers that we released.
We released a full embedded product, and so there were no user options to give us any hassle that way.
And that decision was by design so that we could ensure that it was bug-free.
For example, if you pop an SD Card out in the middle of a write operation, you will corrupt the data, no matter how bug-free your software is. Solution? You physically block the SD Card slot. Since we had to build an external shell for a couple of additional components anyway, it was just a matter of remembering that we wanted to block the slot off.
Kind of. I recently switched to KDE 3.whatever from 2.whatever (finally!) and it seems more stable in most respects. I occasionally have disconnects still between KDE and the X server, and sometimes the K panel or kicker or whatever they call it loses the ability to function.
Still, worst-case scenario is I have to 3-finger salute to log out of KDE and get to a command line, restart X, yadda yadda. Actually, I think one time KDE lost the keyboard too, and I had to walk over to the damned windows machine, telnet in, and kill X. But that was with KDE 2.
Ultimately, the beauty is that with linux, the operating environment has a layer between it and the OS, so the environment can't kill the OS. THat's how it was with windows 3.1, and it was great! No longer though, I suppose that was too stable. So no matter how many bugs that KDE dev team throws in, it can't hurt me! ;)
-Looking for a job as a materials chemist or multivariat
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.
Three words: Formal verification methods. The mechanism of mathematically proving your software to be correct. Languages like Eiffel are even designed with automated verifiers in mind.
[mark@mail mark]$ uptime
3:19pm up 57 days, 5:56, 2 users, load average: 0.15, 0.03, 0.01
The only time this computer reboots is when I update the kernel or I have a power failure. It never crashes and has been running steady for 2 years now.
Sure some Linux programs may crash occasionally but a majority of the system is stable and if you choose the right software it won't crash.
I can't say the same about windows.
Indeed. I couldn't believe this when I encountered it, but it's true. My desktop now only does powersaving when in Linux!
I heard that Win95 worked OK, but somebody at MS decided that as they couldn't figure out how to do IRQ allocation right for the supposedly more complex 'server market', they wouldn't do it at all, and everyone would get to share IRQ 11. Or something.
I am so surprised that i have not seen a post of this type so far in the ones below... considering all the people that use unices on slashdot.
:))
But... my computer doesn't crash. The one i have right now, with flawless hardware, never has... in the nearly a year i have had it. Previous computers haven't crashed on me, ever, except for when the RAM went bad in one of them.
I use Linux, as many people do here. What are you doing wrong that makes you even have to discuss this for anything other than on the behalf of the windows users?
Really, it HAS NOT CRASHED ON ME ONCE.
I load tonnes of stuff up at the same time, often have memory/processor intensive tasks running in the background at low priority... load is close to maxed out a lot of the time (there is always a new build of wine or mozilla to leave running at nice -n 19
And yet no crashes. Do i have a magical aura or something?
It didn't stop the Mac from getting popular.
Most people don't care if the OS crashes. It's annoying, but as long as data's not lost, we can live with it. Everyone here saves their work regularly and backs up at the end of the day, after all. Would that change if the OS didn't go tits up now and again?
The alternative is higher software costs to pay for herculean debugging programmes and other tactics nail the causes of crashes. I'd pay for that in an OS controlling a nuclear power station, but not for a glorified typewriter I play Quake on from time to time.
"And the meaning of words; when they cease to function; when will it start worrying you?"
Noone will ever see this post, but I'll answer anyway. The real question is, why are you running unstable software? Flaky software is common because that's what people are willing to pay for. Now the reason for that is bound up in cost vs. practicality, but software will be flaky as long as you buy flaky software.
(Um, I guess the question was about computers, so my rant applies to hardware too.)
Not that this wasn't entirely predictable.
quit your microsoft windows bashing
can your Dell/Compaq/HP computer run this?
http://www.mersenne.org/freesoft.htm
this will force your computer to do some calculations. the program knows the answer. your crappy computer will probably be wrong because it is an inferior POS with sub-standard parts. if you get errors from that program, then windows and all software within it will crash periodically.
if you can run that for 24 hours straight, then your northbridge, cpu and ram are ok.
every thread at this crappy site:
useful info
some guy comparing the info to something else
some guy telling the first guy that their is no comparison
5 pages of arguing about the comparison
the sum of all this is zero uselfull information until i degrade myself and post something here.
Does anyone think that there will never be bugs in software? Even if all software moves to open source, thorough testing, focus on quality, etc.? Check out the homepage for OpenBSD, the line that used to read "0 security vulnerabilities in the default install for the last * years" now reads "1 security vulnerability in the....". OpenBSD is a model of open source development with a focus security above all and I think most people will agree that they have built one of the most secure OS's ever. Admittedly, this is different than a system crash, but it's similar. Mistakes happen. Always will.
Side note: my windows XP box-0 crashes, win2k-2 crashes in 2.5 years, Linux box-0 crashes. Stability can be achieved on any modern OS.
I have to say I'm not innocent of it, as much as I wish I could be
In the end there are quite a few factors that ultimately come into play as to why an application I've built crashes:
- Laziness. I just simply forget to put in the appropriate error checking in place, and the user attempts something I didn't account for
- Deadlines/Cost. Unrealistic deadlines mean that, althought I'm loathe to release the product management doesn't care and demands a release anyway
- Something larger. There have been cases (I'm on a MS platform for most parts) where a known problem or undocumented "feature" actually prevent the regular operation of the application
All of these are avoidable, could be adequately planned against, and are completely inexcusable from an end user perspective.
And even as a developer I tend to agree. At the end of the day, I really shouldn't care what OS or processor my computer users so long as it reliably does all the work I need it to. I hope that day eventuall arrives.
Glenn
The Smrt way to trade CFDs on the ASX
My spiffy Asus A7N8X motherboard has yet to crash, you are probably running some junk from Compaq/Dell/Gateway etc. I guess you don't understand that the "big" pc manufacturers are in a mega price war and they buy the cheapest they can get. You will never see a top-quality motherboard in a "big-name" vendor's system.
Clickety Click
I worked at Psion on all the early devices as a software developer. The reason the software didn't crash was because it was designed from the ground up with quality in mind. The basic premise was, whatever happens, we can't afford to lose the users personal data in the machine, and the development process and OS design reflected that - with painstaking attention to detail.
The length of the development process was not significantly affected. We were still able to use C, and still had pointers. But we were good programmers, working with good tools with a great OS underpinned by well designed hardware.
In a word... good engineering. It's amazing, developers today don't even aspire to crash-free code - a reset is accepted as a fact of life. It doesn't have to be that way, with good engineering, as we showed.
BB
Part of the answer is that the size and complexity of software has continued to increase, allowed by the increasing speed and lower cost of hardware.
The result has been that our software has grown faster than our ability to insure it won't crash. The tools and languages have been evolving along with the size of programs being written -- and have not yet caught up.
There is also a tendency in software developers and the companies that hire them to try to add value by stretching the limits of what the earlier people have done. Windows is a prime example of this -- continuing to evolve and incorporate pieces of Browsers, Email, etc. The amazing thing is that crashes in this chaotic environment don't happen more often.
Finally, part of the answer is that stuff from the past (legacy stuff like 'C', Unix and the Windows API) rarely gets thrown away, instead it gets built upon. It would be expensive to throw it away, so people try to fix the warts as they find them. This approach is good, as it lets us continue to re-use solutions that worked. But it has the side effect of preserving some of the more crash-prone aspects of code ('C' string overflows, not checking Unix system calls, etc.)
The mainframe where I work gets reloaded every week, and often has peformance problems or downtime.
thank God the internet isn't a human right.
QNX is stable, so is Linux and in defense of Microsoft (a company that has caused more medical and psychiatric grief to more programmers and users than any other force in the universe) Windows is getting better and my Win2000 Pro system has not crashed in months (although it is funky at times).
Crashes are ore often caused by applications than the operating system. My advice is to complain loudly and often.
Your use of "gaming world" is somewhat inaccurate. You're talking about console and arcade hardware, which is the majority of games, but far from all.
Games running on desktop PCs still crash often, and players don't mind much.
The most important thing though is robust software design.
No, the most important thing is limited system variation. The real reason your GameCube stuff doesn't crash badly is because you have exactly one piece of software that will run on exactly one kind of hardware.
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
Don't think that PC software authors don't use exception handlers. It's because multitasking PCs are more flexible and allow users to attempt tasks that aren't necessarily within the capabilties of the system. Console games have only one target platform, so there's no need to allow tasks whose success is uncertain.
Of course, there's no need to mention Microsoft's inability to create a stable system.
I dont think the author has ever used windows XP or 2003
In my experience AMD computers running windows are more stable than ones powered by Intel
My Windows XP Box
Original Install Date: 01/04/2003, 19:05:37
System Up Time: 53 Days, 1 Hours, 29 Minutes, 50 Seconds
System Manufacturer: www.Over16oK.com
System Model: VT8371
System type: X86-based PC
Processor(s): 1 Processor(s) Installed.
[01]: x86 Family 6 Model 6 Stepping 2 AuthenticAMD ~1533 Mhz
Microsoft is making better operating systems just slowly very slowly
Microsoft windows is built as a desktop and meant to be rebooted daily to clean out bugs and memory leaks. Microsoft spends it's development time for quick flashy solutions rarely worried about longivity or standards. After all, they want to sell you a new one every year or two. This is what the consumer has accepted. And almost anyone can install it to at least a point of insecurity but functional level. Makes a great single user desktop.
Linux/UNIX on the other hand is much more stable as the open source is peer reviewed and the standards are much better thought out. The longivity and code openess allows for bugs to be patched. But knowning Linux/UNIX takes more brain power to learn and be proficient, which is why many people don't use it as much. But that is changing, more and more embedded systems, desktops and servers are now using Linux/UNIX as it is stable and reliable when configured correctly. This is a fact, you run UNIX because your serious about being a server, lower TCO and need the stability.
The reason for the difference is the kernel. UNIX, even though it was more than 10 years earlier in design uses protected memory. This means a running process finds it much more difficult to interfere woth other processes. Microsoft Windows still uses an archaic message passing as the primary mode of communications. Message passing predates the UNIX design.
I personally know a Linux machine, under load as a DNS/Proxy approaching 1000 days of uptime. The company likes this as they spend so very little time maintaining it and the users never call. Most support staff don't even know where it is. Quite a few Solaris and HP-UX machines approaching a year. The Solaris machines would be more but they are patched once per year. 95% of the Solaris machines have never unexpectedly crashed!!!
So it depends what you want. Microsoft will eventually adopt Linux. But until then your choices are limited.
What really surprises me, when I look at how much effort NT/2000 shops go through just to keep their servers running, why they don't just load Linux on them. That in itself would be serious ROI and TCO reduction. Might help the IT image some. But I suspect far too many CIOs own MSFT stock.
There are many reason why computers crash, but I think I can at least shed some light on his Zaurus problem.
There is a bug in all versions of the Zaurus ROM. If you reboot the Zaurus twice in a row without suspending it in between it will crash and the only way to get it running again is to perform a hard reset. The fix is availible here. Once I installed this fix, I've never had any more problems with lost data on my Z.
Life is too short to proofread.
I had a less than bracket there but Slashdot removed it.
Tim
Omnia vestra castrorum habetur nobis.
Yes I was referring to an embedded system, and NO my reasoning is not invalid.
My reasoing is perfect and everything I said is true.
You however do not seem to understand the simple fact that the words "open" and "closed" have multiple meanings. Instead of realizing I was discussing the right to place software on the machine, you thought I was using "open" in regards to Open Source. I never said Source, because I was NOT DISCUSSING Open Source. I was refering to Open SYSTEMS (like Windows) as opposed to Closed Systems, (like most embeded systems)
Notice how I said you need a restricted system INSTEAD of Windows. As in Windows is OPEN, NOT RESTRICTED. Your clear prejudices prevented you from reading what I wrote, so instead just skimmed it. Try again. This time read what I said, instead of assuming you are so smart you can guess what I mean. I will try to re-phase the argument here with smaller words.
To prevent system crashes, you must use a simple system (with less abilities) and not add anything to it that was not desigend to be added. This is called a CLOSED SYSTEM - even though the software could be an OPEN SOURCE or a closed source. This is often used in Embeded systems, but is also used for mission critical Server systems as well.
excitingthingstodo.blogspot.com
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
First, embedded systems are no longer thought of, or designed from the perspective of being, "closed". A very simple digital watch is the an example of a "closed" embedded system, being that it does not have to communicate with or rely on another device's logic/input to function (closed loop). On the other hand, the embedded systems found in cars/routers/switches/cellphones/servers etc. are not, and cannot be described as "closed systems" - they rely on input from other digital devices such as sensors or other embedded logic in order to function. By definition, there is NO communication/input in a closed system. Learn. Learn more.
"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."
Yes, as we have learned, if you want to create a system that is based on any type of varibles/input, it has to be open. You do not seem to understand that an embedded system is called "embedded" because the OS instructions are contained in the chip architecture. Instead writing code which uses a defined chip architecture (x86,PPC,Alpha), the code/logic is "embedded" in the chip. You can write software for imbedded devices - my cell phone runs java apps. There are many devices which utilize embedded linux, I have a webcam that runs its own apache webserver. So, no, embedded devices are not "severly" limited, and they most defiantly not slow! They instantly boot when turned on! Ha.
"1) accept a restricted operating system that will never be able to compete with a commercial system like Windows."
Your assumption of being restricted is wrong, check out Transmeta - and what does windows being "commercial" have to do with anything? How is an embedded system not commercial? Why can't a "non-commercial" system compete with a "commercial" system? Is my cellphone not commercial? Do you know the definition of commercial?
"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 thoroughly tested against all the other software that is currently installed on your PC."
How does something being created by "the same company/group" have anything to do with embedded systems, and/or system stability? (proprietary/opensorce) Not designed for my PC? I thought we were talking about embedded devices... What does your misinformed/erronous ideas about embedded devices have to do with a PC?
Your argument is based on numerous false assumptions which makes it untrue, and your misuse of words and their definitions makes your reasoning/correlations invalid. Basically, you have no idea what you are talking about.
This is a mathematically proven un-solvable thing
First off, with the math. I don't know what trade school you went to where they taught you that computers have 'infinite' states, but they don't. Even though there are millions of transistors, they can each be in only one of two states. It is nowhere near 'mathematically proven' that you cannot account for each one of them.
you can never account for every situation
If, by this statement, you mean situations whereby asteroids fall from the sky or the computer malfunctions in some way, then, yes... shit happens. No one expects a programmer to compensate for these things. Writing software that is 'perfect', however, is entirely possible irregardless of the imperfections of the computer (or OS) on which it runs.
You can't write a finite-state machine that can detect or correct an infinite number of states.
Again, with the math. There aren't an 'infinite number' of states. You can write a finite state machine that will check every bit of your code for logical errors. It is expensive and time consuming, so lazy programmers and fly-by-night companies don't do it.
calculating the "best" route from...
I think you've seen the problem with this one, so I won't harp on it. Suffice it to say that maybe you should find a 'CSci' major to explain it to you.
Here it is, folks, the icing on the cake: ... synergy, a business-plan, manager-speak, and other bullshit are NOT key components of successful software...
As revolting as it may sound to the hacker-coders out there, great programmers, software engineering, business processes,
Great programmers are, preferably some who paid attention in algebra. The OSS movement is the proof of this, producing better software than any of that other crap ever has. Maybe you would know that if you had paid attention to their quality, bug-free code instead of subscribing to the Microsoft "Bugs are inevitable, we must add features at all cost" programming model.
"I assumed blithely that there were no elves out there in the darkness"
"factoring two large prime numbers falls into the same group"
Um, I can factor any large prime
number you care to supply in my
head, quite easily. The factors
will be the number one, and the
large prime number under
consideration!