Rough image stabilisation is done on the frame, with fine stabilisation done with gimbal motors. However, the less the gimbal motors have to do the better, and large slow blades are... well... large and slow.
Your traditional heli can only change attitude when the blades are facing along the correct axis. High performance quad/hex/octo motor controllers can accelerate/decelerate the prop noticeably at ~200hz and change the attitude smoothly, not in sinusoidal acceleration bursts based on the angle of a large slow-rotating prop. This is important for filming, to provide smooth stabilisation against gusts. If you really need the negative thrust, try using plain variable-pitch props (think heli tail-rotors) in a multi-rotor config. The performance and agility is much higher than that of a traditional heli.
Add some real-world dust and grit and a few hundred hours of operation and I'd rather have a $100k camera hanging on something with in-built redundancy, manoeuvrability be damned. Consider that each servo driving your swashplate probably has as many moving parts as an entire hexacopter, and you'll get why.
It could be a prop breaking from striking something, or a motor burning out, or a motor controller failing, or any of the wiring for any of the above being broken in some way. Once you are running 8 props you can even treat it as two joined quads, each with a completely redundant radio, GPS, battery, flight controller etc, so you don't ever have a single point of failure.
Some thoughts: 1) Electric motors are more reliable than petrol engines - less moving parts etc 2) There are spare props - these use 6, which means that 1 can completely fail and the UAV can still fly. 3) A plastic bag will pose no issues for these props - they will cut right through. 4) These will have auto-descent for when signal is lost, battery is low or whatever so that they don't just 'fall out of the sky'.
That said, GPS is horribly inaccurate with height, and I'd also be worried with things like clipping buildings and trees. What to speak of chopping somebody up with the before-mentioned powerful props.
Having more blades isn't to help with heavier lifting (more smaller blades is actually less efficient than more bigger blades), it's to give some redundancy so that if one fails the whole machine is still capable of flying in a degraded fashion. Think RAID, but with an extra 2 dimensions.
You need a minimum of 4 blades for stability, having 6 means that any 1 can fail and having 8 means any 2 can fail.
Lavabit didn't provide access in the first place because the FBI didn't have a warrant. By co-operating with the FBI they would have been violating the contractual agreement with their customers, which would have been illegal. However, by the time the FBI got a warrant they weren't interested in what they had come looking for in the first place.
It's like a cop asking if he can search your car, and when you say no, as is your right, he goes off and gets a warrant to have your house searched and your business frozen.
A lot of the constants are generated using hashes of pre-known numbers, such as the SHA512 (pi*2^510) or other ways to prove that the number wasn't created with a 'secret key' weakness. Just because the one encryption standard used bad numbers doesn't mean they are all broken.
It isn't the civilian channel that stops working at 60k feet/mach1, it is the receiver that decides to stop working if it senses these conditions. If you make your own receiver you can bypass these limits.
We're nerds. Not blind consumer-sheep. We want to know what she thinks, how the sensors work, what makes the cameras good. We don't want to know that the interviewer has a smartphone with an integrated camera, and that he's about to buy his new camera as a phone from BestBuy because he dropped his old camera.
This is a professional here, stop thinking you know *anything* about the intricacies of her job and show some respect. Imagine interviewing Linus or Wozniak and telling them that you're going to buy a new keyboard because you spilled coffee on the old one. Then asking them for recommendations on what brand of bluetooth keyboard you should get to go with your $120 tablet. I'm surprised she didn't hang up out of sheer frustration.
Modern military autopilot systems can use camera-based navigation by recognising terrain features from satellite images. Once you have enough processing power, GPS becomes pretty irrelevant.
By osmosis. Imagine inflating a water balloon, if you pump a heavier fluid like water into it, even in the presence of gravity it will take on a spherical shape. Of course it will be *slightly* deformed, but that's all up to the ratio of weight:surface strength.
Which is why they spent over $500 million in 2011 just on HIV vaccine clinical trials? Sorry, your argument doesn't really hold water, and anyway the company that *does* come up with the vaccine will make a killing.
That won't work if they both die from some bug which is triggered by eg a certain write sequence followed by TRIM, then power cut in the middle of TRIM. They will both be killed.
The AC who responded above me has it right. RDRAND is fine to *add* to the random pool, but it can never be trusted as a *sole* source at any point in time. The moment there isn't enough entropy in the pool from other sources, and RDRAND provides a large majority, any application which takes lots of random data can be compromised through a back-doored RDRAND implementation because the entropy from other sources will be quickly 'drained' and RDRAND will provide everything.
Assuming entropy from any unverifiable source is a recipe for failure, and if the pool thinks it has more entropy than it does because of a back-doored RDRAND, it may provide numbers which it thinks are random but which actually aren't. Basically, to be safe it needs to make the assumption that RDRAND provides no additional entropy, at which point there is no point having RDRAND anyway as you are essentially adding some NOPS into your RNG.
Basically, entropy(random1 XOR random2) is only as high as max(entropy(random1),entropy(random2)). If you can't prove that random2 provides more entropy than random1, there is no point XORing it in the first place. On the other hand, it doesn't hurt either (except for execution performance), as long as you don't run out of random1 numbers and decide that you'll just have to use random2 by itself for a while.
1. Did I say the NSA runs Intel? No. However, the NSA does have the legal mandate to co-opt Intel. As such, any unverifiable random sources cannot be trusted as a sole random source for sensitive crypto applications. If it is added to a pool, that is fine, because even if it has 0 entropy it doesn't make the entropy any worse for the pool. If it is completely random, without backdoors, then great, we can take full advantage of the entropy it provides. However, trusting that it has the entropy it claims to is providing a single point of failure, ie. a NSL + gag order for the inclusion of a backdoor. Single points of failure, with plausible failure mechanisms, are not something which is acceptable in a crypto environment.
2. I never mentioned Via or AMD or anybody else. However, they haven't produced an instructions which they claim is perfectly random but which can't be verified. If they did, I don't see why peoples' responses would be any different. Stop trying to turn this into a partisan anti-Intel bash-fest when it clearly isn't.
3. I'm not 100% convinced. That is your own black-and-white thinking speaking. What I am saying is that it can't be trusted to give the entropy it claims, because we can't verify the microcode and transistor blocks. As to other security holes, of course they should be fixed. But that doesn't mean we should introduce a new one so that we can fix the old ones we don't know about yet. Your logic is faulty.
I'm seeing rant after rant of yours on this. You make hyperbolic statements as 'proof' that you are right. What you conveniently ignore is that the Kernel-based RNGs are open-source, while Intel's ones aren't. That is reason enough not to trust the stuff from Intel, because we have no idea if they are adding backdoors because of a NSL and gag order.
As you say, the NSA is smart. They would much rather have weak keys to crack when they need it than hope developers make weak encryption implementations.
You seem to think that just because I debunked your genetic markers argument I am working for 'the man'. BS. Please re-examine your thinking.
I just think that it is pointless getting worked up about a new kind of blood test. The additional risk it creates for the kind of abuse you speak of is negligible. We have plenty of things to discriminate on already that we don't use, this is equivalent to 'sweaty palms' because it can change on a day-to-day basis.
If you are concerned about government abuse, spend your efforts on something more worthwhile, like hosting an EFF fundraiser.
Slashdot Mirror
Rough image stabilisation is done on the frame, with fine stabilisation done with gimbal motors. However, the less the gimbal motors have to do the better, and large slow blades are... well... large and slow.
Your traditional heli can only change attitude when the blades are facing along the correct axis. High performance quad/hex/octo motor controllers can accelerate/decelerate the prop noticeably at ~200hz and change the attitude smoothly, not in sinusoidal acceleration bursts based on the angle of a large slow-rotating prop. This is important for filming, to provide smooth stabilisation against gusts. If you really need the negative thrust, try using plain variable-pitch props (think heli tail-rotors) in a multi-rotor config. The performance and agility is much higher than that of a traditional heli.
Add some real-world dust and grit and a few hundred hours of operation and I'd rather have a $100k camera hanging on something with in-built redundancy, manoeuvrability be damned. Consider that each servo driving your swashplate probably has as many moving parts as an entire hexacopter, and you'll get why.
It could be a prop breaking from striking something, or a motor burning out, or a motor controller failing, or any of the wiring for any of the above being broken in some way. Once you are running 8 props you can even treat it as two joined quads, each with a completely redundant radio, GPS, battery, flight controller etc, so you don't ever have a single point of failure.
Some thoughts:
1) Electric motors are more reliable than petrol engines - less moving parts etc
2) There are spare props - these use 6, which means that 1 can completely fail and the UAV can still fly.
3) A plastic bag will pose no issues for these props - they will cut right through.
4) These will have auto-descent for when signal is lost, battery is low or whatever so that they don't just 'fall out of the sky'.
That said, GPS is horribly inaccurate with height, and I'd also be worried with things like clipping buildings and trees. What to speak of chopping somebody up with the before-mentioned powerful props.
more smaller blades is actually less efficient than more bigger blades
Gah. That doesn't make sense. Additional smaller blades is less efficient than fewer big blades. Big props are more efficient.
Having more blades isn't to help with heavier lifting (more smaller blades is actually less efficient than more bigger blades), it's to give some redundancy so that if one fails the whole machine is still capable of flying in a degraded fashion. Think RAID, but with an extra 2 dimensions.
You need a minimum of 4 blades for stability, having 6 means that any 1 can fail and having 8 means any 2 can fail.
Lavabit didn't provide access in the first place because the FBI didn't have a warrant. By co-operating with the FBI they would have been violating the contractual agreement with their customers, which would have been illegal. However, by the time the FBI got a warrant they weren't interested in what they had come looking for in the first place.
It's like a cop asking if he can search your car, and when you say no, as is your right, he goes off and gets a warrant to have your house searched and your business frozen.
A lot of the constants are generated using hashes of pre-known numbers, such as the SHA512 (pi*2^510) or other ways to prove that the number wasn't created with a 'secret key' weakness. Just because the one encryption standard used bad numbers doesn't mean they are all broken.
You're thinking software. Try thinking hardware.
I bet by hooking the other end of the USB up to 220V I could do some pretty nasty things to your computer.
The https version redirects to regular /. Use http://beta.slashdot.org instead.
In other news, I actually like it. Although it will be hell using lynx...
It isn't the civilian channel that stops working at 60k feet/mach1, it is the receiver that decides to stop working if it senses these conditions. If you make your own receiver you can bypass these limits.
We're nerds. Not blind consumer-sheep. We want to know what she thinks, how the sensors work, what makes the cameras good. We don't want to know that the interviewer has a smartphone with an integrated camera, and that he's about to buy his new camera as a phone from BestBuy because he dropped his old camera.
This is a professional here, stop thinking you know *anything* about the intricacies of her job and show some respect. Imagine interviewing Linus or Wozniak and telling them that you're going to buy a new keyboard because you spilled coffee on the old one. Then asking them for recommendations on what brand of bluetooth keyboard you should get to go with your $120 tablet. I'm surprised she didn't hang up out of sheer frustration.
Modern military autopilot systems can use camera-based navigation by recognising terrain features from satellite images. Once you have enough processing power, GPS becomes pretty irrelevant.
By osmosis. Imagine inflating a water balloon, if you pump a heavier fluid like water into it, even in the presence of gravity it will take on a spherical shape. Of course it will be *slightly* deformed, but that's all up to the ratio of weight:surface strength.
Or it could be to minimise their surface area for a given volume?
Which is why they spent over $500 million in 2011 just on HIV vaccine clinical trials? Sorry, your argument doesn't really hold water, and anyway the company that *does* come up with the vaccine will make a killing.
That won't work if they both die from some bug which is triggered by eg a certain write sequence followed by TRIM, then power cut in the middle of TRIM. They will both be killed.
Why are you using an iron? Use hot air and an oven, it makes SMT a completely different game. Just make sure you use lots of flux.
The AC who responded above me has it right. RDRAND is fine to *add* to the random pool, but it can never be trusted as a *sole* source at any point in time. The moment there isn't enough entropy in the pool from other sources, and RDRAND provides a large majority, any application which takes lots of random data can be compromised through a back-doored RDRAND implementation because the entropy from other sources will be quickly 'drained' and RDRAND will provide everything.
Assuming entropy from any unverifiable source is a recipe for failure, and if the pool thinks it has more entropy than it does because of a back-doored RDRAND, it may provide numbers which it thinks are random but which actually aren't. Basically, to be safe it needs to make the assumption that RDRAND provides no additional entropy, at which point there is no point having RDRAND anyway as you are essentially adding some NOPS into your RNG.
Basically, entropy(random1 XOR random2) is only as high as max(entropy(random1),entropy(random2)). If you can't prove that random2 provides more entropy than random1, there is no point XORing it in the first place. On the other hand, it doesn't hurt either (except for execution performance), as long as you don't run out of random1 numbers and decide that you'll just have to use random2 by itself for a while.
1. Did I say the NSA runs Intel? No. However, the NSA does have the legal mandate to co-opt Intel. As such, any unverifiable random sources cannot be trusted as a sole random source for sensitive crypto applications. If it is added to a pool, that is fine, because even if it has 0 entropy it doesn't make the entropy any worse for the pool. If it is completely random, without backdoors, then great, we can take full advantage of the entropy it provides. However, trusting that it has the entropy it claims to is providing a single point of failure, ie. a NSL + gag order for the inclusion of a backdoor. Single points of failure, with plausible failure mechanisms, are not something which is acceptable in a crypto environment.
2. I never mentioned Via or AMD or anybody else. However, they haven't produced an instructions which they claim is perfectly random but which can't be verified. If they did, I don't see why peoples' responses would be any different. Stop trying to turn this into a partisan anti-Intel bash-fest when it clearly isn't.
3. I'm not 100% convinced. That is your own black-and-white thinking speaking. What I am saying is that it can't be trusted to give the entropy it claims, because we can't verify the microcode and transistor blocks. As to other security holes, of course they should be fixed. But that doesn't mean we should introduce a new one so that we can fix the old ones we don't know about yet. Your logic is faulty.
I'm seeing rant after rant of yours on this. You make hyperbolic statements as 'proof' that you are right. What you conveniently ignore is that the Kernel-based RNGs are open-source, while Intel's ones aren't. That is reason enough not to trust the stuff from Intel, because we have no idea if they are adding backdoors because of a NSL and gag order.
As you say, the NSA is smart. They would much rather have weak keys to crack when they need it than hope developers make weak encryption implementations.
Musk is also a physicist. He actually dropped out of a PhD in physics to start PayPal.
Obligatory SMBC.
Does it come with a 'vibrate' ringer option?
You seem to think that just because I debunked your genetic markers argument I am working for 'the man'. BS. Please re-examine your thinking.
I just think that it is pointless getting worked up about a new kind of blood test. The additional risk it creates for the kind of abuse you speak of is negligible. We have plenty of things to discriminate on already that we don't use, this is equivalent to 'sweaty palms' because it can change on a day-to-day basis.
If you are concerned about government abuse, spend your efforts on something more worthwhile, like hosting an EFF fundraiser.