No. You are an idiot. 127.0.0.1 is a network address. When you are using 127.0.0.1 as your display, all your X11 traffic is operating over the network. You are using network transparency.
The lack of network transparency is when you use things like SHM, or DRM, things that need direct access to hardware, and cannot operate over the network.
Network transparency in X11 is a result of the development environment. All IPC in UNIX was traditionally done through sockets. If your application and server are already communicating over a socket, then it really makes no difference whether that is a local file socket, or a remote network socket. X11 network transparency was basically a happy coincidence.
Starting with OSX, Windows Vista, and Compiz, there has been a shift towards using the 3D hardware in graphics cards to do all UI rendering. Traditionally on X11, this required special extensions that provided direct access to the display hardware, removing the ability for application clients to connect to display servers over the network. AIGLX was developed to allow this interaction to operate over the traditional X11 socket, thus preserving network transparency. The trouble is that this was a huge, convoluted amount of code, adding lots of overhead and numerous bugs.
Weyland was started basically as a reaction to AIGLX. Rather than spending lots of effort abstracting hardware access to maintain networkability, they dropped that requirement and started fresh. The emacs email analogy isn't very accurate, because they're changing THE fundamental design characteristic. It would be more like Linus waking up one morning and deciding he likes microkernels now, scrapping the entirety of the existing monolithic Linux as a result.
Actually, compositing window managers have been transitioning to OpenGL and indirect rendering through AIGLX, allowing those things to once again operate transparently over the network using only the X11 protocol.
What do you think X itself is? Pulseaudio is a sound server, allowing multiple sound sources to be multiplexed in software against one or more sound outputs, for outputs without the capability to perform hardware multiplexing. Xorg is a display server, allowing multiple image sources to be multiplexed in software against one or more display outputs. If you want to get really specific, you can reference the AIGLX extension for allowing the same thing to be done for OpenGL applications.
No. What he's saying is that X11 is still perfectly network transparent, but that the clients are using the protocol in a manner that only works well over very high bandwidth, very low latency links, like a local socket. The only time network transparency goes away is when you're using extensions like SHM or DRM, which typically means you're doing things like video playback, games, or other intensive rendering; tasks which will never function well over slow, laggy links.
Surely if they could legitimately make that claim, studios selling digital music downloads would charge you for a dozen copies of the song, as the data bounced across that many routers on its way from the content server to your machine.
To be fair, many of the problems associated with heavy methamphetamine usage are not actually caused by methamphetamine. It's caused by the fact that methamphetamine is refined using some particularly nasty chemicals, and the poor quality laboratory equipment and conditions available to basement/garage/trunk/RV meth cookers is insufficient to produce a clean product. It's no different to how the high methanol content in cheaply produced moonshine has been known to cause blindness. Legalization, combined with government regulation, would go a long way towards mitigating these ill effects.
All that needs to happen is to allow users to store and blacklist numbers right on their god damned phone. It's absurd that I have to contact AT&T any time I want to block something, and I have a limited quantity of numbers that I can be blocking simultaneously.
Robodialers aren't like email spam. It's not like you can just toss up a new domain, or route your traffic through a massive bot-net of not-blacklisted zombies. You have to buy phone service, and you can't easily change numbers. Individual blacklisting would work wonders against this.
If you got too close and cornered it, a chihuahua could jump up and chew on your balls for a couple seconds, but it would not cause any long term damage, and it would not survive the encounter
Why are any multi-rotor craft easier to fly than a single rotor with a swashplate? Fly-by-wire means nothing. It's merely the replacement of old mechanical or hydraulic control linkages with electronic ones. Pretty much all RC aircraft are fly-by-wire, and always have been, with electric servo motors directly attached to the control surfaces by an arm.
Are you referring to electronic stability augmentation, control remapping, and autopilot systems? There is absolutely no reason why those systems hobbyists have created for multi-rotor craft cannot be reproduced for single-rotor craft. In fact, writing an autopilot for a single-rotor craft would be considerably easier, since changes in thrust will be nearly instantaneous, as you don't have to don't have to worry about that delay waiting for the propeller to spin up. You merely need to be aware of your thrust limits based off the peak power output of your engine.
As a counter argument, the primary reason such systems exist for multi-rotor craft in the first place is because they must exist. The cyclic, collective, and rudder pedals on a single-rotor craft directly control the main and tail swashplates, and allow for direct control of roll, pitch, thrust, and yaw. The controls are natural. On a multi-rotor craft, the pilot's control inputs must be remapped to the power outputs of the motors, to properly simulate the traditional cyclic and collective, and there simply is no yaw control to be had.
I don't question the use of multi-rotor craft in the hobbyist market. A true hobbyist will freely trade a lot of their own time in exchange for reduced cost. A multi-rotor craft makes sense if you're down within the few hundred dollar range. My point is that you're not going to be spending a few hundred dollars to carry a several thousand dollar studio camera, in a several thousand dollar mechanical stabilization mount. The craft itself is going to be in the several thousand dollar range as well. That being the case, you quickly reach a capability limit at which it is cheaper to just use one big motor, rotor, and swashplate, as opposed to ever increasing numbers of small, inefficient propellers and motors.
Sure. Just about anything is better at heat dissipation than air. That's why we use it as an insulator. Of course in computers, we use these fancy things called fans, which cycles the air around, and makes it just wonderful for cooling things. Of course that oil is too viscous to do such things without specially designed containers, so anything with more power draw than a smartphone is just going to sit there and cook.
You need to extend that a bit further. No DRM can work without a proprietary system. That means everything between the DRM module and your monitor must be running trusted binaries, including kernel, browser and graphics drivers. Yes. That means Flash is a broken DRM implementation, and there is nothing stopping you from capturing the decoded video frames on an open system.
Don't get so ahead of yourself. Encryption isn't a bad thing. There would be absolutely nothing wrong if tomorrow, every website switched to https (well actually there would be as it would invalidate all kinds of caching proxies, but that's besides the point). Encryption exists to protect communication from outside entities. In the traditional sense, encryption protects communication between you and the server from 3rd parties. The problem with DRM is that it protects communication between your monitor and the server from you. My computer should not be protecting itself from me.
I wish people would stop up-rating posts like this. The one thing that made the internet what it was today is openness. The HTTP and HTML protocols were OPEN standards. Anyone who wanted to could write their own server or client, and do whatever they wanted with it. In order for DRM to work, this goes away. In order to implement those parts of the standard, the code must be licensed by a single agency, verified that it protects the content from the user, and distributed as a binary to prevent users from altering those protective bits. You won't be able to build a copy of Apache or Lighttpd or Nginx to serve up such content. You won't be able to build a copy of Firefox or Chrome to view such content. You wouldn't be able to build your own Linux kernel or graphics drivers, since those would need to be licensed and trusted in the same manner. It would require that all computers be just as locked down from the user as a standard Windows machine.
No. Stop thinking there is any silver lining to DRM. No open standard can EVER require DRM, as doing so would immediately mean they are no longer open. In order to properly implement a secure DRM mechanism, the entire code path from the time the content is decrypted to the time it shows up on the display must be secure. That's not secure from outside intruders, like ssh, mind you. That is secure from the user themselves. That means the DRM package, the browser, the kernel, the X11 server, the graphics drivers, the graphics firmware, and the display firmware must all be signed binaries. They don't necessarily need to be closed source, but they must be verified and signed as secure by the DRM licensing agency. They may as well be closed source, since the user will never be able to modify and recompile the source, and still be able to access DRM'd content. Once you cease being able to write or download and run your own unsigned software on your own computer, it ceases to be yours.
With a multi-rotor, you've got several motors all running slightly different RPMs, and you've got to deal with the variable resonance coming off them. With a single rotor, you only have to deal with a single motor that only ever runs at a single RPM. Surely that would be much easier to damp out.
Read up on how a swashplate works. You pitch the plate, which results in continuously variable angle of attack and thrust from one side of the rotor disc to the other. It gives you more precise control than any multi-rotor design.
Now as for survivability, a hex/octo-rotor might be able to handle the failure of one of the motors if so designed, of course having six or eight motors means it's just that much more likely to suffer a motor failure. Having a complex variable speed motor means each motor is less resilient than the single-speed motors on a traditional helicopter design. On the other hand, you could always have coaxial motors on a single-rotor craft, and even if you lose the motor, there's still the possibility for an auto-rotation landing.
Doing stuff electronically complex is really cheap. The electronics cost for a single rotor (flybarless) RC helicopter and a hypothetical 200 rotor helicopter would hardly be any different - since the same actual electronics are needed, just with more outputs and fancier software. However, something mechanically complex isn't like this - increasing electronic complexity (especially if most of it is only in software) doesn't make much difference to the unit cost, but mechanical complexity very rapidly increases the unit cost of your aircraft.
If you're talking a hobbyist, sure. A hobbyist isn't likely to have access to a high end machine shop with the kinds of tools necessary to fabricate their own rugged swashplate. On the other hand, they can just slap on a speed controller with more channels, and spend their time coming up with a more complex flight control program. Buying a swashplate costs money, but a hobbyist's time is free. That's the low barrier to entry I was talking about. It's easier for the hobbyist to tinker around with these things.
Once you start getting into the commercial realm, suddenly time is expensive, and competent engineer time doubly so. If it takes twice as long for your mechanical engineers to spec out the rotor, but your electrical engineers only spend a fifth the time to build motors and control boards that only have to operate efficiently at one single RPM, you come out ahead.
For my radio controlled helicopters, I've traded off mechanical complexity (mechanical flybar) for electronics (flybarless, with the flybar's function carried out by electronics). It makes the rotor head much, much simpler, more rugged, more reliable, and there's less to replace when the inevitable crash occurs since there is no longer the flybar nor its mixing arms and linkages in the rotor head.
If you're trying to build something with a significant amount of payload, such as something designed to carry a $10K studio camera and high speed data links, chances are you're going to want more than two rotor blades, so a relatively simple flybar would not be applicable. You would need a more expensive, fully-articulated mount.
From a drone point of view, probably the best (if cost is no object) is collective pitch twin rotor, either like a Chinook or like the Russian co-axial helicopters, because you're not throwing away 30% or more of your power counteracting the main rotor's torque with the tail rotor (and for a battery powered aircraft, this translates directly into more flight time or cheaper batteries).
That's only half right. You're throwing away power because of the induced swirl in the flow. You suffer just as much loss regardless of whether you're using a tail rotor, or multiple counter-rotating lift rotors. That includes things like the Chinook and Osprey. The Russian contra-rotating craft like the Kamov or Hokum are the only types of helicopter which avoid this loss, by using a pair of coaxial rotors to remove much of the swirl from the flow. Multi-rotor craft with their small propellers could do this, by using a shrouded rotor and a stator, or even back-to-back contra-rotating propellers, but I've never seen any examples of people actually doing that.
I've still be unable to get a satisfactory answer to this question. Why are you building and flying quad/hex/octo-rotors, as opposed to traditional single-rotor helicopters? This is a serious question. In terms of performance, loiter duration, maneuverability, pretty much anything that matters to a helicopter, a single rotor will trump multi-rotor craft every time.
I honestly haven't been following the development of multi-rotor craft, because I just don't see the point. What advantages do they actually have over traditional single-rotor helicopters? As an aerospace engineer, the only one I can think of is that at the extremely low end of the market, variable speed electric motors are cheaper than a mechanical swashplate. Is the industry just based off a bunch of amateur hobbyists that got into multi-rotors because of the extremely low barrier to entry, but don't understand the theory enough to understand their disadvantages?
Even professional football players were complaining about having to play under the drone of 10,000 angry bicycle trumpet blowers during the South African World Cup.
Can someone explain to me why everyone seems so gung ho about these multi-rotor aircraft? Seriously, I feel like it's the early 1900s, and all the amateurs are coming out of the woodwork with the foolish believe that if one wing is good, and two is better, then twenty will be amazing, and anyone trying to use the legendary twenty one wings must be sabotaged.
The ONLY redeeming value of multi-rotor craft is that they are mechanically very simple. All you need is three static propellers, three electric motors, some sticks, and a drive controller. The barrier to entry is extremely low, so it opens the RC helicopter market to poor hobbyists. Beyond that, variable frequency motors mean while it is mechanically simple, it is electronically complex, as compared to traditional helicopters that run at a single RPM. Several small rotors mean you have high disk loading, which directly and negatively influences every important performance characteristic for a helicopter. Directional authority is only available in the directions you have rotors, rather than being infinitely variable as on a traditional helicopter. There's really no way to easily yaw them, so you must mount all your instrumentation on a 360 turntable.
I simply don't understand what advantages these things have over a traditional helicopter that you might want to spend more than a few hundred dollars on one. Everything I know about aerodynamics says if you can afford a swash-plate, you use one.
That's just the problem. It's not a steady droning noise, because maneuvering is done through variable rate motors, as opposed to traditional helicopters which use a single-speed motor and variable pitch.
Slashdot Mirror
No. You are an idiot. 127.0.0.1 is a network address. When you are using 127.0.0.1 as your display, all your X11 traffic is operating over the network. You are using network transparency.
The lack of network transparency is when you use things like SHM, or DRM, things that need direct access to hardware, and cannot operate over the network.
Network transparency in X11 is a result of the development environment. All IPC in UNIX was traditionally done through sockets. If your application and server are already communicating over a socket, then it really makes no difference whether that is a local file socket, or a remote network socket. X11 network transparency was basically a happy coincidence.
Starting with OSX, Windows Vista, and Compiz, there has been a shift towards using the 3D hardware in graphics cards to do all UI rendering. Traditionally on X11, this required special extensions that provided direct access to the display hardware, removing the ability for application clients to connect to display servers over the network. AIGLX was developed to allow this interaction to operate over the traditional X11 socket, thus preserving network transparency. The trouble is that this was a huge, convoluted amount of code, adding lots of overhead and numerous bugs.
Weyland was started basically as a reaction to AIGLX. Rather than spending lots of effort abstracting hardware access to maintain networkability, they dropped that requirement and started fresh. The emacs email analogy isn't very accurate, because they're changing THE fundamental design characteristic. It would be more like Linus waking up one morning and deciding he likes microkernels now, scrapping the entirety of the existing monolithic Linux as a result.
Actually, compositing window managers have been transitioning to OpenGL and indirect rendering through AIGLX, allowing those things to once again operate transparently over the network using only the X11 protocol.
What do you think X itself is? Pulseaudio is a sound server, allowing multiple sound sources to be multiplexed in software against one or more sound outputs, for outputs without the capability to perform hardware multiplexing. Xorg is a display server, allowing multiple image sources to be multiplexed in software against one or more display outputs. If you want to get really specific, you can reference the AIGLX extension for allowing the same thing to be done for OpenGL applications.
No. What he's saying is that X11 is still perfectly network transparent, but that the clients are using the protocol in a manner that only works well over very high bandwidth, very low latency links, like a local socket. The only time network transparency goes away is when you're using extensions like SHM or DRM, which typically means you're doing things like video playback, games, or other intensive rendering; tasks which will never function well over slow, laggy links.
Surely if they could legitimately make that claim, studios selling digital music downloads would charge you for a dozen copies of the song, as the data bounced across that many routers on its way from the content server to your machine.
To be fair, many of the problems associated with heavy methamphetamine usage are not actually caused by methamphetamine. It's caused by the fact that methamphetamine is refined using some particularly nasty chemicals, and the poor quality laboratory equipment and conditions available to basement/garage/trunk/RV meth cookers is insufficient to produce a clean product. It's no different to how the high methanol content in cheaply produced moonshine has been known to cause blindness. Legalization, combined with government regulation, would go a long way towards mitigating these ill effects.
The packages were "lost" in transit. You should have paid for the shipping insurance.
All that needs to happen is to allow users to store and blacklist numbers right on their god damned phone. It's absurd that I have to contact AT&T any time I want to block something, and I have a limited quantity of numbers that I can be blocking simultaneously.
Robodialers aren't like email spam. It's not like you can just toss up a new domain, or route your traffic through a massive bot-net of not-blacklisted zombies. You have to buy phone service, and you can't easily change numbers. Individual blacklisting would work wonders against this.
If you got too close and cornered it, a chihuahua could jump up and chew on your balls for a couple seconds, but it would not cause any long term damage, and it would not survive the encounter
If I recall correctly, didn't that one crash due to fatigue, rather than being shot down?
Why are any multi-rotor craft easier to fly than a single rotor with a swashplate? Fly-by-wire means nothing. It's merely the replacement of old mechanical or hydraulic control linkages with electronic ones. Pretty much all RC aircraft are fly-by-wire, and always have been, with electric servo motors directly attached to the control surfaces by an arm.
Are you referring to electronic stability augmentation, control remapping, and autopilot systems? There is absolutely no reason why those systems hobbyists have created for multi-rotor craft cannot be reproduced for single-rotor craft. In fact, writing an autopilot for a single-rotor craft would be considerably easier, since changes in thrust will be nearly instantaneous, as you don't have to don't have to worry about that delay waiting for the propeller to spin up. You merely need to be aware of your thrust limits based off the peak power output of your engine.
As a counter argument, the primary reason such systems exist for multi-rotor craft in the first place is because they must exist. The cyclic, collective, and rudder pedals on a single-rotor craft directly control the main and tail swashplates, and allow for direct control of roll, pitch, thrust, and yaw. The controls are natural. On a multi-rotor craft, the pilot's control inputs must be remapped to the power outputs of the motors, to properly simulate the traditional cyclic and collective, and there simply is no yaw control to be had.
I don't question the use of multi-rotor craft in the hobbyist market. A true hobbyist will freely trade a lot of their own time in exchange for reduced cost. A multi-rotor craft makes sense if you're down within the few hundred dollar range. My point is that you're not going to be spending a few hundred dollars to carry a several thousand dollar studio camera, in a several thousand dollar mechanical stabilization mount. The craft itself is going to be in the several thousand dollar range as well. That being the case, you quickly reach a capability limit at which it is cheaper to just use one big motor, rotor, and swashplate, as opposed to ever increasing numbers of small, inefficient propellers and motors.
Sure. Just about anything is better at heat dissipation than air. That's why we use it as an insulator. Of course in computers, we use these fancy things called fans, which cycles the air around, and makes it just wonderful for cooling things. Of course that oil is too viscous to do such things without specially designed containers, so anything with more power draw than a smartphone is just going to sit there and cook.
You need to extend that a bit further. No DRM can work without a proprietary system. That means everything between the DRM module and your monitor must be running trusted binaries, including kernel, browser and graphics drivers. Yes. That means Flash is a broken DRM implementation, and there is nothing stopping you from capturing the decoded video frames on an open system.
Don't get so ahead of yourself. Encryption isn't a bad thing. There would be absolutely nothing wrong if tomorrow, every website switched to https (well actually there would be as it would invalidate all kinds of caching proxies, but that's besides the point). Encryption exists to protect communication from outside entities. In the traditional sense, encryption protects communication between you and the server from 3rd parties. The problem with DRM is that it protects communication between your monitor and the server from you. My computer should not be protecting itself from me.
I wish people would stop up-rating posts like this. The one thing that made the internet what it was today is openness. The HTTP and HTML protocols were OPEN standards. Anyone who wanted to could write their own server or client, and do whatever they wanted with it. In order for DRM to work, this goes away. In order to implement those parts of the standard, the code must be licensed by a single agency, verified that it protects the content from the user, and distributed as a binary to prevent users from altering those protective bits. You won't be able to build a copy of Apache or Lighttpd or Nginx to serve up such content. You won't be able to build a copy of Firefox or Chrome to view such content. You wouldn't be able to build your own Linux kernel or graphics drivers, since those would need to be licensed and trusted in the same manner. It would require that all computers be just as locked down from the user as a standard Windows machine.
No. Stop thinking there is any silver lining to DRM. No open standard can EVER require DRM, as doing so would immediately mean they are no longer open. In order to properly implement a secure DRM mechanism, the entire code path from the time the content is decrypted to the time it shows up on the display must be secure. That's not secure from outside intruders, like ssh, mind you. That is secure from the user themselves. That means the DRM package, the browser, the kernel, the X11 server, the graphics drivers, the graphics firmware, and the display firmware must all be signed binaries. They don't necessarily need to be closed source, but they must be verified and signed as secure by the DRM licensing agency. They may as well be closed source, since the user will never be able to modify and recompile the source, and still be able to access DRM'd content. Once you cease being able to write or download and run your own unsigned software on your own computer, it ceases to be yours.
With a multi-rotor, you've got several motors all running slightly different RPMs, and you've got to deal with the variable resonance coming off them. With a single rotor, you only have to deal with a single motor that only ever runs at a single RPM. Surely that would be much easier to damp out.
Read up on how a swashplate works. You pitch the plate, which results in continuously variable angle of attack and thrust from one side of the rotor disc to the other. It gives you more precise control than any multi-rotor design.
Now as for survivability, a hex/octo-rotor might be able to handle the failure of one of the motors if so designed, of course having six or eight motors means it's just that much more likely to suffer a motor failure. Having a complex variable speed motor means each motor is less resilient than the single-speed motors on a traditional helicopter design. On the other hand, you could always have coaxial motors on a single-rotor craft, and even if you lose the motor, there's still the possibility for an auto-rotation landing.
Doing stuff electronically complex is really cheap. The electronics cost for a single rotor (flybarless) RC helicopter and a hypothetical 200 rotor helicopter would hardly be any different - since the same actual electronics are needed, just with more outputs and fancier software. However, something mechanically complex isn't like this - increasing electronic complexity (especially if most of it is only in software) doesn't make much difference to the unit cost, but mechanical complexity very rapidly increases the unit cost of your aircraft.
If you're talking a hobbyist, sure. A hobbyist isn't likely to have access to a high end machine shop with the kinds of tools necessary to fabricate their own rugged swashplate. On the other hand, they can just slap on a speed controller with more channels, and spend their time coming up with a more complex flight control program. Buying a swashplate costs money, but a hobbyist's time is free. That's the low barrier to entry I was talking about. It's easier for the hobbyist to tinker around with these things.
Once you start getting into the commercial realm, suddenly time is expensive, and competent engineer time doubly so. If it takes twice as long for your mechanical engineers to spec out the rotor, but your electrical engineers only spend a fifth the time to build motors and control boards that only have to operate efficiently at one single RPM, you come out ahead.
For my radio controlled helicopters, I've traded off mechanical complexity (mechanical flybar) for electronics (flybarless, with the flybar's function carried out by electronics). It makes the rotor head much, much simpler, more rugged, more reliable, and there's less to replace when the inevitable crash occurs since there is no longer the flybar nor its mixing arms and linkages in the rotor head.
If you're trying to build something with a significant amount of payload, such as something designed to carry a $10K studio camera and high speed data links, chances are you're going to want more than two rotor blades, so a relatively simple flybar would not be applicable. You would need a more expensive, fully-articulated mount.
From a drone point of view, probably the best (if cost is no object) is collective pitch twin rotor, either like a Chinook or like the Russian co-axial helicopters, because you're not throwing away 30% or more of your power counteracting the main rotor's torque with the tail rotor (and for a battery powered aircraft, this translates directly into more flight time or cheaper batteries).
That's only half right. You're throwing away power because of the induced swirl in the flow. You suffer just as much loss regardless of whether you're using a tail rotor, or multiple counter-rotating lift rotors. That includes things like the Chinook and Osprey. The Russian contra-rotating craft like the Kamov or Hokum are the only types of helicopter which avoid this loss, by using a pair of coaxial rotors to remove much of the swirl from the flow. Multi-rotor craft with their small propellers could do this, by using a shrouded rotor and a stator, or even back-to-back contra-rotating propellers, but I've never seen any examples of people actually doing that.
I've still be unable to get a satisfactory answer to this question. Why are you building and flying quad/hex/octo-rotors, as opposed to traditional single-rotor helicopters? This is a serious question. In terms of performance, loiter duration, maneuverability, pretty much anything that matters to a helicopter, a single rotor will trump multi-rotor craft every time.
I honestly haven't been following the development of multi-rotor craft, because I just don't see the point. What advantages do they actually have over traditional single-rotor helicopters? As an aerospace engineer, the only one I can think of is that at the extremely low end of the market, variable speed electric motors are cheaper than a mechanical swashplate. Is the industry just based off a bunch of amateur hobbyists that got into multi-rotors because of the extremely low barrier to entry, but don't understand the theory enough to understand their disadvantages?
Even professional football players were complaining about having to play under the drone of 10,000 angry bicycle trumpet blowers during the South African World Cup.
Can someone explain to me why everyone seems so gung ho about these multi-rotor aircraft? Seriously, I feel like it's the early 1900s, and all the amateurs are coming out of the woodwork with the foolish believe that if one wing is good, and two is better, then twenty will be amazing, and anyone trying to use the legendary twenty one wings must be sabotaged.
The ONLY redeeming value of multi-rotor craft is that they are mechanically very simple. All you need is three static propellers, three electric motors, some sticks, and a drive controller. The barrier to entry is extremely low, so it opens the RC helicopter market to poor hobbyists. Beyond that, variable frequency motors mean while it is mechanically simple, it is electronically complex, as compared to traditional helicopters that run at a single RPM. Several small rotors mean you have high disk loading, which directly and negatively influences every important performance characteristic for a helicopter. Directional authority is only available in the directions you have rotors, rather than being infinitely variable as on a traditional helicopter. There's really no way to easily yaw them, so you must mount all your instrumentation on a 360 turntable.
I simply don't understand what advantages these things have over a traditional helicopter that you might want to spend more than a few hundred dollars on one. Everything I know about aerodynamics says if you can afford a swash-plate, you use one.
That's just the problem. It's not a steady droning noise, because maneuvering is done through variable rate motors, as opposed to traditional helicopters which use a single-speed motor and variable pitch.