The biggest thing I have run into when discussing system reliability that people don't seem to get the distinction between a particular system being up and the service being available.
In many cases, the end goal should be for the users to experience however-many-9's you want -- but that doesn't mean that your administrators are only going to have to deal with that much down time on individual systems. In fact, they'll have quite a lot of downtime to cope with -- but you have to be sufficiently redunant that you can still provide the service in the presence of individual system/link failures.
Besides that, a good system will be designed to degrade gracefully in the event of component failures. Your users will be a lot happier if you can tell them 'this service is temporarily unavailable' than if the service just disappears.
The only thing that is exceptionally difficult is having a redundant database synchronized in near-real time across multiple sites. That's where you need to spend the big money on clustering. Front-end servers can be as redundant as you want, and mid-level app servers can be clustered or independent, but the db has got to be there for the rest of it to work.
But if you can't convince management that the goal is that the users' experience of downtime be minimized (and you can measure it), then you're going to have a hard time asking for more money when the apparent amount of time spent fixing broken systems goes up rather than down with each upgrade. Sure, you want to minimize the individual system downtime, but look at services like Google where they have tens of thousands of individual systems with dozens or more down at any given time -- they've just designed their stuff well enough that the service can keep chugging along in the presence of failures.
Are GPS signals cryptographically signed? If they are, then perhaps the system could be made tamperproof against spoofed signals in a Faraday cage.
If not, then capturing the device would pretty much mean you could get at the data.
As for the idea of using these for military commanders & such -- wouldn't the places they're going to need to receive communications have some sort of TEMPEST protection to begin with? GPS is sketchy enough if you're inside a building period -- if you're in an electrically shielded building to boot, there doesn't seem to be much hope that this will work.
Once upon a time, I set up a bunch of free forwarding addresses (one for personal, one for sites I spend money at, one for sites I don't) through Mail.com, and forwarded them to my Yahoo account, which I in turn access through both their web interface while at work and via POP3 from home. All of that used to be free.
Now, to maintain that beyond next month (when the "free" parts of both services end), it would cost me $29.99/yr @ Yahoo plus $19.99/yr per EACH forwarding address at Mail.com. That's almost $90/yr.
Instead, for $15/yr, I got three forwarding addresses from pobox.com, and have them forwarded to the inbox at my ISP (which I was paying for as part of their service anyway). I have never (and don't intend) to ever reveal my actual ISP inbox address to any site or person, so I can maintain the same level of abstraction I had before, but for $75/yr less than Mail.com and Yahoo.com would like me to pay.
Lucent's QIP has been around for 5 or 6 years and is pretty good for centrally managing address space. At a former employer we used it to manage a/8, a/24, and numerous RFC-1918 subnets for a network spanning a couple hundred sites in a few dozen countries. Runs on NT, W2K, HP-UX, AIX, and Solaris.
(Disclaimer: I am not now, nor have I ever been, affiliated with Lucent.)
Slashdot Mirror
In many cases, the end goal should be for the users to experience however-many-9's you want -- but that doesn't mean that your administrators are only going to have to deal with that much down time on individual systems. In fact, they'll have quite a lot of downtime to cope with -- but you have to be sufficiently redunant that you can still provide the service in the presence of individual system/link failures.
Besides that, a good system will be designed to degrade gracefully in the event of component failures. Your users will be a lot happier if you can tell them 'this service is temporarily unavailable' than if the service just disappears.
The only thing that is exceptionally difficult is having a redundant database synchronized in near-real time across multiple sites. That's where you need to spend the big money on clustering. Front-end servers can be as redundant as you want, and mid-level app servers can be clustered or independent, but the db has got to be there for the rest of it to work.
But if you can't convince management that the goal is that the users' experience of downtime be minimized (and you can measure it), then you're going to have a hard time asking for more money when the apparent amount of time spent fixing broken systems goes up rather than down with each upgrade. Sure, you want to minimize the individual system downtime, but look at services like Google where they have tens of thousands of individual systems with dozens or more down at any given time -- they've just designed their stuff well enough that the service can keep chugging along in the presence of failures.
According to their site, Seti@Home clocked in at 96.79 TeraFLOPs over the last 24 hours.
Are GPS signals cryptographically signed? If they are, then perhaps the system could be made tamperproof against spoofed signals in a Faraday cage.
If not, then capturing the device would pretty much mean you could get at the data.
As for the idea of using these for military commanders & such -- wouldn't the places they're going to need to receive communications have some sort of TEMPEST protection to begin with? GPS is sketchy enough if you're inside a building period -- if you're in an electrically shielded building to boot, there doesn't seem to be much hope that this will work.
Now, to maintain that beyond next month (when the "free" parts of both services end), it would cost me $29.99/yr @ Yahoo plus $19.99/yr per EACH forwarding address at Mail.com. That's almost $90/yr.
Instead, for $15/yr, I got three forwarding addresses from pobox.com, and have them forwarded to the inbox at my ISP (which I was paying for as part of their service anyway). I have never (and don't intend) to ever reveal my actual ISP inbox address to any site or person, so I can maintain the same level of abstraction I had before, but for $75/yr less than Mail.com and Yahoo.com would like me to pay.
Lucent's QIP has been around for 5 or 6 years and is pretty good for centrally managing address space. At a former employer we used it to manage a /8, a /24, and numerous RFC-1918 subnets for a network spanning a couple hundred sites in a few dozen countries. Runs on NT, W2K, HP-UX, AIX, and Solaris.
(Disclaimer: I am not now, nor have I ever been, affiliated with Lucent.)