And what happens if you expect code to work EXACTLY the way it does at one point in time, then it changes? Well,.... you could switch to Ada. I'm not at all familiar with it except that the original intent was to stop exactly that kind of thing without overspecifying implementation details.
Didn't I read somewhere that Google uses IDE drives to host their database? I would love to have a database, where if I ever lost a drive or something, I could just go out on the net and get, not an old stale bacup copy, but fresher information than what I just lost. Google knows what they're doing, but it is NOT a general recipe for how to set up a server cluster.
It's the scope of the bug/typo/error/whatever. Pentium Porcessors is harmless enough (limited scope) unless I start down some association of processing five hogs in an abatoir. Sloppy work causes problems. Thankfully, most are limited in scope. I understand your rant, but the real problem is that minor errors have big consequences. There's no silver bullet, but the key is to somehow drastically curtail the bad consequences of errors that will inevitably occur.
And for the life of me when will programmers realize that just because the software works on their box it may not work on another machine.
Just installing Visual Studio,Source Safe etc, makes testing useless on your main machine. Program on your main machine. Test on a clean machine.
Something is horribly broken here.
If you must develop and test for such an environment, you must test on both a clean machine and a machine with all the "goodies" loaded. It doesn't really work to tell a customer that he needs to get rid of all his other software, reinstall Windows, and load your software. And no its not easy, you need to test against all combinations of wierd stuff to ensure that it will actually run.
the program should only do what it was designed to do, not more or less.
throw data at a program that it shouldn't get Exactly. Otherwise it's like a boat that stays afloat only in a harbor on a calm day. And a cracker's exploit of a buffer overflow is maybe the kindest way of experiencing the bug. If you don't think so, explore the consequences of a shipping clerk triggering the same bug on a production system. Horrible thought, but the "black hats" may be the only friends you've got in the business.
I know a few people who write code to run nuclear reactors... But do you know the people who wrote code to run Clippy? Now really, would you trust Clippy to always open that valve on time?
...undertaken there will be mistakes. But we learn from each one... Do we? With Open Source and well publicized bug lists, maybe, some of the time. With Closed Source, surely you jest.
Define catastrophic. (Any) loss of life doen't work unless you are willing to ban automobiles, and even then you have problems, even with walking. Methinks that catastrophic carries the sense of a profound change in the choices of the survivors. If the odds are better with computer than manually administered dosage, unfortunate is maybe a better term than catastrophic. Would it be any less "catastrophic" if it were administered manually and the patients died because it wasn't quite accurate enough. Not an excuse for the bug, but catastrophies are big in scope.
Black Death maybe qualifies. Smallpox II. Another asteroid, like 65 million years ago. Yellowstone blows its top again. Time bomb in (almost all) antivirus software. Clobbers BIOS and runs monitors so they burn up. Something small but the effects keep getting bigger as they cascade. For want of a nail type of thingee.
If every programmer needs to understand every piece of code in the entire system, the size of systems that can be developed is severely restricted. That's a bit like having to know every street in a city to be able to go back and forth from home to work. The basic problem is that which subset of the code must be known belongs to the power set, exponentially more complex if you set arbitrary barriers.
You don't need the code behind the interface if the interface is fully documented. It never is. Not fully. In say FORTRAN, 2+2 should be 4, but after calling a subroutine with a parameter 2 that gets changed to 7, the result is now 14. I think Ada puts a stop to at least some such, at a price. There's no substitute for being able to find out EXACTLY what is being done.
Bugs fixed on the wrong end of the interface just causes more headaches when it eventually is fixed. Actually I quite agree. Of course you're SOL until (and if) whoever finally fixes the problem on the right side of the interface. If the two sides are never allowed to see on the other side, there's a good chance it will never be fixed. Might as well quit now before you get even further behind.
So if you can trust the other guy to fix discrepancies between code and documentation, you have no reason to need the source code. Bought any bridges lately?
Sir, methinks you are an optimist. Faster is better, even if some of the results are wrong. IIRC, Boroughs(sp?) had problems with their hardware running a lot of programs. Seems that a lot of the programs read or wrote memory where it the programs shouln't be accessing anything, and the programs just wouldn't run.
Errr...no. This problem had nothing to do with how well the software was communicating. Seems very much like a problem with how the software are communicating. The software, however indirectly, reads the wrong units. This sounds exactly like a communication problem, and anything else being involved doesn't make the software right. There was a "bug" between the contractor and the contracting agency. That bug caused a bug in the final software. There's more than one bug.
Am I the only one who sees humor in saying, "...software are communicating properly" in a comment about communicating properly? Anyone?
Ok, I'll bite. "...software is communicating properly" means that (one piece of) the software is communicating (one thing) properly (at the moment). It is laughable that anyone would expect anything more. "...software are communicating properly" implies some sort of plurality in what is communicating properly, which is closer to the high end of the continuum between "sometimes does something right" and "never does anything wrong".
Use something like "Programmer is an idiot" unless you are the only possible target regardless of circumstances. Pronoun problem. Who is the "you"? Depends on context. And the code will be relevant in contexts other than when it was initially written, being run for starters. O.T. Who is the "My" of "My Computer"? I didn't put it there. It's not mine.
I had a prof who was stressing someone else's opinion that we change from the word "bug" to the phrase "time bomb" so that people would get a better feeling for what they really were -- incorrect sections of code just waiting to mess you up. I'd vote for Booby-Traps. There's lots of boobies waiting to be trapped. Possibly, an accident looking for a place to happen. But seriously folks, the problem with bugs is that they sometimes get together with other bugs and then produce spectacular results. I've even seen a triple. Three bugs. Any one of them absent, it would be impossible to find anything wrong.
The waste itself provides the energy, or a large portion of it. The process is much like a swamp making swamp gas, but quicker and with a cleaner product. The trick is to waste as little as possible of the energy that's in the waste, and to get a good clean product.
The new process begins with turning waste "biomass" into hydrogen, methane, water, carbon monoxide and carbon dioxide, using standard gasification techniques that involve heat and pressure. But further hydrogen is then produced by also breaking down the methane and water, says Bhattacharya, with the aid of a nanocrystalline catalyst.
The process can be run continuously because pure hydrogen is extracted through a palladium-coated ceramic semi-permeable membrane that blocks other gases. If the hydrogen was not removed the reaction would reach equilibrium and stop. Bhattacharya adds that the heat efficiency of the new system has also been significantly improved.
Them as lives by the crystal ball shall learn to eat ground glass. Nevertheless, I'll hazard a guess. There is the old joke about a camel being a horse designed by a committe. Java is Sun's "baby" and if left to the vagaries of the standards body, somebody, sometime, somehow would manage to sabotage the integrity of the design. It's gotta be real easy to change Java to be more "programmer friendly", a la Virul Basic, and lose the integrity in the process.
And then virus writers will just start sending the virii encased in zipfiles. But unzip programs are designed to show what's inside instead of to hide what's inside. The only real difference between the Unix honor virus and the current Microsoft wormage is that the Microsoft wormage has so much lovely cover in which to hide and disguise itself.
The race is not always to the swift, nor the battle to the strong. But that's the way to bet. (Somebody else said it, probably better, a long time ago)
Makes sense, but sounds like a horribly broken security model, kinda like if the bank manager can get into the vault then you gotta let everybody in, at any time.
That doesn't make sense -- she has to run the attachment in order to be infected. Close, but not quite. The attachment has to be run to be infected. Any setting or lack of setting or wierd whim of Outlook or Windows that causes it to be run is enough. Fat chance of ever figuring out what the settings are or should be, even what's really installed and how that differs from what is claimed to be installed. FUD == running Microsoft software;)
Instead of looking for virii (which will always be a try-to-stay-one-step-ahead-of-the-bad-guys type setup) I just have a list of attachments I don't allow. Good idea but probably better to specify a list of extensions you will ACCEPT. Personally, I wouldn't trust any list to be exaustively inclusive of Microsoft virus executers. A few varieties of zips and tarballs should suffice. There's reasons for using zip other than just compression.
Slashdot Mirror
And what happens if you expect code to work EXACTLY the way it does at one point in time, then it changes? .... you could switch to Ada. I'm not at all familiar with it except that the original intent was to stop exactly that kind of thing without overspecifying implementation details.
Well,
Didn't I read somewhere that Google uses IDE drives to host their database?
I would love to have a database, where if I ever lost a drive or something, I could just go out on the net and get, not an old stale bacup copy, but fresher information than what I just lost.
Google knows what they're doing, but it is NOT a general recipe for how to set up a server cluster.
It's the scope of the bug/typo/error/whatever.
Pentium Porcessors is harmless enough (limited scope) unless I start down some association of processing five hogs in an abatoir.
Sloppy work causes problems. Thankfully, most are limited in scope.
I understand your rant, but the real problem is that minor errors have big consequences. There's no silver bullet, but the key is to somehow drastically curtail the bad consequences of errors that will inevitably occur.
And for the life of me when will programmers realize
that just because the software works on their
box it may not work on another machine.
Just installing Visual Studio,Source Safe etc, makes
testing useless on your main machine.
Program on your main machine.
Test on a clean machine.
Something is horribly broken here.
If you must develop and test for such an environment, you must test on both a clean machine and a machine with all the "goodies" loaded. It doesn't really work to tell a customer that he needs to get rid of all his other software, reinstall Windows, and load your software.
And no its not easy, you need to test against all combinations of wierd stuff to ensure that it will actually run.
the program should only do what it was designed to do, not more or less.
throw data at a program that it shouldn't get
Exactly. Otherwise it's like a boat that stays afloat only in a harbor on a calm day.
And a cracker's exploit of a buffer overflow is maybe the kindest way of experiencing the bug. If you don't think so, explore the consequences of a shipping clerk triggering the same bug on a production system. Horrible thought, but the "black hats" may be the only friends you've got in the business.
I know a few people who write code to run nuclear reactors...
But do you know the people who wrote code to run Clippy?
Now really, would you trust Clippy to always open that valve on time?
...undertaken there will be mistakes. But we learn from each one ...
Do we?
With Open Source and well publicized bug lists, maybe, some of the time.
With Closed Source, surely you jest.
Define catastrophic.
(Any) loss of life doen't work unless you are willing to ban automobiles, and even then you have problems, even with walking.
Methinks that catastrophic carries the sense of a profound change in the choices of the survivors. If the odds are better with computer than manually administered dosage, unfortunate is maybe a better term than catastrophic. Would it be any less "catastrophic" if it were administered manually and the patients died because it wasn't quite accurate enough. Not an excuse for the bug, but catastrophies are big in scope.
Black Death maybe qualifies.
Smallpox II.
Another asteroid, like 65 million years ago.
Yellowstone blows its top again.
Time bomb in (almost all) antivirus software. Clobbers BIOS and runs monitors so they burn up.
Something small but the effects keep getting bigger as they cascade. For want of a nail type of thingee.
If every programmer needs to understand every piece of code in the entire system, the size of systems that can be developed is severely restricted.
That's a bit like having to know every street in a city to be able to go back and forth from home to work. The basic problem is that which subset of the code must be known belongs to the power set, exponentially more complex if you set arbitrary barriers.
You don't need the code behind the interface if the interface is fully documented.
It never is. Not fully.
In say FORTRAN, 2+2 should be 4, but after calling a subroutine with a parameter 2 that gets changed to 7, the result is now 14. I think Ada puts a stop to at least some such, at a price. There's no substitute for being able to find out EXACTLY what is being done.
Bugs fixed on the wrong end of the interface just causes more headaches when it eventually is fixed.
Actually I quite agree. Of course you're SOL until (and if) whoever finally fixes the problem on the right side of the interface. If the two sides are never allowed to see on the other side, there's a good chance it will never be fixed. Might as well quit now before you get even further behind.
So if you can trust the other guy to fix discrepancies between code and documentation, you have no reason to need the source code.
Bought any bridges lately?
Sir, methinks you are an optimist.
Faster is better, even if some of the results are wrong.
IIRC, Boroughs(sp?) had problems with their hardware running a lot of programs. Seems that a lot of the programs read or wrote memory where it the programs shouln't be accessing anything, and the programs just wouldn't run.
Errr...no. This problem had nothing to do with how well the software was communicating.
Seems very much like a problem with how the software are communicating. The software, however indirectly, reads the wrong units. This sounds exactly like a communication problem, and anything else being involved doesn't make the software right. There was a "bug" between the contractor and the contracting agency. That bug caused a bug in the final software. There's more than one bug.
Am I the only one who sees humor in saying, "...software are communicating properly" in a comment about communicating properly? Anyone?
Ok, I'll bite.
"...software is communicating properly" means that (one piece of) the software is communicating (one thing) properly (at the moment). It is laughable that anyone would expect anything more.
"...software are communicating properly" implies some sort of plurality in what is communicating properly, which is closer to the high end of the continuum between "sometimes does something right" and "never does anything wrong".
"burned in" != Software.
ROM BIOS
Use something like "Programmer is an idiot" unless you are the only possible target regardless of circumstances.
Pronoun problem. Who is the "you"? Depends on context. And the code will be relevant in contexts other than when it was initially written, being run for starters.
O.T. Who is the "My" of "My Computer"? I didn't put it there. It's not mine.
"Press any key to continue, any other key to abort".
Funny, yeah. But it beats a dialog box with just an OK box.
I had a prof who was stressing someone else's opinion that we change from the word "bug" to the phrase "time bomb" so that people would get a better feeling for what they really were -- incorrect sections of code just waiting to mess you up.
I'd vote for Booby-Traps. There's lots of boobies waiting to be trapped.
Possibly, an accident looking for a place to happen.
But seriously folks, the problem with bugs is that they sometimes get together with other bugs and then produce spectacular results. I've even seen a triple. Three bugs. Any one of them absent, it would be impossible to find anything wrong.
The waste itself provides the energy, or a large portion of it.
The process is much like a swamp making swamp gas, but quicker and with a cleaner product. The trick is to waste as little as possible of the energy that's in the waste, and to get a good clean product.
The new process begins with turning waste "biomass" into hydrogen, methane, water, carbon monoxide and carbon dioxide, using standard gasification techniques that involve heat and pressure. But further hydrogen is then produced by also breaking down the methane and water, says Bhattacharya, with the aid of a nanocrystalline catalyst.
The process can be run continuously because pure hydrogen is extracted through a palladium-coated ceramic semi-permeable membrane that blocks other gases. If the hydrogen was not removed the reaction would reach equilibrium and stop. Bhattacharya adds that the heat efficiency of the new system has also been significantly improved.
Them as lives by the crystal ball shall learn to eat ground glass.
Nevertheless, I'll hazard a guess.
There is the old joke about a camel being a horse designed by a committe. Java is Sun's "baby" and if left to the vagaries of the standards body, somebody, sometime, somehow would manage to sabotage the integrity of the design. It's gotta be real easy to change Java to be more "programmer friendly", a la Virul Basic, and lose the integrity in the process.
And then virus writers will just start sending the virii encased in zipfiles.
But unzip programs are designed to show what's inside instead of to hide what's inside.
The only real difference between the Unix honor virus and the current Microsoft wormage is that the Microsoft wormage has so much lovely cover in which to hide and disguise itself.
The race is not always to the swift, nor the battle to the strong.
But that's the way to bet.
(Somebody else said it, probably better, a long time ago)
Makes sense, but sounds like a horribly broken security model, kinda like if the bank manager can get into the vault then you gotta let everybody in, at any time.
No, the plural of virus is Microsoft.
That doesn't make sense -- she has to run the attachment in order to be infected. ;)
Close, but not quite. The attachment has to be run to be infected. Any setting or lack of setting or wierd whim of Outlook or Windows that causes it to be run is enough. Fat chance of ever figuring out what the settings are or should be, even what's really installed and how that differs from what is claimed to be installed. FUD == running Microsoft software
Instead of looking for virii (which will always be a try-to-stay-one-step-ahead-of-the-bad-guys type setup) I just have a list of attachments I don't allow.
Good idea but probably better to specify a list of extensions you will ACCEPT. Personally, I wouldn't trust any list to be exaustively inclusive of Microsoft virus executers. A few varieties of zips and tarballs should suffice. There's reasons for using zip other than just compression.
Also to consider: Microsoft dropping supports really means:
NO NEW BUGS.