Mod parent way up. I've seen it in other places too.
Often when you ask people in the accounting department, they'll say they don't really know what's going on because IT made the system. When you talk to IT, they'll say they don't know because the system was specified by Accounting. The truth is that some smart guys in each department got together and forged some sort of system together. Then the smart guys went on to bigger and better things, while the peons were left with some special voodoo system.
Now you want to move said voodoo system over to a consulting company. The assumption is that the Accountants know every detail of what the old system did. Well, they don't. But nobody is willing to step forward and say that. So the new consultants come along and gosh, nobody knows what the systems do.
...the problem is in fact oversimplification of horology. We do not have a reasonable, standard practice for dealing with leap seconds. I've never heard of an OS that allows for 61 (or 59) seconds in a minute. Though it has never happened, leap seconds can theoretically go the other way.
To make matters worse, this concept needs to extend from the OS in to an application. Almost nobody has made the effort to handle this well. It is a relatively rare occurrence these days.
The ultimate question is why we're measuring time based upon the earth's rotation in the first place. Yes, our standards did come from the concept of dividing an astronomical day of the year in to smaller pieces, but our definition of those time units has not used the earth as a reference since 1967. Perhaps we have reached a point where the time of day concept is a bit more arbitrary?
We are able to find stars and know our longitude with very high accuracy without using leap seconds (that's how GPS does it). Is there still a reason why we should keep adjusting our concept of time according to what the earth does?
I say this as an experienced instrument rated private pilot myself and as an engineer of control systems involving safety and high energy systems:
It's easy to sit in an office chair, look back at this behavior, and think my gosh, how stupid is that?
Stupid happens to the best of us. If you can look at yourself in the mirror and say that you've never made a mistake while driving, you either haven't been driving for long, or you're damned good at deluding yourself.
It's no different with pilots. We train and train to avoid accidents. We have learned a great deal about how to avoid making terrible mistakes like this. However, at some point, the automation has to stop trying to warn people of each and every silly thing and get out of the way so that they can do their job. Too many alarms results in alarm fatigue which causes people to ignore what the alarm is trying to say.
The margin for error in airliners is slim. If most people knew how close to the performance envelope they were when they fly, they'd probably never board an airliner again. And yet, pilots manage to fly these things at this performance level every single day. Yes, this was a screw-up. There was supposed to be warning horns to let them know that this situation was present.
Even with random failures, there is a certain likelihood that these failures will converge on a single system and cause a dangerous situation to emerge. There was no one failure point here. The warning failed, and the repair system that was supposed to catch those warning horn failures didn't work, and the pilots forgot to deploy the flaps and slats properly.
Had any one of these things in the chain been caught in time, this would have been an uneventful flight. That is what real safety looks like.
VxWorks is like the Microsoft of the embedded device industry. It is extremely popular. Embedded systems in general are not regularly patched because they're EMBEDDED. People often don't even know they're there.
The real problem isn't VxWorks versus Linux, however. I can just about guarantee that if you were to use a five year old linux kernel, you'd find just as many security flaws as you might with VxWorks. The real problem is that the OS never gets patched.
I need every one of you to understand this: Patching embedded systems like you patch an office computer will get you fired and possibly even prosecuted. These systems were carefully certified and validated by some people who were supposed to know what they were doing. When you introduce new code and then say "this ought to work" you are taking that design responsibility in to your own hands. Unless you too have that background and authority to change this stuff, you would be wise to leave it alone and call someone who does.
The phrase "This ought to work" is a very tired and sick joke where I work.
Agreed. Anaerobic digestion usually results in lots of methane.
I do not understand the rocket part. It could be burned to heat a boiler or in a four cycle engine. Why screw around with a rocket? It's not as if the thrust is needed for something.
I could do this much more anonymously and inexpensively with a backpack, a laptop, a GPS, and a pair of walking shoes. UAVs attract attention because, no matter who is launching them, people are generally suspicious that they're up to no good.
Part of the 802.11 specification contains a behavior known as clear channel availability (CCA) checking. If there is energy on a channel, the unit is not supposed to transmit, on the theory that it might interfere with something.
That something could be a leaky microwave oven. It could be a video transmitter. It could be someone who uses a wireless phone. It could be virtually anything.
All it has to do is to transmit continuously. It can be quite weak. The thresholds for CCA are typically very low. A continuous signal will inhibit other units from transmitting. Whatever that signal is, do not be surprised if it is entirely legal.
I'm assuming that most readers are not licensed amateur radio operators trying to pass themselves off as uber wifi users. The original post mentioned nothing of the sort. However, you are correct --mostly. I have yet to see any case law from the FCC that suggests any sort of primacy for an amateur radio operation of this sort.
All WiFi operates under the condition that it does not interfere with other licensed operations, and that it accepts interference from other sources without complaint to the FCC. The principle is the same world wide: If you opt out of a formal licensing scheme, you shouldn't expect support or enforcement of interference claims.
This is why radio licenses exist. The process may be arcane, expensive and even ridiculous. However, without a license, you have no legal recourse if someone interferes with your operation. I'll be the first to concede that there is much we could do to improve and speed up the licensing schemes. However, that bureaucracy is a subject for another rant. The fact that it may be done poorly does not mean that it isn't necessary.
I've been over this argument more times than I care to remember. Full disclosure before a fix is available is irresponsible.
There are applications out there where you simply can not spray patches at the net to see what sticks. Each update has to be carefully tested and validated. These are typically very high reliability applications.
Your ignorant attitude to this problem overlooks the fact that it's not the software company that you need to be concerned about. It's the customers who bought it!
So go ahead, put a software company under. I don't much care. But if you cause someone to die because a zero day exploit caused the hospital to not see a patient's life support fail, that's a problem. If you hack a SCADA system at some remote site, you could put a neighborhood without electricity for many days.
These bits of software have actual end-users. This isn't just about the company that sold the software, it's about the end-users. People's lives often depend on this software working correctly.
If you don't give them a chance to react, then you're just as guilty as those who actually attack these sites.
Many people have written many articles as well as a significant number of books about this subject.
There are valid reasons, though the short answer is because they don't know any better. Really.
These networks are supposed to be separated from the office. However, real security is hard. All it takes are one or two dreamy eyed, lazy idiots on the office side, wanting access to all that delicious data "in real time" so that they can surf it and "discover new paradigms." They nag the IT department, and before you know it, someone has breached the two networks.
Oh and by the way, it will be interesting to see how all that wild data from the up and coming smart grid project interfaces to SCADA system securely. Security is not high on the agenda of most smart grid designers.
I write this as one who is involved in ISA-99 (Industrial Control Security) and the DNP3 protocol committee, and as a SCADA integrator and end user. There is a tremendous amount of education and work to be done. I wish it were as simple as disconnecting the two networks. Unfortunately, in too many cases, it has already gone way beyond that.
If a client cares about that more than all of the problems with IE6, then they should not have a position in their company that allows them to make IT-related decisions.
Clearly you're out of touch with reality. There is an entire world outside of the IT office. These people have skills you couldn't even dream of. If they acted this way, you'd be a helpless puddle of drool.
Be thankful that you have skills people want and need. Now, about those pesky clients: If they like the user interface, GIVE THEM THE DAMNED USER INTERFACE! If there is something actually wrong with the user interface that misleads them in to doing dangerous things, tell them so that they can make an informed decision. The point is to make it possible for them to do that aspect of their job without getting confused about how to get to the new tab that a web page just opened up.
I know, you're thinking "how could anyone be that ignorant." Well, try talking to people in other professions such as an attorney, or even a fast food worker. They'll give you an entirely new perspective on what ignorance is.
It would be nice to separate the electric generation, transmission, and distribution networks from the Internet, but it ain't happening. SCADA systems are being interconnected to each other and to proxies that deliver data to the Internet in real time, or near real time.
Nobody can avoid this. SCADA systems are delicious fountains of high fructose data that executive operations staff, researchers, and governments are finding hard to resist. The Smart Grid is only the latest of many wide eyed high tech applications to hit this space. There have been many before it.
We're already exposed. The question is how to build resiliency in to this effort. As you might imagine, it's not easy. This isn't some office application where damage can be repaired with a backup. These systems affect physical assets and public safety in our cities. There is no backup to restore broken lives.
This isn't an ideal situation. Most utilities would love to return to the days when everything could be isolated. But if anything, all this smart metering and smart grid stuff will cause everything to get even more connected and integrated. There is good value in such connections. Nevertheless, it has been hyped while glossing over the details of the security risks.
Now that we know we're exposed, we need people with embedded systems backgrounds, control engineers with practical systems design experience, and security professionals to come together and to share information without killing each other. (All three fields are well known for having their share of prima-donna character flaws)
I wish DOE the best of luck. The horse is already out of the barn and they're still trying to figure out how to close the door.
Please keep in mind that, in reality, we have to deal with Slashdot "moderators" and others of their ilk.
They don't realize their limitations of intelligence. They don't particularly care about factual accuracy, either.
So they have absolutely no qualms about referring to somebody they dislike as a "pedophile", and then backing it up with this sort of keystroke moderation as "proof."
If you don't believe me, just look at how they justified moderating this post. They showed computer generated images of this "web page" and pictures of perverts, all available on the Internet.
Let's see: Adam Gadahn. Has he been convicted? Nope. Is there any doubt this man is a traitor? Uhh, let's see: pals around with Osama Bin Ladin, Reads screeds against the US. Coordinates attacks against US troops. And... he's in Pakistan or Afghanistan.
So, no. There can't be any legal process here. We have no jurisdiction. He gives every indication of committing traitorous acts in a war zone.
As long as we have a military that is required to fight a battle in a war zone, I think it should be legal to kill a combatant without wondering about citizenship, legal status, or whether the method of killing is appropriate.
In any case, this is no different than a sniper shooting at enemy combatants a mile away. And nobody has raised legal issues about that.
Personally, I think the ACLU is hungry and looking for more donations. Any military lawyer worth a damn should be able to have this case thrown out of court in no time.
Energy storage is still very much in its infancy. There are many ways to do it and there are many risks as well.
Basically, there are two places where such energy storage is practical. One of them is in large scales at the generation facility, the other is smaller scales at the load.
Personally, I prefer the load side for energy storage because it offers some backup in case the power distribution system is interrupted. It is also very much an issue of research with development of electric and hybrid vehicles.
Conversely, if these energy storage devices failed, how large would the release of energy be? If it were at the generation side, it could be disastrous. However, at the load side it may be less so.
Personally, I like the idea of a hydrocarbon fuel cell with local storage. Similar ideas have been proposed by the likes of Bela Liptak (one of the fathers of modern control engineering as a discipline). He liked the notion of storing hydrogen and oxygen from electrolyzing water. With a bit of chemical engineering I'm sure people could find easier and cheaper forms of fuel cell materials that might be safer and less prone to leaking (gaseous hydrogen isn't exactly easy to store in your home).
Yes, but one of the things that causes "human error" is poor design. Sometimes, the information can be right there at your fingertips but in a form that doesn't encourage an operator to develop good situational awareness. This was one of the causes that lead to the 2005 Texas City Refinery explosion and fire. The information on flow totals in and out of the raffinate splitter process were on a different page of the screen and the operator on duty was tired, busy, and simply didn't think to look at it. Had he done so, he'd have seen that there was an awful lot of flow going in to the tower and nothing coming out.
The point of discussing design like this is to improve situational awareness so that disasters are less likely to happen.
You seem to find insult in this where there is none intended.
The very notions of liberalism and conservatism often change with the generations in ways such that yesterday's liberal views often become conservative. Look at how many on the Right quote Dr. Martin Luther King Jr. By the standards of his day, he was very much a liberal.
Another fact: Empathy and eagerness to improve the world by the young often lead them to what many consider liberal views. They try things that others "know" can't work. Most of these ideas fail, but a few stick. As you get older, experience and pragmatism often set in. Often habit takes over where they should be questioning why we do things the way we do. Using one's experience and "brains" is often a way to keep doing what you've been doing.
If you see this as an insult, you may want to check your knowledge of history and the humanities.
The IEEE-802.15.4 specification defines a way to reduce power, but it does not enshrine this at the MAC layer of this protocol. Perhaps Zigbee may do this, but it isn't in '15.4 as far as I have read.
The feature you're talking about is called Clear Channel Assessment (CCA) and it is part of,most of the wireless specifications. The problem with CCA is that the threshold is shockingly low. And what you hear at the transmitting end isn't necessarily what the receiver hears. In other words, the receiver could be trashed by another signal too far away for you to hear. I need to remind everyone here, this is not a coaxial cable or a fiber system. It is radio. Radios wave systems are not perfect hubs or trunk lines. There are signals on the air that one side may hear that the other doesn't.
Another issue you might not realize is that it takes at least as much power to run an 802.15.4 receiver as it does the transmitter. In most cases, the the transmitter is the local oscillator as well. There isn't much power to be saved.
So why reduce power? To reduce the chance that a signal can be received by others with nefarious intent, and to reduce interference as you said.
I suggest people consider using different channels. Even though the 802.11 channel passband is over 22 MHz wide, and there are really only three channels that don't overlap, you can still choose an adjacent channel and use the despreading to your advantage.
I find that the default channel for most of 802.11b/g routers is channel 6. Use anything but that and you'll probably do OK. Those who can remember the heyday of CB radio, may remember that most of the kiddie walkie talkies used to be on CB channel 14. That was the one channel you didn't want to be on. It is interesting that we still haven't learned that lesson even today.
The old saw: "If you're not a liberal when you're young, you have no heart; if you're not a conservative when you're older, you have no brain." (Variants have been attributed to Winston Churchill, though there is no indication that he ever said this)
Functions have their place, Subroutines have their place. Global variables have their place. Static variables, Heap variables, and stack variables have their place. Even a Go To has it's place (in rare cases).
The point is to use these tools in such a way that someone else can figure out what you're doing.
On the other hand, as Albert Einstein is reputed to have said, things should be simplified as much as possible, but no farther. If the code is obtuse, sometimes it is because the programmer doesn't understand the background of what it is supposed to do. In other words, if you understand Digital Signal Processing, someone's code may look quite elegant. If you don't understand it, it looks obtuse.
We'd all like to think that good programming is simply a matter of writing reasonably concise and well documented code. But it isn't. One needs an education on the subject being programmed. If you don't know the subject well enough, no amount of documentation is going to help you.
The question I have is whether there can ever be conclusive data to prove one side or the other before it actually happens.
I had hopes before that some very bright people might find a way to analyze data and simulate with it. However, given the dubious quality of the data collected thus far, I have to wonder if climate studies are going to produce anything useful.
And then these CRU idiots got exposed. If there was any opportunity for real science to get done before, it's been blown away for a good many years.
Thanks a lot guys. Your disservice to the community ought to win you an IgNobel --except that those usually have some humor in them. There is nothing funny about what CRU did.
My view is that leadership is something that is not limited to one particular field. Some accountants are very good leaders. Some salesmen are very good leaders. And yes, some scientists and engineers are very good leaders.
Somewhere along the way, however, the idea took hold that you had to have a formal grounding in the humanities to be a leader. Little do these people know that scientists, engineers, and other technical professions often DO have a strong grounding in the humanities, though it isn't a formal education.
They have excluded those with formal technical backgrounds on the assumption that a formal training is the ONLY way to get a good grounding in the arts and humanities. I think that's foolishly arrogant, and very very wrong.
Let's let our leaders emerge from whatever backgrounds they have and not exclude someone just because they lack a formal education on the subject.
Slashdot Mirror
Lesson: Don't put all your eggs in one basket. Nothing new about that...
Mod parent way up. I've seen it in other places too.
Often when you ask people in the accounting department, they'll say they don't really know what's going on because IT made the system. When you talk to IT, they'll say they don't know because the system was specified by Accounting. The truth is that some smart guys in each department got together and forged some sort of system together. Then the smart guys went on to bigger and better things, while the peons were left with some special voodoo system.
Now you want to move said voodoo system over to a consulting company. The assumption is that the Accountants know every detail of what the old system did. Well, they don't. But nobody is willing to step forward and say that. So the new consultants come along and gosh, nobody knows what the systems do.
Then people ponder why it "doesn't work." Sigh.
This is how shit happens.
...the problem is in fact oversimplification of horology. We do not have a reasonable, standard practice for dealing with leap seconds. I've never heard of an OS that allows for 61 (or 59) seconds in a minute. Though it has never happened, leap seconds can theoretically go the other way.
To make matters worse, this concept needs to extend from the OS in to an application. Almost nobody has made the effort to handle this well. It is a relatively rare occurrence these days.
The ultimate question is why we're measuring time based upon the earth's rotation in the first place. Yes, our standards did come from the concept of dividing an astronomical day of the year in to smaller pieces, but our definition of those time units has not used the earth as a reference since 1967. Perhaps we have reached a point where the time of day concept is a bit more arbitrary?
We are able to find stars and know our longitude with very high accuracy without using leap seconds (that's how GPS does it). Is there still a reason why we should keep adjusting our concept of time according to what the earth does?
I say this as an experienced instrument rated private pilot myself and as an engineer of control systems involving safety and high energy systems:
It's easy to sit in an office chair, look back at this behavior, and think my gosh, how stupid is that?
Stupid happens to the best of us. If you can look at yourself in the mirror and say that you've never made a mistake while driving, you either haven't been driving for long, or you're damned good at deluding yourself.
It's no different with pilots. We train and train to avoid accidents. We have learned a great deal about how to avoid making terrible mistakes like this. However, at some point, the automation has to stop trying to warn people of each and every silly thing and get out of the way so that they can do their job. Too many alarms results in alarm fatigue which causes people to ignore what the alarm is trying to say.
The margin for error in airliners is slim. If most people knew how close to the performance envelope they were when they fly, they'd probably never board an airliner again. And yet, pilots manage to fly these things at this performance level every single day. Yes, this was a screw-up. There was supposed to be warning horns to let them know that this situation was present.
Even with random failures, there is a certain likelihood that these failures will converge on a single system and cause a dangerous situation to emerge. There was no one failure point here. The warning failed, and the repair system that was supposed to catch those warning horn failures didn't work, and the pilots forgot to deploy the flaps and slats properly.
Had any one of these things in the chain been caught in time, this would have been an uneventful flight. That is what real safety looks like.
Agreed. Here is one example.
VxWorks is like the Microsoft of the embedded device industry. It is extremely popular. Embedded systems in general are not regularly patched because they're EMBEDDED. People often don't even know they're there.
The real problem isn't VxWorks versus Linux, however. I can just about guarantee that if you were to use a five year old linux kernel, you'd find just as many security flaws as you might with VxWorks. The real problem is that the OS never gets patched.
I need every one of you to understand this: Patching embedded systems like you patch an office computer will get you fired and possibly even prosecuted. These systems were carefully certified and validated by some people who were supposed to know what they were doing. When you introduce new code and then say "this ought to work" you are taking that design responsibility in to your own hands. Unless you too have that background and authority to change this stuff, you would be wise to leave it alone and call someone who does.
The phrase "This ought to work" is a very tired and sick joke where I work.
Agreed. Anaerobic digestion usually results in lots of methane.
I do not understand the rocket part. It could be burned to heat a boiler or in a four cycle engine. Why screw around with a rocket? It's not as if the thrust is needed for something.
I could do this much more anonymously and inexpensively with a backpack, a laptop, a GPS, and a pair of walking shoes. UAVs attract attention because, no matter who is launching them, people are generally suspicious that they're up to no good.
Of course, when shown these FACTS, he will continue to believe what he does even more fervently.
Maybe the solution is to be in violent agreement with him. Then maybe he'll question himself.
You're assuming it is overpowered. It may not be.
Part of the 802.11 specification contains a behavior known as clear channel availability (CCA) checking. If there is energy on a channel, the unit is not supposed to transmit, on the theory that it might interfere with something.
That something could be a leaky microwave oven. It could be a video transmitter. It could be someone who uses a wireless phone. It could be virtually anything.
All it has to do is to transmit continuously. It can be quite weak. The thresholds for CCA are typically very low. A continuous signal will inhibit other units from transmitting. Whatever that signal is, do not be surprised if it is entirely legal.
Again, that's what Part 15 is all about...
I'm assuming that most readers are not licensed amateur radio operators trying to pass themselves off as uber wifi users. The original post mentioned nothing of the sort. However, you are correct --mostly. I have yet to see any case law from the FCC that suggests any sort of primacy for an amateur radio operation of this sort.
Uh, no.
Note to moderators: this is not interesting. It is very misinformed.
All WiFi must comply with 47CFR15.5(b).
All WiFi operates under the condition that it does not interfere with other licensed operations, and that it accepts interference from other sources without complaint to the FCC. The principle is the same world wide: If you opt out of a formal licensing scheme, you shouldn't expect support or enforcement of interference claims.
This is why radio licenses exist. The process may be arcane, expensive and even ridiculous. However, without a license, you have no legal recourse if someone interferes with your operation. I'll be the first to concede that there is much we could do to improve and speed up the licensing schemes. However, that bureaucracy is a subject for another rant. The fact that it may be done poorly does not mean that it isn't necessary.
I've been over this argument more times than I care to remember. Full disclosure before a fix is available is irresponsible.
There are applications out there where you simply can not spray patches at the net to see what sticks. Each update has to be carefully tested and validated. These are typically very high reliability applications.
Your ignorant attitude to this problem overlooks the fact that it's not the software company that you need to be concerned about. It's the customers who bought it!
So go ahead, put a software company under. I don't much care. But if you cause someone to die because a zero day exploit caused the hospital to not see a patient's life support fail, that's a problem. If you hack a SCADA system at some remote site, you could put a neighborhood without electricity for many days.
These bits of software have actual end-users. This isn't just about the company that sold the software, it's about the end-users. People's lives often depend on this software working correctly.
If you don't give them a chance to react, then you're just as guilty as those who actually attack these sites.
Many people have written many articles as well as a significant number of books about this subject.
There are valid reasons, though the short answer is because they don't know any better. Really.
These networks are supposed to be separated from the office. However, real security is hard. All it takes are one or two dreamy eyed, lazy idiots on the office side, wanting access to all that delicious data "in real time" so that they can surf it and "discover new paradigms." They nag the IT department, and before you know it, someone has breached the two networks.
Oh and by the way, it will be interesting to see how all that wild data from the up and coming smart grid project interfaces to SCADA system securely. Security is not high on the agenda of most smart grid designers.
I write this as one who is involved in ISA-99 (Industrial Control Security) and the DNP3 protocol committee, and as a SCADA integrator and end user. There is a tremendous amount of education and work to be done. I wish it were as simple as disconnecting the two networks. Unfortunately, in too many cases, it has already gone way beyond that.
Clearly you're out of touch with reality. There is an entire world outside of the IT office. These people have skills you couldn't even dream of. If they acted this way, you'd be a helpless puddle of drool.
Be thankful that you have skills people want and need. Now, about those pesky clients: If they like the user interface, GIVE THEM THE DAMNED USER INTERFACE! If there is something actually wrong with the user interface that misleads them in to doing dangerous things, tell them so that they can make an informed decision. The point is to make it possible for them to do that aspect of their job without getting confused about how to get to the new tab that a web page just opened up.
I know, you're thinking "how could anyone be that ignorant." Well, try talking to people in other professions such as an attorney, or even a fast food worker. They'll give you an entirely new perspective on what ignorance is.
It would be nice to separate the electric generation, transmission, and distribution networks from the Internet, but it ain't happening. SCADA systems are being interconnected to each other and to proxies that deliver data to the Internet in real time, or near real time.
Nobody can avoid this. SCADA systems are delicious fountains of high fructose data that executive operations staff, researchers, and governments are finding hard to resist. The Smart Grid is only the latest of many wide eyed high tech applications to hit this space. There have been many before it.
We're already exposed. The question is how to build resiliency in to this effort. As you might imagine, it's not easy. This isn't some office application where damage can be repaired with a backup. These systems affect physical assets and public safety in our cities. There is no backup to restore broken lives.
This isn't an ideal situation. Most utilities would love to return to the days when everything could be isolated. But if anything, all this smart metering and smart grid stuff will cause everything to get even more connected and integrated. There is good value in such connections. Nevertheless, it has been hyped while glossing over the details of the security risks.
Now that we know we're exposed, we need people with embedded systems backgrounds, control engineers with practical systems design experience, and security professionals to come together and to share information without killing each other. (All three fields are well known for having their share of prima-donna character flaws)
I wish DOE the best of luck. The horse is already out of the barn and they're still trying to figure out how to close the door.
Please keep in mind that, in reality, we have to deal with Slashdot "moderators" and others of their ilk.
They don't realize their limitations of intelligence. They don't particularly care about factual accuracy, either.
So they have absolutely no qualms about referring to somebody they dislike as a "pedophile", and then backing it up with this sort of keystroke moderation as "proof."
If you don't believe me, just look at how they justified moderating this post. They showed computer generated images of this "web page" and pictures of perverts, all available on the Internet.
Let's see: Adam Gadahn. Has he been convicted? Nope. Is there any doubt this man is a traitor? Uhh, let's see: pals around with Osama Bin Ladin, Reads screeds against the US. Coordinates attacks against US troops. And... he's in Pakistan or Afghanistan.
So, no. There can't be any legal process here. We have no jurisdiction. He gives every indication of committing traitorous acts in a war zone.
As long as we have a military that is required to fight a battle in a war zone, I think it should be legal to kill a combatant without wondering about citizenship, legal status, or whether the method of killing is appropriate.
In any case, this is no different than a sniper shooting at enemy combatants a mile away. And nobody has raised legal issues about that.
Personally, I think the ACLU is hungry and looking for more donations. Any military lawyer worth a damn should be able to have this case thrown out of court in no time.
Energy storage is still very much in its infancy. There are many ways to do it and there are many risks as well.
Basically, there are two places where such energy storage is practical. One of them is in large scales at the generation facility, the other is smaller scales at the load.
Personally, I prefer the load side for energy storage because it offers some backup in case the power distribution system is interrupted. It is also very much an issue of research with development of electric and hybrid vehicles.
Conversely, if these energy storage devices failed, how large would the release of energy be? If it were at the generation side, it could be disastrous. However, at the load side it may be less so.
Personally, I like the idea of a hydrocarbon fuel cell with local storage. Similar ideas have been proposed by the likes of Bela Liptak (one of the fathers of modern control engineering as a discipline). He liked the notion of storing hydrogen and oxygen from electrolyzing water. With a bit of chemical engineering I'm sure people could find easier and cheaper forms of fuel cell materials that might be safer and less prone to leaking (gaseous hydrogen isn't exactly easy to store in your home).
Yes, but one of the things that causes "human error" is poor design. Sometimes, the information can be right there at your fingertips but in a form that doesn't encourage an operator to develop good situational awareness. This was one of the causes that lead to the 2005 Texas City Refinery explosion and fire. The information on flow totals in and out of the raffinate splitter process were on a different page of the screen and the operator on duty was tired, busy, and simply didn't think to look at it. Had he done so, he'd have seen that there was an awful lot of flow going in to the tower and nothing coming out.
The point of discussing design like this is to improve situational awareness so that disasters are less likely to happen.
You seem to find insult in this where there is none intended.
The very notions of liberalism and conservatism often change with the generations in ways such that yesterday's liberal views often become conservative. Look at how many on the Right quote Dr. Martin Luther King Jr. By the standards of his day, he was very much a liberal.
Another fact: Empathy and eagerness to improve the world by the young often lead them to what many consider liberal views. They try things that others "know" can't work. Most of these ideas fail, but a few stick. As you get older, experience and pragmatism often set in. Often habit takes over where they should be questioning why we do things the way we do. Using one's experience and "brains" is often a way to keep doing what you've been doing.
If you see this as an insult, you may want to check your knowledge of history and the humanities.
The IEEE-802.15.4 specification defines a way to reduce power, but it does not enshrine this at the MAC layer of this protocol. Perhaps Zigbee may do this, but it isn't in '15.4 as far as I have read.
The feature you're talking about is called Clear Channel Assessment (CCA) and it is part of ,most of the wireless specifications. The problem with CCA is that the threshold is shockingly low. And what you hear at the transmitting end isn't necessarily what the receiver hears. In other words, the receiver could be trashed by another signal too far away for you to hear. I need to remind everyone here, this is not a coaxial cable or a fiber system. It is radio. Radios wave systems are not perfect hubs or trunk lines. There are signals on the air that one side may hear that the other doesn't.
Another issue you might not realize is that it takes at least as much power to run an 802.15.4 receiver as it does the transmitter. In most cases, the the transmitter is the local oscillator as well. There isn't much power to be saved.
So why reduce power? To reduce the chance that a signal can be received by others with nefarious intent, and to reduce interference as you said.
I suggest people consider using different channels. Even though the 802.11 channel passband is over 22 MHz wide, and there are really only three channels that don't overlap, you can still choose an adjacent channel and use the despreading to your advantage.
I find that the default channel for most of 802.11b/g routers is channel 6. Use anything but that and you'll probably do OK. Those who can remember the heyday of CB radio, may remember that most of the kiddie walkie talkies used to be on CB channel 14. That was the one channel you didn't want to be on. It is interesting that we still haven't learned that lesson even today.
The old saw: "If you're not a liberal when you're young, you have no heart; if you're not a conservative when you're older, you have no brain." (Variants have been attributed to Winston Churchill, though there is no indication that he ever said this)
Age may not be such a bad indicator after all.
Functions have their place, Subroutines have their place. Global variables have their place. Static variables, Heap variables, and stack variables have their place. Even a Go To has it's place (in rare cases).
The point is to use these tools in such a way that someone else can figure out what you're doing.
On the other hand, as Albert Einstein is reputed to have said, things should be simplified as much as possible, but no farther. If the code is obtuse, sometimes it is because the programmer doesn't understand the background of what it is supposed to do. In other words, if you understand Digital Signal Processing, someone's code may look quite elegant. If you don't understand it, it looks obtuse.
We'd all like to think that good programming is simply a matter of writing reasonably concise and well documented code. But it isn't. One needs an education on the subject being programmed. If you don't know the subject well enough, no amount of documentation is going to help you.
The question I have is whether there can ever be conclusive data to prove one side or the other before it actually happens.
I had hopes before that some very bright people might find a way to analyze data and simulate with it. However, given the dubious quality of the data collected thus far, I have to wonder if climate studies are going to produce anything useful.
And then these CRU idiots got exposed. If there was any opportunity for real science to get done before, it's been blown away for a good many years.
Thanks a lot guys. Your disservice to the community ought to win you an IgNobel --except that those usually have some humor in them. There is nothing funny about what CRU did.
(spit)
Point taken.
My view is that leadership is something that is not limited to one particular field. Some accountants are very good leaders. Some salesmen are very good leaders. And yes, some scientists and engineers are very good leaders.
Somewhere along the way, however, the idea took hold that you had to have a formal grounding in the humanities to be a leader. Little do these people know that scientists, engineers, and other technical professions often DO have a strong grounding in the humanities, though it isn't a formal education.
They have excluded those with formal technical backgrounds on the assumption that a formal training is the ONLY way to get a good grounding in the arts and humanities. I think that's foolishly arrogant, and very very wrong.
Let's let our leaders emerge from whatever backgrounds they have and not exclude someone just because they lack a formal education on the subject.