Attributed to Albert Einstein, the full quotation sometimes reads “If you can't explain it simply, you don't understand it well enough yourself". He was a smart dude.
The most useful type of documentation is about intent and goals: WHY does the software have these interfaces, what are they supposed to accomplish, what is the overall model of operation, etc. That, I think, is where the best bugs are found. If the model isn't complete, then the code won't be. And that kind of documentation isn't bulky or repetitive--it has a very high return on effort. It's also useful to have documentation that explains particularly clever or complicated implementations.
Less useful is documentation that can easily be inferred from the code. Writing API documentation by hand is tedious and unproductive. If the API and its parameters use well-chosen names there's not a lot to add--and using something like Doxygen makes it easy to include a few hints where they are needed. But Doxygen isn't the place to explain the architecture or system model--that should be thought out first, not stapled into API comments here and there.
Many times I've found bugs by explaining to someone how a system is supposed to work. Doesn't have to be someone who knows much about it, occasionally it's even been my dog. High-level documentation is just another way to exercise that technique, with the advantage that the explanation itself can be reused.
The current DARPA leadership (and to a significant extent, the rest of DoD) is strongly supporting an open source world. This stuff they're doing with Advanced Vehicle Make, it's open. It's being made available for free. To everyone. And in particular to a whole generation of public school students. It's not going to end up as an expensive product that no one uses, or buried forever somewhere inside Lockheed-Martin. The fact that it's notionally about being a better way to build tanks is an excuse, not a motivation, for the people working on it. And this spirit--like that which built the original ARPAnet--is being pushed throughout the organization.
Yes, it's funded by the military. And yes, I'm sure that an omniscient five-year planner like AC could figure out a more optimal way to improve humanity by reallocating a lot of those research dollars to happier pursuits. But it's not like taking away those dollars would automatically put them somewhere more "worthy". And until AC is in charge, well, DARPA is a place where I'm really proud to see my taxpayer dollars going.
I'm sad that Mitch doesn't want to be associated with this effort, but from where I sit, it's doing a lot more good than harm. As opposed, say, to the Chinese Communist Party.
That's a big number. Sounds pretty serious, compared to $38bn in annual revenues.
Except that 3/4 of it is the $12.5bn purchase of Motorola Mobility, an operating business with products, sales, revenue, etc., not to mention a valuable IP portfolio and a big pending tax benefit. If there's one thing that purchase isn't, it's an "R&D Expense".
A total of $3.9bn in as-yet-unsuccessful multi-year R&D projects doesn't look so bad compared to Google' other numbers. What's that, $1-2bn/year? And some of those other projects aren't exactly R&D, like the $1.9bn investment in Atlantic Wind Connection, which is also clearly a business with a plan toward generating revenue. AWC may not succeed with that plan, but it's not R&D.
The Internet Evolution authors are intellectually dishonest frauds. They have mischaracterized their largest numbers in order to make a point that is not supported by evidence.
And, actually, the total of the projects the article lists is $16.9bn, not $16.4bn (making the non-Motorola total $4.4bn, not $3.9bn, which is still completely reasonable), so they apparently can't do simple arithmetic, either.
I've certainly been disappointed by some of Google's apparent mis-handling of R&D projects, and I'd like to believe that they are learning to do better over time, but even if they were having this rate of failed projects, it would be a pretty reasonable price to pay for a self-driving car. Imagine they get trivial revenue as a technology supplier / licensor (say $100/vehicle). In a world market of 50 million vehicles, that's $5bn/year. Not too shabby. And some of those other R&D projects might pan out, too.
By coincidence, this very week I am re-reading E.E. "Doc" Smith's Skylark series. Sure, it's a period piece, when men were men, strong-willed and lantern-jawed and inconceivably brilliant, but it's always a lot of fun and a great nostalgia trip. I'd love to read the original versions sometime, to see how the "science" evolved.
I am equally fond of his Lensmen series, although the first one is little disconnected (as it should be, since it wasn't written for that universe) and "Masters of the Vortex" was amusing but essentially unrelated. I was delighted that my daughter (age 16) loved them, too.
And where else but in Doc Smith (Spacehounds of IPC) can you find a shipwrecked hero who can singlehandedly construct a hydroeelectric power plant, smelting his own copper and steel(!)?
Another favorite of mine is George O. Smith, particularly his The Brain Machine novel and the Venus Equilateral stories. The Brain Machine is a child-prodigy story; if you enjoyed Orson Scott Card's Ender's Game, then The Brain Machine will likely reach you, too.
And I'd wholeheartedly recommend Cordwainer Smith as well. Wish he'd written more.
In the non-Smith category, there's always Michaelmas by Algis Budrys: a great story for those who like Walter Cronkite or self-aware computers that emerge to make the world a better place. His work covered a lot of other topics as well; I liked some more than others, but Michaelmas is my favorite.
I used to have a lot of Science Fiction Book Club anthologies, and they contain some gems (as well as some dross). Anthony Boucher's Treasury of Great Science Fiction and Asimov's Before the Golden Age are two of my favorites.
I have to imagine that not everyone in TSA management is a congenital idiot, and that some of them probably realize how silly the no-liquids rule is. But they also probably realize that they can't just abandon it without being accused of being "soft on crime" and various other silly problems, any of which might lead to the ultimate catastrophe: losing that coveted GS-99 civil service position and lucrative pension.
So what's a non-idiot to do? Simple: adopt a "new technology" that pretty much always blinks green when something gets put in its little hole, and blinks red occasionally just to pretend it actually accomplishes something. Such a device could easily scan a zip-lock bag containing a collection of liquids, and with further improvements could be integrated into the original X-ray apparatus so that it scans bags, too. For historical accuracy, it can claim to use N-rays.
As it happens, we already have liquid scanners just like this, although they are not heavily used. I accidentally tried to carry bottled water through the checkpoint X-ray at DCA 18 months ago, and after the goon squad got over the excitement, they explained that they'd have to dispose of it for me, but that first they would put it through a magic scanner (a suitcase-sized box with a cylindrical cavity and some buttons and lights) to be sure it was safe. To pass the time while being lectured, I asked if they would do something different to dispose of it were the scanner to say it was dangerous, and the responding goon assured me (with no trace of irony) that no, it all went in the same bin.
I have probably taken 300 flights since the "liquid explosive" scare. Since 2008, when I realized that the whole thing was ridiculous, I have never put my liquids into a quart-size baggie, nor have I taken them out for individual passage through the X-ray. In that time, I have been forced to give up my toothpaste in furtherance of the nation's security precisely twice. It's a small price to pay--a few bucks worth of toothpaste and a pious lecture about how dangerous the toothpaste might be, in exchange for significantly less hassle at the checkpoint. I have to imagine that the reason my approach works is that they really don't try very hard to find contraband of this sort. If I were a proper activist, I suppose I'd be willing to wear a "Toothpaste Smuggler" button when I fly, but I lack the courage.
Maybe they'll figure out that they can do this for other stuff, too. I must say that the full-body scanners are a major step backwards, since I can't even keep my passport and ticket in my pockets any more.
It seems possible that the Defense Department is researching this technology not just for economic savings. If technology like this existed, it could be used, for example, to remove a nifty new imaging sensor or radar component from someone else's satellite, or maybe to add a device that connects to that satellite's internal data bus (operation Ivy Bells, anyone?) and taps or modifies the data.
Most satellites have essentially no situational awareness, because being taken apart by little aliens in shiny green spacesuits (or by advanced remanufacturing robots) is just not part of the threat model. So it tends to be very hard for ground control to distinguish between a random equipment failure and a failure caused by deliberate modification of the spacecraft.
This mission probably isn't what the X-37 is for, since it's a low earth orbit vehicle, not geosynchronous.
If you are ever involved in divorce litigation, there is nothing nicer than being able to say "I have no such records" when your deranged spouse's even more deranged bottom-feeding scumbag sends you a discovery request listing 141 categories of documents and demands copies of all paper or electronic records in those categories.
In normal litigation this isn't as much of an issue, because the attorneys are usually able to negotiate a happy medium in which they agree not to issue nuclear-tipped discovery requests and focus on what's actually relevant to the action. In divorce, though, all bets are off, because you're paying both attorneys and an evil one can happily run through all your money (a total with which he is intimately familiar, again unlike normal litigation) by harassing you--your own attorney's fees are just handy collateral damage. Mutual destruction is by far the most profitable outcome for such sharks, since they tend not to get a lot of repeat business. (It's not just divorce, of course: if you're targeted in a SLAPP suit, or, like poor George, have otherwise angered a large corporation, you'll have the same troubles.)
Keep only what you absolutely must. The 7-year deadline is for tax returns, everything else is much more ephemeral. Search for "records retention" to find a variety of helpful guidelines.
After 50-odd years on the planet, I've found that hardly any ordinary paperwork I've kept has ever been useful. Sure, a couple months of bills or bank statements can come in handy, but even a year is more than I have ever needed (as long as I kept track of big items, like the costs of building an addition on the house).
This is especially true of old e-mail. When Cardinal Richelieu said "Give me six lines written by the most honest of men, and in them I will find something with which to hang him", that's what he was talking of. Prescient, he was. Anticipated the Internet and all that it entails.
This looks like a stupid publicity stunt designed by some inexperienced publicity-seekers in collaboration with their organization's addle-pated and self-serving PR office.
I mean, what's not to like?
Err... radiation. If we wanted to know how a smartphone reacted to the LEO radiation environment, we could test that on the ground, and it would be a darn sight cheaper. But we don't need to do that, because we already KNOW that radiation will affect it badly, and that it doesn't include any mechanism to recover from latchups.
Heat transfer in vacuum. Maybe if it's just ticking over and not doing anything, a phone can survive in a vacuum--but my Droid gets plenty hot in air when it's doing anything, so heat dissipation is clearly going to be an issue. Sure, we can add heat pipes and radiators, and try to deal with it by conduction, but hey--rather than adding all that crap, why not avoid the problem to begin with by designing something sensible?
Wasted function. The phone is full of stuff that is completely useless in space: the lovely touchscreen interface (unless we're expecting vacuum-breathing aliens to be able to understand our icons, yes?), audio input and output (didn't anyone remind them that in space, no one can hear you scream?), the cellphone radio (which, if nothing else, would violate all sorts of national radio spectrum laws), etc. Those functions consume (that is, waste) watts of electrical power and add complexity (that is, unreliability). An engineer would have to be daft to design a system like this, when every gram costs so much to get into orbit.
Lots of COTS-grade hardware goes into space these days, and there is plenty of work being done to explore new (and less gold-plated) approaches to redundancy and reliability. But it's designed by engineers who actually know something and have actually thought about the issues.
Although the press release clearly describes the work of buffoons, it is POSSIBLE that the project itself isn't quite so silly as it looks. But based on what's been published, "sensible" doesn't seem to be in the cards.
And all that said, I certainly think government interference in software development of this sort is highly plausible, both for open and closed source.
But mostly it's the Chinese government I'm thinking of. How many Chinese nationals work at Microsoft? How many actually work for the PLA? None? Are you sure?
Could be true, but there's a lot that rings false.
Why doesn't Perry point out the code, or even just identify it, or outline what it did?
Why did he wait for his alleged NDA to expire, rather than pointing it out anonymously? A bug report saying "this is weird" almost certainly wouldn't have any provable connection to him.
In general, well-understood algorithms like those used by IPSec don't leak key data. A bad crypto primitive implementation could do so easily enough, but IPSec doesn't use its own implementations of crypto primitives, does it?
And if it doesn't, then code which accesses key data in any way other than as an opaque object should stick out like a sore thumb.
I eagerly await analysis by someone more familiar with the IPSec code. Shouldn't be hard to find.
I've seen these inexpensive little machines, and I think they're too persnickety for real use: sure, you can get decent models out of them sometimes, but it takes skill and luck and persistence. But their bigger buddies can make some really nice stuff: solid, clean surface finish, etc. I'm just waiting for someone to start a chain of 3D printing shops where you can bring your CAD design in the morning and come back in the afternoon to pick up a copy--just like the copy shops that started springing up in the 1970's after photocopiers got cheap enough.
What he built is a proof of concept for a BATTERY. Not a telegraph.
He's an artist, not an engineer. Rigor is clearly not his strong point. But it's an interesting idea. And making pig iron--even a little bit--in an afternoon is a pretty good accomplishment. Copper is a lot easier, since it smelts easily and has a much lower melting point.
And it's not implausible: after all, there is evidence that better batteries were known in ancient times, and he's certainly right that a Voltaic pile can be constructed from primitive materials. He could have smelted some zinc, too.
But as others have pointed out, miles of wire is the real challenge. Could that be done under the circumstances? Sure: copper smelting was known in prehistory, and drawing copper into wires just requires hardened clay dies. But it would be a LOT of work. You'd probably have to be an inspiring leader with oodles of acolytes to carry out the grunt work. You'd need some insulated wire for the coils, but that's just an application of fabric, and not too hard.
A better idea might have been an optical telegraph, like those that were all over Europe in the early 19th century. Make lenses out of ice in clay molds and use it only in the winter, if you don't want to make glass and grind it.
Don't build 'em yourself, but for sure, spend the money you would have spent on on-site service and warranty options on a good supply of spares. You can just roll in a new machine instantly, set it up with a standard image, and have your user up and running again. Worry about repair/replacement when it's back in the shop, and use repaired machines for non-critical functions.
Schemes like this are (as others have observed) pretty common, and don't address the real problem: what we "desperately need" is a trustworthy way of knowing that an automated system is acting in accord with its owner's intent. Alas, that does not seem to be on the horizon.
I mean, suppose my computer has "secure boot" and "unspoofable identity" and "remote attestation". That's great, if my goal is to prove to the secure server at the other end of the connection that I am running various specific (albeit a priori bug-infested versions) of Windows, drivers, browsers, JVMs, etc. But that's a silly goal, because my adversary is just going to take advantage of it, by running malware on my system that looks like it's acting on my behalf (after all, it has ready access to my unspoofable identity) but is actually transferring the contents of my bank account to the Netherlands Antilles without my knowledge.
Not to mention the general uselessness of "remote attestation" that a TPM provides: it may be able to attest to your configuration (modulo flaws in your gigabytes of software that enable attestation to be subverted or bypassed), but how on earth is the remote end going to make a meaningful decision based on the identity of hundreds or thousands of components that are attested to? Sure, it can reject known bad (flawed) components, but it's preposterous to imagine that you can know what all the bad components might be. Remote attestation is a plausible way of validating that a machine's configuration is the same as it was when it left a corporate IT department, but for making decisions about arbitrary machines in the hands of arbitrary consumers, it's useless.
And as for this specific scheme, come on: it might be a way to identify a flash device reliably if you have the hardware in hand, but, as described, it's done in software. That's right, software, which can be made to emulate any particular configuration of bit errors it desires, without there necessarily even being a physical flash device in the picture. Yes, for limited-resource embedded systems, and environments where access timing can be inferred with high accuracy, there are tricks one can use to make such attacks difficult, but for general-purpose PCs connecting over unreliable high-latency networks? Nope... not without mountains of false alarms.
Make no mistake: trustworthy computing is a hard problem. Unique IDs are fun to research, but not closely related to the solution.
You present a false dichotomy: millions of well-designed, effective, and efficient web pages exist today using the basic facilities of HTML and CSS. A good artist can create beauty within the constraints of his medium, rather than just whining about how the medium isn't rich enough.
What I'm grumpy about is second-raters who foist their artistic "vision" on me without regard to my needs as a consumer. Because what that means is that even though I might believe there is value in what they say, how they choose to say it makes it unpleasant for me to find that value. They are deprived of me as an audience, and I of their wisdom. Hardly the desired outcome for either party. And this new font facility is one more tool that can easily be misused to that end.
This sounds like just what I need: more 100KB unanticipated downloads while I'm stuck at the end of an unreliable slow cellular modem connection. What ever happened to using the web to deliver information instead of "art"?
At least browsers can ignore the new font specifications and still display something useful, unlike what happens with high-fashion websites implemented entirely in Flash. As we know, "Flash home page" == "Hold on to your wallet".
Will it be the same for fancy fonts, too?
This is sorta like ClearPlay--software that automatically excises the "naughty bits" from commercial DVDs (e.g., turning R-rated flicks into G). There was a lawsuit, of course, but they seem to still be in business, so they must have won in some sense. As I recall the argument was that the software was NOT a derivative work because it was distributed completely separately and contained none of the original work. It only knows about the time (location) of the naughty bits so it could skip past them, and was thus no different, except for being automated, from a printed list that would tell the viewer when to hit fast forward.
On the other hand, it seems that some services and software which involved copying the DVD but leaving the naughty bits out didn't succeed--even though the customers could prove that they owned the original DVDs.
This technology seems like it could be considered a wrapper in the same sense as ClearPlay--it doesn't have to contain ANY of the original software, just observations about it.
Tools like this have been around for ages, although they are usually called "GUI test frameworks" or "automation assistants". Such tools provide a way of scripting interactions with an existing GUI. However, they really only focus on mimicking pre-recorded user interactions--it seems like it would be quite time-consuming and fragile to reverse-engineer an arbitrary program's dialogue boxes in a robust way that would allow control to be significantly enhanced.
Also, on Windows, at least, there are tools that enhance the operation of dialogue boxes (for example, adding history and options to the File Open dialog). Those tools work at a more abstract level than snagging pixels, which is a lot more efficient--but that means they are ineffective on applications that have already customized those dialogues.
It seems like the fundamental non-breakthrough here is that the application actually must already include the functionality that you want to express in your modified UI--otherwise, you can modify the UI all you want, but the app will only do what it's capable of. So if you want it to display a bunch of different renderings in sub-windows automatically (to use their example), it had better be capable of that display already.
Spoken like a professor. Well-said! but I'm sure you know that there's law and there's reality, and sometimes they don't quite match up.
Yes, the law requires "reduction to practice" (just like it requires "utility") but that doesn't mean that the examiner has a clue of how to assess that. Since the inventor doesn't have to provide any proof of reduction to practice or utility, in practice, the examiner will accept almost any kind of assertion about those topics.
The larger problem is that many modern inventions are far too complex to permit an unambiguous assessment of utility or enablement. It's not obviously half-baked inventions that are the problem, it's complex computer-based systems.
Far too many issued patents simply do not provide sufficient description for one skilled in the art to duplicate the invention. Often, the inventor didn't know how to do it, either. That's where phrases like "preferably using artificial intelligence means" come in so handy.
This is all part of the "gaming the system" toolkit that companies like IV have perfected.
If you think it's hard to get a patent invalidated on prior art grounds, you should try doing it for utility or enablement.
No doubt those applications had merit... but what is the benefit to society? How did writing the applications provide incentive for the inventive process? What useful products will result from the protection granted by those patents, if issued, and who will invest the resources to turn those ideas into products? And if the patents end up (as so many do) being used to block others from pursuing products that are in any way potentially infringing, exactly how does that "promote the progress of science and useful arts" (to quote the Constitution).
Interestingly, even you imply that some of IV's applications have little merit, and you're paid by them. What might a disinterested party say?
I haven't crossed paths (yet) with IV, but I do believe that they are fundamentally evil. They're a natural consequence of bad laws and legal practice.
They like to describe their model as "Hey, Mr. Inventor, we'll buy your patents, or help you patent your stuff, and even pay you to work on it". This approach is appealing in principle, and to be sure, it does put some money in the hands of those inventors.
The problem is that what the Patent Office treats as an "invention" is almost completely unrelated to what constitutes an "invention" in the real world of commerce. A patent-office invention is just an idea. It doesn't have to be manufacturable, it doesn't have to be a viable product, it even doesn't have to work. It just has to be interesting and complicated enough that a relatively unskilled patent examiner cannot find a good reason to deny a patent. And since the examiner has only limited time (small number of hours) to examine each invention, and he's goaled on patents issued, not denied, well, pretty much anything can be patented.
(When I refer to examiners as "relatively unskilled", I don't mean that they're dummies--but rather, that they are generally less practiced in the art of patent management than the high-powered patent attorneys who craft the applications they're reading. Indeed, an awful lot of good examiners end up turning into those high-paid attorneys, after taking a few yeas of "training" at the Patent Office.)
A real-world invention, on the other hand, has to be something that makes money. It has to work. It has to be manufacturable. It has to be sufficiently well-developed as a product that people want to buy it. And getting to there from the idea stage requires real resources: money to pay engineers, money to advertise and market, etc. And ultimately, of course, a real-world invention has to make a profit: the costs ought not to exceed the revenues.
So what IV is mostly doing is creating or buying patent-office inventions and using those to extract money from entrepreneurs and companies that are trying to create real-world inventions. They're a tax on the real resources that are required to turn an invention into a product, and in that role, they far more often prevent useful products from reaching the market, by increasing their development costs too much for a profitable result. Sure, there are a few poster-child inventions where IV has invested their own resources, or where someone else's profit is feasible even at IV's royalty rates, but those cases are rare--and exist for press releases.
IV's costs are minimal, because they mostly just get smart people together to brainstorm. The ideas are copied down by patent attorneys, turned into applications by IV's legal team, and pushed through the Patent Office. Once issued, a patent is presumptively valid, and fighting it is a crapshoot. So if IV comes to you, you either license or fold, because they have more and better lawyers. They generally do nothing to turn an IV patent into a real-world invention, and they bear none of those real costs.
It is a brilliant business model. At minimal costs, IV exploits a fundamental and likely unfixable problem with the patent process, namely that most modern inventions are too sophisticated, complex, and interrelated for the process to address--yet the government guarantees a monopoly, so you have to play within the system, or be subject to patent litigation that is completely unpredictable (except for its multi-million dollar cost). The patent "reform" proposals floating around just nibble at the edges; the system itself is fundamentally broken.
I tackled this problem with an encrypted (dm-crypt) RAID-1 server equipped with easy-removal SATA cages.
I have a four-drive RAID-1 configuration (that is, every bit gets written to four different drives).
Every two weeks or so, I run a script that dismounts the file system briefly (to render the on-disk state consistent), and pop out two of the RAID drives, leaving two working.
I then mail the two removed drives to my two friends who hold on to my off-site backups (priority mail flat rate box $4.95) and they mail back the drives I sent them previously (I include prepaid labels).
In the meantime, while I'm waiting for my friends to mail drives back, I take the two drives I'd previously gotten back in the mail and put them back in the server. The server recognizes them as out of date and starts rebuilding, and a day or so later, I'm back to having four identical drives.
Lather, rinse, repeat.
There are usually four drives in the server (the two permanent ones, plus the two that will make the next backup), and four drives "out" (two being sent to the undisclosed locations, and two being sent back). So in the event of subtle corruption, I have two complete redundant backup sets: one two weeks old, and one four weeks old.
This works for me because my storage needs are modest enough that a single 1-TB drive holds them comfortably. Next server I build like this will be 2-TB, and that will hold me even longer. Astonishingly, drive capacity is growing faster than my ability to consume it (I used to have multiple boxes of external drives).
It's a lot of drives: eight drives doing the work of one. But drives are cheap: the current sweet spot seems to be $130 for 1.5TB, or about $1000 for the disks and another $500 or so for the rest of the server (those SATA cages are surprisingly expensive).
You could use fewer drives: maybe only single drives as backups, rather than pairs in different locations, and maybe just wait for drives to return from the field, rather than having a shadow set always there and spinning. But the extras are pretty cheap as cheap insurance goes. And, of course, you don't have to mail them (and actually I hand-deliver one of each pair, because one friend is local, but it's comforting to know that my other shadow is 2500 miles away).
If I wanted, I could just pop in an extra drive (or dissimilar pair) for a day and create archival snapshots to store permanently off-site but I haven't really had that need.
I haven't lost a drive in the mail yet, and the rebuild process is a pretty good proof that the drives are working.
I made a previous version of this idea with external USB disks, but SATA drives are MUCH more convenient (and cheaper to mail). All those USB enclosures and their inefficient little power supplies and twisty cables made for a very clumsy (and toasty) configuration. Now, I have just a single full-tower chassis and the cooling is efficient and built in.
This solution is entirely based on commodity parts. Anything that breaks, I can replace with something new that's as good or better. I deliberately made my RAID pairs from dissimilar drives (Seagate and WD), to stave off concurrent failure modes, and even sourced my Seagates from two vendors so I got two made in Thailand and two in China (I think). I used to do tape backup, and man, was that a pain: drives go obsolete, formats disappear, media always gets more expensive, and it's slow and linear. Of course, if I had 100 GB of enterprise data to protect, I might be more interested in a tape-based solution--but it would be a lot more expensive. Disk is clearly where the cost-effectiveness is being pushed most heavily.
Encryption is essential. It would be absurd to be mailing around cleartext drives. But a strong password means that the whole-disk encryption is effective against any plausible attack. I keep the password well-protected and never change it, although it would be easy enough to do that with dm-crypt.
Remember the dreaded Trusted Platform Module (TPM)? Evil enforcer of unbreakable DRM and other nastiness? This is one of the rare cases where TPM-managed encryption works to good effect. If the key is hidden inside the TPM (and if you've avoided making any TPM backups and such), just give the wrong TPM PIN several times in a row and the TPM will become unrecoverable. After all, you're probably pretty nervous under all this coercion, it's natural to make mistakes. The adversary can clone your disk drive without difficulty, but he can't easily clone a hardware-secured TPM--and once it's zeroized its internal keys, they're gone, baby, gone.
That's assuming, of course, that you believe the TPM is secure and doesn't have back doors. It might, but letting THAT secret out for a boring child pr0n case seems unlikely. And the hardware security of some TPMs does look pretty darn good. I mean, after around 20 years of getting hacked by cable-TV pirates, the semiconductor companies have learned a thing or two.
Tight-beam high-bandwidth satellite radio links are great for military use, where it's unlikely that you can depend on existing communication infrastructure.
However, for most commercial uses, it's just silly: even if it were just being used as backhaul for base stations, the requirement for directional antennas alone means that it's way more expensive and less reliable than conventional alternatives, and bandwidth to satellites can't help but be vastly more expensive than terrestrial connections, either wired or wireless. Imagining direct connections from laptops to satellites is even sillier.
There are places where this might actually make sense commercially, like cruise ships and such, but there just aren't that many other places in the middle of nowhere that have enough well-heeled customers to make satellite links a worthwhile proposition.
And, of course, there's latency. Absent a repeal of the lightspeed limit (an action favored by the outgoing Cheney administration, but unlikely to pass before November), going up to geosynchronous orbit and back down will be much worse than going to the other side of the world by fiber. Those folks who have DirecNet experience this today, and it is physically impossible for it to get any better.
Attributed to Albert Einstein, the full quotation sometimes reads “If you can't explain it simply, you don't understand it well enough yourself". He was a smart dude.
The most useful type of documentation is about intent and goals: WHY does the software have these interfaces, what are they supposed to accomplish, what is the overall model of operation, etc. That, I think, is where the best bugs are found. If the model isn't complete, then the code won't be. And that kind of documentation isn't bulky or repetitive--it has a very high return on effort. It's also useful to have documentation that explains particularly clever or complicated implementations.
Less useful is documentation that can easily be inferred from the code. Writing API documentation by hand is tedious and unproductive. If the API and its parameters use well-chosen names there's not a lot to add--and using something like Doxygen makes it easy to include a few hints where they are needed. But Doxygen isn't the place to explain the architecture or system model--that should be thought out first, not stapled into API comments here and there.
Many times I've found bugs by explaining to someone how a system is supposed to work. Doesn't have to be someone who knows much about it, occasionally it's even been my dog. High-level documentation is just another way to exercise that technique, with the advantage that the explanation itself can be reused.
The current DARPA leadership (and to a significant extent, the rest of DoD) is strongly supporting an open source world. This stuff they're doing with Advanced Vehicle Make, it's open. It's being made available for free. To everyone. And in particular to a whole generation of public school students. It's not going to end up as an expensive product that no one uses, or buried forever somewhere inside Lockheed-Martin. The fact that it's notionally about being a better way to build tanks is an excuse, not a motivation, for the people working on it. And this spirit--like that which built the original ARPAnet--is being pushed throughout the organization.
Yes, it's funded by the military. And yes, I'm sure that an omniscient five-year planner like AC could figure out a more optimal way to improve humanity by reallocating a lot of those research dollars to happier pursuits. But it's not like taking away those dollars would automatically put them somewhere more "worthy". And until AC is in charge, well, DARPA is a place where I'm really proud to see my taxpayer dollars going.
I'm sad that Mitch doesn't want to be associated with this effort, but from where I sit, it's doing a lot more good than harm. As opposed, say, to the Chinese Communist Party.
That's a big number. Sounds pretty serious, compared to $38bn in annual revenues.
Except that 3/4 of it is the $12.5bn purchase of Motorola Mobility, an operating business with products, sales, revenue, etc., not to mention a valuable IP portfolio and a big pending tax benefit. If there's one thing that purchase isn't, it's an "R&D Expense".
A total of $3.9bn in as-yet-unsuccessful multi-year R&D projects doesn't look so bad compared to Google' other numbers. What's that, $1-2bn/year? And some of those other projects aren't exactly R&D, like the $1.9bn investment in Atlantic Wind Connection, which is also clearly a business with a plan toward generating revenue. AWC may not succeed with that plan, but it's not R&D.
The Internet Evolution authors are intellectually dishonest frauds. They have mischaracterized their largest numbers in order to make a point that is not supported by evidence.
And, actually, the total of the projects the article lists is $16.9bn, not $16.4bn (making the non-Motorola total $4.4bn, not $3.9bn, which is still completely reasonable), so they apparently can't do simple arithmetic, either.
I've certainly been disappointed by some of Google's apparent mis-handling of R&D projects, and I'd like to believe that they are learning to do better over time, but even if they were having this rate of failed projects, it would be a pretty reasonable price to pay for a self-driving car. Imagine they get trivial revenue as a technology supplier / licensor (say $100/vehicle). In a world market of 50 million vehicles, that's $5bn/year. Not too shabby. And some of those other R&D projects might pan out, too.
By coincidence, this very week I am re-reading E.E. "Doc" Smith's Skylark series. Sure, it's a period piece, when men were men, strong-willed and lantern-jawed and inconceivably brilliant, but it's always a lot of fun and a great nostalgia trip. I'd love to read the original versions sometime, to see how the "science" evolved.
I am equally fond of his Lensmen series, although the first one is little disconnected (as it should be, since it wasn't written for that universe) and "Masters of the Vortex" was amusing but essentially unrelated. I was delighted that my daughter (age 16) loved them, too.
And where else but in Doc Smith (Spacehounds of IPC) can you find a shipwrecked hero who can singlehandedly construct a hydroeelectric power plant, smelting his own copper and steel(!)?
Another favorite of mine is George O. Smith, particularly his The Brain Machine novel and the Venus Equilateral stories. The Brain Machine is a child-prodigy story; if you enjoyed Orson Scott Card's Ender's Game, then The Brain Machine will likely reach you, too.
And I'd wholeheartedly recommend Cordwainer Smith as well. Wish he'd written more.
In the non-Smith category, there's always Michaelmas by Algis Budrys: a great story for those who like Walter Cronkite or self-aware computers that emerge to make the world a better place. His work covered a lot of other topics as well; I liked some more than others, but Michaelmas is my favorite.
I used to have a lot of Science Fiction Book Club anthologies, and they contain some gems (as well as some dross). Anthony Boucher's Treasury of Great Science Fiction and Asimov's Before the Golden Age are two of my favorites.
I have to imagine that not everyone in TSA management is a congenital idiot, and that some of them probably realize how silly the no-liquids rule is. But they also probably realize that they can't just abandon it without being accused of being "soft on crime" and various other silly problems, any of which might lead to the ultimate catastrophe: losing that coveted GS-99 civil service position and lucrative pension.
So what's a non-idiot to do? Simple: adopt a "new technology" that pretty much always blinks green when something gets put in its little hole, and blinks red occasionally just to pretend it actually accomplishes something. Such a device could easily scan a zip-lock bag containing a collection of liquids, and with further improvements could be integrated into the original X-ray apparatus so that it scans bags, too. For historical accuracy, it can claim to use N-rays.
As it happens, we already have liquid scanners just like this, although they are not heavily used. I accidentally tried to carry bottled water through the checkpoint X-ray at DCA 18 months ago, and after the goon squad got over the excitement, they explained that they'd have to dispose of it for me, but that first they would put it through a magic scanner (a suitcase-sized box with a cylindrical cavity and some buttons and lights) to be sure it was safe. To pass the time while being lectured, I asked if they would do something different to dispose of it were the scanner to say it was dangerous, and the responding goon assured me (with no trace of irony) that no, it all went in the same bin.
I have probably taken 300 flights since the "liquid explosive" scare. Since 2008, when I realized that the whole thing was ridiculous, I have never put my liquids into a quart-size baggie, nor have I taken them out for individual passage through the X-ray. In that time, I have been forced to give up my toothpaste in furtherance of the nation's security precisely twice. It's a small price to pay--a few bucks worth of toothpaste and a pious lecture about how dangerous the toothpaste might be, in exchange for significantly less hassle at the checkpoint. I have to imagine that the reason my approach works is that they really don't try very hard to find contraband of this sort. If I were a proper activist, I suppose I'd be willing to wear a "Toothpaste Smuggler" button when I fly, but I lack the courage.
Maybe they'll figure out that they can do this for other stuff, too. I must say that the full-body scanners are a major step backwards, since I can't even keep my passport and ticket in my pockets any more.
Most satellites have essentially no situational awareness, because being taken apart by little aliens in shiny green spacesuits (or by advanced remanufacturing robots) is just not part of the threat model. So it tends to be very hard for ground control to distinguish between a random equipment failure and a failure caused by deliberate modification of the spacecraft.
This mission probably isn't what the X-37 is for, since it's a low earth orbit vehicle, not geosynchronous.
If you are ever involved in divorce litigation, there is nothing nicer than being able to say "I have no such records" when your deranged spouse's even more deranged bottom-feeding scumbag sends you a discovery request listing 141 categories of documents and demands copies of all paper or electronic records in those categories.
In normal litigation this isn't as much of an issue, because the attorneys are usually able to negotiate a happy medium in which they agree not to issue nuclear-tipped discovery requests and focus on what's actually relevant to the action. In divorce, though, all bets are off, because you're paying both attorneys and an evil one can happily run through all your money (a total with which he is intimately familiar, again unlike normal litigation) by harassing you--your own attorney's fees are just handy collateral damage. Mutual destruction is by far the most profitable outcome for such sharks, since they tend not to get a lot of repeat business. (It's not just divorce, of course: if you're targeted in a SLAPP suit, or, like poor George, have otherwise angered a large corporation, you'll have the same troubles.)
Keep only what you absolutely must. The 7-year deadline is for tax returns, everything else is much more ephemeral. Search for "records retention" to find a variety of helpful guidelines.
After 50-odd years on the planet, I've found that hardly any ordinary paperwork I've kept has ever been useful. Sure, a couple months of bills or bank statements can come in handy, but even a year is more than I have ever needed (as long as I kept track of big items, like the costs of building an addition on the house).
This is especially true of old e-mail. When Cardinal Richelieu said "Give me six lines written by the most honest of men, and in them I will find something with which to hang him", that's what he was talking of. Prescient, he was. Anticipated the Internet and all that it entails.
This looks like a stupid publicity stunt designed by some inexperienced publicity-seekers in collaboration with their organization's addle-pated and self-serving PR office.
I mean, what's not to like?
Err... radiation. If we wanted to know how a smartphone reacted to the LEO radiation environment, we could test that on the ground, and it would be a darn sight cheaper. But we don't need to do that, because we already KNOW that radiation will affect it badly, and that it doesn't include any mechanism to recover from latchups.
Heat transfer in vacuum. Maybe if it's just ticking over and not doing anything, a phone can survive in a vacuum--but my Droid gets plenty hot in air when it's doing anything, so heat dissipation is clearly going to be an issue. Sure, we can add heat pipes and radiators, and try to deal with it by conduction, but hey--rather than adding all that crap, why not avoid the problem to begin with by designing something sensible?
Wasted function. The phone is full of stuff that is completely useless in space: the lovely touchscreen interface (unless we're expecting vacuum-breathing aliens to be able to understand our icons, yes?), audio input and output (didn't anyone remind them that in space, no one can hear you scream?), the cellphone radio (which, if nothing else, would violate all sorts of national radio spectrum laws), etc. Those functions consume (that is, waste) watts of electrical power and add complexity (that is, unreliability). An engineer would have to be daft to design a system like this, when every gram costs so much to get into orbit.
Lots of COTS-grade hardware goes into space these days, and there is plenty of work being done to explore new (and less gold-plated) approaches to redundancy and reliability. But it's designed by engineers who actually know something and have actually thought about the issues.
Although the press release clearly describes the work of buffoons, it is POSSIBLE that the project itself isn't quite so silly as it looks. But based on what's been published, "sensible" doesn't seem to be in the cards.
And all that said, I certainly think government interference in software development of this sort is highly plausible, both for open and closed source.
But mostly it's the Chinese government I'm thinking of. How many Chinese nationals work at Microsoft? How many actually work for the PLA? None? Are you sure?
Could be true, but there's a lot that rings false.
Why doesn't Perry point out the code, or even just identify it, or outline what it did?
Why did he wait for his alleged NDA to expire, rather than pointing it out anonymously? A bug report saying "this is weird" almost certainly wouldn't have any provable connection to him.
In general, well-understood algorithms like those used by IPSec don't leak key data. A bad crypto primitive implementation could do so easily enough, but IPSec doesn't use its own implementations of crypto primitives, does it?
And if it doesn't, then code which accesses key data in any way other than as an opaque object should stick out like a sore thumb.
I eagerly await analysis by someone more familiar with the IPSec code. Shouldn't be hard to find.
Public Knowledge just did a nice report about the coming collision of intellectual property expectations and 3D printing/CNC: It Will Be Awesome If They Don't Screw It Up .
I've seen these inexpensive little machines, and I think they're too persnickety for real use: sure, you can get decent models out of them sometimes, but it takes skill and luck and persistence. But their bigger buddies can make some really nice stuff: solid, clean surface finish, etc. I'm just waiting for someone to start a chain of 3D printing shops where you can bring your CAD design in the morning and come back in the afternoon to pick up a copy--just like the copy shops that started springing up in the 1970's after photocopiers got cheap enough.
What he built is a proof of concept for a BATTERY. Not a telegraph.
He's an artist, not an engineer. Rigor is clearly not his strong point. But it's an interesting idea. And making pig iron--even a little bit--in an afternoon is a pretty good accomplishment. Copper is a lot easier, since it smelts easily and has a much lower melting point.
And it's not implausible: after all, there is evidence that better batteries were known in ancient times, and he's certainly right that a Voltaic pile can be constructed from primitive materials. He could have smelted some zinc, too.
But as others have pointed out, miles of wire is the real challenge. Could that be done under the circumstances? Sure: copper smelting was known in prehistory, and drawing copper into wires just requires hardened clay dies. But it would be a LOT of work. You'd probably have to be an inspiring leader with oodles of acolytes to carry out the grunt work. You'd need some insulated wire for the coils, but that's just an application of fabric, and not too hard.
A better idea might have been an optical telegraph, like those that were all over Europe in the early 19th century. Make lenses out of ice in clay molds and use it only in the winter, if you don't want to make glass and grind it.
Don't build 'em yourself, but for sure, spend the money you would have spent on on-site service and warranty options on a good supply of spares. You can just roll in a new machine instantly, set it up with a standard image, and have your user up and running again. Worry about repair/replacement when it's back in the shop, and use repaired machines for non-critical functions.
With copper capers. A classic: http://www.youtube.com/watch?v=cVkZZsS-66c
Schemes like this are (as others have observed) pretty common, and don't address the real problem: what we "desperately need" is a trustworthy way of knowing that an automated system is acting in accord with its owner's intent. Alas, that does not seem to be on the horizon.
I mean, suppose my computer has "secure boot" and "unspoofable identity" and "remote attestation". That's great, if my goal is to prove to the secure server at the other end of the connection that I am running various specific (albeit a priori bug-infested versions) of Windows, drivers, browsers, JVMs, etc. But that's a silly goal, because my adversary is just going to take advantage of it, by running malware on my system that looks like it's acting on my behalf (after all, it has ready access to my unspoofable identity) but is actually transferring the contents of my bank account to the Netherlands Antilles without my knowledge.
Not to mention the general uselessness of "remote attestation" that a TPM provides: it may be able to attest to your configuration (modulo flaws in your gigabytes of software that enable attestation to be subverted or bypassed), but how on earth is the remote end going to make a meaningful decision based on the identity of hundreds or thousands of components that are attested to? Sure, it can reject known bad (flawed) components, but it's preposterous to imagine that you can know what all the bad components might be. Remote attestation is a plausible way of validating that a machine's configuration is the same as it was when it left a corporate IT department, but for making decisions about arbitrary machines in the hands of arbitrary consumers, it's useless.
And as for this specific scheme, come on: it might be a way to identify a flash device reliably if you have the hardware in hand, but, as described, it's done in software. That's right, software, which can be made to emulate any particular configuration of bit errors it desires, without there necessarily even being a physical flash device in the picture. Yes, for limited-resource embedded systems, and environments where access timing can be inferred with high accuracy, there are tricks one can use to make such attacks difficult, but for general-purpose PCs connecting over unreliable high-latency networks? Nope... not without mountains of false alarms.
Make no mistake: trustworthy computing is a hard problem. Unique IDs are fun to research, but not closely related to the solution.
You present a false dichotomy: millions of well-designed, effective, and efficient web pages exist today using the basic facilities of HTML and CSS. A good artist can create beauty within the constraints of his medium, rather than just whining about how the medium isn't rich enough.
What I'm grumpy about is second-raters who foist their artistic "vision" on me without regard to my needs as a consumer. Because what that means is that even though I might believe there is value in what they say, how they choose to say it makes it unpleasant for me to find that value. They are deprived of me as an audience, and I of their wisdom. Hardly the desired outcome for either party. And this new font facility is one more tool that can easily be misused to that end.
This sounds like just what I need: more 100KB unanticipated downloads while I'm stuck at the end of an unreliable slow cellular modem connection. What ever happened to using the web to deliver information instead of "art"? At least browsers can ignore the new font specifications and still display something useful, unlike what happens with high-fashion websites implemented entirely in Flash. As we know, "Flash home page" == "Hold on to your wallet". Will it be the same for fancy fonts, too?
This is sorta like ClearPlay--software that automatically excises the "naughty bits" from commercial DVDs (e.g., turning R-rated flicks into G). There was a lawsuit, of course, but they seem to still be in business, so they must have won in some sense. As I recall the argument was that the software was NOT a derivative work because it was distributed completely separately and contained none of the original work. It only knows about the time (location) of the naughty bits so it could skip past them, and was thus no different, except for being automated, from a printed list that would tell the viewer when to hit fast forward.
On the other hand, it seems that some services and software which involved copying the DVD but leaving the naughty bits out didn't succeed--even though the customers could prove that they owned the original DVDs.
This technology seems like it could be considered a wrapper in the same sense as ClearPlay--it doesn't have to contain ANY of the original software, just observations about it.
Tools like this have been around for ages, although they are usually called "GUI test frameworks" or "automation assistants". Such tools provide a way of scripting interactions with an existing GUI. However, they really only focus on mimicking pre-recorded user interactions--it seems like it would be quite time-consuming and fragile to reverse-engineer an arbitrary program's dialogue boxes in a robust way that would allow control to be significantly enhanced.
Also, on Windows, at least, there are tools that enhance the operation of dialogue boxes (for example, adding history and options to the File Open dialog). Those tools work at a more abstract level than snagging pixels, which is a lot more efficient--but that means they are ineffective on applications that have already customized those dialogues.
It seems like the fundamental non-breakthrough here is that the application actually must already include the functionality that you want to express in your modified UI--otherwise, you can modify the UI all you want, but the app will only do what it's capable of. So if you want it to display a bunch of different renderings in sub-windows automatically (to use their example), it had better be capable of that display already.
Spoken like a professor. Well-said! but I'm sure you know that there's law and there's reality, and sometimes they don't quite match up.
Yes, the law requires "reduction to practice" (just like it requires "utility") but that doesn't mean that the examiner has a clue of how to assess that. Since the inventor doesn't have to provide any proof of reduction to practice or utility, in practice, the examiner will accept almost any kind of assertion about those topics.
The larger problem is that many modern inventions are far too complex to permit an unambiguous assessment of utility or enablement. It's not obviously half-baked inventions that are the problem, it's complex computer-based systems.
Far too many issued patents simply do not provide sufficient description for one skilled in the art to duplicate the invention. Often, the inventor didn't know how to do it, either. That's where phrases like "preferably using artificial intelligence means" come in so handy.
This is all part of the "gaming the system" toolkit that companies like IV have perfected.
If you think it's hard to get a patent invalidated on prior art grounds, you should try doing it for utility or enablement.
No doubt those applications had merit... but what is the benefit to society? How did writing the applications provide incentive for the inventive process? What useful products will result from the protection granted by those patents, if issued, and who will invest the resources to turn those ideas into products? And if the patents end up (as so many do) being used to block others from pursuing products that are in any way potentially infringing, exactly how does that "promote the progress of science and useful arts" (to quote the Constitution).
Interestingly, even you imply that some of IV's applications have little merit, and you're paid by them. What might a disinterested party say?
I haven't crossed paths (yet) with IV, but I do believe that they are fundamentally evil. They're a natural consequence of bad laws and legal practice.
They like to describe their model as "Hey, Mr. Inventor, we'll buy your patents, or help you patent your stuff, and even pay you to work on it". This approach is appealing in principle, and to be sure, it does put some money in the hands of those inventors.
The problem is that what the Patent Office treats as an "invention" is almost completely unrelated to what constitutes an "invention" in the real world of commerce. A patent-office invention is just an idea. It doesn't have to be manufacturable, it doesn't have to be a viable product, it even doesn't have to work. It just has to be interesting and complicated enough that a relatively unskilled patent examiner cannot find a good reason to deny a patent. And since the examiner has only limited time (small number of hours) to examine each invention, and he's goaled on patents issued, not denied, well, pretty much anything can be patented.
(When I refer to examiners as "relatively unskilled", I don't mean that they're dummies--but rather, that they are generally less practiced in the art of patent management than the high-powered patent attorneys who craft the applications they're reading. Indeed, an awful lot of good examiners end up turning into those high-paid attorneys, after taking a few yeas of "training" at the Patent Office.)
A real-world invention, on the other hand, has to be something that makes money. It has to work. It has to be manufacturable. It has to be sufficiently well-developed as a product that people want to buy it. And getting to there from the idea stage requires real resources: money to pay engineers, money to advertise and market, etc. And ultimately, of course, a real-world invention has to make a profit: the costs ought not to exceed the revenues.
So what IV is mostly doing is creating or buying patent-office inventions and using those to extract money from entrepreneurs and companies that are trying to create real-world inventions. They're a tax on the real resources that are required to turn an invention into a product, and in that role, they far more often prevent useful products from reaching the market, by increasing their development costs too much for a profitable result. Sure, there are a few poster-child inventions where IV has invested their own resources, or where someone else's profit is feasible even at IV's royalty rates, but those cases are rare--and exist for press releases.
IV's costs are minimal, because they mostly just get smart people together to brainstorm. The ideas are copied down by patent attorneys, turned into applications by IV's legal team, and pushed through the Patent Office. Once issued, a patent is presumptively valid, and fighting it is a crapshoot. So if IV comes to you, you either license or fold, because they have more and better lawyers. They generally do nothing to turn an IV patent into a real-world invention, and they bear none of those real costs.
It is a brilliant business model. At minimal costs, IV exploits a fundamental and likely unfixable problem with the patent process, namely that most modern inventions are too sophisticated, complex, and interrelated for the process to address--yet the government guarantees a monopoly, so you have to play within the system, or be subject to patent litigation that is completely unpredictable (except for its multi-million dollar cost). The patent "reform" proposals floating around just nibble at the edges; the system itself is fundamentally broken.
I tackled this problem with an encrypted (dm-crypt) RAID-1 server equipped with easy-removal SATA cages.
I have a four-drive RAID-1 configuration (that is, every bit gets written to four different drives).
Every two weeks or so, I run a script that dismounts the file system briefly (to render the on-disk state consistent), and pop out two of the RAID drives, leaving two working.
I then mail the two removed drives to my two friends who hold on to my off-site backups (priority mail flat rate box $4.95) and they mail back the drives I sent them previously (I include prepaid labels).
In the meantime, while I'm waiting for my friends to mail drives back, I take the two drives I'd previously gotten back in the mail and put them back in the server. The server recognizes them as out of date and starts rebuilding, and a day or so later, I'm back to having four identical drives.
Lather, rinse, repeat.
There are usually four drives in the server (the two permanent ones, plus the two that will make the next backup), and four drives "out" (two being sent to the undisclosed locations, and two being sent back). So in the event of subtle corruption, I have two complete redundant backup sets: one two weeks old, and one four weeks old.
This works for me because my storage needs are modest enough that a single 1-TB drive holds them comfortably. Next server I build like this will be 2-TB, and that will hold me even longer. Astonishingly, drive capacity is growing faster than my ability to consume it (I used to have multiple boxes of external drives).
It's a lot of drives: eight drives doing the work of one. But drives are cheap: the current sweet spot seems to be $130 for 1.5TB, or about $1000 for the disks and another $500 or so for the rest of the server (those SATA cages are surprisingly expensive).
You could use fewer drives: maybe only single drives as backups, rather than pairs in different locations, and maybe just wait for drives to return from the field, rather than having a shadow set always there and spinning. But the extras are pretty cheap as cheap insurance goes. And, of course, you don't have to mail them (and actually I hand-deliver one of each pair, because one friend is local, but it's comforting to know that my other shadow is 2500 miles away).
If I wanted, I could just pop in an extra drive (or dissimilar pair) for a day and create archival snapshots to store permanently off-site but I haven't really had that need.
I haven't lost a drive in the mail yet, and the rebuild process is a pretty good proof that the drives are working.
I made a previous version of this idea with external USB disks, but SATA drives are MUCH more convenient (and cheaper to mail). All those USB enclosures and their inefficient little power supplies and twisty cables made for a very clumsy (and toasty) configuration. Now, I have just a single full-tower chassis and the cooling is efficient and built in.
This solution is entirely based on commodity parts. Anything that breaks, I can replace with something new that's as good or better. I deliberately made my RAID pairs from dissimilar drives (Seagate and WD), to stave off concurrent failure modes, and even sourced my Seagates from two vendors so I got two made in Thailand and two in China (I think). I used to do tape backup, and man, was that a pain: drives go obsolete, formats disappear, media always gets more expensive, and it's slow and linear. Of course, if I had 100 GB of enterprise data to protect, I might be more interested in a tape-based solution--but it would be a lot more expensive. Disk is clearly where the cost-effectiveness is being pushed most heavily.
Encryption is essential. It would be absurd to be mailing around cleartext drives. But a strong password means that the whole-disk encryption is effective against any plausible attack. I keep the password well-protected and never change it, although it would be easy enough to do that with dm-crypt.
I w
Remember the dreaded Trusted Platform Module (TPM)? Evil enforcer of unbreakable DRM and other nastiness? This is one of the rare cases where TPM-managed encryption works to good effect. If the key is hidden inside the TPM (and if you've avoided making any TPM backups and such), just give the wrong TPM PIN several times in a row and the TPM will become unrecoverable. After all, you're probably pretty nervous under all this coercion, it's natural to make mistakes. The adversary can clone your disk drive without difficulty, but he can't easily clone a hardware-secured TPM--and once it's zeroized its internal keys, they're gone, baby, gone.
That's assuming, of course, that you believe the TPM is secure and doesn't have back doors. It might, but letting THAT secret out for a boring child pr0n case seems unlikely. And the hardware security of some TPMs does look pretty darn good. I mean, after around 20 years of getting hacked by cable-TV pirates, the semiconductor companies have learned a thing or two.
However, for most commercial uses, it's just silly: even if it were just being used as backhaul for base stations, the requirement for directional antennas alone means that it's way more expensive and less reliable than conventional alternatives, and bandwidth to satellites can't help but be vastly more expensive than terrestrial connections, either wired or wireless. Imagining direct connections from laptops to satellites is even sillier.
There are places where this might actually make sense commercially, like cruise ships and such, but there just aren't that many other places in the middle of nowhere that have enough well-heeled customers to make satellite links a worthwhile proposition.
And, of course, there's latency. Absent a repeal of the lightspeed limit (an action favored by the outgoing Cheney administration, but unlikely to pass before November), going up to geosynchronous orbit and back down will be much worse than going to the other side of the world by fiber. Those folks who have DirecNet experience this today, and it is physically impossible for it to get any better.