This is almost funny, were it not something that has affected so many people in a serious way. My group works with OPC systems every day (doing integration work between various BAS systems and 3rd party products), and one of my biggest concerns with OPC is when we're forced to deploy it via DCOM.
By definition, OPC uses COM for local (within the same PC) client/server interaction, and DCOM for client/server interaction across a network. The setup, connect, and disconnect issues surrounding DCOM have spawned an industry within the OPC industry for working around these issues.
For example, some OPC servers require "remote registry browsing." This means exactly what it sounds like. My computer browses the registry of your computer so I can find out what OPC servers you have installed. In one of its better moves, Microsoft told the OPC foundation that future versions of Windows would restrict remote registry browsing, so they've come up with various solutions. However, some older servers still require this for server browsing, and some companies (ahem) are perfectly OK with it!
Last week, I exchanged e-mails with another engineer who suggested that because my group wanted to avoid DCOM security issues, that it must be because we weren't technically savvy enough to do so. I'm on the other side wondering why he's willing to put the customer's system at risk.
Now, back to reality, W32.Blaster attacks a machine using remote procedure calls, and OPC uses RPC to perform client/server data transfer. While setting up a network to facilitate OPC *may* not inherently make it susceptible to W32.Blaster, it may, depending on how Blaster actually works (I don't know enough about it to say one way or the other).
In short, I'm not ready to point the finger at OPC for the blackout, but it wouldn't surprise me to find that many places that implement OPC using DCOM have been hammered by W32.Blaster. The very settings that make it easy to make OPC/DCOM work correctly open their systems up to all sorts of nasty things once a rogue program is running on one of them.
OPC/DCOM (as typically implemented) represents a serious "trust relationship," and most companies don't make process control PCs part of an NT domain. As a result, setting up launch/access/config permissions becomes a tricky and error-prone matter of managing account names and passwords from other PCs. Since managing those becomes a distributed nightmare, many places unwisely don't force those machines to abide by password policy, and (even worse) use simple password & username combos.
This should sound like a recipe for disaster.
Tim
P.S. I sincerely hope that RPC and the W32.Blaster had *nothing* to do with the blackouts, but I doubt that most of the public will ever know. The insiders will most certainly not let out the details if it did.
Yeah... all the techies clearly missed the theme park that's NEXT DOOR TO THE CONVENTION HALL. Besides, these people no doubt have huge families, drive SUVs, and really need a place to park Martha and the kiddo's while they're in the hall sipping scotch on the rocks with the stuffed shirts...
Years ago, Borland was hosting a party in San Diego for their annual developer convention. Cool place, but as I was standing around chatting with other Delphi programmers, I realized that we were not only all wearing the official Borland conference shirts (looking like the dweebs we were), we were all CLUELESS about the beautiful surroundings and oceanfront view. Oddly enough, we weren't there to see the sights, we were there to talk about code!
What were these MML2 morons thinking... that the attendees would be actually INDOORS, having a LAN PARTY???? You're right. Idiots... all of them.
Next time, instead of picking a nice centralized location in the Midwest, where hotels are ridiculously cheap, and the mid-sized airport is an absolute breeze to go through, they should opt for the wonders of LA or NYC, where their travel budgets would go up by a good 50% or so. After all, none of these guys are travelling on a shoestring or anything!
I'm not so sure your comparison is valid, because you generally don't know from one moment to the next what the CPU speed of your PC is. It stays the same, and it is what it was when you bought it. You may even forget about it if you're not a slashdotter.
In contrast, I know my S2000 redlines at 9K every time I drive it. I have a 466Mhz Celeron (Win98) next to a 350Mhz iMac (OS9), but the only time I think about the speed of either machine is when I'm adding/upgrading, or if someone asks. The iMac is zippier for most things, but I've just come to expect that.
Another consideration is that circuits dealing with very small signals (i.e. RF or nanovolt amps) will be all over the place with an etched board (remnants of the etching process). For several years, I worked for an electronic scale company where we would build custom load cell trimming boxes. The leakage from a hand-etched board relegated most of these to the "this is what it will look like" collection, and not something you could actually install at a job site for beta feedback.
In contrast, milling the board would give you similar turnaround time (less than an hour or so) but without the leakage. At the time I was doing this (about 10 years ago), I was printing out negatives on laser transparencies, photo-etching directly from the printer output, and then straight to the drilling machine. In one case, I was able to prototype a new trimming box for a customer within 2 hours, including layout & board stuffing time.
Being able to produce a milled board in an hour or so would be pretty groovy, but I have to think a pen plotter & Dremel tool would be more accurate.
Slashdot Mirror
This is almost funny, were it not something that has affected so many people in a serious way. My group works with OPC systems every day (doing integration work between various BAS systems and 3rd party products), and one of my biggest concerns with OPC is when we're forced to deploy it via DCOM.
By definition, OPC uses COM for local (within the same PC) client/server interaction, and DCOM for client/server interaction across a network. The setup, connect, and disconnect issues surrounding DCOM have spawned an industry within the OPC industry for working around these issues.
For example, some OPC servers require "remote registry browsing." This means exactly what it sounds like. My computer browses the registry of your computer so I can find out what OPC servers you have installed. In one of its better moves, Microsoft told the OPC foundation that future versions of Windows would restrict remote registry browsing, so they've come up with various solutions. However, some older servers still require this for server browsing, and some companies (ahem) are perfectly OK with it!
Last week, I exchanged e-mails with another engineer who suggested that because my group wanted to avoid DCOM security issues, that it must be because we weren't technically savvy enough to do so. I'm on the other side wondering why he's willing to put the customer's system at risk.
Now, back to reality, W32.Blaster attacks a machine using remote procedure calls, and OPC uses RPC to perform client/server data transfer. While setting up a network to facilitate OPC *may* not inherently make it susceptible to W32.Blaster, it may, depending on how Blaster actually works (I don't know enough about it to say one way or the other).
In short, I'm not ready to point the finger at OPC for the blackout, but it wouldn't surprise me to find that many places that implement OPC using DCOM have been hammered by W32.Blaster. The very settings that make it easy to make OPC/DCOM work correctly open their systems up to all sorts of nasty things once a rogue program is running on one of them.
OPC/DCOM (as typically implemented) represents a serious "trust relationship," and most companies don't make process control PCs part of an NT domain. As a result, setting up launch/access/config permissions becomes a tricky and error-prone matter of managing account names and passwords from other PCs. Since managing those becomes a distributed nightmare, many places unwisely don't force those machines to abide by password policy, and (even worse) use simple password & username combos.
This should sound like a recipe for disaster.
Tim
P.S. I sincerely hope that RPC and the W32.Blaster had *nothing* to do with the blackouts, but I doubt that most of the public will ever know. The insiders will most certainly not let out the details if it did.
Yeah... all the techies clearly missed the theme park that's NEXT DOOR TO THE CONVENTION HALL. Besides, these people no doubt have huge families, drive SUVs, and really need a place to park Martha and the kiddo's while they're in the hall sipping scotch on the rocks with the stuffed shirts...
Years ago, Borland was hosting a party in San Diego for their annual developer convention. Cool place, but as I was standing around chatting with other Delphi programmers, I realized that we were not only all wearing the official Borland conference shirts (looking like the dweebs we were), we were all CLUELESS about the beautiful surroundings and oceanfront view. Oddly enough, we weren't there to see the sights, we were there to talk about code!
What were these MML2 morons thinking... that the attendees would be actually INDOORS, having a LAN PARTY???? You're right. Idiots... all of them.
Next time, instead of picking a nice centralized location in the Midwest, where hotels are ridiculously cheap, and the mid-sized airport is an absolute breeze to go through, they should opt for the wonders of LA or NYC, where their travel budgets would go up by a good 50% or so. After all, none of these guys are travelling on a shoestring or anything!
Tim
I'm not so sure your comparison is valid, because you generally don't know from one moment to the next what the CPU speed of your PC is. It stays the same, and it is what it was when you bought it. You may even forget about it if you're not a slashdotter.
In contrast, I know my S2000 redlines at 9K every time I drive it. I have a 466Mhz Celeron (Win98) next to a 350Mhz iMac (OS9), but the only time I think about the speed of either machine is when I'm adding/upgrading, or if someone asks. The iMac is zippier for most things, but I've just come to expect that.
Tim
You mean BOTH of them? Tim
Another consideration is that circuits dealing with very small signals (i.e. RF or nanovolt amps) will be all over the place with an etched board (remnants of the etching process). For several years, I worked for an electronic scale company where we would build custom load cell trimming boxes. The leakage from a hand-etched board relegated most of these to the "this is what it will look like" collection, and not something you could actually install at a job site for beta feedback.
In contrast, milling the board would give you similar turnaround time (less than an hour or so) but without the leakage. At the time I was doing this (about 10 years ago), I was printing out negatives on laser transparencies, photo-etching directly from the printer output, and then straight to the drilling machine. In one case, I was able to prototype a new trimming box for a customer within 2 hours, including layout & board stuffing time.
Being able to produce a milled board in an hour or so would be pretty groovy, but I have to think a pen plotter & Dremel tool would be more accurate.