At no point can either Amy or Bill determine whether or not the other coin has been flipped. All they can say for sure is that WHEN IT IS, it will come up a certain way. Maybe it already has been flipped, maybe it hasn't. The only way to find out would be using a classical communications channel.
There is a CORRELATION between the two 'coins' with entanglement, but there is NO causality. Flipping one coin does NOT cause the other one to flip, this has actually been verified by various iterations of experiments testing Bell's hypothesis. The logic is a bit trickier and my simple analogy isn't good enough to explain it, but in actual quantum mechanics if one flip caused the other, then certain experiments could be devised which would have different results than if the two flips are merely 'coincidence'.
This is one of the amazing things about QM. There is actually NO causality anywhere in QM, only a distribution of the probabilities in a particular special type of function space. Causality is an emergent phenomenon which only exists at the 'macroscopic' level. Even then it isn't absolute. I believe it was Stephen Hawking who once quipped that Cthulhu could materialize in the middle of the Pacific Ocean at any moment and no law of physics would be broken.
There are a LOT of other interesting ideas which come out of this, like questions about the meaning of entropy, which leads into questions like the Anthropic Principle.
The flaw in your reasoning is you cannot TELL by looking at your qubit whether or not the other qubit has been measured yet or not. Thus the scheme you propose is simply impossible.
All the two sides can determine is that they each end up with the same measurements whenever they DO measure their entangled states. Unless they agree beforehand on what that information means it is just a random number which they both share.
No information has passed from one end of the channel to the other.
Because the measurements you each make at each end are RANDOM. You each know that the measurements made by the other end are the same as yours, but that doesn't amount to 'information'. You would have to agree beforehand what EVERY possible sequence of random values would be when it was actually measured, which means all the information you could possibly transmit would have to be carried with each party (subject to classical relativistic mechanics).
Thus you each DO 'know' something when you do your measurements, but that knowing in and of itself is uninformative, and neither party has any control over WHAT is transmitted.
Suppose Bob and Amy entangle 2 coins so if one comes up heads, the other comes up tails. Now they go away from each other and each flip their coin. All they know is that the other's coin came up opposite to that, and which way the two together came up is random. If they want the way the two came up to 'mean' something, they have to agree on that meaning BEFORE they go apart (or by radio etc). THAT is the information, and it wasn't transmitted 'faster than light', it was carried in their heads or it was carried by radio etc.
The actual situation is a bit more complex than that, but from an information perspective this the right way to think about it.
Because you would have to AGREE BEFOREHAND on what each collapse MEANT. Each series of measurements on each end is RANDOM. Thus all each end of the channel knows is a random number. They each know the SAME random number (or its inverse which is the same thing). It is just a random number, it contains no information.
In order for information to be passed, the two sides would have to agree (by communicating using a classical channel) as to what they would interpret their random numbers to mean. The information thus ALREADY EXISTS at each end of the quantum channel and no new information is passed beyond that by the quantum channel.
Here's an illustration of the non-tranmission of information via entanglement.
Suppose we have a pair of 'magic coins'. Either coin can be flipped and come up either heads or tails, and the other coin will always come up the opposite.
Now, suppose 2 people meet in New York and agree that they will meet again in Oslo if Amy's coin comes up heads and Bill's coin comes up tails, or they will meet in Sidney if Bill's coin comes up heads and Amy's coin comes up tails. Then Amy goes to Peking and flips her coin. It comes up heads, so she meets Bill in Oslo.
The information, which city they will meet in, was AGREED ON BEFORE HAND, it wasn't 'transmitted' by the flip of the coins. The information was in Amy's head when she went to Peking, it traveled by a classical channel governed by relativistic limitations.
This can be seen explicitly if you assume that Amy and Bill DIDN'T agree on which face of the coins meant Oslo or Sidney. In that case when Bill and Amy flip their coins they DO know that their opposite number's coin came up the other way, but neither of them knows which city to go to! In other words, no information was conveyed between them BY the flip of the coins.
2 entangled quantum states are like 2 magic coins. When you flip one coin and it comes up heads, the other coin comes up tails.
Now, suppose I flip my coin, and your 100 light years away. You don't know if I have flipped my coin or not, nor if it came up heads or tails. You flip yours, it comes up tails, you now know mine must have come up heads. What information has passed between us? ALL we each know is how the other's coin came up. There is no way to use that fact to communicate anything else.
Now, you CAN use it as say an encryption key, but the encrypted data STILL needs to be transmitted between both parties, and that is subject to relativistic limitations.
So, in some sense a quantum state is 'teleported' between two entangled systems, but no actual information is exchanged which is of any use to anyone. Where it becomes interesting from a computing perspective is when you teleport superpositions of states, which allows you to store or move qbits around reliably and accurately (because they don't have to actually travel through the intervening distance, where they would most likely be perturbed). You still can't transmit information instantly because there is classical information required (how the other guys 'coin' flipped) required to interpret whatever answer you get.
Not only are a large percentage of your line of business type systems written in Java, but it is a perfectly fine language for writing applications in. I can build an application on top of RCP and avoid reinventing MANY large wheels, and when I'm done I have an application which will run on pretty much any OS. I can reuse the code to make a mobile version or some mobile mini apps. I can share code libraries between the client and the server, and it took me 2 hours of coding and testing the other day to include javascript in the client (and it can instantly call any function in the client).
Got nothing against other languages and toolsets, but Java development is a fine place to be right now. Applets may not be that great, but JWS fills a niche that is useful too.
Since when did you run your high throughput transaction processing system on a desktop OS? These numbers are basically meaningless in the sense that they don't reflect anything anyone would actually do with the software that was tested.
Now, a comparison between 2000 Server, 2003, and 2008 would have been more useful.
As you say, I suppose this whole thing demonstrates that MS can make progress optimizing an SMP kernel. Sure would be pretty surprising if they couldn't!
Maybe someone will make some comparisons vs some Linux kernel builds and some OpenSolaris builds. That would be just as interesting, since it is a bit less clear whether or not those teams have or are able to make equivalent or better optimizations.
If you count all production which supports the entire defense establishment, then it is a VERY large percentage!
The production dedicated to actually building military hardware is much lower, but that effectively just represents the tip of a very large iceberg. Of course were defense spending to be reduced, that proportion would decrease much more.
But it is a fair number in that it gets at the actual total impact of military spending on the US economy.
I see there has been a few people flinging that one around here lately, but it is totally appropriate in the context of military spending.
When you build a bomb, you produce something that certainly gives the bomb builder a job, but it produces no other useful input to society. When you instead spend that money on roads, bridges, renewable energy, R&D, or even just plain consumer goods at least you get SOMETHING out of it.
Some people will respond that the military provides some sort of 'security'. Well, up to a certain point that might be true, but consider it further.
No amount of spending is going to 'make you safe'. There are at least 5,000 strategic nuclear weapons on hair trigger alert pointed at the US. No amount of spending on more weapons is going to make any impact on that threat. Nor is there any reasonable way to defend the US against terrorism by more such spending. I'm not suggesting we should just ignore terrorists, but tanks, warplanes, warships, etc do not materially add to our security against such things.
In fact one can just as effectively argue that we are LESS secure because of the threatening size and capability of our military, which all other countries on the earth don't equal and must all consider as a possible threat, which then leads to increased spending everywhere else. Nor would George W Bush have had the opportunity to screw things up as he did if he wasn't given so many toys to play with.
I'll be amused to go back and consider all these points again after the US is forced to withdraw from Afghanistan and the Taliban resumes power and after the government of Iraq degenerates back into anarchy and ends up either yet again a totalitarian dictatorship and/or an Iranian puppet state.
I get modded 'Flamebait'? Great huh? Truth hurts I guess. What do you get when a bunch of morons are the moderators, the lowest common denominator of crap just rises right to the top...
Oh well, it matters not. The US has finished itself off anyway. I figure we'll have that 50% defense reduction pretty soon now. Hard to hire soldiers when you're broke.
Depends on who's numbers you look at. Different groups count different things depending on what they'd like you to believe. My main point was that the 3% figure is FAR below a realistic total number. 3% only counts direct DoD spending budgeted for the existing military. It doesn't count huge costs like the support of the VA, much of the R&D budget, and a whole lot of ancillary expenses and things that are only being paid for because they indirectly contribute to defense.
No doubt there are reasonable arguments against counting some of the things the numbers I threw out there do count, and the numbers you quote don't seem unreasonable either. I'd accept them as being a reasonable point of discussion.
done on this, I think back in the 60's. They concluded that the actual likely casualties were much lower on both sides. Most of Japan's Army was in China or isolated in various places. The Allies had TOTAL air and sea superiority, so they could outflank any defense along the coast and prevent any movement or concentration of enemy forces, or even resupply. At that point there was basically no oil anywhere in Japan.
This may not have been as apparent to the Allies in 1945 however. We can endlessly argue one way or the other about Hiroshima and Nagasaki. The truth is they attacked us and showed no mercy and we fought back against them with everything we had. If you have a guy on the ropes and he isn't quite down yet you step up and hit him again, as hard as you can.
87% of the US manufacturing base is devoted to weapons manufacture. The US accounts for over 75% of all military expenditures, world wide, and over 50% is on our own military (not counting the costs of Iraq or Afghanistan).
As to what percentage of the GDP that is, the 3% figure is highly conservative and only counts the direct costs of bombs, guns, payroll, and some of the cost of weapons development.
The compounded cost of that wasted economic output is very high over time. Each year, even assuming 3% is the best figure, you loose 3% of your economic output which could have gone into growth without costing anyone a dime, net. The doubling time at 3% is what, 20 some odd years? So, starting in 1948 would make 60 years of this, so the economy is now roughly 1/2 the size it could be if we hadn't just plowed all that money into the ground.
Now obviously the US couldn't entirely do without a military, but the total cost of the military was considerably over 3% too, so on the whole it looks to me like if we had HALVED our spending (so we're only 1/3 of the total world defense budget) we would be an economic powerhouse right now instead of being a basket case with a military that is still designed to fight the Russians in Europe.
So your '3% is nothing in the grand scheme of things' is just a bit off;).
Sorry, I was there on the phone with the Lead tech support person. Flat out I was told, no, we choose not to reveal what the value of that registry key is supposed to be, sorry. And then they billed us for the tech support.
I don't bash Microsoft about their products, although I am understandably vastly more familiar with and perfectly happy with Linux. I've just seen first hand that the vendor's interests are always before your own. It would have cost them nothing to get me out of that jam. I don't blame them for the loss of the data, there were a whole list of things that should have saved us, like backups maybe? Nor do I think they are any worse than any other vendor in particular.
If I HAVE to have certain things, like Cisco routers, then I pay for the commercial stuff too. I'd just rather not be locked into proprietary technology for the core functions of my business.
FREEDOM is the issue. This is what so many people are missing. Now some will say that freedom doesn't mean anything or is irrelevant to them, but I would beg to differ with them.
For Example, I recall an incident which cost my company over $10k. We were running an NT4 server that was spanning volume sets over a number of disks (never mind the wisdom of that, it was a supported feature and we used it as intended). One day in its typical fashion NT porked its registry and had to be reinstalled. No more access to that volume set! Oh, we talked to MS about it and their answer was flat out "sure we know what you'd have to edit into the registry to get that volume set to work again, but we just don't choose to tell you."
Vendors don't care about you. Certainly big vendors don't care about you one bit. You're an ant to them, and they won't even give you the time of day.
Had that been a Linux server in a similar situation all I'd have had to do was dig around and find out HOW to fix the problem and fix it.
So as far as I'm concerned forget proprietary software vendors. I can always hire a consultant to fix any issues I have with OSS or staff can do it. Commercial software is just too much of a risk, certainly for anything my business depends on. We ditched MS products 10 years ago and never looked back.
I guess you'd have to explain that to the big multinational financial firms that are our clients. They are a fantasy! lol.
Beyond that though, while I make the argument in terms of very large organizations, SoA can have benefits for much smaller organizations as well. Smaller organizations may often be able to get by with the old fashioned chewing gum and duct tape sort of IT of the past, but that doesn't mean they wouldn't be more profitable and more responsive if they had better visibility into their data, etc.
Beyond that most smaller organizations are components in the supply chains of or provide services to large corporations. Those large corporations are certainly interested in being able to integrate their suppliers into THEIR enterprise systems, and that means it is an advantage to understand SoA and build your systems in an SoA fashion.
Don't assume that the rest of the world is just like your little bit of it. And don't assume that just because you do things a certain way in your little bit that it is the only way or the best way.
That isn't what SoA is about
on
The Zen of SOA
·
· Score: 1
SoA isn't about building standardized libraries really. It is about building large scale enterprise wide distributed architectures. Remote procedure calling is only one facet of SoA.
DCOM is an RPC mechanism. The problem with DCOM is that it was designed as a platform specific mechanism. Yes, in theory you could implement it on any platform, but it is really only suitable for use on Windows and, like CORBA, it is difficult to maintain and implement code using it.
SoA's preferred equivalent to DCOM/CORBA is SOAP and the associated WS-* standard profiles built on top of SOAP. These are much more portable, standardized, and flexible, but they do essentially the same thing, and it is only a small part of SoA.
SoA also includes things like service description (WSDL) and service directories (UDDI), standardized taxonomies for data (XSD etc), message routing, distributed transactions, asynchronous services, and business process description and implementation.
So, while I could build a distributed application using DCOM, CORBA, or JRMP, with SoA I can go far beyond just that. With a properly designed SoA architecture I can construct catalogs of services, identify service instances dynamically, and build applications on top of the entire enterprise wide set of services that are reliable and maintainable. These kinds of things were simply impossible with DCOM or other RPC standards because they simply didn't address all of the necessary functionality and were too cumbersome.
SoA may be a 'buzz word', but what it represents is very real and has very real uses and benefits.
You aren't looking at it from the right POV
on
The Zen of SOA
·
· Score: 1
Now, imagine you are in charge of the entire enterprise-wide information processing activity and architecture of a very large corporation. one which is global in scale, has possibly 100's of facilities, dozens of lines of business, and 10's of thousands of employees.
Some sort of ad-hoc approach where each little department basically does its thing and maybe if they're lucky they can share some data with (only a few) other 'compatible' departments in other places, and you have to have 500 bean counters writing reports all day just to get enough visibility into your own business operations to even ATTEMPT to manage this thing is not going to cut it. Not in the 21st Century.
So, you really HAVE to come at the whole problem from an enterprise wide perspective. That means applying system architectural principles to the whole enterprise. That means the data and services provided by IT infrastructure in any and all locations need to be able to dovetail together. This is where things like SoA come in. Using web services, federated naming, ITIL, and a highly systematic set of 'meta-processes' (like the kind of thing you find in TOGAF) is what makes the difference between you and the competition. Or more likely at least keeps you at par with the competition.
From a small/medium sized business perspective it might not seem like it makes a whole lot of sense, but in reality those 'extra layers' are abstractions and services which allow this large enterprise to be knit together. Done well it is a good thing!
Slashdot Mirror
At no point can either Amy or Bill determine whether or not the other coin has been flipped. All they can say for sure is that WHEN IT IS, it will come up a certain way. Maybe it already has been flipped, maybe it hasn't. The only way to find out would be using a classical communications channel.
There is a CORRELATION between the two 'coins' with entanglement, but there is NO causality. Flipping one coin does NOT cause the other one to flip, this has actually been verified by various iterations of experiments testing Bell's hypothesis. The logic is a bit trickier and my simple analogy isn't good enough to explain it, but in actual quantum mechanics if one flip caused the other, then certain experiments could be devised which would have different results than if the two flips are merely 'coincidence'.
This is one of the amazing things about QM. There is actually NO causality anywhere in QM, only a distribution of the probabilities in a particular special type of function space. Causality is an emergent phenomenon which only exists at the 'macroscopic' level. Even then it isn't absolute. I believe it was Stephen Hawking who once quipped that Cthulhu could materialize in the middle of the Pacific Ocean at any moment and no law of physics would be broken.
There are a LOT of other interesting ideas which come out of this, like questions about the meaning of entropy, which leads into questions like the Anthropic Principle.
No kidding.
quantum mechanics, lol.
The flaw in your reasoning is you cannot TELL by looking at your qubit whether or not the other qubit has been measured yet or not. Thus the scheme you propose is simply impossible.
All the two sides can determine is that they each end up with the same measurements whenever they DO measure their entangled states. Unless they agree beforehand on what that information means it is just a random number which they both share.
No information has passed from one end of the channel to the other.
Because the measurements you each make at each end are RANDOM. You each know that the measurements made by the other end are the same as yours, but that doesn't amount to 'information'. You would have to agree beforehand what EVERY possible sequence of random values would be when it was actually measured, which means all the information you could possibly transmit would have to be carried with each party (subject to classical relativistic mechanics).
Thus you each DO 'know' something when you do your measurements, but that knowing in and of itself is uninformative, and neither party has any control over WHAT is transmitted.
Suppose Bob and Amy entangle 2 coins so if one comes up heads, the other comes up tails. Now they go away from each other and each flip their coin. All they know is that the other's coin came up opposite to that, and which way the two together came up is random. If they want the way the two came up to 'mean' something, they have to agree on that meaning BEFORE they go apart (or by radio etc). THAT is the information, and it wasn't transmitted 'faster than light', it was carried in their heads or it was carried by radio etc.
The actual situation is a bit more complex than that, but from an information perspective this the right way to think about it.
Because you would have to AGREE BEFOREHAND on what each collapse MEANT. Each series of measurements on each end is RANDOM. Thus all each end of the channel knows is a random number. They each know the SAME random number (or its inverse which is the same thing). It is just a random number, it contains no information.
In order for information to be passed, the two sides would have to agree (by communicating using a classical channel) as to what they would interpret their random numbers to mean. The information thus ALREADY EXISTS at each end of the quantum channel and no new information is passed beyond that by the quantum channel.
Here's an illustration of the non-tranmission of information via entanglement.
Suppose we have a pair of 'magic coins'. Either coin can be flipped and come up either heads or tails, and the other coin will always come up the opposite.
Now, suppose 2 people meet in New York and agree that they will meet again in Oslo if Amy's coin comes up heads and Bill's coin comes up tails, or they will meet in Sidney if Bill's coin comes up heads and Amy's coin comes up tails. Then Amy goes to Peking and flips her coin. It comes up heads, so she meets Bill in Oslo.
The information, which city they will meet in, was AGREED ON BEFORE HAND, it wasn't 'transmitted' by the flip of the coins. The information was in Amy's head when she went to Peking, it traveled by a classical channel governed by relativistic limitations.
This can be seen explicitly if you assume that Amy and Bill DIDN'T agree on which face of the coins meant Oslo or Sidney. In that case when Bill and Amy flip their coins they DO know that their opposite number's coin came up the other way, but neither of them knows which city to go to! In other words, no information was conveyed between them BY the flip of the coins.
2 entangled quantum states are like 2 magic coins. When you flip one coin and it comes up heads, the other coin comes up tails.
Now, suppose I flip my coin, and your 100 light years away. You don't know if I have flipped my coin or not, nor if it came up heads or tails. You flip yours, it comes up tails, you now know mine must have come up heads. What information has passed between us? ALL we each know is how the other's coin came up. There is no way to use that fact to communicate anything else.
Now, you CAN use it as say an encryption key, but the encrypted data STILL needs to be transmitted between both parties, and that is subject to relativistic limitations.
So, in some sense a quantum state is 'teleported' between two entangled systems, but no actual information is exchanged which is of any use to anyone. Where it becomes interesting from a computing perspective is when you teleport superpositions of states, which allows you to store or move qbits around reliably and accurately (because they don't have to actually travel through the intervening distance, where they would most likely be perturbed). You still can't transmit information instantly because there is classical information required (how the other guys 'coin' flipped) required to interpret whatever answer you get.
Not only are a large percentage of your line of business type systems written in Java, but it is a perfectly fine language for writing applications in. I can build an application on top of RCP and avoid reinventing MANY large wheels, and when I'm done I have an application which will run on pretty much any OS. I can reuse the code to make a mobile version or some mobile mini apps. I can share code libraries between the client and the server, and it took me 2 hours of coding and testing the other day to include javascript in the client (and it can instantly call any function in the client).
Got nothing against other languages and toolsets, but Java development is a fine place to be right now. Applets may not be that great, but JWS fills a niche that is useful too.
Has a lot more functionality than flashblocker and their ilk, and will defeat the VAST majority of browser based attacks as well.
Plus it has some slightly more flexible options for configuration, etc.
Since when did you run your high throughput transaction processing system on a desktop OS? These numbers are basically meaningless in the sense that they don't reflect anything anyone would actually do with the software that was tested.
Now, a comparison between 2000 Server, 2003, and 2008 would have been more useful.
As you say, I suppose this whole thing demonstrates that MS can make progress optimizing an SMP kernel. Sure would be pretty surprising if they couldn't!
Maybe someone will make some comparisons vs some Linux kernel builds and some OpenSolaris builds. That would be just as interesting, since it is a bit less clear whether or not those teams have or are able to make equivalent or better optimizations.
If you count all production which supports the entire defense establishment, then it is a VERY large percentage!
The production dedicated to actually building military hardware is much lower, but that effectively just represents the tip of a very large iceberg. Of course were defense spending to be reduced, that proportion would decrease much more.
But it is a fair number in that it gets at the actual total impact of military spending on the US economy.
I see there has been a few people flinging that one around here lately, but it is totally appropriate in the context of military spending.
When you build a bomb, you produce something that certainly gives the bomb builder a job, but it produces no other useful input to society. When you instead spend that money on roads, bridges, renewable energy, R&D, or even just plain consumer goods at least you get SOMETHING out of it.
Some people will respond that the military provides some sort of 'security'. Well, up to a certain point that might be true, but consider it further.
No amount of spending is going to 'make you safe'. There are at least 5,000 strategic nuclear weapons on hair trigger alert pointed at the US. No amount of spending on more weapons is going to make any impact on that threat. Nor is there any reasonable way to defend the US against terrorism by more such spending. I'm not suggesting we should just ignore terrorists, but tanks, warplanes, warships, etc do not materially add to our security against such things.
In fact one can just as effectively argue that we are LESS secure because of the threatening size and capability of our military, which all other countries on the earth don't equal and must all consider as a possible threat, which then leads to increased spending everywhere else. Nor would George W Bush have had the opportunity to screw things up as he did if he wasn't given so many toys to play with.
I'll be amused to go back and consider all these points again after the US is forced to withdraw from Afghanistan and the Taliban resumes power and after the government of Iraq degenerates back into anarchy and ends up either yet again a totalitarian dictatorship and/or an Iranian puppet state.
I get modded 'Flamebait'? Great huh? Truth hurts I guess. What do you get when a bunch of morons are the moderators, the lowest common denominator of crap just rises right to the top...
Oh well, it matters not. The US has finished itself off anyway. I figure we'll have that 50% defense reduction pretty soon now. Hard to hire soldiers when you're broke.
Depends on who's numbers you look at. Different groups count different things depending on what they'd like you to believe. My main point was that the 3% figure is FAR below a realistic total number. 3% only counts direct DoD spending budgeted for the existing military. It doesn't count huge costs like the support of the VA, much of the R&D budget, and a whole lot of ancillary expenses and things that are only being paid for because they indirectly contribute to defense.
No doubt there are reasonable arguments against counting some of the things the numbers I threw out there do count, and the numbers you quote don't seem unreasonable either. I'd accept them as being a reasonable point of discussion.
Top dollar now for old surplus US Government safes. Good for scrap metal they say!
done on this, I think back in the 60's. They concluded that the actual likely casualties were much lower on both sides. Most of Japan's Army was in China or isolated in various places. The Allies had TOTAL air and sea superiority, so they could outflank any defense along the coast and prevent any movement or concentration of enemy forces, or even resupply. At that point there was basically no oil anywhere in Japan.
This may not have been as apparent to the Allies in 1945 however. We can endlessly argue one way or the other about Hiroshima and Nagasaki. The truth is they attacked us and showed no mercy and we fought back against them with everything we had. If you have a guy on the ropes and he isn't quite down yet you step up and hit him again, as hard as you can.
Dir Bob:
Please report to your nearest Ministry of Health clinic for evaluation.
Your Truely
B. B.
87% of the US manufacturing base is devoted to weapons manufacture. The US accounts for over 75% of all military expenditures, world wide, and over 50% is on our own military (not counting the costs of Iraq or Afghanistan).
As to what percentage of the GDP that is, the 3% figure is highly conservative and only counts the direct costs of bombs, guns, payroll, and some of the cost of weapons development.
The compounded cost of that wasted economic output is very high over time. Each year, even assuming 3% is the best figure, you loose 3% of your economic output which could have gone into growth without costing anyone a dime, net. The doubling time at 3% is what, 20 some odd years? So, starting in 1948 would make 60 years of this, so the economy is now roughly 1/2 the size it could be if we hadn't just plowed all that money into the ground.
Now obviously the US couldn't entirely do without a military, but the total cost of the military was considerably over 3% too, so on the whole it looks to me like if we had HALVED our spending (so we're only 1/3 of the total world defense budget) we would be an economic powerhouse right now instead of being a basket case with a military that is still designed to fight the Russians in Europe.
So your '3% is nothing in the grand scheme of things' is just a bit off ;).
Sorry, I was there on the phone with the Lead tech support person. Flat out I was told, no, we choose not to reveal what the value of that registry key is supposed to be, sorry. And then they billed us for the tech support.
I don't bash Microsoft about their products, although I am understandably vastly more familiar with and perfectly happy with Linux. I've just seen first hand that the vendor's interests are always before your own. It would have cost them nothing to get me out of that jam. I don't blame them for the loss of the data, there were a whole list of things that should have saved us, like backups maybe? Nor do I think they are any worse than any other vendor in particular.
If I HAVE to have certain things, like Cisco routers, then I pay for the commercial stuff too. I'd just rather not be locked into proprietary technology for the core functions of my business.
FREEDOM is the issue. This is what so many people are missing. Now some will say that freedom doesn't mean anything or is irrelevant to them, but I would beg to differ with them.
For Example, I recall an incident which cost my company over $10k. We were running an NT4 server that was spanning volume sets over a number of disks (never mind the wisdom of that, it was a supported feature and we used it as intended). One day in its typical fashion NT porked its registry and had to be reinstalled. No more access to that volume set! Oh, we talked to MS about it and their answer was flat out "sure we know what you'd have to edit into the registry to get that volume set to work again, but we just don't choose to tell you."
Vendors don't care about you. Certainly big vendors don't care about you one bit. You're an ant to them, and they won't even give you the time of day.
Had that been a Linux server in a similar situation all I'd have had to do was dig around and find out HOW to fix the problem and fix it.
So as far as I'm concerned forget proprietary software vendors. I can always hire a consultant to fix any issues I have with OSS or staff can do it. Commercial software is just too much of a risk, certainly for anything my business depends on. We ditched MS products 10 years ago and never looked back.
Uh, huh, sure...
I guess you'd have to explain that to the big multinational financial firms that are our clients. They are a fantasy! lol.
Beyond that though, while I make the argument in terms of very large organizations, SoA can have benefits for much smaller organizations as well. Smaller organizations may often be able to get by with the old fashioned chewing gum and duct tape sort of IT of the past, but that doesn't mean they wouldn't be more profitable and more responsive if they had better visibility into their data, etc.
Beyond that most smaller organizations are components in the supply chains of or provide services to large corporations. Those large corporations are certainly interested in being able to integrate their suppliers into THEIR enterprise systems, and that means it is an advantage to understand SoA and build your systems in an SoA fashion.
Don't assume that the rest of the world is just like your little bit of it. And don't assume that just because you do things a certain way in your little bit that it is the only way or the best way.
SoA isn't about building standardized libraries really. It is about building large scale enterprise wide distributed architectures. Remote procedure calling is only one facet of SoA.
DCOM is an RPC mechanism. The problem with DCOM is that it was designed as a platform specific mechanism. Yes, in theory you could implement it on any platform, but it is really only suitable for use on Windows and, like CORBA, it is difficult to maintain and implement code using it.
SoA's preferred equivalent to DCOM/CORBA is SOAP and the associated WS-* standard profiles built on top of SOAP. These are much more portable, standardized, and flexible, but they do essentially the same thing, and it is only a small part of SoA.
SoA also includes things like service description (WSDL) and service directories (UDDI), standardized taxonomies for data (XSD etc), message routing, distributed transactions, asynchronous services, and business process description and implementation.
So, while I could build a distributed application using DCOM, CORBA, or JRMP, with SoA I can go far beyond just that. With a properly designed SoA architecture I can construct catalogs of services, identify service instances dynamically, and build applications on top of the entire enterprise wide set of services that are reliable and maintainable. These kinds of things were simply impossible with DCOM or other RPC standards because they simply didn't address all of the necessary functionality and were too cumbersome.
SoA may be a 'buzz word', but what it represents is very real and has very real uses and benefits.
Now, imagine you are in charge of the entire enterprise-wide information processing activity and architecture of a very large corporation. one which is global in scale, has possibly 100's of facilities, dozens of lines of business, and 10's of thousands of employees.
Some sort of ad-hoc approach where each little department basically does its thing and maybe if they're lucky they can share some data with (only a few) other 'compatible' departments in other places, and you have to have 500 bean counters writing reports all day just to get enough visibility into your own business operations to even ATTEMPT to manage this thing is not going to cut it. Not in the 21st Century.
So, you really HAVE to come at the whole problem from an enterprise wide perspective. That means applying system architectural principles to the whole enterprise. That means the data and services provided by IT infrastructure in any and all locations need to be able to dovetail together. This is where things like SoA come in. Using web services, federated naming, ITIL, and a highly systematic set of 'meta-processes' (like the kind of thing you find in TOGAF) is what makes the difference between you and the competition. Or more likely at least keeps you at par with the competition.
From a small/medium sized business perspective it might not seem like it makes a whole lot of sense, but in reality those 'extra layers' are abstractions and services which allow this large enterprise to be knit together. Done well it is a good thing!