The idea of drone swarms doesn't go well together with aerodynamics and basic physical intuition. If you shrink an aircraft down, the aerodynamic cross-section (i.e the drag force) scales with the area (scale^2), but your engine thrust is going to drop roughly by the decrease in volume (scale^3).
So you end up losing maximum airspeed and fuel efficiency (in terms of the mass you're moving) the smaller you go. Unless the drones in your swarm were really big, it doesn't work out.
Although, I imagine we'll see some smaller, unmanned jet fighters in the future (assuming someone figures out how to control something like that remotely, or autonomously). A smaller aircraft has the advantage of a smaller radar cross-section and being more difficult to hit. Doing away with the pilot cuts out a lot of weight and frees up room for a larger engine and fuel tank, offseting the downsides of the smaller size somewhat. There should be a sweet spot where that works out.
Shape is the major determining factor for radar return, not size. From Ben Rich's Skunk Works-
>I really wanted a photographer around for historical purposes to capture the expression on Kelly’s big, brooding moon-shaped mug when I showed him the electromagnetic chamber results. Hopeless Diamond was exactly as Denys had predicted: a thousand times stealthier than the twelve-year-old drone. The fact that the test results matched Denys’s computer calculations was the first proof that we actually knew what in hell we were doing. Still, Kelly reacted about as graciously as a cop realizing he had collared the wrong suspect. He grudgingly flipped me the quarter and said, “Don’t spend it until you see the damned thing fly.” But then he sent for Denys Overholser and grilled the poor guy past the point of well-done on the whys and hows of stealth technology. He told me later that he was surprised to learn that with flat surfaces the amount of radar energy returning to the sender is independent of the target’s size. A small airplane, a bomber, an aircraft carrier, all with the same shape, will have identical radar cross sections. “By God, I never would have believed that,” he confessed. I had the feeling that maybe he still didn’t.
>with flat surfaces the amount of radar energy returning to the sender is independent of the target’s size.
it is basic geometry. Like a flat mirror, no matter the size, will reflect to you the same Sun spotlight (to be precise - as long as the mirror is bigger than 32 arcminutes as seen from the receiving position)
Yup, shape is the biggest thing you can control, then radar absorbing and reflecting materials.
One of the big anecdotes from the early days of stealth aircraft development in the 1970s is how at some wavelengths the Hopeless Diamond shape wasn't visible to range radars at all. During one test, the range radar guys went absolutely crazy trying to detect the shape -- which was a pole model, not even flying yet -- and were about to just give up, when suddenly, there it is on their screens, plain as day. Awesome, the Hopeless Diamond lost its stealth! Or not, because what really happened was a bird landed on the pole model.
> If you shrink an aircraft down, the aerodynamic cross-section (i.e the drag force) scales with the area (scale^2), but your engine thrust is going to drop roughly by the decrease in volume (scale^3).
Why would we shrink drones down? You read drone swarm and assumed small, but most swarm proposals are using drones of a similar size as today or even large in some cases. They're swarms because of the way they interact with one another, and overwhelm enemy defensive systems, not because they're small.
Yes, but the parasitic drag scales with velocity squared, and the induced drag scales with mass. Shrink the aircraft by 2 in all dimensions, you're fine on induced drag, you just need to slow down by a factor of 1-sqrt(2) -- 30%. Structural weight will also be much less. You also aren't carrying the weight of a pilot cockpit, ejection seat, etc. You don't have the drag penalty from the canopy either.
You do need to duplicate a lot of systems, but with modern electronics, these are a lot lighter and take much less power than before. The swarm aspect also allows for large synthetic apertures instead of a big single radar aperture in the nose of one aircraft. Swarms can also deploy cheap unguided weapons, because they can get very close to a target without the worry of losing a pilot and a $100 million airplane. The structural advantages of being small can also be exploited in an unmanned vehicle in that they can sustain much higher G loads than a large airplane, and with no pilot to black out, they will be much more agile in evading missiles.
"swarm" means large numbers by definition, otherwise you have... well, plain-old coordination. Large numbers of F-35-sized aircraft is flaunting economics in the face a quite a bit (so I'm sure the US military loves the idea).
We already have large numbers of F-35 sized aircraft, and are dedicated to having a current stock for the forseeable future, so the economics are already proven.
The issue is not that any given drone is expensive. The issue is that any given manned vehicle with roughly the same profile will involve the same-ish hardware along with expensive life support and safety systems, and a super expensive pilot, and super expensive logistics and possible recovery missions. Plane for plane the drones let us do more with less, justifying their investment during ongoing appropriations. Human pilots will always have a role, but will never be disposable in the way a drone can be.
And, yeah, "swarms" because there is no cookie cutter monolithic answer to what unmanned military craft should look like... Low speed ground hugging smart missiles, ocean based spy capsules in mesh networks, slow speed support craft, high altitude recon craft, in theatre air fire support, air-to-air combat drones, and orbital UAVs can all coordinate. All we know is ever increasing automation and standardization is intersecting with decreasing costs and requirements... very fertile ground for mass production.
Aircraft drag is largely from the wings producing lift, which scales with weight (l^3).
The drag from the fuselage does scale as l^2, but most drones have small fuselages since they don't need room for a pilot and (for fighter planes) a big glass canopy, and lifting drag dominates.
Your comment assumes "drone" means anything like we have today. Any fighter designed in the last 40 years could be made substantially better by removing the pilot and everything necessary to keep him alive and in the fight.
That drone swarm is dropped from a fighter and they don't go very fast or probably have much range. The was to defend would be to stop the fighter flying over your target. I'm not sure it dropping drones would be any more effective than dropping guided bombs in the traditional way.
On Win10 you need to have enough swap space on an SSD; HDD I/O has totally kneecapped latency, seemingly due to blind usage of NCQ (AHCI driver got replaced from Win7), so it chokes out entirely when combined with the even more broken swap manager.
"Enough" meaning "infinite", because you're going to have something leaking all that memory. Task manager doesn't even show memory usage by default (add the "commit size" field), only the working set (and the swapping is insanely aggressive, so memory leaks just don't show up). Nobody seems to actually check that; even built-in stuff like Windows Update leaks pretty badly.
Why the hell does RSA ever get used anymore, esp. in smartcards etc? It's been obsolete for like 10 years thanks to ECC, and ECC is way easier to implement (esp. 127-bit and 521-bit).
Beyond that, RSA is so much easier to understand and implement. Because computing powers of numbers is easier than computing multiples of points on a curve.
Not necessarily, 1.3MJ (360 Wh; but screw that unit) of diesel isn't much of an explosive under normal circumstances. It really depends on the maximum power output under normal operation, and whether it can occur uncontrollably.
Windows 10 is borderline unusable due to it (it evicts RAM very aggressively to use as disk cache). Doesn't help that their IO scheduler is completely screwed up too (and they removed the ability to disable NCQ, so disk performance on HDDs is down the drain).
On that subject, I'm curious whether there is any CPU out there that sets the overflow flag incorrectly when computing (-1) - n when n is the most negative number (which negates to itself, so implementing subtraction by simply negating the RHS and adding will screw up the flags).
The ARM ARM documents sub(left, right, no carry) as add(left, ~right, carry set), which is also the most straightforward implementation if you have to account for carry anyway.
* There's an old feature which causes POP SS/MOV SS instructions to delay all interrupts until the next instruction has executed, to safely allow changing both SS and SP without an interrupt firing inbetween on a bad stack.
* If such an instruction itself causes an interrupt (by triggering a memory breakpoint through the debug registers), it is delayed (as intended).
* The delayed interrupt will fire after the second instruction even if the second instruction disabled interrupts.
* By means of the above, a MOV SS instruction triggering a #DB followed by an INT n instruction will cause the #DB exception to fire before the first instruction of the interrupt handler, even though this should be impossible (as entering the handlers sets IF=0, disabling interrupts).
* The OS #DB handler assumes GS has been fixed up by the previous interrupt handler, which in now under user control.
To be fair, Intel docs are so consistently gibberish that it might as well be classified a separate language (similar to english, but only a quarter the information density).
In this case it seems they just didn't properly specify a piece of insane behaviour though. Hell, I'd consider it an outright CPU bug if I'm reading this right. Seemingly there's a "feature" where loading SS causes interrupts to be delayed until after the next instruction, even if the next instruction disables interrupts - so you can cause an interrupt to fire on the first instruction of the handler (where it should be impossible).
1. The CPU does a buffer overflow when reading the array of bits used to determine IO permission for instructions like "in" and "out". Every OS which supports the feature has to add an extra byte of 0xff beyond the end of the array.
2. Returning from a 32-bit OS to a 16-bit process will only update the low 16 bits of the stack pointer. The upper 16 bits can still be read, leaking info about the kernel stack. Linux has a complicated work-around called espfix.
So you end up losing maximum airspeed and fuel efficiency (in terms of the mass you're moving) the smaller you go. Unless the drones in your swarm were really big, it doesn't work out.
Although, I imagine we'll see some smaller, unmanned jet fighters in the future (assuming someone figures out how to control something like that remotely, or autonomously). A smaller aircraft has the advantage of a smaller radar cross-section and being more difficult to hit. Doing away with the pilot cuts out a lot of weight and frees up room for a larger engine and fuel tank, offseting the downsides of the smaller size somewhat. There should be a sweet spot where that works out.