I won't go into the findings of the NOVA team, but I will point out that your educated guess is completely wrong.
The airbus does have a considerably more advanced and automated autopilot system than Boeing provides. However, that only is engaged during "Normal Law" flight. When any of the sensors on the plane detect a fault, an alarm chimes, and the system informs the pilot that "Alternate Law" is engaged. In Alternate Law mode, the pilot is allowed to use the full control capabilities of the plane, not the restricted range that the sensors believe to be safe.
After alternate law engaged, the pilot can control the engines, and all control surfaces to whatever degree of capability he'd like. The plane in question definitely switched to Alt. Law mode; this fact was radio broadcast back to the Airbus HQ shortly before the plane disappeared. There's a high probability that the pilot was mislead by weather radar readings that said that he could shoot through a "hole" between two storm clouds, but which masked the fact that there was a third (much larger) storm further beyond. Once he was stuck in the middle of all those storms, it was game over.
The pilot and the passengers were not at the mercy of an autopilot that refused to allow corrective action; it is probable that bad data presented to the pilot did not allow him to correctly act.
I doubt this has to do with ITAR. I've worked on a DARPA-funded project which was covered by ITAR restrictions. I did not need to undergo a background check; I just needed to demonstrate American citizenship (read: show my passport to my boss).
You say that you're writing a lot of "C-like" embedded C++. Are you doing fully OOP style coding and using 'new' and 'delete'? Or are you mostly taking advantage of conveniences like namespaces, scoped variable declarations, etc?
If your code is really more C-ish, you could take a look at the Apache Portable Runtime (http://apr.apache.org/). The APR is the library that Apache httpd is based on; they cover most system-level utilities (sockets, files, etc) you could need in a portable way. The APR is more 'C-like' in that a file descriptor is an opaque handle which you pass in to functions like apr_file_puts(), etc., rather than doing the C++ thing of file->puts()..
But if you're ok with the syntax, it's Apache licensed (corporation friendly), well tested (httpd is pretty ubiquitous after all) and actively maintained.
Millions watch it every day. And take what they say seriously. The 30 minutes you saw were probably representative of the whole day. The talking head changes, the unapologetic agenda they advance doesn't.
I used to work on autonomous UAVs as an engineering competition project in college. This was a couple of years back, so the technology's probably changed a bit. But here's some advice to get you started.
First of all, I would not bother trying to program the entire system myself. There's an awful lot to do, simulation is challenging, and failed tests are expensive and will set you back a lot of time. So you should focus on integrating existing stuff as much as possible. There'll still be crashes/failures/etc, but it's more manageable.
One UAV autopilot was called the MicroPilot (http://www.micropilot.com/). This worked okay, but as of 2005 had really terrible documentation and the UI would let you set certain controls to invalid settings, leading to some problems. So double-check everything on the flight line. The MicroPilot was based on the "Magic" board which contained GPS and gyros and an FPGA; you could in theory program that yourself. I can't find this board in a quick Google search, but it's out there somewhere.
Another competing brand was called the Kestrel. Haven't used it, but know that others have had success. (http://www.procerusuav.com/productsKestrelAutopilot.php)
Other similar things to look up are "FMA Co-pilot" and "picopilot." These are not fully-integrated GPS/gyro/altitude/controller setups, but they can work with external gyros to maintain straight and level flight, etc.
We had good success getting "flying wing" foam airplanes to fly stably under autopilot. A more "traditional looking" plane has lots more room in the fuselage for components, but they're harder to fly. A fat foam wing can fly very stably; a fuselage can be built down the centerline, and some components can be embedded into hollows in the wing. If you do this, reinforce the wing with carbon-fiber spars. We used a custom design based off of the MotherShip (http://www.flyingfoam.com/products.html) because we needed additional lifting capacity. We added a tail-prop electric motor to this. Buy that from a hobby store, as well as the ESC.
Gas engines are also available, but you can't do that with a flying wing; you'll need a fuselage to hold a fuel tank. Gas engines are a bit more finicky than electrics, but can provide more overall lifting power.
We transmitted video via a Black Widow (http://www.blackwidowav.com/) AV transmitter. It was hooked up to a relatively nondescript digital camera and transmitted a TV signal back on UHF; we could watch this on a TV powered by an inverter off a car battery in the field.
A small embedded controller (e.g., an Arduino) would be useful to program for operations like managing a high-resolution camera. If if can also read in data over a serial port, it can be interfaced with the micropilot to provide higher-level operational instructions (e.g., download new mission goals). A micropilot will keep a log of all its sensor data so you can review it afterward. This is valuable for tuning the wing.
You can build a gimballed camera into the bottom of your plane without much difficulty; hook up those servers to the aileron servos, but wired in reverse.
One project which was difficult to make work was bilateral communication with the airplane. You'll of course have your primary RC receiver on board to allow manual takeover of flight control, but talking to an on-board Arduino is challenging. You'll need some sort of radio modem. We tried serial radio modems that operated at 900 MHz and 2.4 GHz, but usually encountered unacceptable signal corruption / interference to make this practical. Modern hardware may have eliminated the design flaws that we saw 5 years ago though.
And that, boys and girls, is why financial institutions and other things with real-world consequences are in the world of *adults,* and not third graders.
Seriously, if you make "April Fools Day joke trades" with your retirement fund, your really do deserve exactly what you get.
Spoken like someone who has absolutely no concept on how certificates and signing works.
is full of smugness about the strength of certificates and public-key crypto. I agree that *if* a public-key crypto scheme is implemented 100% securely, it is in fact likely to be unforge-able during our lifetimes.
All I am pointing out is that Microsoft has made horrific gaffes in this space in the past. Your confidence that "they screwed it up once, they learned from it, and then they battened down all the hatches and sealed it up correctly" seems overwrought. I don't know why you are so confident that Microsoft can build an uncrackable system. Crypto is notoriously difficult to implement correctly, and Microsoft has a history of introducing bugs into their code. Not that I can necessarily blame them--they build *huge* systems, so bugs are bound to creep in there. But the bugs are real and they have real effects on end-users. The fact that you're calling it "not your typical PKI setup" makes it sound like there's even more potential for bugs -- if there isn't a robust implementation already tested for years, then how do they know they've implemented it 100% perfectly?
Maybe you will consider me too much of a skeptic, but I've seen enough stupid bugs in enough products that I can't be anything else, especially when it comes to crypto.
(Hell, just yesterday we saw someone who managed to dump the contents of his USB key into an installer disk. How do we know that the "microsoft-priv.pem" file won't share a similar fate? If it even takes 72 hours for Microsoft to discover the problem and revoke the key, that's enough for potentially hundreds of thousands of people to be infected without their knowledge. Likely? Not really. Possible? I can't rule it out.)
All of the above is true. And solid reasons for using TeX. But there are more great features as well.
The mathematical typesetting language has an admittedly high learning curve. It's got a lot of complicated function names and arcane naming rules for some symbols. But it produces beautifully-typeset mathematical formulas (see an earlier response to your query), and once you've memorized the fifty or so symbols that are relevant to the equations in your particular field, you can write your formulas ridiculously fast.
Take for example, the quadratic formula: $x = \frac{-b \pm \sqrt{b^2 - 4ac}}{2a}$
I imagine that at first glance, this looks like gibberish to the non-LaTeXperts in the room. But if you squint, you can decode what it means. The only obscure symbol in there is the \pm for the plus-over-minus character. Commands like \frac{..}{..} and \sqrt{..} create nice variable-sized objects that grow to fit over, under, or around their arguments. And if there's a symbol in Greek, Hebrew, or any more arcane set of mathematical algebras that is necessary for your equation, Tex/probably/ has it covered somewhere (though you may have to dig to find it). In general, though, typing in equations using your "familiar" fifty or so characters winds up being far, far faster than using some WYSIWYG equation-editor. If you've got several hundred equations to typeset, you'd never get past the first chapter without it. After you adjust to getting superscripts by writing "x^2" and subscripts with "x_i," you'll never look back.
There are lots of things I could throw out, sure, but most of them came from principle numero uno - talk to each other.
I second that. And don't just "talk to each other." There's a lot of different ways you can communicate with one another. For instance:
Do you both work independently and then regularly schedule periodic code reviews 2x a week? Or do you do code reviews on a more demand-driven basis when someone feels they have a particular milestone to show the other? Or do you sit next to one another and work in a pair-programming team?
Do you put documents in a shared place that define the design of things? When you discuss designs together face-to-face, do you take notes?
One of these answers isn't inherently better than any other, but what you should probably be striving for is to take a step back and analyze the process of developing and communicating with your partner itself, and adapt that as you, your project, etc evolve as well. So always try to communicate better this month than you did last month, where defining "better" is specific to you two. Then when the third programmer comes along, you'll have a framework to work with him in as well.
One concrete suggestion though: For your design docs and instructions on how to build and test things, start a wiki. You might be in charge of 3--5 people before you know it, and the "tacit knowledge" of how to operate your system will be continually harder to pass on without something like this.
Actually, they might make some remark referring to the fact that they're actually based in Seattle. It's not quite so sunny here as the neighboring land to the South, but it is still very pretty outside most days:)
I call bullshit on this story. I've recently traveled internationally and went through 8 major airports (plus 'random selection' secondary inspection in Philadelphia) throughout the world, with a laptop, Nintendo DS, two Ipod Mini's, and a case of DVD's all stuffed into my laptop bag, while returning from an Islamic nation and nobody asked me to show them anything. And I've had a shmucky customs agent detain me for 30 minutes while going through my bags verrrrrrrrrry slowly and rambling the whole time about how he better not find drugs or contraband or whatever in my bags and I'd better tell him now if I've got any (NB: I didn't). So what have we learned? That you have a luckier record than I have with airport security. But I'm young and have long hair which makes me a "troublemaker" in some peoples' eyes. I've been told that when I look older, this'll happen less. But some people look black/brown/muslim/female/hippie/counter-cultural/whatever and get hassled more than you do.
Your experience, believe it or not, does not establish the absolute truth for every one of the millions of airline passengers who deal with the TSA and US Customs & Immigration on a daily basis. I wouldn't discount anyone's anecdote of their actoins simply based on my own prior experience.
1. Thirteen year old girls are usually emotional basket cases.
As opposed to all those emotionally stable adult females... See, this is why women don't hang out and post on slashdot. Let us know when you move out of mom's basement, will you?
You should take a look at other installation systems. This is a well-studied problem on Windows. In particular, try looking at what the Nullsoft installer does. It's a pretty lightweight installer, very powerful, has lots of Windows-specific things (like rollback-able registry updates) too.
It might be your best bet to try to build off of something like this system to include versioning and dependency meta-data. Then all you need to do is solve that piece of the puzzle, rather than reinvent the whole wheel in the process.
The device in question was called a "tasp". They work in remote control form (like an "anti-taser"), but the addicts have them implanted in their head to provide a constant trickle.
"Totally alien waveform"? I admit it will be a different waveform than the one it sent to the sound card, but to call it "totally alien" implies that there is absolutely no correlation. I actually bet it'd probably be very highly correlated.
I bet that a simple convolution filter would be able to cancel out an overwhelming percentage of the output sound.
Nature's been mentioned plenty of times; Science and Cell are two other very well-regarded journals. I'm under the impression that the Springer-Verlager engineering and math series' are reasonably well thought of. Ideally you'd be published in an IEEE conference or whatever, but plenty of people write articles for those texts.
And 5GHz should not be difficult considering it doesnt have the x86 overhead, is more RISC and that generally PPC has a simpler core. I'll be interested if it comes with quad cores or more.
Eh? RISC chips usually run at lower clock speeds than CISC ones; the difference is that the IPC (instructions retired per clock) for RISC chips tends to be much higher, causing a corresponding performance increase desipte the lower clock rate. CISC chips often take multiple cycles per instruction, whereas RISC pipelines tend to bang out an instruction (or more!) every clock.
Jews believe in Jesus in the same manner that we believe in, say, Benjamin Franklin. His existance isn't particularly disputed. But he is completely theologically irrelevant. He is not mentioned at all in Jewish texts, liturgy, or philosphy.
So, it's data structures with multiple "next" pointers, each list threaded through in a different order? I've implemented this myself dozens of times. Prior art? I've got 1000's of lines of it.:\
Slashdot Mirror
There was a NOVA episode about this crash (an earlier commenter linked to it, but here it is again: http://www.pbs.org/wgbh/nova/space/crash-flight-447.html).
I won't go into the findings of the NOVA team, but I will point out that your educated guess is completely wrong.
The airbus does have a considerably more advanced and automated autopilot system than Boeing provides. However, that only is engaged during "Normal Law" flight. When any of the sensors on the plane detect a fault, an alarm chimes, and the system informs the pilot that "Alternate Law" is engaged. In Alternate Law mode, the pilot is allowed to use the full control capabilities of the plane, not the restricted range that the sensors believe to be safe.
After alternate law engaged, the pilot can control the engines, and all control surfaces to whatever degree of capability he'd like. The plane in question definitely switched to Alt. Law mode; this fact was radio broadcast back to the Airbus HQ shortly before the plane disappeared. There's a high probability that the pilot was mislead by weather radar readings that said that he could shoot through a "hole" between two storm clouds, but which masked the fact that there was a third (much larger) storm further beyond. Once he was stuck in the middle of all those storms, it was game over.
The pilot and the passengers were not at the mercy of an autopilot that refused to allow corrective action; it is probable that bad data presented to the pilot did not allow him to correctly act.
I doubt this has to do with ITAR. I've worked on a DARPA-funded project which was covered by ITAR restrictions. I did not need to undergo a background check; I just needed to demonstrate American citizenship (read: show my passport to my boss).
You say that you're writing a lot of "C-like" embedded C++. Are you doing fully OOP style coding and using 'new' and 'delete'? Or are you mostly taking advantage of conveniences like namespaces, scoped variable declarations, etc?
If your code is really more C-ish, you could take a look at the Apache Portable Runtime (http://apr.apache.org/). The APR is the library that Apache httpd is based on; they cover most system-level utilities (sockets, files, etc) you could need in a portable way. The APR is more 'C-like' in that a file descriptor is an opaque handle which you pass in to functions like apr_file_puts(), etc., rather than doing the C++ thing of file->puts()..
But if you're ok with the syntax, it's Apache licensed (corporation friendly), well tested (httpd is pretty ubiquitous after all) and actively maintained.
Millions watch it every day. And take what they say seriously. The 30 minutes you saw were probably representative of the whole day. The talking head changes, the unapologetic agenda they advance doesn't.
I used to work on autonomous UAVs as an engineering competition project in college. This was a couple of years back, so the technology's probably changed a bit. But here's some advice to get you started.
First of all, I would not bother trying to program the entire system myself. There's an awful lot to do, simulation is challenging, and failed tests are expensive and will set you back a lot of time. So you should focus on integrating existing stuff as much as possible. There'll still be crashes/failures/etc, but it's more manageable.
One UAV autopilot was called the MicroPilot (http://www.micropilot.com/). This worked okay, but as of 2005 had really terrible documentation and the UI would let you set certain controls to invalid settings, leading to some problems. So double-check everything on the flight line. The MicroPilot was based on the "Magic" board which contained GPS and gyros and an FPGA; you could in theory program that yourself. I can't find this board in a quick Google search, but it's out there somewhere.
Another competing brand was called the Kestrel. Haven't used it, but know that others have had success. (http://www.procerusuav.com/productsKestrelAutopilot.php)
Other similar things to look up are "FMA Co-pilot" and "picopilot." These are not fully-integrated GPS/gyro/altitude/controller setups, but they can work with external gyros to maintain straight and level flight, etc.
We had good success getting "flying wing" foam airplanes to fly stably under autopilot. A more "traditional looking" plane has lots more room in the fuselage for components, but they're harder to fly. A fat foam wing can fly very stably; a fuselage can be built down the centerline, and some components can be embedded into hollows in the wing. If you do this, reinforce the wing with carbon-fiber spars. We used a custom design based off of the MotherShip (http://www.flyingfoam.com/products.html) because we needed additional lifting capacity. We added a tail-prop electric motor to this. Buy that from a hobby store, as well as the ESC.
Gas engines are also available, but you can't do that with a flying wing; you'll need a fuselage to hold a fuel tank. Gas engines are a bit more finicky than electrics, but can provide more overall lifting power.
We transmitted video via a Black Widow (http://www.blackwidowav.com/) AV transmitter. It was hooked up to a relatively nondescript digital camera and transmitted a TV signal back on UHF; we could watch this on a TV powered by an inverter off a car battery in the field.
A small embedded controller (e.g., an Arduino) would be useful to program for operations like managing a high-resolution camera. If if can also read in data over a serial port, it can be interfaced with the micropilot to provide higher-level operational instructions (e.g., download new mission goals). A micropilot will keep a log of all its sensor data so you can review it afterward. This is valuable for tuning the wing.
You can build a gimballed camera into the bottom of your plane without much difficulty; hook up those servers to the aileron servos, but wired in reverse.
One project which was difficult to make work was bilateral communication with the airplane. You'll of course have your primary RC receiver on board to allow manual takeover of flight control, but talking to an on-board Arduino is challenging. You'll need some sort of radio modem. We tried serial radio modems that operated at 900 MHz and 2.4 GHz, but usually encountered unacceptable signal corruption / interference to make this practical. Modern hardware may have eliminated the design flaws that we saw 5 years ago though.
Good luck with your project!
And that, boys and girls, is why financial institutions and other things with real-world consequences are in the world of *adults,* and not third graders. Seriously, if you make "April Fools Day joke trades" with your retirement fund, your really do deserve exactly what you get.
If you press the little button in the lower-right corner of the screen, and then select "list" mode, you get turn-by-turn directions.
Your original claim:
Spoken like someone who has absolutely no concept on how certificates and signing works.
is full of smugness about the strength of certificates and public-key crypto. I agree that *if* a public-key crypto scheme is implemented 100% securely, it is in fact likely to be unforge-able during our lifetimes.
All I am pointing out is that Microsoft has made horrific gaffes in this space in the past. Your confidence that "they screwed it up once, they learned from it, and then they battened down all the hatches and sealed it up correctly" seems overwrought. I don't know why you are so confident that Microsoft can build an uncrackable system. Crypto is notoriously difficult to implement correctly, and Microsoft has a history of introducing bugs into their code. Not that I can necessarily blame them--they build *huge* systems, so bugs are bound to creep in there. But the bugs are real and they have real effects on end-users. The fact that you're calling it "not your typical PKI setup" makes it sound like there's even more potential for bugs -- if there isn't a robust implementation already tested for years, then how do they know they've implemented it 100% perfectly?
Maybe you will consider me too much of a skeptic, but I've seen enough stupid bugs in enough products that I can't be anything else, especially when it comes to crypto.
(Hell, just yesterday we saw someone who managed to dump the contents of his USB key into an installer disk. How do we know that the "microsoft-priv.pem" file won't share a similar fate? If it even takes 72 hours for Microsoft to discover the problem and revoke the key, that's enough for potentially hundreds of thousands of people to be infected without their knowledge. Likely? Not really. Possible? I can't rule it out.)
Actually, if you read the link I posted, it mentioned that there was no revocation mechanism in place for that particular scenario.
Hm, maybe you should read up a bit :)
http://www.schneier.com/crypto-gram-0104.html#7
It happened in 2001... doesn't mean it can't happen again -- the attack was purely social engineering.
All of the above is true. And solid reasons for using TeX. But there are more great features as well.
The mathematical typesetting language has an admittedly high learning curve. It's got a lot of complicated function names and arcane naming rules for some symbols. But it produces beautifully-typeset mathematical formulas (see an earlier response to your query), and once you've memorized the fifty or so symbols that are relevant to the equations in your particular field, you can write your formulas ridiculously fast.
Take for example, the quadratic formula:
$x = \frac{-b \pm \sqrt{b^2 - 4ac}}{2a}$
I imagine that at first glance, this looks like gibberish to the non-LaTeXperts in the room. But if you squint, you can decode what it means. The only obscure symbol in there is the \pm for the plus-over-minus character. Commands like \frac{..}{..} and \sqrt{..} create nice variable-sized objects that grow to fit over, under, or around their arguments. And if there's a symbol in Greek, Hebrew, or any more arcane set of mathematical algebras that is necessary for your equation, Tex /probably/ has it covered somewhere (though you may have to dig to find it). In general, though, typing in equations using your "familiar" fifty or so characters winds up being far, far faster than using some WYSIWYG equation-editor. If you've got several hundred equations to typeset, you'd never get past the first chapter without it. After you adjust to getting superscripts by writing "x^2" and subscripts with "x_i," you'll never look back.
Did I also mention you can grep it?
There are lots of things I could throw out, sure, but most of them came from principle numero uno - talk to each other.
I second that. And don't just "talk to each other." There's a lot of different ways you can communicate with one another. For instance:
Do you both work independently and then regularly schedule periodic code reviews 2x a week? Or do you do code reviews on a more demand-driven basis when someone feels they have a particular milestone to show the other? Or do you sit next to one another and work in a pair-programming team?
Do you put documents in a shared place that define the design of things? When you discuss designs together face-to-face, do you take notes?
One of these answers isn't inherently better than any other, but what you should probably be striving for is to take a step back and analyze the process of developing and communicating with your partner itself, and adapt that as you, your project, etc evolve as well. So always try to communicate better this month than you did last month, where defining "better" is specific to you two. Then when the third programmer comes along, you'll have a framework to work with him in as well.
One concrete suggestion though: For your design docs and instructions on how to build and test things, start a wiki. You might be in charge of 3--5 people before you know it, and the "tacit knowledge" of how to operate your system will be continually harder to pass on without something like this.
If you clear your browsing history (ctrl+shift+del), it resets the page visit counts to zero.
No, he's referring to the "look in the drawer in the principal's office where they write down the password for the school mainframe" trick :)
Actually, they might make some remark referring to the fact that they're actually based in Seattle. It's not quite so sunny here as the neighboring land to the South, but it is still very pretty outside most days :)
Your experience, believe it or not, does not establish the absolute truth for every one of the millions of airline passengers who deal with the TSA and US Customs & Immigration on a daily basis. I wouldn't discount anyone's anecdote of their actoins simply based on my own prior experience.
As opposed to all those emotionally stable adult females... See, this is why women don't hang out and post on slashdot. Let us know when you move out of mom's basement, will you?
ye's.
You should take a look at other installation systems. This is a well-studied problem on Windows. In particular, try looking at what the Nullsoft installer does. It's a pretty lightweight installer, very powerful, has lots of Windows-specific things (like rollback-able registry updates) too.
It might be your best bet to try to build off of something like this system to include versioning and dependency meta-data. Then all you need to do is solve that piece of the puzzle, rather than reinvent the whole wheel in the process.
The device in question was called a "tasp". They work in remote control form (like an "anti-taser"), but the addicts have them implanted in their head to provide a constant trickle.
"Totally alien waveform"? I admit it will be a different waveform than the one it sent to the sound card, but to call it "totally alien" implies that there is absolutely no correlation. I actually bet it'd probably be very highly correlated.
I bet that a simple convolution filter would be able to cancel out an overwhelming percentage of the output sound.
Nature's been mentioned plenty of times; Science and Cell are two other very well-regarded journals. I'm under the impression that the Springer-Verlager engineering and math series' are reasonably well thought of. Ideally you'd be published in an IEEE conference or whatever, but plenty of people write articles for those texts.
Eh? RISC chips usually run at lower clock speeds than CISC ones; the difference is that the IPC (instructions retired per clock) for RISC chips tends to be much higher, causing a corresponding performance increase desipte the lower clock rate. CISC chips often take multiple cycles per instruction, whereas RISC pipelines tend to bang out an instruction (or more!) every clock.
Jews believe in Jesus in the same manner that we believe in, say, Benjamin Franklin. His existance isn't particularly disputed. But he is completely theologically irrelevant. He is not mentioned at all in Jewish texts, liturgy, or philosphy.
So, it's data structures with multiple "next" pointers, each list threaded through in a different order? I've implemented this myself dozens of times. Prior art? I've got 1000's of lines of it. :\