First, they're using bloated programs on poorly optimized file systems and they then complain about performance.
Second, a better optimization would result if you took in to account what the file type was.You'd lose some compatibility, but you'd gain a surprising amount of performance. The solution has been sitting around for decades: Anyone remember the infamous Record Management System from DEC? It existed as a layer between the kernel and the user space.
It would answer the concerns of these researchers, but it would require a massive rewrite of all the programs that use the file systems.
Yes, there are. Modern radio systems are meant to be good enough to be reliable. Ham radio systems are the art of the possible. Most hams these days are experimenters who enjoy trying odd things. I've seen voice powered radios, I've seen radio systems designed to communicate via lunar reflections, I've seen radio systems designed to pick up spacecraft in deep space.
Some hams like to study radio wave propagation. Again, this is the art of the possible, not the engineering of the certain. Bouncing signals off of thunderstorms, sporadic E layer reflectors or meteor trails are all in this category. Occasionally, they stumble across something that works surprisingly well.
Some still tinker with modulation methods. Hams were playing with spread spectrum radios in the mid 1980s --long before the engineers sat down to work on the so-called wireless standards. Today, work continues with all sorts of forward error correction codes and modulation techniques.
So, yes, there still is a ham radio. Yes, there still are a more than a few slobs who like to do nothing better than listen to themselves talk on short-wave. But there is still a vibrant core that continues to study all sorts of forgotten alleys in the technology.
Yes, City OSs already exist. These are the SCADA systems that utilities use to manage their resources. The problem is that these SCADA systems do not manage resources small enough to make the sorts of differences that these pro-city coordinators expect. It is not financially feasible to do it yet.
There is also a myth that a central authority will be staffed with geniuses who will automatically comprehend the situation and make it better. As recent blackouts in Chile showed, however, it is quite possible to be overwhelmed with alarms that no human can sort through.
What good is a boss if he micro-manages everything around?
There are dozens of automation controller manufactures out there. Many using these insecure protocols with no replacements in sight.
I would like to point out that there ARE some efforts to secure the non-deterministic SCADA side of things. Secure authentication is available for the DNP (IEEE-1815) protocol. At the present they must be pre-shared symmetric keys and there is no way to change those keys over the protocol; though that feature has been written and is undergoing review. The secure authentication specification is described in IEC 62351. Other protocols such as IEC 60870, and UCA2 (61850) are working on similar authentication features.
As for PLC/PAC protocols, they were designed for real time millisecond by millisecond timing. Authenticating would at least double the number of network transactions required to pass traffic and validate it. Some slower applications may be able to handle such speed penalties, but many can not. Remember that these protocols were designed to use the IP transport layer because the test equipment, network hardware, and software is widely available, cheap, and well understood. Unfortunately too many small minded idiots put it on the internet for the bragging rights of showing how one can program the plant floor controller from a tiki bar on the other side of the earth.
Regardless of what the marketeer crowd may have said in the past, it makes no sense to expose a deterministic real time network to any node that doesn't play nice. You don't have to do anything special to bring down such networks. If the traffic level gets too extreme, the controllers will fault. This is by design. They are supposed to make calculations every so many milliseconds and flush the results back to the field within a very short, limited time window. If they can't do that, they must stop working and the I/O should assume a safe state.
So yes, it's not hard to make a mess of one of these networks. That's why those networks must be carefully defended and kept to a very limited scope. Building authentication in to such networks is not nearly as effective at keeping hackers at bay as conventional wisdom would have you believe.
I expressed an opinion. People should be able to have different opinions. The wrongness is in your assumption that somehow there is a correct answer here. That is how group think gets started.
In any case, I thought you were being silly, so I decided to be silly back. I decided not to say much more than that because others have already argued back and forth, and I have little to add to the conversation. Besides, I don't always have the endless hours to while away on Slashdot, explaining my opinions to people whose political views are so narrow that they refuse to consider another point of view.
Go forth, believe what you want; but do yourself a favor and try a little respect for those who disagree with you. Sooner or later you will have to do as I have on other occasions and eat your words. At least this way, you won't have to eat bilious nonsense.
First, the study of climate (or astronomy) is not strictly a science. There are no opportunities to conduct controlled experiments. This is not inherently bad, but one must be careful not to label something a "science" when a sincere argument can be made that it is not. Luminaries such as Richard Feynman made such arguments, so I don't think one would be in bad company when saying that this study is not a science.
Second, the study of climate is fraught with error. Again, there is nothing wrong with this. Without the ability to conduct a controlled experiment, the best one can do is to model what is going on and to hypothesize why the model doesn't agree with observations or make accurate predictions.
The wrongness is when those very same people take their study results in to the political limelight and say to the effect "This is the sky; it is falling; and you must do as I say or evil will happen." Doesn't the notion of conflict of interest enter here?
There are many responses to how we could manage our changing climate. I am happy to read the research. I may read a suggestion regarding the responses. But really, it got a bad name because too many political hacks took a centralized conservation approach and built a phony baloney market in Carbon Dioxide indulgences that most researchers agree will have a minimal effect on the climate, while ignoring other potentially much more serious Green House Gasses like Methane.
Astronomy doesn't have this problem because astronomy is primarily a study of discoveries with very few implications on politics. And no, I don't see a good reason to call it a science, either.
Mod parent up. People are treating this as if it is voodoo technology that never existed before. In reality, these methods have existed for many decades. The problem is mass production and getting it down to a cost, size, and weight that people can want and afford.
Some of these problems can be overcome with newer technologies and improved linearity of amplifier and mixer technologies. My guess is that with a combination of that, frequency diversity, orthogonal antenna polarization, quadrature phase (TX PLL methods aren't the only way to achieve this, quadrature hybrids will do this too), and perhaps orthogonal code spread spectrum, there may be just enough separation to make this work.
But all this is a guess. The article doesn't reveal very much about what these researchers actually did to achieve this performance. In truth, it is easy to build a receiver and transmitter with better performance than what you have in your phone, if you don't care what the size, cost, and weight is. The phone of today is a marvelous series of compromises that yields a mass market device that is "good enough."
That, dear Slashdot readers, is what engineering is REALLY all about. It will be interesting to see how small, inexpensive, and light weight the Rice University researchers managed to make their prototype...
Writing is different than speaking. The greeting has already been made. Those are wasted words; and a wasted opportunity to make a good first impression. Instead, write something meaningful that could introduce yourself and establish common or contrasting interests: For example, "I'm intrigued that you like Ethiopian style cooking. I had an interesting experience in an Ethiopian restaurant..." This draws the reader's attention in to encourage further discussion.
The implication of writing (not saying, WRITING) "hi, how are you doing..." in this context shows a lack of imagination, and conveys an overall notion of "I am not enthusiastic about anything. I'm bored. Entertain me."
In general, when dating (regardless of sex or orientation), one would usually seek someone else who can be enthusiastic about something. The reason? You want to be the target of some of that enthusiasm. You want to share interests somewhere. These are the things that build relationships. You have to seek a common ground upon which to build experiences and adventures together.
In such a vast sea of people on the Internet, first impressions can mean a lot. Don't discount it.
This being slashdot, I don't expect that many of you will understand this advice. Nevertheless, here goes:
A big turn-off is someone who does not know how to communicate well. A relationship and a marriage are all about communication. This article is about a written introduction that makes a first impression, so you want to look your best. It's the same reason you would think carefully about what to wear and where to go on a first date.
Starting off with sexy talk is typically a turn off to a person looking for a relationship. If the relationship works, the sex will happen. Starting off with sex talk first is usually an indicator of someone whose expectations are quite shallow, or someone who is utterly disingenuous. Either way, it doesn't present an impression of someone who communicates well. Besides, trolling for sex in a place that advertises relationships isn't very honest.
I write this as someone who has been married for fifteen years, has three children, and watched with sadness as numerous other relationships and marriages of friends and acquaintances have fallen apart.
Our office is a small building on a concrete slab. We NEVER feel much in the way of movement. When this thing hit, I ran outside. The water storage reservoirs were making ominous oil-canning sounds on an industrial scale. Significant rumbling with some side to side movement.
Reminder for those of you in the East Coast: Something made those Appalachian mountains. It may not be as active as the West coast, but it would be wise not to ignore it.
Technically, dougmc, you're correct. HOWEVER, if you get in to trouble of any kind, and the FAA comes after you, that Advisory Circular is going to stand out like a sore thumb in court. It is generally considered to be good practice. Deviating from it requires a VERY compelling reason.
Pilots, whether licensed or not, are expected not to behave in a careless or reckless manner. Deviating from an AC without very good cause will almost always be considered as such.
JBMcB, an RC aircraft is intended to stay below 300 AGL and remain within sight of the operator. A commercial UAV can go much further and can represent a hazard to aviation.
The problem is an issue of HOW pilots avoid each other. A drone can not see and avoid other aircraft. A manned helicopter or airplane CAN. If you have two aircraft at the same altitude and opposite direction (something that can happen in Class G airspace), you have just a few seconds from a flyspeck in the windshield to imminent collision.
A UAV is fundamentally different. If it is not coordinated with Flight Service Stations and air traffic control, and it is flown at altitudes exceeding 300 AGL, then the risks to other aircraft are significant. The big sky theory works most of the time. However, in a disaster zone, should anything go wrong, you won't get much help on site for quite a while.
I have hit seagulls while flying my airplane. It's a scary thing. Anything bigger than that is not something you'd ever want to see.
Whether it is or is not an intelligence disinformation tool, DEBKA is generally regarded as being very unreliable. I wouldn't trust anything written there unless it were confirmed by at least two other independent sources.
If you don't have soft parts, how can the loud parts surprise you? Isn't that one of the elements of music that we're throwing away? The element of surprise?
I was one of many children. We didn't go to camp much. Instead, we explored the city parks and library. We designed and built our own rockets with no adult supervision. Not all of them flew as expected. We explored forgotten civil war forts, mapped (and found) old trenches between forts, built ham radio gear and antennas, studied assembly language programming on a local university's DecSystem-20, and read mounds of science fiction.
In short, I didn't need a camp to teach me how to do this stuff. I am a self made nerd.
Uh, no. DHS did not squelch anything. They made a request and NSS labs obliged.
This is important: the issue here is not about the PLC, it is about the process it controls. Ultimately Siemens is the small fry here. The real problem are the utilities and other critical infrastructure that depend upon this stuff. They can't just throw a patch at it like you would do with a PC. They have to validate that patch and that means expensive down time and careful planning. There are literally months when logistics prevent me from patching. Divulging this stuff to the public so soon runs the risk of attacks against infrastructure that could not be patched in time.
The problem is that most people do not understand the reality of what PLC networks are like. If you're on the same network as a PLC, regardless of OEM, you own it. End of story.
The network where PLC gear works is not an office network. It was never designed to be compatible with office networks. The fact that they use commonplace protocols such as Ethernet and IP does not mean they're suitable for office computing. These choices were made primarily because these technologies are cheap, not because we were encouraging interconnection with offices. There is no technology available that can secure a PLC on a network. It inherently trusts the remote I/O it may have. It has to trust the programs it receives. Very few people, even among OEM companies, understand this.
Nobody has yet built a key server system designed to work at the latencies and diversity needed for industrial networking. It is not nearly as trivial as it may look. I say this as someone who is participating on the committee that is doing this very sort of thing. DNP (IEEE 1815) has a secure authentication addition to the protocol, compatible with IEC 62351-5. We are working very hard to make sure that this works in an environment where things can afford to take a little extra time if needed (in a SCADA system).
So far nobody has managed to do this with a PLC environment.
Thus, saying "if you send this or that to a PLC, you can break it" is silly. You don't even have to break the PLC, you can break the process it controls. That's far worse.
Meanwhile, with Siemens acting as if the WinCC compromise doesn't exist, I have to wonder if they understand what I have just written. They've known of this situation for over three years and what have they done? I'm glad our company doesn't use WinCC, and it will be a long time before we seriously consider using their PLC gear.
It's called IRLP. However, the primary purpose of ham radio is radio communications over bands ranging from medium waves through SHF.
On a broader note: it isn't just ham radio that will be affected, but also low band VHF users. And remember, if the signal leaks, it can also be interfered with.
The whole notion of stuffing broadband traffic over power lines has been tried and proven unworkable in many attempts on both sides of the Atlantic. Power lines were never designed to be balanced transmission lines such as a CAT 5 cable. They will radiate and they'll also pick up significant levels of short-wave signals. There has also been demonstrations that broadcast FM reception, and the new digital audio broadcasts will all be interfered with.
This is the very definition of insanity: It has been documented time and time again in many countries over several decades that sending broadband signals over power lines makes terrible RF noise and suffers from poor performance. And yet people continue to think that if they try it, that somehow it might work.
The solution is obvious: install your own power sources and you can walk away from the grid without telling anyone anything. Use solar power, with a diesel or natural gas generator as backup.
Of course this may result in more greenhouse gasses than we are making right now --but that's the law of unintended consequences.
The truth is that the software industry marches forward at a much faster pace than we can deploy. Today's ultra reliable souped up cool stuff becomes yesterday's "what the hell were they thinking?" stupidity very quickly. In truth, it's not just about the code YOU write, it's the code that OTHERS write. They're making assumptions about your work and you're making assumptions about their work. Those assumptions are often wrong.
From my perspective as an end user, I often can not see the dividing line between you and your component software companies. I often can not tell whether you're using VxWorks, an embedded version of BSD, or some small company's custom RTOS. So whatever you do to improve your code may be irrelevant if the host OS crashes. From where I sit, the end result is the same.
That said, stability in most embedded OSs is usually pretty good. But the issue here is not stability. The issue is whether the software can stand up to even a mild attack. I once saw someone attack a SIL rated PLC with a LAND attack (names of guilty parties redacted to protect industry). The PLC curled up and crashed.
I would like to be able to say better things, but I have seen otherwise. Sorry...
I integrate, deploy, and maintain a SCADA system for a large water and waste-water utility.
Here are some facts on the ground:
1. Yes, the software is out of date, and it is poorly reviewed. The reason is that the market is small, the deployment costs are huge, and it is difficult to differentiate the bad from the worse. The effort required to swap out SCADA or control system software make similar office operations look trivial.
2. Yes, the flaws are hard to fix. We design these things for safety, and reliability, first. We have an ethical duty to turn the CIA model upside down to become the AIC model. Security is often an afterthought. In any case, most of you probably do not realize that security for an industrial process is very different from security for an office. In an office, if the computer stops, the whole office process stops and that's it. Nothing more happens. In an industrial process, the physics and chemistry of the process will continue to do something whether your control system is online or not. In other words, unlike in an office, the control system for an industrial process augments the process, it does not run it. Thus, if you crash the office computers, everything stops. If you crash a control system, the process keeps doing something, even if it is something that nobody would ever want.
3. Industrial processes can't "just shut down" on a whim. To patch a control system you need to get to a place where the process can be safely shut down, and the new process can be safely validated to prove that it does everything that is expected of it. Getting this much time and attention from people takes significant down time. With the lean operations that most places run, that kind of downtime may not be available for an entire SEASON.
4. Because of this, revealing software flaws is often a dangerous proposition. By the time we can safely patch something in an industrial control system, there may be tool kits for script kiddies.
5. Due to safety concerns, almost nobody will seriously consider an effort to spray patches to the field. Again, this is not the office. The penalty for getting things wrong could be deadly. Automated patching without careful testing on each stage of the process can be a firing offense in some companies.
I believe that the theory that the Australian CERT is using is that by keeping some flaws quiet, they reduce the chance that others may develop script kiddie development kits. I honestly do not know whether this can work, but I give them credit for trying. It will be interesting to see what metrics they use to prove this effort is effective.
Finally, please stop with the "industrial software is crap" nonsense. We engineers know that all too well; but there are no better alternatives. Would you like to see us go back to the days when everything was run with pneumatic controls or analog computers? I'll bet you wouldn't appreciate the prices you'd pay. If you like electricity and running water, find ways to write better software.
Do you mean that while the probe is in the flame current will flow through it in one direction but not the other, or that the act of putting it in the flame and running current through it will cause it to have the properties of a diode after it has been removed from the flame? Your use of the word "constructed" has me unsure.
Of what is this probe made? Is it U-shaped? (current can't just go to end of conductor and stop, it has to get back to its point of origin)
I meant the former. Google flame diode and you'll see what I'm talking about. Many gas stoves and furnaces now use this technique to assure a flame is present.
Slashdot Mirror
First, they're using bloated programs on poorly optimized file systems and they then complain about performance.
Second, a better optimization would result if you took in to account what the file type was.You'd lose some compatibility, but you'd gain a surprising amount of performance. The solution has been sitting around for decades: Anyone remember the infamous Record Management System from DEC? It existed as a layer between the kernel and the user space.
It would answer the concerns of these researchers, but it would require a massive rewrite of all the programs that use the file systems.
We're headed back to the future...
Yes, there are. Modern radio systems are meant to be good enough to be reliable. Ham radio systems are the art of the possible. Most hams these days are experimenters who enjoy trying odd things. I've seen voice powered radios, I've seen radio systems designed to communicate via lunar reflections, I've seen radio systems designed to pick up spacecraft in deep space.
Some hams like to study radio wave propagation. Again, this is the art of the possible, not the engineering of the certain. Bouncing signals off of thunderstorms, sporadic E layer reflectors or meteor trails are all in this category. Occasionally, they stumble across something that works surprisingly well.
Some still tinker with modulation methods. Hams were playing with spread spectrum radios in the mid 1980s --long before the engineers sat down to work on the so-called wireless standards. Today, work continues with all sorts of forward error correction codes and modulation techniques.
So, yes, there still is a ham radio. Yes, there still are a more than a few slobs who like to do nothing better than listen to themselves talk on short-wave. But there is still a vibrant core that continues to study all sorts of forgotten alleys in the technology.
Didn't we discuss this Yesterday?
Yes, City OSs already exist. These are the SCADA systems that utilities use to manage their resources. The problem is that these SCADA systems do not manage resources small enough to make the sorts of differences that these pro-city coordinators expect. It is not financially feasible to do it yet.
There is also a myth that a central authority will be staffed with geniuses who will automatically comprehend the situation and make it better. As recent blackouts in Chile showed, however, it is quite possible to be overwhelmed with alarms that no human can sort through.
What good is a boss if he micro-manages everything around?
I would like to point out that there ARE some efforts to secure the non-deterministic SCADA side of things. Secure authentication is available for the DNP (IEEE-1815) protocol. At the present they must be pre-shared symmetric keys and there is no way to change those keys over the protocol; though that feature has been written and is undergoing review. The secure authentication specification is described in IEC 62351. Other protocols such as IEC 60870, and UCA2 (61850) are working on similar authentication features.
As for PLC/PAC protocols, they were designed for real time millisecond by millisecond timing. Authenticating would at least double the number of network transactions required to pass traffic and validate it. Some slower applications may be able to handle such speed penalties, but many can not. Remember that these protocols were designed to use the IP transport layer because the test equipment, network hardware, and software is widely available, cheap, and well understood. Unfortunately too many small minded idiots put it on the internet for the bragging rights of showing how one can program the plant floor controller from a tiki bar on the other side of the earth.
Regardless of what the marketeer crowd may have said in the past, it makes no sense to expose a deterministic real time network to any node that doesn't play nice. You don't have to do anything special to bring down such networks. If the traffic level gets too extreme, the controllers will fault. This is by design. They are supposed to make calculations every so many milliseconds and flush the results back to the field within a very short, limited time window. If they can't do that, they must stop working and the I/O should assume a safe state.
So yes, it's not hard to make a mess of one of these networks. That's why those networks must be carefully defended and kept to a very limited scope. Building authentication in to such networks is not nearly as effective at keeping hackers at bay as conventional wisdom would have you believe.
I expressed an opinion. People should be able to have different opinions. The wrongness is in your assumption that somehow there is a correct answer here. That is how group think gets started.
In any case, I thought you were being silly, so I decided to be silly back. I decided not to say much more than that because others have already argued back and forth, and I have little to add to the conversation. Besides, I don't always have the endless hours to while away on Slashdot, explaining my opinions to people whose political views are so narrow that they refuse to consider another point of view.
Go forth, believe what you want; but do yourself a favor and try a little respect for those who disagree with you. Sooner or later you will have to do as I have on other occasions and eat your words. At least this way, you won't have to eat bilious nonsense.
Your statement is unsupported, so your argument is null.
First, the study of climate (or astronomy) is not strictly a science. There are no opportunities to conduct controlled experiments. This is not inherently bad, but one must be careful not to label something a "science" when a sincere argument can be made that it is not. Luminaries such as Richard Feynman made such arguments, so I don't think one would be in bad company when saying that this study is not a science.
Second, the study of climate is fraught with error. Again, there is nothing wrong with this. Without the ability to conduct a controlled experiment, the best one can do is to model what is going on and to hypothesize why the model doesn't agree with observations or make accurate predictions.
The wrongness is when those very same people take their study results in to the political limelight and say to the effect "This is the sky; it is falling; and you must do as I say or evil will happen." Doesn't the notion of conflict of interest enter here?
There are many responses to how we could manage our changing climate. I am happy to read the research. I may read a suggestion regarding the responses. But really, it got a bad name because too many political hacks took a centralized conservation approach and built a phony baloney market in Carbon Dioxide indulgences that most researchers agree will have a minimal effect on the climate, while ignoring other potentially much more serious Green House Gasses like Methane.
Astronomy doesn't have this problem because astronomy is primarily a study of discoveries with very few implications on politics. And no, I don't see a good reason to call it a science, either.
Mod parent up. People are treating this as if it is voodoo technology that never existed before. In reality, these methods have existed for many decades. The problem is mass production and getting it down to a cost, size, and weight that people can want and afford.
Some of these problems can be overcome with newer technologies and improved linearity of amplifier and mixer technologies. My guess is that with a combination of that, frequency diversity, orthogonal antenna polarization, quadrature phase (TX PLL methods aren't the only way to achieve this, quadrature hybrids will do this too), and perhaps orthogonal code spread spectrum, there may be just enough separation to make this work.
But all this is a guess. The article doesn't reveal very much about what these researchers actually did to achieve this performance. In truth, it is easy to build a receiver and transmitter with better performance than what you have in your phone, if you don't care what the size, cost, and weight is. The phone of today is a marvelous series of compromises that yields a mass market device that is "good enough."
That, dear Slashdot readers, is what engineering is REALLY all about. It will be interesting to see how small, inexpensive, and light weight the Rice University researchers managed to make their prototype...
Writing is different than speaking. The greeting has already been made. Those are wasted words; and a wasted opportunity to make a good first impression. Instead, write something meaningful that could introduce yourself and establish common or contrasting interests: For example, "I'm intrigued that you like Ethiopian style cooking. I had an interesting experience in an Ethiopian restaurant..." This draws the reader's attention in to encourage further discussion.
The implication of writing (not saying, WRITING) "hi, how are you doing..." in this context shows a lack of imagination, and conveys an overall notion of "I am not enthusiastic about anything. I'm bored. Entertain me."
In general, when dating (regardless of sex or orientation), one would usually seek someone else who can be enthusiastic about something. The reason? You want to be the target of some of that enthusiasm. You want to share interests somewhere. These are the things that build relationships. You have to seek a common ground upon which to build experiences and adventures together.
In such a vast sea of people on the Internet, first impressions can mean a lot. Don't discount it.
I wish you well. This must be hard for you, walking away from something you have herded for the last 15 years.
Don't look back. Make something cool.
Steve Jobs isn't the only leader in this world...
This being slashdot, I don't expect that many of you will understand this advice. Nevertheless, here goes:
A big turn-off is someone who does not know how to communicate well. A relationship and a marriage are all about communication. This article is about a written introduction that makes a first impression, so you want to look your best. It's the same reason you would think carefully about what to wear and where to go on a first date.
Starting off with sexy talk is typically a turn off to a person looking for a relationship. If the relationship works, the sex will happen. Starting off with sex talk first is usually an indicator of someone whose expectations are quite shallow, or someone who is utterly disingenuous. Either way, it doesn't present an impression of someone who communicates well. Besides, trolling for sex in a place that advertises relationships isn't very honest.
I write this as someone who has been married for fifteen years, has three children, and watched with sadness as numerous other relationships and marriages of friends and acquaintances have fallen apart.
Our office is a small building on a concrete slab. We NEVER feel much in the way of movement. When this thing hit, I ran outside. The water storage reservoirs were making ominous oil-canning sounds on an industrial scale. Significant rumbling with some side to side movement.
Reminder for those of you in the East Coast: Something made those Appalachian mountains. It may not be as active as the West coast, but it would be wise not to ignore it.
Then explain the popularity of TED. Explain the Maker Fairs. Explain the continuing development of computer software and media from the home.
This idiot snob from the NYT (But I repeat myself) is acting as if these things need to show up in the Legacy Media to be considered "popular."
Has it ever occurred to him that he might not be looking in the right places?
Technically, dougmc, you're correct. HOWEVER, if you get in to trouble of any kind, and the FAA comes after you, that Advisory Circular is going to stand out like a sore thumb in court. It is generally considered to be good practice. Deviating from it requires a VERY compelling reason.
Pilots, whether licensed or not, are expected not to behave in a careless or reckless manner. Deviating from an AC without very good cause will almost always be considered as such.
JBMcB, an RC aircraft is intended to stay below 300 AGL and remain within sight of the operator. A commercial UAV can go much further and can represent a hazard to aviation.
The problem is an issue of HOW pilots avoid each other. A drone can not see and avoid other aircraft. A manned helicopter or airplane CAN. If you have two aircraft at the same altitude and opposite direction (something that can happen in Class G airspace), you have just a few seconds from a flyspeck in the windshield to imminent collision.
A UAV is fundamentally different. If it is not coordinated with Flight Service Stations and air traffic control, and it is flown at altitudes exceeding 300 AGL, then the risks to other aircraft are significant. The big sky theory works most of the time. However, in a disaster zone, should anything go wrong, you won't get much help on site for quite a while.
I have hit seagulls while flying my airplane. It's a scary thing. Anything bigger than that is not something you'd ever want to see.
Whether it is or is not an intelligence disinformation tool, DEBKA is generally regarded as being very unreliable. I wouldn't trust anything written there unless it were confirmed by at least two other independent sources.
If you don't have soft parts, how can the loud parts surprise you? Isn't that one of the elements of music that we're throwing away? The element of surprise?
I was one of many children. We didn't go to camp much. Instead, we explored the city parks and library. We designed and built our own rockets with no adult supervision. Not all of them flew as expected. We explored forgotten civil war forts, mapped (and found) old trenches between forts, built ham radio gear and antennas, studied assembly language programming on a local university's DecSystem-20, and read mounds of science fiction.
In short, I didn't need a camp to teach me how to do this stuff. I am a self made nerd.
Uh, no. DHS did not squelch anything. They made a request and NSS labs obliged.
This is important: the issue here is not about the PLC, it is about the process it controls. Ultimately Siemens is the small fry here. The real problem are the utilities and other critical infrastructure that depend upon this stuff. They can't just throw a patch at it like you would do with a PC. They have to validate that patch and that means expensive down time and careful planning. There are literally months when logistics prevent me from patching. Divulging this stuff to the public so soon runs the risk of attacks against infrastructure that could not be patched in time.
The problem is that most people do not understand the reality of what PLC networks are like. If you're on the same network as a PLC, regardless of OEM, you own it. End of story.
The network where PLC gear works is not an office network. It was never designed to be compatible with office networks. The fact that they use commonplace protocols such as Ethernet and IP does not mean they're suitable for office computing. These choices were made primarily because these technologies are cheap, not because we were encouraging interconnection with offices. There is no technology available that can secure a PLC on a network. It inherently trusts the remote I/O it may have. It has to trust the programs it receives. Very few people, even among OEM companies, understand this.
Nobody has yet built a key server system designed to work at the latencies and diversity needed for industrial networking. It is not nearly as trivial as it may look. I say this as someone who is participating on the committee that is doing this very sort of thing. DNP (IEEE 1815) has a secure authentication addition to the protocol, compatible with IEC 62351-5. We are working very hard to make sure that this works in an environment where things can afford to take a little extra time if needed (in a SCADA system).
So far nobody has managed to do this with a PLC environment.
Thus, saying "if you send this or that to a PLC, you can break it" is silly. You don't even have to break the PLC, you can break the process it controls. That's far worse.
Meanwhile, with Siemens acting as if the WinCC compromise doesn't exist, I have to wonder if they understand what I have just written. They've known of this situation for over three years and what have they done? I'm glad our company doesn't use WinCC, and it will be a long time before we seriously consider using their PLC gear.
It's called IRLP. However, the primary purpose of ham radio is radio communications over bands ranging from medium waves through SHF.
On a broader note: it isn't just ham radio that will be affected, but also low band VHF users. And remember, if the signal leaks, it can also be interfered with.
The whole notion of stuffing broadband traffic over power lines has been tried and proven unworkable in many attempts on both sides of the Atlantic. Power lines were never designed to be balanced transmission lines such as a CAT 5 cable. They will radiate and they'll also pick up significant levels of short-wave signals. There has also been demonstrations that broadcast FM reception, and the new digital audio broadcasts will all be interfered with.
This is the very definition of insanity: It has been documented time and time again in many countries over several decades that sending broadband signals over power lines makes terrible RF noise and suffers from poor performance. And yet people continue to think that if they try it, that somehow it might work.
The solution is obvious: install your own power sources and you can walk away from the grid without telling anyone anything. Use solar power, with a diesel or natural gas generator as backup.
Of course this may result in more greenhouse gasses than we are making right now --but that's the law of unintended consequences.
The truth is that the software industry marches forward at a much faster pace than we can deploy. Today's ultra reliable souped up cool stuff becomes yesterday's "what the hell were they thinking?" stupidity very quickly. In truth, it's not just about the code YOU write, it's the code that OTHERS write. They're making assumptions about your work and you're making assumptions about their work. Those assumptions are often wrong.
From my perspective as an end user, I often can not see the dividing line between you and your component software companies. I often can not tell whether you're using VxWorks, an embedded version of BSD, or some small company's custom RTOS. So whatever you do to improve your code may be irrelevant if the host OS crashes. From where I sit, the end result is the same.
That said, stability in most embedded OSs is usually pretty good. But the issue here is not stability. The issue is whether the software can stand up to even a mild attack. I once saw someone attack a SIL rated PLC with a LAND attack (names of guilty parties redacted to protect industry). The PLC curled up and crashed.
I would like to be able to say better things, but I have seen otherwise. Sorry...
I integrate, deploy, and maintain a SCADA system for a large water and waste-water utility.
Here are some facts on the ground:
1. Yes, the software is out of date, and it is poorly reviewed. The reason is that the market is small, the deployment costs are huge, and it is difficult to differentiate the bad from the worse. The effort required to swap out SCADA or control system software make similar office operations look trivial.
2. Yes, the flaws are hard to fix. We design these things for safety, and reliability, first. We have an ethical duty to turn the CIA model upside down to become the AIC model. Security is often an afterthought. In any case, most of you probably do not realize that security for an industrial process is very different from security for an office. In an office, if the computer stops, the whole office process stops and that's it. Nothing more happens. In an industrial process, the physics and chemistry of the process will continue to do something whether your control system is online or not. In other words, unlike in an office, the control system for an industrial process augments the process, it does not run it. Thus, if you crash the office computers, everything stops. If you crash a control system, the process keeps doing something, even if it is something that nobody would ever want .
3. Industrial processes can't "just shut down" on a whim. To patch a control system you need to get to a place where the process can be safely shut down, and the new process can be safely validated to prove that it does everything that is expected of it. Getting this much time and attention from people takes significant down time. With the lean operations that most places run, that kind of downtime may not be available for an entire SEASON.
4. Because of this, revealing software flaws is often a dangerous proposition. By the time we can safely patch something in an industrial control system, there may be tool kits for script kiddies.
5. Due to safety concerns, almost nobody will seriously consider an effort to spray patches to the field. Again, this is not the office. The penalty for getting things wrong could be deadly. Automated patching without careful testing on each stage of the process can be a firing offense in some companies.
I believe that the theory that the Australian CERT is using is that by keeping some flaws quiet, they reduce the chance that others may develop script kiddie development kits. I honestly do not know whether this can work, but I give them credit for trying. It will be interesting to see what metrics they use to prove this effort is effective.
Finally, please stop with the "industrial software is crap" nonsense. We engineers know that all too well; but there are no better alternatives. Would you like to see us go back to the days when everything was run with pneumatic controls or analog computers? I'll bet you wouldn't appreciate the prices you'd pay. If you like electricity and running water, find ways to write better software.
Do you mean that while the probe is in the flame current will flow through it in one direction but not the other, or that the act of putting it in the flame and running current through it will cause it to have the properties of a diode after it has been removed from the flame? Your use of the word "constructed" has me unsure.
Of what is this probe made? Is it U-shaped? (current can't just go to end of conductor and stop, it has to get back to its point of origin)
I meant the former. Google flame diode and you'll see what I'm talking about. Many gas stoves and furnaces now use this technique to assure a flame is present.