Neither. What I meant is that clouds need to be Tinkertoys that can be used to assemble services with no single point of failure. S3's Achilles heel is that it's all Amazon. If Amazon has a widespread failure or decide to stop doing business with you, your service is instantly, irrevocably dead in the water.
If you're able to spread your storage among multiple providers as S3 does among Amazon's own machinery, you're no longer at the mercy of one provider. Contract with P1, P2 and P3 to do your raw block storage. Contract with P4 and P5 to run the storage service against what you have stored at P1, P2 and P3. If P2 goes poof, you keep running, contract with P6 for new bulk storage, tell your storage services at P4 and P5 you have new space at P6 and it gets loaded up, same as Amazon would do if a machine holding your data fails. If P4 goes away, you fail over to P5 and contract with P7 to run your aggregation service.
I wrote a whole article about this topic a couple of years ago, including some discussion about what will have to happen for something like this to come to fruition. Not wanting to be a blog link ho, I didn't post it here.
Actually, the biggest mistake companies make is using the *same* data centers for its core business. If you're in bed with a single provider, then you break when they break. Until there's a standard way to provision and operate things across multiple providers, this is going to be a problem. What we need isn’t a lot of clouds providing services. We need services being provided by a lot of clouds.
And our tax dollars already go towards the up keep of the internet's infrastructure.
I'm sorry, but this is so incorrect that it isn't funny. The Internet was commercialized in 1995 when NSFNET was decommissioned. Since then, what you know as "The Internet" in the U.S. has been carried on private equipment and circuits. The exception is the U.S. government's own infrastructure, and they're just like any other ISP, carrying traffic for their own departments and agencies.
I doubt very much they're proposing that memory be done across the PCI bus. Memory is modular and reusable, so pulling modules out of old CPU cards and snapping it into new ones helps cut the cost of upgrades and changes.
Or you could just break an ankle jumping to conclusions.
My thoughts exactly. We saw this 20 years ago with the CPU and bus controller on a ISA cards and peripherals out on the bus.
I don't think this is a bad thing, though. It will encourage re-use of things we'd otherwise throw on the scrap heap because they happened to be soldered onto the same motherboard with all of the CPU- and bus-specific hardware. This will reduce upgrade costs, and I'd much rather see a box of small cards become obsolete than an entire rack full of servers.
Do you think anything you just wrote would be anything but cryptic to someone unfamiliar with English?
"Perl 5 provides word-oriented aliases to all of these variables, if you choose to write COBOL in Perl. Oddly, most folks don't."
-- Larry Wall on his choice of name for Perl's "$_" variable
Really, it just puts the onus on employees to carefully vet the companies that make them offers. It's no different than going to work for a company with a shaky business model that collapses a year later. If you go to work for a company with a record of having been shut down for doing illegal things, you run the risk of them being recidivist.
Except that it wasn't. Both phases of E911 were laid out by FCC rules adopted in 1996. Phase I was required to be in place by 1998. The rules for Phase II underwent minor tweaks in 1999 and 2000 and the first implementations were mandated for October 1, 2001.
While I appreciate that September 11 is America's new national pastime, the seeds for E911 were planted long before 2001. I was working on systems to locate phones in 1994.
I think you completely misread what I'm suggesting. What I propose is that the OP, who describes himself as a neophyte when it comes to software, find someone with some experience in that field to be a mentor and help get him off to a good start.
Here's my rationale: I've been writing software for 31 years and have 25 years of industry experience. For the last seven years, I've been working for a company that is staffed mostly by electrical engineers who specialize in signal processing and are really, really good at it. A lot of what they write works, but software isn't their bailiwick, and it lacks the organization and forethought about how it might be used in the future that people who've been around the block tend to put into it.
By teaming up with someone in CS, the OP won't be figuring out how to do it right by trial and error and perhaps turning out ugly code in the first place, and he gets to spread some of the applied math gospel to the heathens over in CS.:-)
Don't take this the wrong way, but you're in math, not CS. Call the CS department, find someone who's willing to team up with you on this and work together on turning the mathematical end of your contributions into good code. You'll come out of it with a better understanding of how software should go together, your CS cohort will get some insight into applied math and both of you will be better for the experience.
If this project goes as well for the FBI as its Virtual Case File program, which was only a small fraction of the cost of this monster even after all they money they spent trying to salvage it, I don't think we have much to worry about.
As much as we bemoan the devolution that's going on inside the government, it has the side benefit of keeping some of the things they're trying to do in check. Will Rogers and I are both glad we don't get all of the government we pay for.
In 1994 (that's pushing two decades ago) I worked on a pilot project with Bell Atlantic Mobile (now Verizon), FHWA, Virginia DOT and the Maryland DOT that tracked mobile phones along the Washington, DC Beltway. The phones didn't have to cooperate, and it was also discovered that call rates went through the roof just as backups started to form. A bunch of the technology we developed ended up in some of the early E911 systems.
Slashdot Mirror
Neither. What I meant is that clouds need to be Tinkertoys that can be used to assemble services with no single point of failure. S3's Achilles heel is that it's all Amazon. If Amazon has a widespread failure or decide to stop doing business with you, your service is instantly, irrevocably dead in the water.
If you're able to spread your storage among multiple providers as S3 does among Amazon's own machinery, you're no longer at the mercy of one provider. Contract with P1, P2 and P3 to do your raw block storage. Contract with P4 and P5 to run the storage service against what you have stored at P1, P2 and P3. If P2 goes poof, you keep running, contract with P6 for new bulk storage, tell your storage services at P4 and P5 you have new space at P6 and it gets loaded up, same as Amazon would do if a machine holding your data fails. If P4 goes away, you fail over to P5 and contract with P7 to run your aggregation service.
I wrote a whole article about this topic a couple of years ago, including some discussion about what will have to happen for something like this to come to fruition. Not wanting to be a blog link ho, I didn't post it here.
Actually, the biggest mistake companies make is using the *same* data centers for its core business. If you're in bed with a single provider, then you break when they break. Until there's a standard way to provision and operate things across multiple providers, this is going to be a problem. What we need isn’t a lot of clouds providing services. We need services being provided by a lot of clouds.
More likely because a filler that isn't round will become damaged a lot quicker than one that is.
And our tax dollars already go towards the up keep of the internet's infrastructure.
I'm sorry, but this is so incorrect that it isn't funny. The Internet was commercialized in 1995 when NSFNET was decommissioned. Since then, what you know as "The Internet" in the U.S. has been carried on private equipment and circuits. The exception is the U.S. government's own infrastructure, and they're just like any other ISP, carrying traffic for their own departments and agencies.
...And that tax credit for mortgage interest. Why should mortgage payers get a break?
I doubt very much they're proposing that memory be done across the PCI bus. Memory is modular and reusable, so pulling modules out of old CPU cards and snapping it into new ones helps cut the cost of upgrades and changes.
Or you could just break an ankle jumping to conclusions.
My thoughts exactly. We saw this 20 years ago with the CPU and bus controller on a ISA cards and peripherals out on the bus.
I don't think this is a bad thing, though. It will encourage re-use of things we'd otherwise throw on the scrap heap because they happened to be soldered onto the same motherboard with all of the CPU- and bus-specific hardware. This will reduce upgrade costs, and I'd much rather see a box of small cards become obsolete than an entire rack full of servers.
Do you think anything you just wrote would be anything but cryptic to someone unfamiliar with English?
"Perl 5 provides word-oriented aliases to all of these variables, if you choose to write COBOL in Perl. Oddly, most folks don't."
-- Larry Wall on his choice of name for Perl's "$_" variable
This dinosaur feels compelled to remind you, sonny, that all languages suck, including JavaScript.
Really, it just puts the onus on employees to carefully vet the companies that make them offers. It's no different than going to work for a company with a shaky business model that collapses a year later. If you go to work for a company with a record of having been shut down for doing illegal things, you run the risk of them being recidivist.
Eeeeeyeah. I can play the pedantic game, too. The mandate wasn't made after 9/11.
This is fun.
Except that it wasn't. Both phases of E911 were laid out by FCC rules adopted in 1996. Phase I was required to be in place by 1998. The rules for Phase II underwent minor tweaks in 1999 and 2000 and the first implementations were mandated for October 1, 2001.
While I appreciate that September 11 is America's new national pastime, the seeds for E911 were planted long before 2001. I was working on systems to locate phones in 1994.
Disk BASIC was a TRS-80 product.
I think you completely misread what I'm suggesting. What I propose is that the OP, who describes himself as a neophyte when it comes to software, find someone with some experience in that field to be a mentor and help get him off to a good start.
Here's my rationale: I've been writing software for 31 years and have 25 years of industry experience. For the last seven years, I've been working for a company that is staffed mostly by electrical engineers who specialize in signal processing and are really, really good at it. A lot of what they write works, but software isn't their bailiwick, and it lacks the organization and forethought about how it might be used in the future that people who've been around the block tend to put into it.
By teaming up with someone in CS, the OP won't be figuring out how to do it right by trial and error and perhaps turning out ugly code in the first place, and he gets to spread some of the applied math gospel to the heathens over in CS. :-)
Don't take this the wrong way, but you're in math, not CS. Call the CS department, find someone who's willing to team up with you on this and work together on turning the mathematical end of your contributions into good code. You'll come out of it with a better understanding of how software should go together, your CS cohort will get some insight into applied math and both of you will be better for the experience.
...And don't think for a minute that the issuing bank doesn't keep records of which accounts were issued to what customers and when.
If this project goes as well for the FBI as its Virtual Case File program, which was only a small fraction of the cost of this monster even after all they money they spent trying to salvage it, I don't think we have much to worry about.
As much as we bemoan the devolution that's going on inside the government, it has the side benefit of keeping some of the things they're trying to do in check. Will Rogers and I are both glad we don't get all of the government we pay for.
Ugh. Where did I get the two decades figure? Let's do the math...
(Takes the square root then the arctangent, carries the 1...)
Fourteen.
--Mark
This isn't new by any stretch of the imagination.
In 1994 (that's pushing two decades ago) I worked on a pilot project with Bell Atlantic Mobile (now Verizon), FHWA, Virginia DOT and the Maryland DOT that tracked mobile phones along the Washington, DC Beltway. The phones didn't have to cooperate, and it was also discovered that call rates went through the roof just as backups started to form. A bunch of the technology we developed ended up in some of the early E911 systems.
In retrospect, you're right.
Like it or not, the difference between the two is that Viacom actually has a case.
Email designers?
Email designers?
Really?
Read the article again, and this time remember that "lua" is a word the Hawaiians use for the bathroom.
NMCI notwithstanding, there's tons of open source software running all over DoD as we speak, and very little of it is likely to go away anytime soon.