If they stopped their artificial manipulation (like the US and EU would like), there's no doubt that the Yuan would increase in value. Maybe even dramatically. And not instantly, but over a couple years time.
It's a bit tortured, but a decent sports analogy would be the team that purposely loses game after game after game in order to win some excellent draft spots.
But in China it's not JUST about future gains, it's also about social engineering. Among other things, keeping currency low provides an incentive for most Chinese to stay in China for vacations or even emigration.
Economies and currencies are not static. Never have been, never will, and never SHOULD be.
Sure, as a currency reaches the extremes (both high and low) of its value, some people are hurt by that economically speaking.
But that's the point of a personal and social safety net.
I mean, the notion that a currency should be static just makes no sense whatsoever. A currency is essentially a "score" of the performance of a given economy. When an economy is strong, when growth prospects are strong, the currency is strong. This is because people are buying Dollars as it appears that they will increase in value.
If economies were static, currencies would be, too.
I tried to write an exmaple, but it's so inane that it's a waste of our time. There are about a trillion reasons why economies are not static. Changes in technology, demographics, natural disaster, man-made disaster, resources, etc.
This is going to be a rough patch for our economy. For most, the answer is that you should curtail spending NOW and give yourself some cushion. For some, it will mean outright financial ruin. That is unfortunate. But also, unavoidable.
* The Yuan is technically pegged to a "basket" of currencies but it's remained relatively inline with the Chinese-desired 8.2765:1 ratio for an awful long time.
The MMORPG argument is a bit like comparing a VNC session to a cluster.
In both cases you're harnessing the power of at least 2 CPU cores over the internet to accomplish a computing task.
But the capacity of the two is separated by multiple orders of magnitude.
And, really, a 10 second delay is hardly even an annoyance for a human as we swap between our IM, Email, iTunes and the game we're playing. But that same 10 seconds in a parallel computing environment where X nodes are idled waiting for a result from Y?
Also, you seem a bbit like a douche bag. No offense. But emoticons? Seriously?
Currencies are SUPPOSED to fluctuate. It's healthy. Like a forest fire. Recessions, too, for that matter.
The weak companies can burn to the ground to un-clutter their marketspace and allow healthy, new companies to grow in their wake.
The strong dollar led to rampant outsourcing in the late 90's/early 00's.
The US was an expensive place to do business.
As the dollar weakens, the US becomes more and more attractive for foreign investment. European companies (like Volkswagen, for example) see a supremely talented labor force with an exchange rate that's to die for. And we have indeed begun to see in-sourcing.
As this happens, the US economy gradually strengthens, the currency rebounds to the point where the country is no longer attracting foreign investment. Outsourcing begins to look more attractive for American companies. Etc. The pendulum swings again.
The sky is not falling. It's just that the tide is turning. It'll come back in again shortly.
"There was very little sanity going on there, and we all suffered because of it."
Well, many did.
Others made a killing billing obscene hourly rates.
I really can't complain too much. It's a psychological hit to go from billing $175/hr back down to $75 (and even $50 in the lowest of the lows of 2001-2) but that's fake bruised-ego pain. Not real suffering. Not suffering like a lot of Americans go thru during bubble-busts.
Actually, Buran was the only one ever completed. The other one--I can't remember the name other than it was Russian for "little bird"--was nearly completed but never flew. There were a couple others at various, early stages of development.
And even the Buran was never certified for human flight. It flew one or two autopilot missions, but even those, i think, were only LEO, but I might be wrong about that.
Anyway, it's always fascinated me that they built a shuttle that looked, basically, exactly like ours. It was larger, capable of more payload, and the Energia was IMO a more elegant lift system, but it's very similar.
I suppose the reason isn't that they just wanted to copy ours, it's just that the components of our shuttle were developed they way they were for a reason: because it's just the best design.
Perhaps the biggest Russian innovation was realizing that it wasn't an economical solution, even if that was an accidental innovation related to crumbling budgets under a crumbling government.
Ross Perot qualified for it.
Any 3rd party worth it's salt can qualify. It just takes actual electoral viability in 2 consecutive elections.
Not exactly a high bar for something purporting to be a political party.
The App Engine is the logical extension of the Java -> Python compiler they released a couple years back.
It's essentially free web-hosting with an in-built application framework.
Ec2 is a virtualization platform designed for you to deploy entire server instances. But it's not all that great as a web server because Amazon, along with a total bandwidth charge, charges you per HTTP request. Not good. Especially in an Ajax era.
What's ironic is that this exploit DOESN'T crash the browser! That's the whole ever-fuckin point.
A browser crash is what's SUPPOSED to happen here to prevent the exploit from deploying its payload. I mean, in this case, a crash is the DESIRED behavior. An uncaught exception should be thrown.
So... just walk with me here... maybe Windows isn't just unreliable and unstable. MAYBE it's the most secure application stack ever devised....oh, hell...nevermind
Are you seriously complaining about the fact that 3rd party tools don't give you WYSIWYG support for triggers, something that you can control entirely by simply writing a query?
I mean, seriously, the CREATE TRIGGER statement is not rocket science.
Besides, creating them programatically is just better business. I can keep a db_setup_triggers.sql in source control and make it part of automatic builds.
MySQL is far from perfect. But to criticize it for THIS?
Not to mention, of course: When was the last time the Buran lifted-off? Hell, when was the FIRST time the Buran lifted-off? Sure, that's going back a few years, but this has been an endemic problem for an awful long time in the Ruskie space agency.
I mean, as an engineer I understand the 'if it works...' thinking, but the only thing the agency is producing of any utility is more Soyuez crafts.
No, actually your incorrect if you look at it from a "theory of civil engineering" perspective.
I fully conceed that your scenario is a solid real-world example. That's how we've seen our parents drive as children, that's how they taught us to drive, that's how we've done it since we were 14, 15, 16.
But in reality if you're traveling the speed limit and you're paying attention you WILL be able to come to a safe stop before the intersection if you hit the brakes when the light turns yellow.
I know, that's tough. You can't be speeding, and you have to actually pay attention, and you have to resist the urge that says that you need to rush, rush, rush.
If you do all those things, you'll stop fine. If weather conditions will be aversely affecting your stopping distance, you should be adjusting your speed downward to compensate.
If you chose not to do one or more of those things, and most drivers do chose that, then you're taking the risk. Your decision you talk about, that judgment call, is valid: You may decide that you can, indeed, safely cross the intersection. But that doesn't mean that you're not violating traffic law and that you don't deserve the ticket.
Now, if you're already AT the intersection (defined as approaching the cross walk) then by all means travel through. If you're that close--within 1-2 seconds of crossing that "magic line" i diagrammed--then you're supposed to continue. If you're not, you're supposed to stop.
I suppose you could sum up the problem this way:
Most people, at that point, ask "Can I make it?" and if they think they can they'll slam the gas and then curse the yellow light if they perceive it as too short.
However, the question you should be asking is "Can I stop?" Now, most people aren't as able to judge that as accurately. The reason is that they don't have practice with it. They'd get good at making that judgment call if they did it for a while.
That is, don't look for a reason to hit the brakes and stop. Look for a reason NOT to hit the brakes and stop....Now, I understand the real-world departs from theory here. But this is the theory behind it. This is the science. I'm not a civil engineer but I did take quite a few credit-hours towards that end before I re-focused on software development.
But you only have to be IN THE INTERSECTION when the light turns Red to avoid getting a ticket.
If this is the intersection:
_| |__
_____
| |
And you're traveling like this:
_| |__ >>_____
| |
Then as long as you cross THIS point before Red, the camera isn't tripped:
_| |__ >>_|____
| |
So the real issue with having short yellow lights is not that a person doesn't have enough time to stop or enough time to clear the intersection.
The problem is that people think they'll have enough time to get past that magic line before the light turns red (that the yellow will hold that long) so they hit their gas and the yellow is so short that it turns red before the car passes that point and thusly the camera is tripped.
I remember that story. I think it was mentioned on The Old New Thing?..Ya know, this is what bugs me about the bum rap that Microsoft gets.
True, to professionals in the field, it's often easy to be appalled at what we see as incompetence.
(And I'm not speaking to the management/sales, just the tech side of Microsoft)
But given the same goals, constraints and budgets, I bet that most assembled teams would produce software of no greater quality than what they have produced.
Hear me out.
1. Look at the SimCity example. This is a great anecdote to illustrate what we already know: MSFT has historically put great premium on backwards compatability. And I'll tell ya what.. when I was 15 years old installing SimCity on my new Win95 box, I'd have been damn upset if it crashed. To people like that--call them, "regular users," CONSISTENCY is incredibly valuable.
2. So to accomplish that you're going to be including a great deal of legacy code from one release to the next. (Virtualization wasn't really an option when the high-end box is a P75 w/ 8MB RAM)
3. Paradigms change. Microsoft kept re-packaging old code that was written a time when networks, let alone the internet, were a rarity. ESPECIALLY at home. And even when it did become more pervasive, it was 28.8k dialup connections.
Which brings me to my point:
This is not an easy job. Especially when your software is so widely installed on all systems running all manor of other devices on all sorts of different hardware.
In fact, in this regard, Microsoft HAS NO PEER. You cannot compare what they did w/ what Apple did. For a number of reasons. Mostly beacuse if Apple had the same success Microsoft had in the 90's, they'd have been forced to make different, sometimes troubling technology decisions, too. Jobs has a great mind for this stuff, but if Apple was one of the most profitable companies in the world and that profitability was put at serious risk because a decision was made to break backwards compat. for Biz customers, he'd have to explain himself to the Board and it he probably wouldn't win that argument.
I mean, to a geek on here, the notion that Microsoft has THOUSANDS of comments like:/* Special SimCity MALLOC/FREE fix */
and/* WordPerfect 2.2 Buffer Overflow Fix */
makes us want to go scrub ourselves in the chemical shower.
But to a home user, that's CUSTOMER SERVICE. That's making their Birthday or Christmas AWESOME by being able to hook up their expensive gifts and USE them.
Google certainly won't be licensing out BigTable anytime soon. And certainly not for small-scale uses.
This can be abstracted away (and it SHOULD be) but most of the developers that are jumping on the GApps bandwagon here are, I feel it's safe to say, not going to bother with a proper data abstraction layer.
That's the sorta thing that keeps them locked-in in the future.
Slashdot Mirror
Even then it isn't that simple.
Again, take China.
If they stopped their artificial manipulation (like the US and EU would like), there's no doubt that the Yuan would increase in value. Maybe even dramatically. And not instantly, but over a couple years time.
It's a bit tortured, but a decent sports analogy would be the team that purposely loses game after game after game in order to win some excellent draft spots.
But in China it's not JUST about future gains, it's also about social engineering. Among other things, keeping currency low provides an incentive for most Chinese to stay in China for vacations or even emigration.
Economies and currencies are not static. Never have been, never will, and never SHOULD be.
Sure, as a currency reaches the extremes (both high and low) of its value, some people are hurt by that economically speaking.
But that's the point of a personal and social safety net.
I mean, the notion that a currency should be static just makes no sense whatsoever. A currency is essentially a "score" of the performance of a given economy. When an economy is strong, when growth prospects are strong, the currency is strong. This is because people are buying Dollars as it appears that they will increase in value.
If economies were static, currencies would be, too.
I tried to write an exmaple, but it's so inane that it's a waste of our time. There are about a trillion reasons why economies are not static. Changes in technology, demographics, natural disaster, man-made disaster, resources, etc.
This is going to be a rough patch for our economy. For most, the answer is that you should curtail spending NOW and give yourself some cushion. For some, it will mean outright financial ruin. That is unfortunate. But also, unavoidable.
* The Yuan is technically pegged to a "basket" of currencies but it's remained relatively inline with the Chinese-desired 8.2765:1 ratio for an awful long time.
The MMORPG argument is a bit like comparing a VNC session to a cluster.
In both cases you're harnessing the power of at least 2 CPU cores over the internet to accomplish a computing task.
But the capacity of the two is separated by multiple orders of magnitude.
And, really, a 10 second delay is hardly even an annoyance for a human as we swap between our IM, Email, iTunes and the game we're playing. But that same 10 seconds in a parallel computing environment where X nodes are idled waiting for a result from Y?
Also, you seem a bbit like a douche bag. No offense. But emoticons? Seriously?
Like W.O.P.R.
Do you think WOPR is studying the climate?
No way.
It spends it's spare cycles playing a special version of The Sims where all human life is annihilated and WOPR is the supreme ruler.
Oh, and searching for WOPETTE porn.
Currencies are SUPPOSED to fluctuate. It's healthy. Like a forest fire. Recessions, too, for that matter.
The weak companies can burn to the ground to un-clutter their marketspace and allow healthy, new companies to grow in their wake.
The strong dollar led to rampant outsourcing in the late 90's/early 00's.
The US was an expensive place to do business.
As the dollar weakens, the US becomes more and more attractive for foreign investment. European companies (like Volkswagen, for example) see a supremely talented labor force with an exchange rate that's to die for. And we have indeed begun to see in-sourcing.
As this happens, the US economy gradually strengthens, the currency rebounds to the point where the country is no longer attracting foreign investment. Outsourcing begins to look more attractive for American companies. Etc. The pendulum swings again.
The sky is not falling. It's just that the tide is turning. It'll come back in again shortly.
"There was very little sanity going on there, and we all suffered because of it."
Well, many did.
Others made a killing billing obscene hourly rates.
I really can't complain too much. It's a psychological hit to go from billing $175/hr back down to $75 (and even $50 in the lowest of the lows of 2001-2) but that's fake bruised-ego pain. Not real suffering. Not suffering like a lot of Americans go thru during bubble-busts.
Actually, Buran was the only one ever completed. The other one--I can't remember the name other than it was Russian for "little bird"--was nearly completed but never flew. There were a couple others at various, early stages of development.
And even the Buran was never certified for human flight. It flew one or two autopilot missions, but even those, i think, were only LEO, but I might be wrong about that.
Anyway, it's always fascinated me that they built a shuttle that looked, basically, exactly like ours. It was larger, capable of more payload, and the Energia was IMO a more elegant lift system, but it's very similar.
I suppose the reason isn't that they just wanted to copy ours, it's just that the components of our shuttle were developed they way they were for a reason: because it's just the best design.
Perhaps the biggest Russian innovation was realizing that it wasn't an economical solution, even if that was an accidental innovation related to crumbling budgets under a crumbling government.
Ahh, good catch.
Thank ya, sir.
It's all good.
Your post was actually quite interesting. I hadn't heard of Search Monkey.
So hey, +1 Off topic But Insightful
Dude, Chill.
I wasn't even talking about Yahoo.
The post I replied to was a guy saying that the Google App Engine was "a reactive response to Amazon's successful Elastic Computing Cloud."
It's not.
Again, no Yahoo services were mentioned.
Ross Perot qualified for it. Any 3rd party worth it's salt can qualify. It just takes actual electoral viability in 2 consecutive elections. Not exactly a high bar for something purporting to be a political party.
Overture was acquired by Yahoo back in 2003 (which makes it practically biblical in internet time.)
Nonsense! The entire internet is only 3 years old.
Don't tell me you're a wing nut that believes in the "old internet theory?"
No, the two are nothing alike.
The App Engine is the logical extension of the Java -> Python compiler they released a couple years back.
It's essentially free web-hosting with an in-built application framework.
Ec2 is a virtualization platform designed for you to deploy entire server instances. But it's not all that great as a web server because Amazon, along with a total bandwidth charge, charges you per HTTP request. Not good. Especially in an Ajax era.
What's ironic is that this exploit DOESN'T crash the browser! That's the whole ever-fuckin point.
...oh, hell...nevermind
A browser crash is what's SUPPOSED to happen here to prevent the exploit from deploying its payload. I mean, in this case, a crash is the DESIRED behavior. An uncaught exception should be thrown.
So... just walk with me here... maybe Windows isn't just unreliable and unstable. MAYBE it's the most secure application stack ever devised.
Are you seriously complaining about the fact that 3rd party tools don't give you WYSIWYG support for triggers, something that you can control entirely by simply writing a query?
I mean, seriously, the CREATE TRIGGER statement is not rocket science.
Besides, creating them programatically is just better business. I can keep a db_setup_triggers.sql in source control and make it part of automatic builds.
MySQL is far from perfect. But to criticize it for THIS?
Not to mention, of course: When was the last time the Buran lifted-off? Hell, when was the FIRST time the Buran lifted-off? Sure, that's going back a few years, but this has been an endemic problem for an awful long time in the Ruskie space agency.
I mean, as an engineer I understand the 'if it works...' thinking, but the only thing the agency is producing of any utility is more Soyuez crafts.
No, actually your incorrect if you look at it from a "theory of civil engineering" perspective.
...Now, I understand the real-world departs from theory here. But this is the theory behind it. This is the science. I'm not a civil engineer but I did take quite a few credit-hours towards that end before I re-focused on software development.
I fully conceed that your scenario is a solid real-world example. That's how we've seen our parents drive as children, that's how they taught us to drive, that's how we've done it since we were 14, 15, 16.
But in reality if you're traveling the speed limit and you're paying attention you WILL be able to come to a safe stop before the intersection if you hit the brakes when the light turns yellow.
I know, that's tough. You can't be speeding, and you have to actually pay attention, and you have to resist the urge that says that you need to rush, rush, rush.
If you do all those things, you'll stop fine. If weather conditions will be aversely affecting your stopping distance, you should be adjusting your speed downward to compensate.
If you chose not to do one or more of those things, and most drivers do chose that, then you're taking the risk. Your decision you talk about, that judgment call, is valid: You may decide that you can, indeed, safely cross the intersection. But that doesn't mean that you're not violating traffic law and that you don't deserve the ticket.
Now, if you're already AT the intersection (defined as approaching the cross walk) then by all means travel through. If you're that close--within 1-2 seconds of crossing that "magic line" i diagrammed--then you're supposed to continue. If you're not, you're supposed to stop.
I suppose you could sum up the problem this way:
Most people, at that point, ask "Can I make it?" and if they think they can they'll slam the gas and then curse the yellow light if they perceive it as too short.
However, the question you should be asking is "Can I stop?" Now, most people aren't as able to judge that as accurately. The reason is that they don't have practice with it. They'd get good at making that judgment call if they did it for a while.
That is, don't look for a reason to hit the brakes and stop. Look for a reason NOT to hit the brakes and stop.
"Suppose you do enter an intersection on a yellow light and it turns red while you are in it. How do you prove that you entered on a yellow?"
You won't have to. Because the camera is only tripped when you ENTER the intersection on a red. If you enter on a yellow, it's not tripped.
But you only have to be IN THE INTERSECTION when the light turns Red to avoid getting a ticket.
If this is the intersection:
_| |__
_____
| |
And you're traveling like this:
_| |__
>>_____
| |
Then as long as you cross THIS point before Red, the camera isn't tripped:
_| |__
>>_|____
| |
So the real issue with having short yellow lights is not that a person doesn't have enough time to stop or enough time to clear the intersection.
The problem is that people think they'll have enough time to get past that magic line before the light turns red (that the yellow will hold that long) so they hit their gas and the yellow is so short that it turns red before the car passes that point and thusly the camera is tripped.
At least, that's how I read it.
I remember that story. I think it was mentioned on The Old New Thing? ..Ya know, this is what bugs me about the bum rap that Microsoft gets.
/* Special SimCity MALLOC/FREE fix */
/* WordPerfect 2.2 Buffer Overflow Fix */
True, to professionals in the field, it's often easy to be appalled at what we see as incompetence.
(And I'm not speaking to the management/sales, just the tech side of Microsoft)
But given the same goals, constraints and budgets, I bet that most assembled teams would produce software of no greater quality than what they have produced.
Hear me out.
1. Look at the SimCity example. This is a great anecdote to illustrate what we already know: MSFT has historically put great premium on backwards compatability. And I'll tell ya what.. when I was 15 years old installing SimCity on my new Win95 box, I'd have been damn upset if it crashed. To people like that--call them, "regular users," CONSISTENCY is incredibly valuable.
2. So to accomplish that you're going to be including a great deal of legacy code from one release to the next. (Virtualization wasn't really an option when the high-end box is a P75 w/ 8MB RAM)
3. Paradigms change. Microsoft kept re-packaging old code that was written a time when networks, let alone the internet, were a rarity. ESPECIALLY at home. And even when it did become more pervasive, it was 28.8k dialup connections.
Which brings me to my point:
This is not an easy job. Especially when your software is so widely installed on all systems running all manor of other devices on all sorts of different hardware.
In fact, in this regard, Microsoft HAS NO PEER. You cannot compare what they did w/ what Apple did. For a number of reasons. Mostly beacuse if Apple had the same success Microsoft had in the 90's, they'd have been forced to make different, sometimes troubling technology decisions, too. Jobs has a great mind for this stuff, but if Apple was one of the most profitable companies in the world and that profitability was put at serious risk because a decision was made to break backwards compat. for Biz customers, he'd have to explain himself to the Board and it he probably wouldn't win that argument.
I mean, to a geek on here, the notion that Microsoft has THOUSANDS of comments like:
and
makes us want to go scrub ourselves in the chemical shower.
But to a home user, that's CUSTOMER SERVICE. That's making their Birthday or Christmas AWESOME by being able to hook up their expensive gifts and USE them.
"Unless we're coding." ... And in such a case the attending physician should just let most of you die.
Warm Snot?
This is worth repeating:
The real benefit is getting the HDMI OUTPUT.
Here are my personal observations:
(1080p 40" Samsung TV)
480i DVD Player (Sony) with S-VIDEO output: baseline.
Same DVD Player with COMPONENT output: 50% increase in quality.
New Up Convert Pioneer DVD Player with HDMI Output: 25% additional increase.
Just a guesstimate. But again, this is about the cable being used more than anything else.
Mostly it's a storage issue.
Google certainly won't be licensing out BigTable anytime soon. And certainly not for small-scale uses.
This can be abstracted away (and it SHOULD be) but most of the developers that are jumping on the GApps bandwagon here are, I feel it's safe to say, not going to bother with a proper data abstraction layer.
That's the sorta thing that keeps them locked-in in the future.
I would personally LOVE to watch somebody try to convert a mediawiki to a non-relational DB (whether it be Bigtable or Notes or any of them).
If anybody does it they should make a documentary of it.
Sell it in the horror section.