One application for space elevators is launching satellites. GEO is an obvious application, but it's high enough up that latency to Earth is annoying, an d for any given frequency band it gets a bit crowded up there. However, since an elevator substantially reduces the costs of lifting weights to orbit, it's also a really convenient way of launching LEO satellites for altitudes like 300-1000km (e.g. replacing Iridium / Teledesic/etc.)
It's not as easy as it seems, because if you just chuck a satellite out the door, that puts it in an orbit designed to bash into your cables, but you can lift a rocket with maneuvering-orbits quantities of fuel rather than escaping-the-gravity-well quantities of fuel, which is a big win, and use it for a "bus" to deploy small satellites. (It's too bad you can't just chuck stuff out the door - there are lots of things you can do with a bunch of cheap nanosats.)
I don't know if a parachute for the whole elevator would make sense (probably, but might be weight issues.) But parachutes for the passengers would probably work. The case that matters most is when the elevator's below the break, which means that at least for Earth-based causes of failure, it's at a relatively low altitude / speed. If you're going individually, bail out with breather equipment once you start to get some atmosphere.
This machine wasn't designed as a camcorder - it was designed as a sub-notebook laptop computer, and the camera is there partly because they're Sony and partly for applications like video-conferencing. The 10 hours of video is an artifact of being able to fit a 30GB disk in the laptop, not because they thought that was the ideal amount of video capacity to have. You'll probably use much of the space for other things. (Besides, if you're shooting that much video, you're usually either somewhere you've got electricity or you're filming things that you'd rathe r have a real videocamera for.)
By the way, if you remember Neal Stephenson's Cryptonomicon, this is the kind of machine Randy used to surreptitiously record his meeting with somebody-or-other, probably the Dentist, when they were busy convincing everybody of their plans for Increasing Shareholder Value. Predecessors of this machine design were available back then.
For Unix-like mainstream operating systems, OpenBSD is probably about the best of them, but security is still something that's only partly built in - Unix had good security design goals, and OpenBSD intensively beats up anything it adopts, but there's still a "root", rather than a collection of least-privilege administrative functions, and if you're root, you can still make things setuid-root in spite of weaknesses. The Mach microkernels had some possibilities of doing real security, but just about everybody's abandoned them for big monolithic kernels.
EROS, the Extremely Reliable Operating System, by Jonathan Shapiro et al., is a capability-based operating system, inspired by KeyKOS and other academic systems from a decade or so ago. A capability is similar to an object handle - you can only access an object (file, process, etc.) if you have a capa that gives you the kinds of permissions you need for the action you want to take. Lots more information at www.eros-os.org.
(Note: that's eros-os.org, not eros.org, which is something entirely different:-)
Sun did several secure Unix variants, including Compartmented Mode Workstation, which met requirements from a slightly different set of DoD bureaucrats, and was roughly B 1.5.
There were probably some others.
Boeing and some Honeywell stuff had A-rated special-purpose network gateway machines
What's the difference in cost between 2MB and 8MB? Probably about $6, and it really affects the usability of the machine if you're a geek, because it affects whether you have to decide whether to install something. With 8MB, you're almost never out of space unless you've got lots of E-Books. With 2MB, you can do the basics, and all the address lists you want, but if you want to carry around E-Books or get a particular Avantgo channel or whatever, you need to see if you've got enough memory. (I've stopped commuting by train, so I no longer bother with Avantgo, but it was really nice to have a mix of newspapers on my Palm.)
Even 4MB would have helped a lot, if the difference in cost really affects their profit margins. Sigh.
It's nice to have a brand new shiny machine with over 384MB of RAM, but one reason for using Linux is so that I can use cheap machines in my lab which have much smaller memories - the P60s and P133s that max out at 64MB of old-flavor fast-page-mode RAM, for instance. I haven'tr tried Galeon on them, but Netscape 6.0 on Windows and whatever flavor Mozilla it was on GNOME both died in horriffically ugly ways, because they wanted lots and lots of RAM that just want't there. But Netscape 2.0 and I think even 3.0 really rocked on my 8MB 386 box, and Opera 1.x was not only faster, you could install it from about 700KB of zip that filled half a floppy disk, as opposed to needing half a CDROM.
Rob Pike's description of the 8 1/2 windowing system on Plan 9 was "Ken and I have spent a decade learning what a windowing system shouldn't do and we wrote one that doesn't do that", and it was small and blazingly fast, in spite of rendering Unicode fonts and such.
Users want to be able to see text, pictures, and navigation on most web pages, especially the ones they like. Some of them also like animated pictures, and important navigation features include at least launching email-sending clients from mailto:s and other configured helper applications. Users behind firewalls also want proxies to work. SSL (or equivalent crypto) and forms are important, but that's about as fancy as I want. Cookies were a bad design, but having something to preserve state is probably important too. All told, this is a pretty small browser. Mosaic or the first Opera release was 90% of the way there.
Content providers have much different desires, which leads them to make web pages that force users to get big hairy bloated browsers with zillions of features. Sometimes this is because they want really tight control over the user experience, which is marketer-speak for "pages that look cool", and sometimes this is because they're using incompatibility-encouraging-bloatware authoring tools to write their pages in (especially if they don't know any better:-). These two intentions are of course interrelated, and they're somewhat driven by the desire of authoring tool vendors to have Lots Of Impressive-Sounding Features so you'll buy their tool instead of just using emacs or some authorware package that's either cheap or integrated into their browser. As a user, I don't *want* my main browser to have Javascript, ActiveX, DreckiFire!, or even Java, and I'd rather not have it enforcing the author's ugly little fonts on me either. I don't mind if there are occasional pages that pop up an auxiliary bloated browser to handle Java if it's doing something I really want, but in fact I've got to leave the stuff turned on most of the time because way too many pages use it gratuitously.
The only good excuse out there for turning a browser from something small and simple into a bigger-than-emacs operating system was that Java-capable browsers offered a mechanism to make the underlying OS ignorable, which would have let us get rid of Microsoft a few years ago. Internet Explorer wasn't intended to anti-trustfully undermine the profitability of the browser market by being free (Netscape has already done that, and was in no position to complain), but it was critical for Microsoft to avoid having browsers kill Windows by rendering backwards compatibility uninteresting.
Compressed flammable gasses on airplanes are just an all-around bad idea.
I'd prefer Ethanol as a fuel, at least if it can tolerate a small amount of water rather than requiring anhydrous. Airplanes could start carrying the full-strength Everclear (apparently the 192-proof is illegal in California, so we can only get 151 here, but I assume the real stuff is available.) (For non-US readers, this is 96%-pure ethanol, with the other 4% being water.) And unlike methanol, it's relatively non-poisonous. So while you wouldn't have a fuel line feeding directly into your laptop from the airline seat, it'd still be convenient, and you could drink the leftovers....
There have been proposals to make watermarkish tags that Digital Rights Management RIAA/MPAA-compliant digital video equipment would have to obey by refusing to copy. So all you need is a button displaying the "can't photograph this" watermark and the Fritz-compliant equipment wouldn't be able to use your picture. Unlikely to happen in practice, though.
Akamai (and its competitors, AT&T and Speedera) have a business model that says they put lots of caching servers out in the network and sell caching to the web content providers who want to get their content out. By contrast, the original web caching was a pull model - businesses with firewalls and some ISPs use either transparent or explicit-proxy-based caching to cache *incoming* content at their gateways or other concentration points (e.g. cable modem network head ends), and they cover the cost of the caching equipment by reducing their bandwidth needs as well as by giving users service that's perceived to be better. Flooding networks like Usenet are good for non-realtime multicast-like behaviour, and multicast is good for streaming but could also be integrated with caching systems. Back during the Internet boom, there were several companies such as I-Beam that used satellite broadcasting to push content out to caching servers, but alas, Chapter 11 has eaten most of them.
One of the frustrating things about PDAs is the lack of full-sized keyboards - you can get various foldy things or thumb-typing things, but having USB controller means that you can add a real keyboard and mouse to this, which is nice. (Has anybody even *done* a Graffiti-X?)
Also, while the screen is still small, being able to add a USB disk drive and printer lets you make this into a real computer, not just an accessory device. Somebody else complained that it was only USB1, not USB2, and while it's not blazingly fast, it's more than enough to do real work. On the othe r hand, $300 (plus $200-300 for a USB disk) can get you a much more powerful desktop computer, if you don't care about portability.
There may be less Indian immigration to the US as a whole than to Britain, but there's immense regional variation. In particular, high-tech areas like Silicon Valley and computer-related businesses have a lot of Indians, so Slashdotters are more likely to live and work around Indians than the average American. I didn't see an excessive number of racist loser commentary here, but perhaps the moderation system has hidden most of that. What I did see that might be perceived as anti-Indian was the issue about price - why is a $300 machine from India that doesn't appear to have any Indian design localization any more interesting than a $300 machine from Taiwan or wherever, and why isn't it priced closer to the Indian economy.
I did see some stereotypes about the electrical systems in India - much more relevant for the Simputer, which was village oriented, than for this computer, but both silly for something meant to run on batteries (like duuhhh! I had been wondering if it had Palm-like month-long battery life or Wince-like day-short battery life, probably the latter.) There were also some questions about language - while most educated Indians speak English, that's not necessarily the language they want to take notes in or keep their address book in.
I checked out www.simputer.org, which says that the simputer organization has become dormant but has licensed its goodies to Picopeta and Encore, both of whom have vaporous forward-looking statements. While the hardware looks similar, building something in this form factor with StrongArm is a relatively obvious design pattern, and the interfaces built in are randomly a bit different. Kaii is designed to be a PDA for high-tech folk, while Simputer is targeted toward being a village computer/communications system.
The real important design differences are in software. Simputer FAQ. One of the big focuses of the Simputer was the IML information markup language, which is an XMLish application designed to be really convenient for multilingual applications, which in India means multiple alphabetic systems as well (so there's an input system), people with limited literacy, support smartcard media well, etc., and they've got some multilingual text-to-speech Kaii doesn't seem to have anything like that - their language support is English, with optional European , Arabic, and East Asian language support, and the possibility of developing something for Indian languages, and they're running a bunch of non-Indian-developed application suites. (There is Unicode support, at least.) The Simputer also has a built-in softmodem capability, which makes sense for something targeted toward the village computer market, while the Kaii lets you plug in standard cards, which could be modem, memory, ether, wireless, etc.
It's not uncommon for some kinds of dessert from India to be topped with very thin silver foil. (Hmmm... how to describe burfee to people who've never seen it - many of the flavors are sort of like marzipan or vanilla fudge.) Haven't turned blue from the stuff yet.
I've been sysadmin and I've been a user. While it's important for sysadmins to occasionally bully users into doing things they're too lazy to do otherwise, it's also important to realize who works for whom, which is that the sysadmin works for the user. In some companies the relationship is close enough to be obvious, while in other companies it's indirect - the sysadmin works for the company, and the user works for the company, but the company hires the sysadmin to LET THE USERS GET THE USERS' WORK DONE. (I'm shouting because I've been in too many environments where this isn't obvious.)
Virus updates are critical - the other posting by A.C. indicates that he sets up the machines on his net to update them frequently, and in a LAN-based environment, that's usually not a bad policy, though updating at boot time sometimes can interfere with what a developer is doing, or with somebody installing new hardware or software that requires reboots, or whatever. But I'm in a company that has people working out in the field, and while it may be important to get a virus update today, a 10 megabyte data file update on a 56kbps dialup line takes a long time - and if I'm out at a customer site trying to show their CIO how our really cool web site can help them make money, or I'm in the airport trying to send an important email before getting on a plane, I can't wait an hour for the latest virus update to download - that can wait till I'm back at the office.
Microsoft Outlook's integration of calendar, incoming mail, and storage of old mail, all in one big system, makes this particularly critical. The other day I needed to get on a conference call, and had the phone number in my Outlook Calendar, and dialed up 15 minutes before the call to get any relevant emails (and my Palm Pilot battery had run out the other day so I hadn't copied the schedule to there.) Somebody in Marketing had decided to mail 10 MB of glossy viewgraphs to everybody, and while it was downloading, I couldn't access the old messages to find the website for the slides for the call. The older antivirus software used to have similar behaviour - it insisted on doing its updates at boot time, before anything else could run, whether the user needed it right then or not. The newer stuff is often sufficiently well-behaved that it just dogs down the network connection rather than totally preventing you from working, but it's still a problem.
Saying "After the game, [the human] was never worried about losing..." does sound rather like he won, and makes it clear that the author knew the results by the time he wrote it....
You're mostly correct today, but your assertions may not remain correct for very long, especially if Fritz Hollings gets his bills adopted.
Almost every PC-like computer today lets you get at instructions to the video display adapter somehow. As computers move to tighter integration, with low-to-medium-end graphics adapters built into the system chipsets, this may require more cooperation from the operating system because there's nowhere to stick a digital logic probe, but it's still doable.
Almost every video display adapter available today lets you get at the digital version of the image before it's fed to the D/A converters. (Audio probably doesn't.) In the past it was simply a result of the obvious architecture for building the things - using some kind of frame buffer than your equipment can write in. Depending on the system, this may take some complex programming, but it can be done. It's also convenient for some applications, such as print-screen and other screen dumps, so it's good to have. (And OCR is good enough you don't need special OCR fonts any more, just simple conventional ones.) The systems that don't let you do that are largely special-purpose things that don't have general-purpose programming available to the users (e.g. video games.) And
But that may not always remain true - the Digital Rights Management crowd are agitating to get control of system design, because all your bits are belong to them and they want to keep it that way. Imagine if your video board and sound board or their integrated chipset equivalents used encrypted data formats instead of unencrypted - it wouldn't matter that you put a logic probe in the line, because you couldn't read the bits. It wouldn't even require much extra CPU - the RC4 encryption algorithm is strong enough, fast enough, and uses very little memory. Key exchange is requires some CPU, but it would be pretty simple to build a public-private keypair into the adapter, where the public key is retrievable by the CPU but the private key is only accessible to the adapter, and require a setup message (either at boot time, or perhaps on a per-application basis) that creates a session key, pk-encrypts it, and hands it to the adapter.
As a crypto geek, I've got mixed feelings about this - I'd like to be able to write an encrypted voice telephony or video conferencing system that not only couldn't be eavesdropped on, but also couldn't be wiretapped by a virus stealing the data path. But the TCPA / Palladium / Fritz Hollings view of DRM basically requires the system to give root access to any program that wants to use the security, and that's blazingly unsafe. It's not clear to me that you can get away with much less than that and still get real application security, but the stuff's obviously Not Ready For Prime Time even on a requirements basis, much less a design or implementation basis.
How scalable is this system? The Codecon transcripts said you were just starting to work on the project at the time, and hadn't done much with it - but it's often hard to change scalability much past the beginning of a project. Unfortunately, the documentation on the web page is still pretty much bottom-up, not top-down, and having just heard about this today I haven't downloaded and played with it yet. Does every message on every channel go to every relay, or do relays only carry all channel creation announcements and then only carry user messages if they're on a path to somebody who wants to receive the channel? Are you doing flooding, or some kind of spanning tree, or some other way to minimize or maximize various traffic measures? If somebody's sending a big file, does it only go to one recipient, or are you multicasting it to a group, and does a recipient need to have acknowledged willingness to accept a file before you transfer it to him/her, or does it just go scream&leap its way across the network?
Resistance to Deliberate Attacks is often strongly related to scalability. Sure, there are other ways to attack systems - find bugs in the code, or do social engineering attacks like posting Scientology documents and Metallica songs and ratting out any identifiable network operators. But attacks on the network's scalability can be really hard to fix, because they abuse things the system _is_ supposed to do rather than things it isn't. Have you looked at what parts of the network are easy to overload with data volume or small-message quantity or CPU-burning public-key crypto calculations or other critical resources?
Slashdot Mirror
It's not as easy as it seems, because if you just chuck a satellite out the door, that puts it in an orbit designed to bash into your cables, but you can lift a rocket with maneuvering-orbits quantities of fuel rather than escaping-the-gravity-well quantities of fuel, which is a big win, and use it for a "bus" to deploy small satellites. (It's too bad you can't just chuck stuff out the door - there are lots of things you can do with a bunch of cheap nanosats.)
I don't know if a parachute for the whole elevator would make sense (probably, but might be weight issues.) But parachutes for the passengers would probably work. The case that matters most is when the elevator's below the break, which means that at least for Earth-based causes of failure, it's at a relatively low altitude / speed. If you're going individually, bail out with breather equipment once you start to get some atmosphere.
Actually, London would do pretty well, and sometimes Seattle.
The 10 hours of video is an artifact of being able to fit a 30GB disk in the laptop, not because they thought that was the ideal amount of video capacity to have. You'll probably use much of the space for other things. (Besides, if you're shooting that much video, you're usually either somewhere you've got electricity or you're filming things that you'd rathe r have a real videocamera for.)
By the way, if you remember Neal Stephenson's Cryptonomicon, this is the kind of machine Randy used to surreptitiously record his meeting with somebody-or-other, probably the Dentist, when they were busy convincing everybody of their plans for Increasing Shareholder Value. Predecessors of this machine design were available back then.
Hey, it takes a lot of work to install Unix, set up WINE, and then get all the MSOffice applications to work well on top of WINE :-)
EROS, the Extremely Reliable Operating System, by Jonathan Shapiro et al., is a capability-based operating system, inspired by KeyKOS and other academic systems from a decade or so ago. A capability is similar to an object handle - you can only access an object (file, process, etc.) if you have a capa that gives you the kinds of permissions you need for the action you want to take. Lots more information at www.eros-os.org.
(Note: that's eros-os.org, not eros.org, which is something entirely different :-)
Even 4MB would have helped a lot, if the difference in cost really affects their profit margins. Sigh.
Just what I need to get launched into the 8th dimension when I accidentally walk by some radio source....
Rob Pike's description of the 8 1/2 windowing system on Plan 9 was "Ken and I have spent a decade learning what a windowing system shouldn't do and we wrote one that doesn't do that", and it was small and blazingly fast, in spite of rendering Unicode fonts and such.
Content providers have much different desires, which leads them to make web pages that force users to get big hairy bloated browsers with zillions of features. Sometimes this is because they want really tight control over the user experience, which is marketer-speak for "pages that look cool", and sometimes this is because they're using incompatibility-encouraging-bloatware authoring tools to write their pages in (especially if they don't know any better
The only good excuse out there for turning a browser from something small and simple into a bigger-than-emacs operating system was that Java-capable browsers offered a mechanism to make the underlying OS ignorable, which would have let us get rid of Microsoft a few years ago. Internet Explorer wasn't intended to anti-trustfully undermine the profitability of the browser market by being free (Netscape has already done that, and was in no position to complain), but it was critical for Microsoft to avoid having browsers kill Windows by rendering backwards compatibility uninteresting.
I'd prefer Ethanol as a fuel, at least if it can tolerate a small amount of water rather than requiring anhydrous. Airplanes could start carrying the full-strength Everclear (apparently the 192-proof is illegal in California, so we can only get 151 here, but I assume the real stuff is available.) (For non-US readers, this is 96%-pure ethanol, with the other 4% being water.) And unlike methanol, it's relatively non-poisonous. So while you wouldn't have a fuel line feeding directly into your laptop from the airline seat, it'd still be convenient, and you could drink the leftovers....
There have been proposals to make watermarkish tags that Digital Rights Management RIAA/MPAA-compliant digital video equipment would have to obey by refusing to copy. So all you need is a button displaying the "can't photograph this" watermark and the Fritz-compliant equipment wouldn't be able to use your picture. Unlikely to happen in practice, though.
Akamai (and its competitors, AT&T and Speedera) have a business model that says they put lots of caching servers out in the network and sell caching to the web content providers who want to get their content out. By contrast, the original web caching was a pull model - businesses with firewalls and some ISPs use either transparent or explicit-proxy-based caching to cache *incoming* content at their gateways or other concentration points (e.g. cable modem network head ends), and they cover the cost of the caching equipment by reducing their bandwidth needs as well as by giving users service that's perceived to be better. Flooding networks like Usenet are good for non-realtime multicast-like behaviour, and multicast is good for streaming but could also be integrated with caching systems. Back during the Internet boom, there were several companies such as I-Beam that used satellite broadcasting to push content out to caching servers, but alas, Chapter 11 has eaten most of them.
We're going there REAL SOON
Also, while the screen is still small, being able to add a USB disk drive and printer lets you make this into a real computer, not just an accessory device. Somebody else complained that it was only USB1, not USB2, and while it's not blazingly fast, it's more than enough to do real work. On the othe r hand, $300 (plus $200-300 for a USB disk) can get you a much more powerful desktop computer, if you don't care about portability.
See
my other Slashdot posting for discussion and/or speculation on differences.
I did see some stereotypes about the electrical systems in India - much more relevant for the Simputer, which was village oriented, than for this computer, but both silly for something meant to run on batteries (like duuhhh! I had been wondering if it had Palm-like month-long battery life or Wince-like day-short battery life, probably the latter.) There were also some questions about language - while most educated Indians speak English, that's not necessarily the language they want to take notes in or keep their address book in.
The real important design differences are in software. Simputer FAQ. One of the big focuses of the Simputer was the IML information markup language, which is an XMLish application designed to be really convenient for multilingual applications, which in India means multiple alphabetic systems as well (so there's an input system), people with limited literacy, support smartcard media well, etc., and they've got some multilingual text-to-speech Kaii doesn't seem to have anything like that - their language support is English, with optional European , Arabic, and East Asian language support, and the possibility of developing something for Indian languages, and they're running a bunch of non-Indian-developed application suites. (There is Unicode support, at least.) The Simputer also has a built-in softmodem capability, which makes sense for something targeted toward the village computer market, while the Kaii lets you plug in standard cards, which could be modem, memory, ether, wireless, etc.
It's not uncommon for some kinds of dessert from India to be topped with very thin silver foil. (Hmmm... how to describe burfee to people who've never seen it - many of the flavors are sort of like marzipan or vanilla fudge.) Haven't turned blue from the stuff yet.
Virus updates are critical - the other posting by A.C. indicates that he sets up the machines on his net to update them frequently, and in a LAN-based environment, that's usually not a bad policy, though updating at boot time sometimes can interfere with what a developer is doing, or with somebody installing new hardware or software that requires reboots, or whatever. But I'm in a company that has people working out in the field, and while it may be important to get a virus update today, a 10 megabyte data file update on a 56kbps dialup line takes a long time - and if I'm out at a customer site trying to show their CIO how our really cool web site can help them make money, or I'm in the airport trying to send an important email before getting on a plane, I can't wait an hour for the latest virus update to download - that can wait till I'm back at the office.
Microsoft Outlook's integration of calendar, incoming mail, and storage of old mail, all in one big system, makes this particularly critical. The other day I needed to get on a conference call, and had the phone number in my Outlook Calendar, and dialed up 15 minutes before the call to get any relevant emails (and my Palm Pilot battery had run out the other day so I hadn't copied the schedule to there.) Somebody in Marketing had decided to mail 10 MB of glossy viewgraphs to everybody, and while it was downloading, I couldn't access the old messages to find the website for the slides for the call. The older antivirus software used to have similar behaviour - it insisted on doing its updates at boot time, before anything else could run, whether the user needed it right then or not. The newer stuff is often sufficiently well-behaved that it just dogs down the network connection rather than totally preventing you from working, but it's still a problem.
Saying "After the game, [the human] was never worried about losing..." does sound rather like he won, and makes it clear that the author knew the results by the time he wrote it....
Almost every PC-like computer today lets you get at instructions to the video display adapter somehow. As computers move to tighter integration, with low-to-medium-end graphics adapters built into the system chipsets, this may require more cooperation from the operating system because there's nowhere to stick a digital logic probe, but it's still doable.
Almost every video display adapter available today lets you get at the digital version of the image before it's fed to the D/A converters. (Audio probably doesn't.) In the past it was simply a result of the obvious architecture for building the things - using some kind of frame buffer than your equipment can write in. Depending on the system, this may take some complex programming, but it can be done. It's also convenient for some applications, such as print-screen and other screen dumps, so it's good to have. (And OCR is good enough you don't need special OCR fonts any more, just simple conventional ones.) The systems that don't let you do that are largely special-purpose things that don't have general-purpose programming available to the users (e.g. video games.) And
But that may not always remain true - the Digital Rights Management crowd are agitating to get control of system design, because all your bits are belong to them and they want to keep it that way. Imagine if your video board and sound board or their integrated chipset equivalents used encrypted data formats instead of unencrypted - it wouldn't matter that you put a logic probe in the line, because you couldn't read the bits. It wouldn't even require much extra CPU - the RC4 encryption algorithm is strong enough, fast enough, and uses very little memory. Key exchange is requires some CPU, but it would be pretty simple to build a public-private keypair into the adapter, where the public key is retrievable by the CPU but the private key is only accessible to the adapter, and require a setup message (either at boot time, or perhaps on a per-application basis) that creates a session key, pk-encrypts it, and hands it to the adapter.
As a crypto geek, I've got mixed feelings about this - I'd like to be able to write an encrypted voice telephony or video conferencing system that not only couldn't be eavesdropped on, but also couldn't be wiretapped by a virus stealing the data path. But the TCPA / Palladium / Fritz Hollings view of DRM basically requires the system to give root access to any program that wants to use the security, and that's blazingly unsafe. It's not clear to me that you can get away with much less than that and still get real application security, but the stuff's obviously Not Ready For Prime Time even on a requirements basis, much less a design or implementation basis.
Resistance to Deliberate Attacks is often strongly related to scalability. Sure, there are other ways to attack systems - find bugs in the code, or do social engineering attacks like posting Scientology documents and Metallica songs and ratting out any identifiable network operators. But attacks on the network's scalability can be really hard to fix, because they abuse things the system _is_ supposed to do rather than things it isn't. Have you looked at what parts of the network are easy to overload with data volume or small-message quantity or CPU-burning public-key crypto calculations or other critical resources?
.
.
Oh, also, Invisibility is Cool, huh huh, huh huh, Invisible, yeah cool.