If Google did not make this deal, then they would probably be SOL as MS can make their search the default and over time Google would become as relevant as Netscape.
I probably wouldn't word this as Google "muscling in" but rather as taking a critical step in defending against MS "muscling in."
Remove that requirement, and I will write "provably correct" software as easy as any civil engineer proves their bridges and buildings won't fall down.
Even with that requirement removed, there are still such a ridiculous number of permutations of input and state for most programs that testing all is very time consuming and generally not economically feasible, and any ONE of those inputs or states could be a problem. Mechanical engineers, on the other hand do not have to test every perumtation of molecules that may be on, near or around the item being constructed. Software is discrete and state based and physical engineering is continuous and different approaches are required for the two different disciplines.
It is possible to give the same sort of assurances for software by using similar engineering techniques.
Please enlighten myself and all of the math and computer science researchers that have been attemting to solve the problem of correctness. What specifically can be done to ensure correctness of algorithm, and correctness of tens/hundreds of thousands of algorithms working in conjunction. What physical engineering techniques apply?
I don't disagree that it is a worthwhile goal to create bug-free software, and I think that with proper languages/tools/etc. progress can be made, but if you think the answer will come from the physical engineering disciplines then I don't think you have studied the problem.
Have you ever seen a bridge where 1 broken bolt causes the thing to collapse?
Physical processes tend to be continuous and small failures in most areas can easily be countered with general design principles.
Software, on the other hand, is discrete with an enourmous number of paths through the system. Small failures can lead to other small failures, or to gigantic failures, there is little correlation between the size of the initial fault and the size of resulting problem.
We know how to produce fault-less code, test all possible scenarios. But this tends to be expensive, just like testing all possible uses/states of a bridge would be expensive.
There are things that can be done to isolate and reduce the number of possible faults, but they are not the same things that you do when building bridges.
Practically every other morning last year my commute was slowed considerably by each of these following groups that repeatedly protested on the overpass of the freeway:
1) Support our troops
2) Out of Iraq
3) Union vs Darigold (milk producer)
4) Can't remember the other one
I was so annoyed by it that I purposely:
Did not support our troops
But I didn't want them out of Iraq either
And I made sure I purchased Darigold Milk at the grocery store!
"The biggest unreliability with Windows is the stupid things that users do."
I think what you are trying to say is:
"The biggest unreliability with Windows is that the users are too damn lazy to plug all of the holes in Windows."
Placing a value judgement of "Negative", "Neutral" or "Positive" on a mutation is an error. The mutations just "are", and the resulting creature has either shifted to being more optimized for a slightly diferent niche in the environment, and less optimized for the niche the parents exist in, or it has remained optimized for the niche of it's parents.
Based on reports from developers working with cell (PS3 and Mercury systems products) the processor appears to deliver the raw performance that has been described by IBM.
As a programmer with a couple decades of experience, and having used a wide variety of languages, I don't see why people complain about VB. Can you give me some examples of why you think it's retarded?
I can just see "Inspector Leopard of Scotland Yard, Special Fraud Film Director Squad" focusing on the clearly fraudulent shipment of DVD's that the dog has identified, while the crate marked "Warning: Illegal Terrorist Shipment" slides slowly down the conveyor completely unnoticed.
Quote from the organization:
"After an exhaustive search of about 38 web sites we have chosen the top 37 in a variety of categories. Although we realize there are about 14 billion web sites we did not visit, we feel pretty good about our choices."
"Patents are supposed to be used by the people who invent things to get money from the people who use those inventions to make products"
Patents are "supposed" to be used for exactly what we the people decide they should be used for. They are an artificial temporary monopoly that WE citizens have agreed to allow (through our representatives) in exchange for the economic benefit that goes along with the monopoly. That benefit is a window of opportunity to recoup the investment in R&D used to create the product, which in turn encourages economic development and investment.
I (and it would appear I'm not alone) did not ever agree to "idea squatters" that randomly combine trivial technologies, never produce product and ultimately REDUCE the very economic investment and development that patents were supposed to encourage.
No, it's not name calling, it's calling a spade a spade.
You state that hardware is more reliable than software because hardware is non-algorithmic and synchronous. This does not seem to be correct.
Hardware is typically more reliable than software for the following reasons:
1) Patching hardware is very difficult and expensive, so they get it right the first time. Patching software is cheap and easy, so they don't worry as much.
2) Harwdare does have errors, have you ever looked at the errata sheets for CPU's?
3) Hardware typically has a more limited set of functions than software, software combines those limited functions into increasingly large sequences resulting in a much larger state space, which in turn requires more testing.
You state that the brain is reliable because it is signal based and synchronous. This is not the reason the brain is reliable (the brain is asynchronous, not synchronous). The brain is reliable because it employs a mathematical model that matches input to closest previous match from experience. It will always choose an output, although the output will only be as good as experience and training.
It was difficult on that page to see a concrete argument showing how a UBM improves reliability, other than the stated analogies. If I have missed a key point as to why a UBM has advantages, I would be interested in knowing what those reasons are.
Waterboy's Mom: "Don't you go sayin' that Scott McNealy man coined that phrase! Your momma coined that phrase! I was settin' out back fryin' up some gators when all suddenly like I thought, 'the network is...'"
Both McNeally and Schwartz spend way too much time bad-mouthing the competition. Every time they do that I think "Hmm, Sun must be worried about something otherwise they wouldn't be bad-mouthing those guys."
I've been part of business deals where this exact type of behavior is why the client chose not to do business with our competition.
Mainframes have detailed error detection and transaction rollback at the hardware level. AS400's are rock solid, no virus, no buffer overflows, very secure, etc. etc. I'm sure some Unix systems are very good also. The unreliability you speak of is Windows and PC hardware, primarily due to the fact they are inexpensive. You get what you pay for.
It happened to me. I was logging onto some box after having passed through a few different operating systems on various boxes to get there, when I keyed in my password the damn thing got echoed back to the screen and the person behind me started laughing (it was one of those passwords you wouldn't tell your mom about!).
What is being stifled is the trivial application of routine usage of technologies. Here are a couple examples you may not be aware of:
1) Amazon is the only company that can have a web site where you click 1 time to purchase (as in, your name and address are read in from the cookie instead of you keying it in). Barnes and Noble was required to change their web site to 2 clicks.
2) RIM (Blackberry) both went after other companies successfully, and was a target themselves (NTP $600million) for violations of the patented method of sending text over a wire-less communications connection.
There are tens of thousands of trivial examples like these that have been patented.
For me personally, not being able to takes notes would be a serious problem. As I take notes it forces me to concentrate on the topic and internalize the concepts. Throughout college, I gained far more from the note taking PROCESS than from the usage of the notes themselves.
I agree SLA's are worthless, for a variety of reasons.
However, I disagree that centralized IT should die. I have spent much time in my professional career undoing the nightmare of islands of systems where information is stored in multiple places (and only one is current), the same data value is stored differently (different customer numbers, item numbers, etc.). Attempting to reconcile differences in procedures, bring info together after the fact, etc. etc. is time consuming and error prone.
I can see having dedicated resources as long as the enterprise architecture is coordinated and reasonably centralized.
Slashdot Mirror
If Google did not make this deal, then they would probably be SOL as MS can make their search the default and over time Google would become as relevant as Netscape.
I probably wouldn't word this as Google "muscling in" but rather as taking a critical step in defending against MS "muscling in."
Remove that requirement, and I will write "provably correct" software as easy as any civil engineer proves their bridges and buildings won't fall down.
Even with that requirement removed, there are still such a ridiculous number of permutations of input and state for most programs that testing all is very time consuming and generally not economically feasible, and any ONE of those inputs or states could be a problem. Mechanical engineers, on the other hand do not have to test every perumtation of molecules that may be on, near or around the item being constructed. Software is discrete and state based and physical engineering is continuous and different approaches are required for the two different disciplines.
It is possible to give the same sort of assurances for software by using similar engineering techniques.
Please enlighten myself and all of the math and computer science researchers that have been attemting to solve the problem of correctness. What specifically can be done to ensure correctness of algorithm, and correctness of tens/hundreds of thousands of algorithms working in conjunction. What physical engineering techniques apply?
I don't disagree that it is a worthwhile goal to create bug-free software, and I think that with proper languages/tools/etc. progress can be made, but if you think the answer will come from the physical engineering disciplines then I don't think you have studied the problem.
That was one of the funniest SNL fake commercials I have ever seen!
Have you ever seen a bridge where 1 broken bolt causes the thing to collapse?
Physical processes tend to be continuous and small failures in most areas can easily be countered with general design principles.
Software, on the other hand, is discrete with an enourmous number of paths through the system. Small failures can lead to other small failures, or to gigantic failures, there is little correlation between the size of the initial fault and the size of resulting problem.
We know how to produce fault-less code, test all possible scenarios. But this tends to be expensive, just like testing all possible uses/states of a bridge would be expensive.
There are things that can be done to isolate and reduce the number of possible faults, but they are not the same things that you do when building bridges.
Practically every other morning last year my commute was slowed considerably by each of these following groups that repeatedly protested on the overpass of the freeway:
1) Support our troops
2) Out of Iraq
3) Union vs Darigold (milk producer)
4) Can't remember the other one
I was so annoyed by it that I purposely:
Did not support our troops
But I didn't want them out of Iraq either
And I made sure I purchased Darigold Milk at the grocery store!
"The biggest unreliability with Windows is the stupid things that users do."
I think what you are trying to say is:
"The biggest unreliability with Windows is that the users are too damn lazy to plug all of the holes in Windows."
Placing a value judgement of "Negative", "Neutral" or "Positive" on a mutation is an error. The mutations just "are", and the resulting creature has either shifted to being more optimized for a slightly diferent niche in the environment, and less optimized for the niche the parents exist in, or it has remained optimized for the niche of it's parents.
Based on reports from developers working with cell (PS3 and Mercury systems products) the processor appears to deliver the raw performance that has been described by IBM.
As a programmer with a couple decades of experience, and having used a wide variety of languages, I don't see why people complain about VB. Can you give me some examples of why you think it's retarded?
I can just see "Inspector Leopard of Scotland Yard, Special Fraud Film Director Squad" focusing on the clearly fraudulent shipment of DVD's that the dog has identified, while the crate marked "Warning: Illegal Terrorist Shipment" slides slowly down the conveyor completely unnoticed.
Quote from the organization:
"After an exhaustive search of about 38 web sites we have chosen the top 37 in a variety of categories. Although we realize there are about 14 billion web sites we did not visit, we feel pretty good about our choices."
Was Scott a programmer or just a really active user?
Don't worry, I won't tell them your dirty little secret, "pacman"!
"Patents are supposed to be used by the people who invent things to get money from the people who use those inventions to make products"
Patents are "supposed" to be used for exactly what we the people decide they should be used for. They are an artificial temporary monopoly that WE citizens have agreed to allow (through our representatives) in exchange for the economic benefit that goes along with the monopoly. That benefit is a window of opportunity to recoup the investment in R&D used to create the product, which in turn encourages economic development and investment.
I (and it would appear I'm not alone) did not ever agree to "idea squatters" that randomly combine trivial technologies, never produce product and ultimately REDUCE the very economic investment and development that patents were supposed to encourage.
No, it's not name calling, it's calling a spade a spade.
You state that hardware is more reliable than software because hardware is non-algorithmic and synchronous. This does not seem to be correct.
Hardware is typically more reliable than software for the following reasons:
1) Patching hardware is very difficult and expensive, so they get it right the first time. Patching software is cheap and easy, so they don't worry as much.
2) Harwdare does have errors, have you ever looked at the errata sheets for CPU's?
3) Hardware typically has a more limited set of functions than software, software combines those limited functions into increasingly large sequences resulting in a much larger state space, which in turn requires more testing.
You state that the brain is reliable because it is signal based and synchronous. This is not the reason the brain is reliable (the brain is asynchronous, not synchronous). The brain is reliable because it employs a mathematical model that matches input to closest previous match from experience. It will always choose an output, although the output will only be as good as experience and training.
It was difficult on that page to see a concrete argument showing how a UBM improves reliability, other than the stated analogies. If I have missed a key point as to why a UBM has advantages, I would be interested in knowing what those reasons are.
Waterboy's Mom: "Don't you go sayin' that Scott McNealy man coined that phrase! Your momma coined that phrase! I was settin' out back fryin' up some gators when all suddenly like I thought, 'the network is...'"
Both McNeally and Schwartz spend way too much time bad-mouthing the competition. Every time they do that I think "Hmm, Sun must be worried about something otherwise they wouldn't be bad-mouthing those guys."
I've been part of business deals where this exact type of behavior is why the client chose not to do business with our competition.
Mainframes have detailed error detection and transaction rollback at the hardware level. AS400's are rock solid, no virus, no buffer overflows, very secure, etc. etc. I'm sure some Unix systems are very good also. The unreliability you speak of is Windows and PC hardware, primarily due to the fact they are inexpensive. You get what you pay for.
It happened to me. I was logging onto some box after having passed through a few different operating systems on various boxes to get there, when I keyed in my password the damn thing got echoed back to the screen and the person behind me started laughing (it was one of those passwords you wouldn't tell your mom about!).
What is being stifled is the trivial application of routine usage of technologies. Here are a couple examples you may not be aware of:
1) Amazon is the only company that can have a web site where you click 1 time to purchase (as in, your name and address are read in from the cookie instead of you keying it in). Barnes and Noble was required to change their web site to 2 clicks. 2) RIM (Blackberry) both went after other companies successfully, and was a target themselves (NTP $600million) for violations of the patented method of sending text over a wire-less communications connection. There are tens of thousands of trivial examples like these that have been patented.
But they have a really good reputation for shipping products
I think you need to go back and check your facts on this one. MS regularly misses ship dates, especially on large projects like OS's.
For me personally, not being able to takes notes would be a serious problem. As I take notes it forces me to concentrate on the topic and internalize the concepts. Throughout college, I gained far more from the note taking PROCESS than from the usage of the notes themselves.
I agree SLA's are worthless, for a variety of reasons.
However, I disagree that centralized IT should die. I have spent much time in my professional career undoing the nightmare of islands of systems where information is stored in multiple places (and only one is current), the same data value is stored differently (different customer numbers, item numbers, etc.). Attempting to reconcile differences in procedures, bring info together after the fact, etc. etc. is time consuming and error prone.
I can see having dedicated resources as long as the enterprise architecture is coordinated and reasonably centralized.
I heard you were dead.