Firefox is crashing all the time
Jul. 16th, 2005 08:19 pmGoddamn Firefox is crashing all the time! Even after I got the latest version, 1.0.5.
Can anyone patch? If you want to crash your Firefox too, you can do it here
It's one of my beliefs that programs should not be released unless they are pretty-much bug-free (*). And even when they are not, they should not bring down whole programs... it's just ridiculous.
EDIT: (*) in an ideal world.
Can anyone patch? If you want to crash your Firefox too, you can do it here
It's one of my beliefs that programs should not be released unless they are pretty-much bug-free (*). And even when they are not, they should not bring down whole programs... it's just ridiculous.
EDIT: (*) in an ideal world.
(no subject)
Date: 2005-07-17 01:04 am (UTC)I consider Firefox pretty stable. I guess there to be about a dozen annoying problems that any normal person might come accross, this is pretty low.
Eidos shipped Tomb Raider with 3,000 open bugs. yeah, you read that right.
(no subject)
Date: 2005-07-17 08:59 am (UTC)If a normal user might come across them, then testers should have come across them too. So there should be no excuse: once found, a bug should be easy to fix. If it's not easy to fix, it should be because they use buggy libraries (so the fault lies outside): but in practice, many bugs are hard to fix because the code is a huge mess, poorly documented (I don't ask for much), etc, and nobody understands it well enough.
I know that people are always running to ship stuff, but I just find it unacceptable. In the long run, things are much easier when the code is elegantly written.
(no subject)
Date: 2005-07-17 09:18 am (UTC)I’m going to pin you down on this as a result.
First, testers are not normal people. Have you ever met a professional tester? I’m really asking you this, because I designed the test suite for several fortune 500 companies, including companies like Disney.
Let’s assume the testers tested, and stop finding bugs. At what point do you ship?
(no subject)
Date: 2005-07-17 09:36 am (UTC)I don't think I have ever see one at work. The places where I've worked, we had to test our own shit 95% of the time.
In any case, testers should be emulating what users do. If they can't do that, they should be bringing people off the street to test for them.
If the testers, doing the above, can't find bugs after considerable effort, then it's time to ship.
Btw I don't like the word "bug", because it takes the resposibility away from the programmer: a bug is not a bug that landed in the circuit, it's a programming error that was made by a specific person, who failed to notice it or correct it.
(no subject)
Date: 2005-07-17 09:44 am (UTC)(no subject)
Date: 2005-07-17 09:49 am (UTC)(no subject)
Date: 2005-07-17 10:00 am (UTC)A: Catch 22. A person capable of testing is not a normal user. A normal user will not walk down all the paths, and therefore can’t be a tester.
Q: Btw I don't like the word "bug", because it takes the resposibility away from the programmer: a bug is not a bug that landed in the circuit, it's a programming error that was made by a specific person, who failed to notice it or correct it.
A: Hilarious. LOL.
G, this statement is so….silly….I love that you have this innocence about you. I’m trying not to be condescending, although there is no way to avoid it for me here.
Ok, so let’s start with something simple. A programmer writes code, and it works. And on all the configurations available to the tester it works. But when released into the market, it turns out that hundreds of thousands of systems fail using it. This is the normal path of a software “bug.”
(no subject)
Date: 2005-07-17 10:35 am (UTC)Ok. You could have the two working together, though.
But anyway, a professional tester should be able to uncover any bugs that a normal user does, even if he can't emulate their exact behavior.
Hilarious. LOL.
Credit goes to Paul Graham.
But when released into the market, it turns out that hundreds of thousands of systems fail using it. This is the normal path of a software “bug.”
Ok. This must be because the code couldn't be tested on those systems.
If the testers don't have such configurations available, maybe they should consider doing a restricted pre-release first on a wide range of machines.
I understand that if you jump from 20 testers to millions of users, you *will* find new bugs (unless your system is the bug-free kind, possibly provenly so through some kind of formal methods), so it might be wiser to jump from 5 to 500 first.
In any case, such problems will arise because the different user systems don't conform to a standard. I am indeed an idealist... today's systems (OSs, libraries, etc.) are a huge mess, and this leads to unpredictable behavior when you run new code. This is one advantage of writing code for a standardized system, like the Java VM, but even then these sorts of problems still arise. Before you tell me, I am speculating / bullshitting a bit here. The point is that things *could* be different, and your code's behavior *should* be predictable (although the fault may lie in the world (I know blaming the world does no good))... I dream of an all-around well-designed system, like TUNES.
I have a love-hate relationship with developing real software systems, and the hate part comes from this lack of control.
(no subject)
Date: 2005-07-17 04:41 pm (UTC)A person capable of testing is not a normal user. A normal user will not walk down all the paths, and therefore can’t be a tester.
Q: Ok. You could have the two working together, though.
A: I have actually seen that tried several times. They want to kill each other.
Q: But anyway, a professional tester should be able to uncover any bugs that a normal user does, even if he can't emulate their exact behavior.
A: That is exactly like saying that a person should be able to think like someone else. That is simply not human nature. If anyone had that ability, they would have magic powers.
Q: Ok. This must be because the code couldn't be tested on those systems.
A: No, that is just one path. I gave just one thin path to follow.
We need to test on every platform, with every configuration of software. For example, just on Windows we need to test on W95, 98, 2000, XP, ME, then with SP1, SP2, SP3, SP4. Then we need to test all that with low memory, high memory (sometimes things only go wrong when there is too much space). About 5% of bugs now a days are bugs from the interaction of specific products.
They compete for resources. Application A fails only when Application B is running, or when it is trying to do something at the same time.
Q: If the testers don't have such configurations available, maybe they should consider doing a restricted pre-release first on a wide range of machines.
A: there is no way to control how people will use Beta software.
Q: (unless your system is the bug-free kind)
A: this makes no empirical or mathematical sense to me.
There is no such thing as bug free software. There is simply software that operates well enough. A bug can rationally be defined as any function of the system that operates in a manner unacceptable by the expectations of the user.
This can include everything from an application that crashes, deletes your data, or on the other end of the spectrum, this could include issues that for one person is a bug, and for another, it is a feature.
Q:. This is one advantage of writing code for a standardized system, like the Java VM,
A: LOL. Java. Would this be the same JAVA that we refuse to use? The same JAVA that we refer to as write once, test many many many times?
Q: but even then these sorts of problems still arise. Before you tell me, I am speculating / bullshitting a bit here. The point is that things *could* be different, and your code's behavior *should* be predictable (although the fault may lie in the world (I know blaming the world does no good))... I dream of an all-around well-designed system, like TUNES.
A: In a perfect system, or said differently, a system written so well that even a room full of nerds agree it “well designed” you will simply have a different type of bug. People will try more, and thus re-extend themselves.
Q: I have a love-hate relationship with developing real software systems, and the hate part comes from this lack of control.
A: Agreed. That is also where the money is made. People who have a stomach for it and make software quickly and to the expectations of the users, tend to win.
Keep in mind, our company makes two of the types of software that has to be more bug free than most software, which is gambling hardware/software (which is a subset in my mind of money tracking software), and control systems for airplanes (which is a subset of life endangering software shared by interactive medical software).
Bugs are simply a product of the formula that pits cost of repair or perfection against marketplace.
For example, back in the 70’s a famous CEO made the division to ship a car that they knew had a bug in the systems that would kill people during specific type of an impact.
They added up the chance of this happening and the lawsuits, against repairing or changing al the vehicles. It was cheaper to ship without fixing.
People die.
The CEO, and the company continue on…
(no subject)
Date: 2005-07-17 05:44 pm (UTC)A: That is exactly like saying that a person should be able to think like someone else. That is simply not human nature. If anyone had that ability, they would have magic powers.
No. The point is that you don't need to test every possibility, if you can generalize. The question is: when *can* you generalize? (when running in poorly designed systems, not very often)
We need to test on every platform, with every configuration of software. For example, just on Windows we need to test on W95, 98, 2000, XP, ME, then with SP1, SP2, SP3, SP4. Then we need to test all that with low memory, high memory (sometimes things only go wrong when there is too much space). About 5% of bugs now a days are bugs from the interaction of specific products.
They compete for resources. Application A fails only when Application B is running, or when it is trying to do something at the same time.
These are great illustrations of how poorly designed the underlying system is. In a good system, it would simply not matter how much memory you have... and even if it did, it would tell you exactly what is causing the error.
There is no such thing as bug free software.
There exists software that is *mathematically*proven* to be correct, i.e. that they meet their specifications. This area is called "formal methods".
Of course, these proofs make assumptions that other things will behave correctly.
I used to argue with my boss about this over lunch: he used to say that there was no perfect software. One day, Oracle claimed to have released an "unbreakable" system and I knew rightaway he would be skeptical... and he sure was. Whether it really was unbreakable, I don't know (apparently not).
A bug can rationally be defined as any function of the system that operates in a manner unacceptable by the expectations of the user.
My definition: a bug is a programming error which causes a system to not meet its specifications.
there is no way to control how people will use Beta software.
but you *can* make sure that your system will get used on all (common) combinations of OSs x ServicePacks, by giving these free beta copies to users of each kind of system.
In a perfect system, or said differently, a system written so well that even a room full of nerds agree it “well designed” you will simply have a different type of bug. People will try more, and thus re-extend themselves.
Unless there really *are* no bugs.
But maybe I should stop talking about bug-free application software until I can make some to show around.
(no subject)
Date: 2005-07-18 08:27 am (UTC)Q: But maybe I should stop talking about bug-free application software until I can make some to show around.
A: Yeah……..this would indeed make this conversation more balanced.
(no subject)
Date: 2005-07-18 06:11 pm (UTC)I've heard this before, second hand from you...
Btw, formal methods are now being used in some such mission-critical applications. They tend to be the only kind of people who can afford the slow and expensive development of a bug-free system.
this would indeed make this conversation more balanced.
oh, so you see this as a competitive debate?
Much of our disagreement is semantic. Counterfactuals ("should", "would", etc.) can be interpreted as truth in some alternative world... often an idealization of our current world.
When I use counterfactuals, I usually mean them in a world farther away than most people would. This makes me a dreamer.
How ideal is a world where everyone is reasonably rational (say "top half of HtG" standard)? It's certainly pretty far from our current reality, but it's not only logically possible: it's also humanly possible and socially possible. When I say my "should"s, I often mean them in such a world. So they're maybe not very useful statements to make.
P.S.: I added "(*) in an ideal world" to my post.
(no subject)
Date: 2005-07-18 06:41 pm (UTC)Escher Technologies: building Bug-Free Software
As usual, caveat emptor applies.
(no subject)
Date: 2005-07-18 10:50 pm (UTC)A: I don’t think there is any competition. I simply view your perception as somewhere between mal-informed, and naive. Even in consideration of “” I usually mean them in a world farther away than most people would. This makes me a dreamer.”
I am more than willing to work through examples with you item after item why the very definition of “bug” will lose meaning.
This is a conversation I have been having for about 30 years with my own teams. Those that hold your view eventually give it up when tested. It may take 5 or 10 more messages back and forth as we test this.
We can even start in your perfect world where the foundation was poured with level concrete. Then talk about why things start to go off…which we will label a bug.
Q: Escher Technologies: building Bug-Free Software
A: Yeah, impressive statements, while I’m sure it is useful, it is a far cry from bug free software.