Can anyone name an important algorithm or representation from this decade?
There's been substantial progress in trainable computer vision systems in the last decade.
Computer vision is finally starting to work on real-world scenes. SLAM algorithms work now. Texture matchers work. There really has been progress in those areas.
We still don't have a clue how to do strong AI, but we probably have the CPU power. One of those Google data centers probably could do strong AI if we had any clue how to program the thing.
It certainly has more storage than a brain.
A big problem with Google's "content network" is that most of the ad sites have no real content. The newspaper industry at least has something worth attaching ads to. Google is taking a 50% cut of ad revenue without doing very much for it.
This may push Google ads towards the "bottom feeder" made-for-Adwords sites, especially if the news media become very aggressive about going after anyone copying their content. This will make thosse ads much less valuable; that's where the low-value clicks come from.
Anyone can copy Wikipedia, but like the GPL, the result remains open. So anything copied from Wikipedia into Knol, and anything derived therefrom, remains freely copyable, regardless of any terms Google may seek to impose..
There has to be something really embarrassing for Bush that will come out unless "telecom immunity" passes. The political push for this from the White House doesn't make sense otherwise. Bush has limited political capital left, and he's spending it on the "telecom immunity" issue. Not the surveillance issue, which might actually have something to do with terrorism, but the immunity issue.
This doesn't do that much for SCO. It gives Novell, IBM and Red Hat cash to go after.
Remember, there are substantial legal claims against SCO, and those claims are on much stronger grounds than SCO's claims against anybody.
SCO is headed for their day in court:
U.S. District Court - District of Utah - Court Calendar
Honorable Dale A. Kimball
Tuesday, 04/29/2008
08:30 am: SCO Grp v. Novell Inc (2:04-cv-00139-DAK-BCW) Bench Trial
The only question in that trial is how much money SCO owes Novell. SCO will appeal, but they are unlikely to win.
I know a little about DOCSIS. DOCSIS 1.0 treats all IP traffic from a given host as one "flow", with one QoS. In DOCSIS 1.0, carrier-provided telephony might have a better QOS, but all IP traffic was treated as one flow.
DOCSIS 1.1 and 2.0 were supposed to have more QOS capability, and Microsoft put support in Windows 2000 and later that was supposed to use it, but I don't think it was really deployed at a level such that IPv4 precedence fields did anything useful.
DOCSIS 3.0 is supposed to know more about IPv6 QOS, according to this 750-page specification. Data is assigned to preconfigured "flows" using a matching system with rules for IP precedence, IP address, TCP/UDP source/destination port, etc. (See section C2, page 552.) Downstream queuing seems to be pure preemptive (see section 7.6, page 240), based on "priority". The spec seems to be kind of vague about when to queue and when to drop packets, but it kind of looks like you could configure a stock DOCSIS 3.0 system to do fair queueing. In U.S. Patent #7161945, Broadcom suggests such an implementation, using "leaky bucket" fair queueing.
The way to prevent abuse of the priority system is to traffic-limit the high priority traffic. DOCSIS 3.0 has support for that sort of thing; you could configure a flow with a low maximum latency and and a low downstream peak traffic rate, plus a "best effort" flow. If you send too much stuff on the low-latency flow, some of it is dropped. That sets up the right incentives to play nice.
The classification of DOCSIS flows into priority groups is entirely at the whim of the cable operator, and there's no way, apparently, for the customer to even read it. Which would be useful. "Net neutrality" is defined by those settings.
This depends on the cable system. Some systems backhaul each cable segment to the headend and use a centralized "cable modem termination system", a rack of routers in one place.
Some install routers in apartment buildings and street-side pedestals. True pole-mounted routers are used in some applications. As the hardware becomes smaller and more rugged, more smarts are moving to the node on the pole, because this reduces backhaul bandwidth requirements. Of course, it's harder to maintain and upgrade out there. There's a tradeoff between fibre/wire cost and outside plant cost.
The little cleaning robots from iRobot are cute; but they're Rod Brooks dumb. They navigate by bumping into the walls, and have no idea where they are. They're round,
so they can't clean in corners. They're really only slightly better than the one in the GE kitchen of the future from 1956.
We need less home automation, and better building automation for meeting rooms of all sizes. Audio, video, lighting, and HVAC should be handled intelligently by the room control system, with next to no user input required.
Optimal HVAC control is well understood but rarely seen. It requires room sensors for temperature, humidity, C02, CO, fire, smoke, and room occupancy, all of which you can now get in one little box. You also need controllable dampers on the ducts, outside air sensors, fan speed control, and something really reliable to run the system. Once you have that, HVAC works far better. When a room is empty, airflow is reduced but temperature is maintained reasonably close to normal. When someone enters the room, airflow is stepped up a bit. Heating and cooling are adjusted. As more people enter the room, the CO2 reading goes up and the fan speeds increase to bring it back down. If humidity goes up, the HVAC system pumps in more dry air. If CO goes up, but fire alarms haven't tripped, indicating smokers, fan speeds go way up. When outside conditions are suitable, more air is brought in from outside without running it through the A/C or heating system. When this is all working, you'll never notice it.
Yes, they have to do some traffic shaping, but it can be done better.
If the problem is bandwidth hogging by individual residential users, the answer is probably some variation on fair queuing. There's class-based fair queueing in most Cisco edge routers; it just has to be used correctly.
I'd argue that, for residential connections, you need only two basic classes of service - high bandwidth, high latency, and low-bandwidth, low latency. VoIP and real-time game transactions should be low-bandwidth, low-latency; everything else should be high-bandwidth, high latency.
For the low-bandwidth, low-latency streams, the per-IP-address queue should have priority, but the maximum number of buffers on the queue should be deliberately limited. If you try to send too much too fast with low latency, you lose packets. The high-bandwidth, high-latency streams have lower priority but can buffer up to available router memory. That works for streaming video, music piracy, and similar non-time-critical loads.
Note that putting a high precedence on a high-bandwidth stream increases the packet loss rate, so there's no win in doing that. VoIP should request high precedence, but video should not. Clever game developers should put a high precedence on the traffic that needs it, while letting the background traffic that loads assets run at a lower precedence.
High-bandwidth, low-latency is really needed only for real-time interactive video, and that's a premium service, because it really does need more capacity behind it.
Multiple consumers on the same cable segment contend for upstream bandwidth at the router that connects the cable segment to the larger network. That's where fair queuing has to be applied. Similarly, it has to be applied at the router that connects the backbone to the downlink to the cable segment. Fair queuing is only useful at choke points where the number of streams is limited, but the cable modem industry has exactly that situation.
The cable industry problem, I suspect, is that many of the routers out on the pole are still too dumb to do this. This is a killer for P2P traffic, which saturates upstream bandwidth. Upstream bandwidth has to be properly queued at the router on the pole; it can't be managed from the head end of the cable system. The Comcast "fake RST" interference with connections was an attempt to deal with the problem from the head end, which is the wrong answer.
If the players in cable and DSL would agree on policy in this area, or the FCC mandated a standard, cable performance would degrade gracefully under heavy load. Without idiocy like faking connection resets.
A standard on residential IP precedence handling would be a big help. If application developers could rely on the rules, VoIP traffic would work better. Games could get better latency; only some game traffic, the actual user action traffic, needs high precedence. The background loading of game assets should be running at lower priority. When there's a penalty for requesting too much bandwidth at high precedence, it gets used properly.
From a technical perspective, that's how to do "network neutrality".
Look at Scientology. Hubbard is dead, but the organization keeps rolling on. It might be around in a century, positioned somewhat like Christian Science.
Even the Rosicrucians keep plugging along.
It helps if the cult owns real estate. Christian Science, the Rosicrucians, and Scientology all invested heavily in prime real estate during the founder's lifetime. (When in San Jose, visit Rosicrucian Park, a city block of pseudo-Egyptian buildings surrounded by a residential neighborhood.)
If you want to do embedded systems development, it's cheap. If you know what you're doing. You can get an Atmel ATMega128 board with a little LCD display and a few pushbuttons for about $50, a JTAG programmer cable for about $20, and a complete development environment with simulator, debugger, and C compiler for free. Even C++ works; GCC supports the thing.
Unfortunately, you can't get all this stuff in one box with a nice little "Embedded Development for Dummies" book. There are environments well supported for hobbyists, such as the Basic STAMP (late 1970s technology) and the PIC (1980s technology). But they're so retro it's embarrassing.
I'm not saying it's a good career choice, but serious programmers ought to do a little low-level work on a tiny machine just to know what it's like.
BeOS was Apple's #1 choice as a base for what they wanted to build into Mac OS X
Actually, Apple had a relatively good new OS, MacOS 8, a real protected-mode OS which got as far as a first developer release. But it wasn't backwards compatible with old MacOS programs, and apps would have to be rewritten. In particular, Microsoft Office for Mac would need an overhaul, and Microsoft wasn't willing to do one. The same problem applied to BeOS.
Steve Jobs was brought in to suck up to Microsoft and cut the deal which kept Office on the Mac for five years. Apple needed that deal to survive. That's the real reason for the NeXT acquisition. NeXT was supposed to be closer to deployable than MacOS 8 or BeOS, but, as it turned out, it was years away from delivery as MacOS X.
Friendfinder, the dating service, (AFF, alt.com, etc.) was notorious for this. Most of the profiles on their sites were of people who were no longer members. Good-looking photos stayed on the site for years after account termination. It took a lawsuit to stop that.
This is about what Air Force types call "Airspace Deconfliction". In any major war today, you've got all sorts of players using the airspace. There are bombers, some of which don't show on radar. There are tankers for the bombers. There are fighters zooming around, UAVs, helicopters, and missiles. Plus there's ground antiaircraft fire and artillery. And that's just our side; the enemy has their stuff, and it has to be found, identified, and avoided or targeted.
All this has to be coordinated, at least loosely. Coordination today is mostly at the level of "this area/altitude is reserved for this group", with preplanning of who fits where. That works until the enemy crosses the lines, which, if they're not totally incompetent, they will. Then plans have to be changed in a hurry.
Systems to deal with a mess like that could be a big help if they can be made to work.
I'd be more impressed if this were from someone who started up a company that grew. This guy has a little software company with one product, and he's had a little company with one product for, what, ten years now?
For comparison, read The Autodesk File. Autodesk was started with $60K from the founders, never accepted any venture capital, and had revenue of $1.8 billion last year.
I'm not sure whether closing the magnetic circuit between the motor and the wheel is affecting the motor output or the wheel braking. It could be either, or both.
But the observed effect isn't that surprising. All this guy really has is a brake that applies when the coil is not energized or shorted, which is an understood phenomenon and commercially available.
So I have been thwarted in understanding what "non-linear magnetic steel" is.
There are whole families of non-linear magnetic devices.
Non-linear magnetic effects are used in saturable reactors for motor control, magnetic amplifiers, and other AC electrical devices.
You don't see those things much any more, because power semiconductors are now used instead, but the physics still works. Also see this explanation of magnetic hysteresis, which is a related non-linear magnetic effect.
Consider a permanent magnet brake that relies on hysteresis effects to absorb energy.
Reversing magnetic domains requires energy, which comes out as heat. Look at the figure "Variation in hysteresis curves" in this article. Maximum braking is achieved when the magnetic field is near the middle, wide parts of the curves. If you use a coil to apply a magnetic field that forces the material closer to saturation, or to cancel out the field from the permanent magnets, the braking effect decreases. That's probably what's going on with the "Perepiteia" device. Mild steels are in the midrange of magnetic materials; they are easy to saturate magnetically, which is why they make wimpy permanent magnets, but have moderate hysteresis, so they make inefficient transformer cores. For a magnetic brake, though, you want something in the midrange of magnetic materials, where the magnetic domains resist changing direction enough to generate heat, but don't resist so strongly that nothing happens, as in a strong magnet. I suspect that the "Perepiteia" device has coils wound on mild steel, and the braking energy is dumped into heating up those metal cores.
(Here's more than you probably want to know about saturation and hysteresis in magnetic materials for transformer design.).
I'm still not clear on whether the magnetic connection to the motor in the "Perepiteia" device really has much to do with this. But there's nothing mysterious about an electromagnetic brake that turns off when you short the coils. It's unusual, but known.
This isn't really my field, but I do have a classical EE degree, so I had to learn this stuff once.
After watching the videos (whew!) here's what seems to be happening.
The setup is an induction motor driving a magnetic brake. The brake has both permanent magnets and coils. With the coils unloaded, there's some braking effect, as you can see when he turns the magnet wheel by hand. With the coils shorted, the braking effect decreases. This seems backwards, because, usually, shorting a generator increases the mechanical load. That's why this guy thinks he has something.
There's a classic Physics 101 demo where you have a big conductive disk rotating between the poles of an electromagnet, and when you short the electromagnet, there's a huge drag on the disk and it stops. That's an eddy current brake, and it's the analogy this guy is depending on.
But, in fact, he's re-invented a known type of magnetic brake. This isn't an eddy current brake; the addition of permanent magnets makes it something else. A known something else.
Here's an example of such a permanent magnet brake. Note that "the brake is applied when the coil current is zero", just as with the "Perepiteia" device. This is backwards from most magnetic brakes. Here, the permanent magnets are providing the field for braking, and current in the coil overrides the permanent magnets. In the "Perepiteia" device, the coils act as generators and have current through them the magnet wheel is rotating and the coils are shorted. This effect requires a nonlinear magnetic steel, so this is non-trivial magnetically. But commercial electromagnetic simulation software can simulate this effect, so it's well understood physics. It's a rare enough technology that there's no accepted name for this type of brake.
Note that in the Perepiteia videos, he has to hand-start his wheel, even though it's being driven by an induction motor. That's because, with his setup, the brake drag is at max when the wheel is stationary. With the wheel stationary, there's no current in the coils, so there's nothing to override the permanent magnets. Once the wheel is turning, the coils generate some power and reduce the braking effect.
There's even a patent on the application of this principle to powered window blinds. See U.S. Patent #6,967,418. There, it's used to hold the blinds in place with power off.
I can't tell you how many people send us bad data and flat out ignore the response.
Sometimes you can get things fixed at other sites. We have a list of major sites being exploited by phishing sites, which is updated every three hours by matching PhishTank (10,000 entries) against OpenDirectory (1.7 million entries), and looking for domains in both. We blacklist sites on a per-domain basis, and needed to measure and minimize the collateral damage.
When we started that list last November, it had 174 domains on it. After reports to abuse addresses, two articles in The Register, and help from PhishTank and the Anti-Phishing Working Group, we're down to 45 domains. Only eight of those domains have been on the list for more than 60 days. The remaining long term problem domains are five DSL providers, a free web hosting service, and two ordinary web sites that had break-ins they've never cleaned up. The rest of the list changes frequently, as sites are added to the list due to some problem, then removed from the list as the problem is fixed.
When we started, Google, Yahoo, MSN, and Dell were all on the list. They've all cleaned up their act. They just needed a little nudging.
With the legit sites tightened up, phishing blacklists become much more effective. It's now safe to blacklist entire base domains, not just URLs or subdomains. Anti-phishing tools just became more effective.
"Open source" goes back to the 1960s.
The Free Software Foundation was established in 1985. The first major Linux release was in 1992. These new guys from the late 1990s are just mouthing off.
Slashdot Mirror
Can anyone name an important algorithm or representation from this decade?
There's been substantial progress in trainable computer vision systems in the last decade. Computer vision is finally starting to work on real-world scenes. SLAM algorithms work now. Texture matchers work. There really has been progress in those areas.
We still don't have a clue how to do strong AI, but we probably have the CPU power. One of those Google data centers probably could do strong AI if we had any clue how to program the thing. It certainly has more storage than a brain.
This isn't a hardware problem any more.
That makes sense.
A big problem with Google's "content network" is that most of the ad sites have no real content. The newspaper industry at least has something worth attaching ads to. Google is taking a 50% cut of ad revenue without doing very much for it.
This may push Google ads towards the "bottom feeder" made-for-Adwords sites, especially if the news media become very aggressive about going after anyone copying their content. This will make thosse ads much less valuable; that's where the low-value clicks come from.
Anyone can copy Wikipedia, but like the GPL, the result remains open. So anything copied from Wikipedia into Knol, and anything derived therefrom, remains freely copyable, regardless of any terms Google may seek to impose..
There has to be something really embarrassing for Bush that will come out unless "telecom immunity" passes. The political push for this from the White House doesn't make sense otherwise. Bush has limited political capital left, and he's spending it on the "telecom immunity" issue. Not the surveillance issue, which might actually have something to do with terrorism, but the immunity issue.
This doesn't do that much for SCO. It gives Novell, IBM and Red Hat cash to go after. Remember, there are substantial legal claims against SCO, and those claims are on much stronger grounds than SCO's claims against anybody.
SCO is headed for their day in court:
U.S. District Court - District of Utah - Court Calendar
Honorable Dale A. Kimball
Tuesday, 04/29/2008
08:30 am: SCO Grp v. Novell Inc (2:04-cv-00139-DAK-BCW) Bench Trial
The only question in that trial is how much money SCO owes Novell. SCO will appeal, but they are unlikely to win.
Fiight sim users who do landings have to have a joystick. You can zoom around with a game pad, but try to do a good landing without a joystick.
Wasn't there some kind of Star Wars animated TV series a few years back? Did anybody notice?
I know a little about DOCSIS. DOCSIS 1.0 treats all IP traffic from a given host as one "flow", with one QoS. In DOCSIS 1.0, carrier-provided telephony might have a better QOS, but all IP traffic was treated as one flow.
DOCSIS 1.1 and 2.0 were supposed to have more QOS capability, and Microsoft put support in Windows 2000 and later that was supposed to use it, but I don't think it was really deployed at a level such that IPv4 precedence fields did anything useful.
DOCSIS 3.0 is supposed to know more about IPv6 QOS, according to this 750-page specification. Data is assigned to preconfigured "flows" using a matching system with rules for IP precedence, IP address, TCP/UDP source/destination port, etc. (See section C2, page 552.) Downstream queuing seems to be pure preemptive (see section 7.6, page 240), based on "priority". The spec seems to be kind of vague about when to queue and when to drop packets, but it kind of looks like you could configure a stock DOCSIS 3.0 system to do fair queueing. In U.S. Patent #7161945, Broadcom suggests such an implementation, using "leaky bucket" fair queueing.
The way to prevent abuse of the priority system is to traffic-limit the high priority traffic. DOCSIS 3.0 has support for that sort of thing; you could configure a flow with a low maximum latency and and a low downstream peak traffic rate, plus a "best effort" flow. If you send too much stuff on the low-latency flow, some of it is dropped. That sets up the right incentives to play nice.
The classification of DOCSIS flows into priority groups is entirely at the whim of the cable operator, and there's no way, apparently, for the customer to even read it. Which would be useful. "Net neutrality" is defined by those settings.
There is no router on the pole.
This depends on the cable system. Some systems backhaul each cable segment to the headend and use a centralized "cable modem termination system", a rack of routers in one place. Some install routers in apartment buildings and street-side pedestals. True pole-mounted routers are used in some applications. As the hardware becomes smaller and more rugged, more smarts are moving to the node on the pole, because this reduces backhaul bandwidth requirements. Of course, it's harder to maintain and upgrade out there. There's a tradeoff between fibre/wire cost and outside plant cost.
The little cleaning robots from iRobot are cute; but they're Rod Brooks dumb. They navigate by bumping into the walls, and have no idea where they are. They're round, so they can't clean in corners. They're really only slightly better than the one in the GE kitchen of the future from 1956.
We need less home automation, and better building automation for meeting rooms of all sizes. Audio, video, lighting, and HVAC should be handled intelligently by the room control system, with next to no user input required.
Optimal HVAC control is well understood but rarely seen. It requires room sensors for temperature, humidity, C02, CO, fire, smoke, and room occupancy, all of which you can now get in one little box. You also need controllable dampers on the ducts, outside air sensors, fan speed control, and something really reliable to run the system. Once you have that, HVAC works far better. When a room is empty, airflow is reduced but temperature is maintained reasonably close to normal. When someone enters the room, airflow is stepped up a bit. Heating and cooling are adjusted. As more people enter the room, the CO2 reading goes up and the fan speeds increase to bring it back down. If humidity goes up, the HVAC system pumps in more dry air. If CO goes up, but fire alarms haven't tripped, indicating smokers, fan speeds go way up. When outside conditions are suitable, more air is brought in from outside without running it through the A/C or heating system. When this is all working, you'll never notice it.
Yes, they have to do some traffic shaping, but it can be done better.
If the problem is bandwidth hogging by individual residential users, the answer is probably some variation on fair queuing. There's class-based fair queueing in most Cisco edge routers; it just has to be used correctly.
I'd argue that, for residential connections, you need only two basic classes of service - high bandwidth, high latency, and low-bandwidth, low latency. VoIP and real-time game transactions should be low-bandwidth, low-latency; everything else should be high-bandwidth, high latency.
For the low-bandwidth, low-latency streams, the per-IP-address queue should have priority, but the maximum number of buffers on the queue should be deliberately limited. If you try to send too much too fast with low latency, you lose packets. The high-bandwidth, high-latency streams have lower priority but can buffer up to available router memory. That works for streaming video, music piracy, and similar non-time-critical loads.
Note that putting a high precedence on a high-bandwidth stream increases the packet loss rate, so there's no win in doing that. VoIP should request high precedence, but video should not. Clever game developers should put a high precedence on the traffic that needs it, while letting the background traffic that loads assets run at a lower precedence.
High-bandwidth, low-latency is really needed only for real-time interactive video, and that's a premium service, because it really does need more capacity behind it.
Multiple consumers on the same cable segment contend for upstream bandwidth at the router that connects the cable segment to the larger network. That's where fair queuing has to be applied. Similarly, it has to be applied at the router that connects the backbone to the downlink to the cable segment. Fair queuing is only useful at choke points where the number of streams is limited, but the cable modem industry has exactly that situation.
The cable industry problem, I suspect, is that many of the routers out on the pole are still too dumb to do this. This is a killer for P2P traffic, which saturates upstream bandwidth. Upstream bandwidth has to be properly queued at the router on the pole; it can't be managed from the head end of the cable system. The Comcast "fake RST" interference with connections was an attempt to deal with the problem from the head end, which is the wrong answer.
If the players in cable and DSL would agree on policy in this area, or the FCC mandated a standard, cable performance would degrade gracefully under heavy load. Without idiocy like faking connection resets.
A standard on residential IP precedence handling would be a big help. If application developers could rely on the rules, VoIP traffic would work better. Games could get better latency; only some game traffic, the actual user action traffic, needs high precedence. The background loading of game assets should be running at lower priority. When there's a penalty for requesting too much bandwidth at high precedence, it gets used properly.
From a technical perspective, that's how to do "network neutrality".
Look at Scientology. Hubbard is dead, but the organization keeps rolling on. It might be around in a century, positioned somewhat like Christian Science. Even the Rosicrucians keep plugging along.
It helps if the cult owns real estate. Christian Science, the Rosicrucians, and Scientology all invested heavily in prime real estate during the founder's lifetime. (When in San Jose, visit Rosicrucian Park, a city block of pseudo-Egyptian buildings surrounded by a residential neighborhood.)
The FSF needs a building.
This could be useful in cell phones. Validate the owner before allowing financial transactions via phone.
But, of course, it would really be used to insure that only the registered owner could view DRM-protected content.
If you want to do embedded systems development, it's cheap. If you know what you're doing. You can get an Atmel ATMega128 board with a little LCD display and a few pushbuttons for about $50, a JTAG programmer cable for about $20, and a complete development environment with simulator, debugger, and C compiler for free. Even C++ works; GCC supports the thing.
Unfortunately, you can't get all this stuff in one box with a nice little "Embedded Development for Dummies" book. There are environments well supported for hobbyists, such as the Basic STAMP (late 1970s technology) and the PIC (1980s technology). But they're so retro it's embarrassing.
I'm not saying it's a good career choice, but serious programmers ought to do a little low-level work on a tiny machine just to know what it's like.
BeOS was Apple's #1 choice as a base for what they wanted to build into Mac OS X
Actually, Apple had a relatively good new OS, MacOS 8, a real protected-mode OS which got as far as a first developer release. But it wasn't backwards compatible with old MacOS programs, and apps would have to be rewritten. In particular, Microsoft Office for Mac would need an overhaul, and Microsoft wasn't willing to do one. The same problem applied to BeOS.
Steve Jobs was brought in to suck up to Microsoft and cut the deal which kept Office on the Mac for five years. Apple needed that deal to survive. That's the real reason for the NeXT acquisition. NeXT was supposed to be closer to deployable than MacOS 8 or BeOS, but, as it turned out, it was years away from delivery as MacOS X.
Friendfinder, the dating service, (AFF, alt.com, etc.) was notorious for this. Most of the profiles on their sites were of people who were no longer members. Good-looking photos stayed on the site for years after account termination. It took a lawsuit to stop that.
This is about what Air Force types call "Airspace Deconfliction". In any major war today, you've got all sorts of players using the airspace. There are bombers, some of which don't show on radar. There are tankers for the bombers. There are fighters zooming around, UAVs, helicopters, and missiles. Plus there's ground antiaircraft fire and artillery. And that's just our side; the enemy has their stuff, and it has to be found, identified, and avoided or targeted.
All this has to be coordinated, at least loosely. Coordination today is mostly at the level of "this area/altitude is reserved for this group", with preplanning of who fits where. That works until the enemy crosses the lines, which, if they're not totally incompetent, they will. Then plans have to be changed in a hurry.
Systems to deal with a mess like that could be a big help if they can be made to work.
I'd be more impressed if this were from someone who started up a company that grew. This guy has a little software company with one product, and he's had a little company with one product for, what, ten years now?
For comparison, read The Autodesk File. Autodesk was started with $60K from the founders, never accepted any venture capital, and had revenue of $1.8 billion last year.
I'm not sure whether closing the magnetic circuit between the motor and the wheel is affecting the motor output or the wheel braking. It could be either, or both.
But the observed effect isn't that surprising. All this guy really has is a brake that applies when the coil is not energized or shorted, which is an understood phenomenon and commercially available.
So I have been thwarted in understanding what "non-linear magnetic steel" is.
There are whole families of non-linear magnetic devices. Non-linear magnetic effects are used in saturable reactors for motor control, magnetic amplifiers, and other AC electrical devices. You don't see those things much any more, because power semiconductors are now used instead, but the physics still works. Also see this explanation of magnetic hysteresis, which is a related non-linear magnetic effect.
Consider a permanent magnet brake that relies on hysteresis effects to absorb energy. Reversing magnetic domains requires energy, which comes out as heat. Look at the figure "Variation in hysteresis curves" in this article. Maximum braking is achieved when the magnetic field is near the middle, wide parts of the curves. If you use a coil to apply a magnetic field that forces the material closer to saturation, or to cancel out the field from the permanent magnets, the braking effect decreases. That's probably what's going on with the "Perepiteia" device. Mild steels are in the midrange of magnetic materials; they are easy to saturate magnetically, which is why they make wimpy permanent magnets, but have moderate hysteresis, so they make inefficient transformer cores. For a magnetic brake, though, you want something in the midrange of magnetic materials, where the magnetic domains resist changing direction enough to generate heat, but don't resist so strongly that nothing happens, as in a strong magnet. I suspect that the "Perepiteia" device has coils wound on mild steel, and the braking energy is dumped into heating up those metal cores. (Here's more than you probably want to know about saturation and hysteresis in magnetic materials for transformer design.).
I'm still not clear on whether the magnetic connection to the motor in the "Perepiteia" device really has much to do with this. But there's nothing mysterious about an electromagnetic brake that turns off when you short the coils. It's unusual, but known.
This isn't really my field, but I do have a classical EE degree, so I had to learn this stuff once.
After watching the videos (whew!) here's what seems to be happening.
The setup is an induction motor driving a magnetic brake. The brake has both permanent magnets and coils. With the coils unloaded, there's some braking effect, as you can see when he turns the magnet wheel by hand. With the coils shorted, the braking effect decreases. This seems backwards, because, usually, shorting a generator increases the mechanical load. That's why this guy thinks he has something.
There's a classic Physics 101 demo where you have a big conductive disk rotating between the poles of an electromagnet, and when you short the electromagnet, there's a huge drag on the disk and it stops. That's an eddy current brake, and it's the analogy this guy is depending on.
But, in fact, he's re-invented a known type of magnetic brake. This isn't an eddy current brake; the addition of permanent magnets makes it something else. A known something else.
Here's an example of such a permanent magnet brake. Note that "the brake is applied when the coil current is zero", just as with the "Perepiteia" device. This is backwards from most magnetic brakes. Here, the permanent magnets are providing the field for braking, and current in the coil overrides the permanent magnets. In the "Perepiteia" device, the coils act as generators and have current through them the magnet wheel is rotating and the coils are shorted. This effect requires a nonlinear magnetic steel, so this is non-trivial magnetically. But commercial electromagnetic simulation software can simulate this effect, so it's well understood physics. It's a rare enough technology that there's no accepted name for this type of brake.
Note that in the Perepiteia videos, he has to hand-start his wheel, even though it's being driven by an induction motor. That's because, with his setup, the brake drag is at max when the wheel is stationary. With the wheel stationary, there's no current in the coils, so there's nothing to override the permanent magnets. Once the wheel is turning, the coils generate some power and reduce the braking effect.
There's even a patent on the application of this principle to powered window blinds. See U.S. Patent #6,967,418. There, it's used to hold the blinds in place with power off.
I can't tell you how many people send us bad data and flat out ignore the response.
Sometimes you can get things fixed at other sites. We have a list of major sites being exploited by phishing sites, which is updated every three hours by matching PhishTank (10,000 entries) against OpenDirectory (1.7 million entries), and looking for domains in both. We blacklist sites on a per-domain basis, and needed to measure and minimize the collateral damage.
When we started that list last November, it had 174 domains on it. After reports to abuse addresses, two articles in The Register, and help from PhishTank and the Anti-Phishing Working Group, we're down to 45 domains. Only eight of those domains have been on the list for more than 60 days. The remaining long term problem domains are five DSL providers, a free web hosting service, and two ordinary web sites that had break-ins they've never cleaned up. The rest of the list changes frequently, as sites are added to the list due to some problem, then removed from the list as the problem is fixed.
When we started, Google, Yahoo, MSN, and Dell were all on the list. They've all cleaned up their act. They just needed a little nudging.
With the legit sites tightened up, phishing blacklists become much more effective. It's now safe to blacklist entire base domains, not just URLs or subdomains. Anti-phishing tools just became more effective.
So, yes, you really can get such problems fixed.
Thanks for finding the "gotchas".
"Open source" goes back to the 1960s. The Free Software Foundation was established in 1985. The first major Linux release was in 1992. These new guys from the late 1990s are just mouthing off.