Many low-tech existing weapons would work. Tear gas. Flash-bangs. Net or wire entanglement ammo.
Tanks with a bulldozer blade worked fine against Iraquis in Desert Storm.
Moller has been spewing hype about his VTOL craft since 1967. I have his 1974 brochure, in which the thing was to be available Real Soon Now. It's still Real Soon Now.
He did an IPO a few years back, got in trouble with the SEC, paid a fine, and throttled back the hype a bit.
This new guy is worse.
The numbers on this thing are amusing.
It's way overpowered. Unlike Moller, this thing uses a jet engine.
Hanging a CJ610, with about 3000 pounds of thrust, on a 4000 pound aircraft is overkill. Two of those engines power a 20,000 pound Learjet.
CJ610 engines cost about $250,000 used and overhauled.
This looks like a variation on the scheme to use DNS to distribute public keys for encrypted mail. It could even use the same key.
The basic idea, as I understand it, is that the DNS for a domain holds a public key, and mail sent with a "from" address in that domain must be signed with that public key. That's an old idea, and not all that bad. You create your own public/private key pair; you don't have to buy a "certificate" from somebody. (I think.)
If you control a domain's DNS info, you can send mail from anywhere with that domain listed as the sender, as long as you know the private key.
For the free-mail services, it's fine. All their mail is authored via web applications and sent from their own servers. Only the service has the private key. Only the outgoing SMTP servers need to know the private key. That's the Yahoo Mail case.
If you own a domain, you should have full control over your own public and private keys.
But adding additional info to a DNS record is not well supported by most hosting services. If you're not running DNS yourself, you may have problems setting your public key. Hosting services have to support this.
Signing can occur either in the original user agent (the SMTP sender) or in a mail forwarder.
It's easier to implement this in mail forwarders,
but if you want to send using a return address other than the one of the mail forwarder you're using, your user agent has to know how to sign mail.
If you're downstream from an ISP and don't control a domain, the ISP owns the key for the domain and can control what they sign. That has implications. They might force you to use web mail, for example.
Or run their client software on your machine.
Spammers can still register domains, run their own DNS, sign their mail, and spam.
It doesn't really stop spam.
Your public key is now valuable, and a target for spyware and viruses.
Expect to see viruses that steal public keys from (inevitably) Outlook and send them to spammers.
Or just send spam from the attacked machine.
What this really does is provide a clear way to identify joe-jobs using addresses from major mail services like Yahoo Mail. That helps Yahoo more than anybody else.
Somebody would figure out some weapon more effective than knife fighting. Land mines. Punji sticks. Something that would push its way through a shield.
Then the Fremen would face the basic problem of desert warfare against an enemy with air power - no place to hide.
By space opera standards, Honor Harrington is quite good. E.E. "Doc" Smith's "Lensman" series, the first space opera, has truly one-dimensional characters. Smith is remembered for the scale of his writings; others wrote about single trips to the Moon; Smith wrote about intergalactic empires. He single-handedly scaled up science fiction.
Weber's characters have strengths and weaknesses. Honor isn't perfect. She has more character flaws than any hero from Star Trek or Star Wars. She's into revenge, and makes some mistakes because of it.
Her real strength is tactics. That makes sense; she's in a navy that trains and selects for tactical skill. She doesn't get that skill by magic; she goes to the Academy and works her way up to command over many years.
The Peep leaders are Weber's most complex characters. Some of them are boors, yet even Warden Tresca plays chess by mail. The Peep military commanders are in tough positions, caught between their political masters and military realities, and deal with them in different ways.
Most just do their jobs. One or two go over to the Manty side. Some die for the People's Republic. Some try a coup. Rod Pierre (oh, please) has a tiger by the tail and can't let go; he's portrayed as ruthless but not evil.
Weber is writing for people who know what Jellicoe did at Jutland. Battle charts wouldn't seem out of place in Weber's books. Fortunately, like Tom Clancy, he has the sense to avoid them.
It's unusual to see tactical skill in SF.
Usually, there's too much individual heroism and not enough planning. Historically, it's hard to find any example where individual heroism changed the outcome of a major war. But it happens all the time in fiction. David Drake gets this, and he's gradually been pulling SF around.
Tactics in print SF are bad enough, but in movie SF, they're appalling.
Nobody in the Star Wars universe has any decent tactical sense. On either side. Much like World War I. Dune. Starship Troopers. Battlefield Earth. The list of bad examples goes on.
The judge is hearing all the motions on discovery today. SCO will probably lose on some issues. So they have to issue PR statements as spin control.
Ignore them. Wait for the judge's first rulings.
Sounds like another Bush pork program.
Remember Reagan's "National Aerospace Plane"? And the Strategic Defense Initiative? Total flops, but big profits for some contractors.
Besides, NASA is too incompetent to bring this off.
They haven't been able to build a new launch vehicle in over thirty years. But they've spent more money trying than they spent on Apollo.
NASA has been described as "the world's largest sheltered workshop". For good reasons.
As a longtime SpamCop customer, I now want to find an alternative. Nobody here seems to have any suggestions.
SpamCop owned by IronPort can't be anything like SpamCop is now. All the real work on SpamCop is done by volunteers. Nobody is going to volunteer their time for IronPort.
There ought to be something useful you can assemble at the molecular level, atom by atom. Ever since IBM used a scanning tunneling microscope to move xenon atoms around, it's been clear that you can do some things that way.
But so far, nobody has built much useful that way. Positioning xenon atoms works well because they're inert and don't bond to anything. Breaking and attaching bonds without damaging the working tip is tough.
Obvious things to build include read and write heads for molecular recording. You get to pick the recording medium, so you can pick materials and bonds compatible with the manipulator.
STMs manufactured by MEMS techniques exist now, so there's reasonable potential there.
I was planning on doing just that when California's new anti-spam law turned on in January. But Congress legalized spamming last week (S.877), and now it's hopeless.
QNX works a lot like that, but it always copies.
All I/O goes through the message passing mechanism. File systems, device drivers, and networking are all implemented as user mode programs. This works just fine; the only downside is the copying overhead, which isn't that bad provided that the system does something other than copying most of the time. (Running a web server on QNX is possible, but for a heavily loaded server that mostly serves plain pages, suboptimal.)
Some OS in the 1980s did do something more like that, moving pages from the sender's address space to the receiver's address space using the MMU. This is very efficient for big transfers, but inefficient for small ones. Plus, you have to align sends on page boundaries.
At one point I looked into the possibility of using IA-32 segmentation hardware to pass data between processes, but it turns out that the "call gate" mechanism can't quite do the job. The IA-32 segmentation hardware looked promising because both small and large segments are supported.
With a little extra hardware support, this approach to an OS could be very effective.
What's really needed is something like IA-32 call gates, but with hardware that lets you pass
one or two segments and part of the stack into another address space. Then you could pass parameters by reference across address space boundaries in a protected way.
Done right, this means low-overhead big objects, like CORBA/DCOM/Active-X.
But it's too late for this. UNIX/Linux assumes a vanilla hardware model; even rings of protection, which are in all IA-32 machines, aren't used. Windows is One Big Kernel for competitive reasons. We've lost the chance to fix this.
The real problem is that the UNIX/Linux world has never been able to get interprocess communication right.
The problem is that what the application wants is a subroutine call, but what the OS usually gives you is an I/O operation.
An example of good message passing is MsgSend/MsgReceive in QNX. Once you've set up a connection, you call MsgSend, which passes your message to the server waiting in a MsgReceive, and blocks the caller until the server does a MsgReply. This is all optimized so that if the server isn't busy when the call is made, control transfers to the server immediately, the server processes the request, and control transfers back. The most common case is very low overhead. Yet the same operations work over a network if needed.
The wrong way to do it is to marshall up all the data and pump it through a socket, just to talk to another process on the same machine. This generates far more transactions at the OS level, and the overhead is much higher. Because the OS doesn't know you're doing a subroutine-call like operation, there are several extra unnecessary context switches.
Worse, systems like CORBA do conversions to network-neutral formats, with even more overhead.
There was an attempt to fix this in Mach, but it was not very successful, and Mach messaging never became mainstream. Windows has COM/DCOM/etc, which is clunky, but good enough to make Office work.
Today, when you call a number that's a dial-up of a a major ISP, what usually happens is that the telco finds out via SS7 that the destination is a modem.
The call is then routed to a local point of presence, converted to IP, and shipped over the Internet to the destination. The point of presence need not be owned by the ISP; it's often a shared facility owned by a telco.
This is called a virtual point of presence.
This is a service ISPs can buy from telcos if they want "local dial up numbers" all over the country.
The logical next step would be to push this technology were pushed out to end offices, which would allow have customer line terminations that allowed higher bandwidths than 56K if the analog local loop supported it.
DSL already does that job better, so there's no reason to do this. Telcos would prefer that DSL worked like virtual points of presence, so they could have "call charges", but fortunately, that didn't happen. Telcos keep trying to put "dial up" features into DSL, but nobody goes for it.
This actually predicts more life in the semiconductor technology than previously expected.
A few years ago, the SIA roadmap said we hit the wall around 2013. Now it looks like there's more life ahead.
The new ITRS Roadmap (the successor to the SIA Roadmap) comes out today. This is the semiconductor industry's consensus position on what happens next. Multiple technologies have to advance for each new generation of semiconductors.
The roadmap is an attempt to predict the problems ahead.
Someone will probably post an ITRS Roadmap story soon, and this issue can be continued then.
The big problem with all this stuff is that it runs on batteries. We have too much stuff now that needs battery replacement. If it transmits much, it's going to need more power than a coin cell can provide for a year.
Wireless power transmission is a possibility. At low power levels, it's quite feasible. That's how RFID tags work, after all. In controlled spaces, like hospitals, airports, aircraft, and prisons, it could work.
That's a plastic concept model, people, not a working prototype. To make it work, they'd have to do most of the engineering needed to make it real.
My favorite concept vehicle remains the General Motors Firebird III. That was a working vehicle. Turbine power. Automatic driving. Joystick steering. Huge tailfins. 1959.
But see Gravel vs. US, which is more on point. That's the Pentagon Papers case. Hutchinson is a defamation case. The question in Hutchinson was whether a member of Congress has unlimited right to defame or libel anyone, and the Supreme Court ruled that the member does not. The question in Gravel relates to the release of protected information to influence public debate.
The current Supreme Court might well decide Gravel differently.
Has this ever come up before in an intellectual property context? And has it come up recently, since the expansion in intellectual property rights in the last decade?
Slashdot Mirror
Many low-tech existing weapons would work. Tear gas. Flash-bangs. Net or wire entanglement ammo. Tanks with a bulldozer blade worked fine against Iraquis in Desert Storm.
This new guy is worse.
The numbers on this thing are amusing. It's way overpowered. Unlike Moller, this thing uses a jet engine. Hanging a CJ610, with about 3000 pounds of thrust, on a 4000 pound aircraft is overkill. Two of those engines power a 20,000 pound Learjet. CJ610 engines cost about $250,000 used and overhauled.
It's unclear why the takeoff distance is so long.
The sender has to have the private key, and that's vulnerable on the sender's machine.
The basic idea, as I understand it, is that the DNS for a domain holds a public key, and mail sent with a "from" address in that domain must be signed with that public key. That's an old idea, and not all that bad. You create your own public/private key pair; you don't have to buy a "certificate" from somebody. (I think.) If you control a domain's DNS info, you can send mail from anywhere with that domain listed as the sender, as long as you know the private key.
For the free-mail services, it's fine. All their mail is authored via web applications and sent from their own servers. Only the service has the private key. Only the outgoing SMTP servers need to know the private key. That's the Yahoo Mail case.
If you own a domain, you should have full control over your own public and private keys. But adding additional info to a DNS record is not well supported by most hosting services. If you're not running DNS yourself, you may have problems setting your public key. Hosting services have to support this.
Signing can occur either in the original user agent (the SMTP sender) or in a mail forwarder. It's easier to implement this in mail forwarders, but if you want to send using a return address other than the one of the mail forwarder you're using, your user agent has to know how to sign mail.
If you're downstream from an ISP and don't control a domain, the ISP owns the key for the domain and can control what they sign. That has implications. They might force you to use web mail, for example. Or run their client software on your machine.
Spammers can still register domains, run their own DNS, sign their mail, and spam. It doesn't really stop spam.
Your public key is now valuable, and a target for spyware and viruses. Expect to see viruses that steal public keys from (inevitably) Outlook and send them to spammers. Or just send spam from the attacked machine.
What this really does is provide a clear way to identify joe-jobs using addresses from major mail services like Yahoo Mail. That helps Yahoo more than anybody else.
Then the Fremen would face the basic problem of desert warfare against an enemy with air power - no place to hide.
But we don't have the technology any more.
Weber's characters have strengths and weaknesses. Honor isn't perfect. She has more character flaws than any hero from Star Trek or Star Wars. She's into revenge, and makes some mistakes because of it.
Her real strength is tactics. That makes sense; she's in a navy that trains and selects for tactical skill. She doesn't get that skill by magic; she goes to the Academy and works her way up to command over many years.
The Peep leaders are Weber's most complex characters. Some of them are boors, yet even Warden Tresca plays chess by mail. The Peep military commanders are in tough positions, caught between their political masters and military realities, and deal with them in different ways. Most just do their jobs. One or two go over to the Manty side. Some die for the People's Republic. Some try a coup. Rod Pierre (oh, please) has a tiger by the tail and can't let go; he's portrayed as ruthless but not evil.
Weber is writing for people who know what Jellicoe did at Jutland. Battle charts wouldn't seem out of place in Weber's books. Fortunately, like Tom Clancy, he has the sense to avoid them.
It's unusual to see tactical skill in SF. Usually, there's too much individual heroism and not enough planning. Historically, it's hard to find any example where individual heroism changed the outcome of a major war. But it happens all the time in fiction. David Drake gets this, and he's gradually been pulling SF around.
Tactics in print SF are bad enough, but in movie SF, they're appalling. Nobody in the Star Wars universe has any decent tactical sense. On either side. Much like World War I. Dune. Starship Troopers. Battlefield Earth. The list of bad examples goes on.
The judge is hearing all the motions on discovery today. SCO will probably lose on some issues. So they have to issue PR statements as spin control. Ignore them. Wait for the judge's first rulings.
Besides, NASA is too incompetent to bring this off. They haven't been able to build a new launch vehicle in over thirty years. But they've spent more money trying than they spent on Apollo.
NASA has been described as "the world's largest sheltered workshop". For good reasons.
SpamCop owned by IronPort can't be anything like SpamCop is now. All the real work on SpamCop is done by volunteers. Nobody is going to volunteer their time for IronPort.
But so far, nobody has built much useful that way. Positioning xenon atoms works well because they're inert and don't bond to anything. Breaking and attaching bonds without damaging the working tip is tough.
Obvious things to build include read and write heads for molecular recording. You get to pick the recording medium, so you can pick materials and bonds compatible with the manipulator.
STMs manufactured by MEMS techniques exist now, so there's reasonable potential there.
I was planning on doing just that when California's new anti-spam law turned on in January. But Congress legalized spamming last week (S.877), and now it's hopeless.
Some OS in the 1980s did do something more like that, moving pages from the sender's address space to the receiver's address space using the MMU. This is very efficient for big transfers, but inefficient for small ones. Plus, you have to align sends on page boundaries.
At one point I looked into the possibility of using IA-32 segmentation hardware to pass data between processes, but it turns out that the "call gate" mechanism can't quite do the job. The IA-32 segmentation hardware looked promising because both small and large segments are supported.
With a little extra hardware support, this approach to an OS could be very effective. What's really needed is something like IA-32 call gates, but with hardware that lets you pass one or two segments and part of the stack into another address space. Then you could pass parameters by reference across address space boundaries in a protected way. Done right, this means low-overhead big objects, like CORBA/DCOM/Active-X.
But it's too late for this. UNIX/Linux assumes a vanilla hardware model; even rings of protection, which are in all IA-32 machines, aren't used. Windows is One Big Kernel for competitive reasons. We've lost the chance to fix this.
The real problem is that the UNIX/Linux world has never been able to get interprocess communication right. The problem is that what the application wants is a subroutine call, but what the OS usually gives you is an I/O operation.
An example of good message passing is MsgSend/MsgReceive in QNX. Once you've set up a connection, you call MsgSend, which passes your message to the server waiting in a MsgReceive, and blocks the caller until the server does a MsgReply. This is all optimized so that if the server isn't busy when the call is made, control transfers to the server immediately, the server processes the request, and control transfers back. The most common case is very low overhead. Yet the same operations work over a network if needed.
The wrong way to do it is to marshall up all the data and pump it through a socket, just to talk to another process on the same machine. This generates far more transactions at the OS level, and the overhead is much higher. Because the OS doesn't know you're doing a subroutine-call like operation, there are several extra unnecessary context switches. Worse, systems like CORBA do conversions to network-neutral formats, with even more overhead.
There was an attempt to fix this in Mach, but it was not very successful, and Mach messaging never became mainstream. Windows has COM/DCOM/etc, which is clunky, but good enough to make Office work.
Except for the retro crowd still using C, this stopped being a problem years ago.
Today, when you call a number that's a dial-up of a a major ISP, what usually happens is that the telco finds out via SS7 that the destination is a modem. The call is then routed to a local point of presence, converted to IP, and shipped over the Internet to the destination. The point of presence need not be owned by the ISP; it's often a shared facility owned by a telco. This is called a virtual point of presence. This is a service ISPs can buy from telcos if they want "local dial up numbers" all over the country.
The logical next step would be to push this technology were pushed out to end offices, which would allow have customer line terminations that allowed higher bandwidths than 56K if the analog local loop supported it.
DSL already does that job better, so there's no reason to do this. Telcos would prefer that DSL worked like virtual points of presence, so they could have "call charges", but fortunately, that didn't happen. Telcos keep trying to put "dial up" features into DSL, but nobody goes for it.
The new ITRS Roadmap (the successor to the SIA Roadmap) comes out today. This is the semiconductor industry's consensus position on what happens next. Multiple technologies have to advance for each new generation of semiconductors. The roadmap is an attempt to predict the problems ahead.
Someone will probably post an ITRS Roadmap story soon, and this issue can be continued then.
A few hundred lawsuits later, everything will be as tight as it was in the Multics days.
There are CEOs like that.
Among the failed dot-coms, there are quite a number of CEOs like that.
Wireless power transmission is a possibility. At low power levels, it's quite feasible. That's how RFID tags work, after all. In controlled spaces, like hospitals, airports, aircraft, and prisons, it could work.
My favorite concept vehicle remains the General Motors Firebird III. That was a working vehicle. Turbine power. Automatic driving. Joystick steering. Huge tailfins. 1959.
And how secure is that backdoor?
Remember, the government of China is going Linux. This may be a policy move by China to start working on Microsoft's market share.
This is why security by patching is fundamentally ineffective against enemies, as opposed to nusances.
The current Supreme Court might well decide Gravel differently.
Has this ever come up before in an intellectual property context? And has it come up recently, since the expansion in intellectual property rights in the last decade?