That makes sense, but it does stand to reason (or, at least, to my reason) that these queries that garner large numbers of results could have had a significant impact on the bottom line of the survey.
Well, there's a worse bias. They're grabbing words from an Ispell word list.
There are websites which contain the Ispell word list. There appear to be more of those returned in Google as results than in Yahoo. (here is one returned in Google for "apprizers expense", but which is not returned in Yahoo.)
This basically contributes a pedestal to their result - they'll never get zero results, because they'll always get the Ispell lists back, and because those results always return the same number (about 8 Google to 1 or 2 Yahoo), you'll bias the results of the entire set to that result.
They needed to remove results which are returned in common to multiple searches, as that's essentially double counting.
No, it's accurate. They're testing Yahoo's claim of how many pages they've indexed, which just means that all indexed pages that contain the requested words should be returned from the search request. If yahoo returns fewer unique pages, yahoo has indexed fewer pages.
Actually, it might not be, thanks to their methodology.
They only used searches with less than 1000 results. They therefore got a lot of searches with small results numbers (because they were searching for bizarre word combinations, like "promotion bedabble"). The total number of results was something like 500,000 or so (order of magnitude) for 10,000 searches. That's an average of 50 results/search, and I'd bet there's a large, large tail, so the most common search is probably something like 10 results.
The problem with this is that in their word list, the same sites are being returned over and over!. For instance, sites containing dictionary lists appear in both "promotion bedabble" and "foliolate defecations" because, duh, that's the only place they'll appear. Since they're just searching the same type of site over and over, they get the same result magnified a lot: Google has more "dictionary lists" in its index than Yahoo. Most of the "dictionary list" word searches returned about 10-20 for Google, and few, if any, for Yahoo.
It's a pretty serious flaw in the methodology, as far as I can tell - they're double counting huge numbers of results, and so they're not really getting a good statistical sample of the index.
I remember telling my neighbor the next thing you'd know they'd be making a Mario RPG
Square did, actually. Joint venture between Square & Nintendo. Proved to be so succesful that Nintendo made three sequels: Paper Mario, Paper Mario 2, and Mario & Luigi: Superstar Saga.
Fantastic games. Feel free to bash them all you want, but who cares if they're reusing some characters? The characters don't matter as much as the gameplay does, which is fantastic.
I disagree completely with you and saying that this is not enough for sustainable human development. I'm sure this is enough water to sustain development for years to come, long enough for somebody to find water somewhere else.
Well, it's of order 20 trillion liters (10mi*10mi*200 feet) of ice (which is about the same volume as the equivalent liquid water content - ice is only about 10% less dense).
A random site says that Americans use on average 80-100 gallons per day, which means that water would supply a colony of 10,000 for 11,000 years.
Yes, the water needs for a colony are higher than the water needs for a person, but an off-planet colony probably is going to recycle water (one would hope), so I'd imagine actually that it probably works out pretty well.
So yah, I agree with you. This is a heckuva lot of water.
However, the premise is all wrong, and that is why spam-chess fails:
The premise of a Bayesian filter is that is learns sequences of words, or characters, or whatever. Spam-chess learns sequences of moves. This premise is wrong, since good moves are related to complete board positions, not to what was done in the previous few moves.
But this problem is easily fixed - instead of giving spam-chess the move sequence, give it the board state as a function of move number. You could easily write a program which does this from the games.
I'm not sure that this is the limitation, though. For one thing, if you play as if board state is the only thing that matters, then you're completely ignoring playing style of the person you're playing. A move sequence contains more information than the board state, not less. So in theory, you may be able to play better, not worse. Of course, this is in theory - in practice it does mean the signal/noise of the data is lower.
I think the main limitation - not being able to understand values of exchanges - is probably the biggest problem. It's also the easiest to fix, as you can just write a program to add the piece that's being taken (i.e. instead of Bxc4, you'd have BxBc4). The relative value of each piece can be determined just from the number of times an exchange happens for winners.
Sounds like a good place to put a radiotelescope, particularly one dedicated to SETI.
No. You've still got the Sun right there. Lunar L3 would be a good place to put a radio telescope, as it's dark for half the month (no solar interference) and the Moon shields you from Earth-based interference.
Solar L3 isn't particularly great for anything. It's pretty much the least useful Lagrange point.
Actually that is the classical mathematical definition of stability of a fixed point of a dynamical system -- if you start close you stay close.
Well, it's kinda like that. With a pendulum, there's a restoring force back to the point of equilibrium. With L4/L5, there's a restoring force about the point of equilibrium.
With a pendulum, you're always guaranteed to pass back through the equilibrium point - the mean displacement is always zero. With L4/L5, that's not true.
The description of L4/L5 as a valley isn't really correct. If you displace from L4, you go into an orbit around L4. You don't go back through it.
The L1 and L2 points aren't *stable*, so it's not clear to me a priori that space elevators to those points from the Moon would work out so well.
Geosynchronous orbit isn't stable either - if you push away from it, you don't come back. But an elevator to there is stable, because it's anchored to the planet - so moving radially outward, tension pulls you back inward. Moving inward, the planet's rotation pulls you back outward. Same goes for each of the other directions. It's exactly the same for the lunar elevators to L1/L2.
Putting a lunar elevator there is an excellent way of avoiding propellant. It's also most likely extremely cheap, since all you need is a really long Kevlar cable.
Long story short, your space elevator would begin wrapping itself around the Earth in very short order.
Sorry, I meant affixed to the Moon, not affixed to the Earth. The reason it'd be cheap is because the Moon's gravity is much less than Earth's - so you'd only need something like Kevlar to be strong enough.
None of the Lagrange points can really be "occupied". None of them are stable in the classical sense (i.e. a fixed point in space that everything falls down to). SOHO, WMAP (and in the future, JWST) will all be in orbits about the Lagrange points.
Just because there's one thing there doesn't mean there can't be others. Plus, the ones we're mentioning here are just the solar Lagrange points. The lunar Lagrange points are all unoccupied (as far as I know...). The lunar L1/L2 are terrific places for a cheap, easy to build space elevator.
The derivations are linked on a page off of Wikipedia.
It's a little too technical. Though it is interesting that they don't have the timescales - I might add those. It's also interesting that one of the pages Wiki links to screws up days and years (http://www.physics.montana.edu/faculty/cornish/la grange.html) for L3's timescale.
The "actually" was because I didn't think you stressed it quite enough. It's more than just "most orbits". It's all the lowest energy ones.
Especially when you realize that if you're transferring cargo, you're almost guaranteed to use the IPS transfers, it's pretty much a given that when humanity starts actively mining asteroids, we're going to need something at almost all of the Lagrange points - both the Earth/Moon and the Earth/Sun ones. Except the Earth/Sun L3. That one sucks.
In fact, by far the most intelligent thing is what was suggested a bit ago by Jerome Pearson. Two lunar space elevators. Since (lunar) L1/L2 are stationary points, and the Moon is rotationally locked, you can build elevators to them (and it'd only take Kevlar, not nanotubes). It's so ridiculously obvious, that I can't imagine that it won't happen, unless there's a dynamic instability someone hasn't thought of.
Actually, the Lagrange points are terribly huge chokepoints - the (apparently) lowest-energy transfers (the Interplanetary Superhighway) all pass through Lagrange points.
This makes the Lagrange points ridiculously useful for future cargo transit through the Solar System. Transfers on the Interplanetary Superhighway cost almost no energy whatsoever. So you could easily imagine staging points at the Lagrange points of several major bodies, holding probes or cargo until a proper path opens up, and then sending something off.
The Genesis mission was one of the first to take an Interplanetary Superhighway path. (Honestly, those orbits drive me nuts. I understood Hohmann transfer orbits. I liked the fact that they were lowest energy. It was obvious. And then while I was still in classes, someone had to come along and prove the whole thing wrong.)
L1 and L2 are unstable on the timescale of 23 days.
L3 is unstable on a timescale of 150 years. That is, it's pretty stable for satellites, just not for planetary bodies. Of course, it also happens to be a friggin' useless orbit, as it never has line of sight visibility with Earth.
L4 and L5 are stable, so long as the mass of the larger object is greater than 24.96 times the mass of the smaller object. (Yes, it's really that odd number: it's actually 25*((1+sqrt(1-4/625))/2) ).
L4 and L5 are actually strange. They don't act like classical stability points, like most people think. If you push something away from L4/L5, it doesn't come back to L4/L5. It does, however, begin to orbit L4/L5, and those orbits are stable.
The big problem with positrons is storing them. Unless these people have a major new idea to get around the Brillouin limit on Penning Traps
They do. It's not a major new idea, since it's been around a while. They're trying to stabilize positronium.
Smith isn't a complete crackpot - he was a professor at PSU when I was there, and was always trying to push limits on Penning traps. He actually built several very small positron traps as well.
That's complete bull. This is completely unrelated to the halting problem - mainly because I'm not suggesting that you could create a program that would recognize *all* compilers, guaranteed.
You could imagine a compiler that looks for string matching to several C constructs, and if it finds that in a program, it inserts a quick first-stage program which checks its arguments to insert the backdoor, then if it doesn't have them, it continues with the rest of the program, otherwise, it spits out the preformed code it's supposed to. Would this be undetectable? No way. Would that guarantee that it would be found? Also no way.
Using the compiler. The C compiler of which you speak only recognized itself and the kernel - any other code that you compiled was not affected, which means that a compiler that you wrote from scratch would not be affected by this back door.
But that idea is easily extendable to a compiler that can recognize other compilers (via language commonalities) as well. It's much much harder to imagine, but it's definitely possible.
There will always be ways around a simple implementation of such a backdoor, sure, but that doesn't mean that in theory you don't have this problem.
In a closed source compiler, there is zero chance.
Not really. You could always disassemble the compiler binary, and examine the assembly. Or just examine the machine code, and find it.
Now, if your response to this is "well, that's far too difficult" then go and read the linked speech by the grandparent. The "backdoor compiler" that was being talked about has no record in the source whatsoever. The backdoor exists simply because compilers are almost always compiled by compilers and run on computers, and so there's a possibility that viral code from the very, very first compilers could remain around for a long time.
Open source is not a guarantee for compilers. It's just much, much harder to put something undetectable in it.
Regardless of whether or not AMD processors support these extensions, the code excutes in slower, emulation mode if it does not detect 'Genuine Intel'.
An important note here is that it's not like you can say "well, Intel can't be forced to know what their competitors implement or don't implement".
You're not supposed to check the vendor ID string to determine whether or not feature sets exist. If you want to know if a processor supports MMX, it's just
mov eax, 1;We want to use the value 1 as our argument
cpuid;call the cpuid instruction
shr edx, 23;shift right 23 times
and edx, 1;'and' out the 1st bit
cmp edx, 0;compare the result with 0
je err;If it's zero this feature's not supported ;Other wise continue
mov eax, 1
ret
This isn't about instruction timing, which sure, they can't be expected to find out about. But these are standards that they themselves published, and they are blatantly ignoring those standards. In fact, they're going out of their way to ignore those standards - it's a lot more effort to check the vendor ID string than just to compare a single bit in the CPUID register.
However, the games must be designed well. In Hot Shots Golf it takes 10 seconds max to load a course to play it. If a racing game took 30 seconds to load a track, no one would play it more than twice. The developers need to be VERY careful with this.
That, of course, is the big mistake. Sony is leaving it up to the developers to cover for this, and that's a huge mistake - because portable games are cheaply made. They always have been. They're (by necessity) simpler than full console games, which means that they'll be put out quicker, and with less testing, than the full console games. This shouldn't be the way things are - but it is.
Racing game that took 30 seconds to load a track? Yah. The PSP has one. Midnight Club 3 takes 70 seconds on average to load a track. And the tracks are only 150 seconds to play!
That's kindof the whole point. The system will get the reputation that the developers give it, not the reputation that it could have if the game was designed well. Even the GBA isn't immune to this - first generation games were very hard to play because they used a poor color palette, and so the GBA got a terrible reputation for having an awful screen. Later games were better, but the damage had already been done.
The onus should be on Sony, not on developers. They never should have let Midnight Club 3 see the light of day - it makes the PSP look horrible. But I think it might be too late.
Mennonites still hold onto the traditions except that they accept "modern" lifestyles - they own cars, TVs, computers, and so forth, but still honor the traditional dress and religious beliefs.
The traditional dress bits are choices, as with most things in the Mennonite church. So some Mennonites will wear traditional dress (like my grandmother) and some will not (like my aunt).
As for technology, same thing goes - some Mennonites use cars. Others don't. It's pretty much just a very "cautious" view of technology, which is probably pretty wise, mind you, in the sense that they don't let technology change who they are.
There are Mennonite churches all over the place, even as far out as Carlisle and as far north as Selinsgrove (not that those names mean anything to people who are not from the area).
There are Mennonite churches all over the place. There are some areas that tend to be more concentrated. Near Eastern Mennonite University in Virginia, for one, in eastern Pennsylvania, eastern Ohio, around Chicago (hours around), but they're pretty much spread all over.
Honestly, the percentage of Mennonites that you'd confuse for Amish probably diminishes every year.
Slashdot Mirror
That makes sense, but it does stand to reason (or, at least, to my reason) that these queries that garner large numbers of results could have had a significant impact on the bottom line of the survey.
Well, there's a worse bias. They're grabbing words from an Ispell word list.
There are websites which contain the Ispell word list. There appear to be more of those returned in Google as results than in Yahoo. (here is one returned in Google for "apprizers expense", but which is not returned in Yahoo.)
This basically contributes a pedestal to their result - they'll never get zero results, because they'll always get the Ispell lists back, and because those results always return the same number (about 8 Google to 1 or 2 Yahoo), you'll bias the results of the entire set to that result.
They needed to remove results which are returned in common to multiple searches, as that's essentially double counting.
No, it's accurate. They're testing Yahoo's claim of how many pages they've indexed, which just means that all indexed pages that contain the requested words should be returned from the search request. If yahoo returns fewer unique pages, yahoo has indexed fewer pages.
Actually, it might not be, thanks to their methodology.
They only used searches with less than 1000 results. They therefore got a lot of searches with small results numbers (because they were searching for bizarre word combinations, like "promotion bedabble"). The total number of results was something like 500,000 or so (order of magnitude) for 10,000 searches. That's an average of 50 results/search, and I'd bet there's a large, large tail, so the most common search is probably something like 10 results.
The problem with this is that in their word list, the same sites are being returned over and over!. For instance, sites containing dictionary lists appear in both "promotion bedabble" and "foliolate defecations" because, duh, that's the only place they'll appear. Since they're just searching the same type of site over and over, they get the same result magnified a lot: Google has more "dictionary lists" in its index than Yahoo. Most of the "dictionary list" word searches returned about 10-20 for Google, and few, if any, for Yahoo.
It's a pretty serious flaw in the methodology, as far as I can tell - they're double counting huge numbers of results, and so they're not really getting a good statistical sample of the index.
I remember telling my neighbor the next thing you'd know they'd be making a Mario RPG
Square did, actually. Joint venture between Square & Nintendo. Proved to be so succesful that Nintendo made three sequels: Paper Mario, Paper Mario 2, and Mario & Luigi: Superstar Saga.
Fantastic games. Feel free to bash them all you want, but who cares if they're reusing some characters? The characters don't matter as much as the gameplay does, which is fantastic.
I disagree completely with you and saying that this is not enough for sustainable human development. I'm sure this is enough water to sustain development for years to come, long enough for somebody to find water somewhere else.
Well, it's of order 20 trillion liters (10mi*10mi*200 feet) of ice (which is about the same volume as the equivalent liquid water content - ice is only about 10% less dense).
A random site says that Americans use on average 80-100 gallons per day, which means that water would supply a colony of 10,000 for 11,000 years.
Yes, the water needs for a colony are higher than the water needs for a person, but an off-planet colony probably is going to recycle water (one would hope), so I'd imagine actually that it probably works out pretty well.
So yah, I agree with you. This is a heckuva lot of water.
But this problem is easily fixed - instead of giving spam-chess the move sequence, give it the board state as a function of move number. You could easily write a program which does this from the games.
I'm not sure that this is the limitation, though. For one thing, if you play as if board state is the only thing that matters, then you're completely ignoring playing style of the person you're playing. A move sequence contains more information than the board state, not less. So in theory, you may be able to play better, not worse. Of course, this is in theory - in practice it does mean the signal/noise of the data is lower.
I think the main limitation - not being able to understand values of exchanges - is probably the biggest problem. It's also the easiest to fix, as you can just write a program to add the piece that's being taken (i.e. instead of Bxc4, you'd have BxBc4). The relative value of each piece can be determined just from the number of times an exchange happens for winners.
Sounds like a good place to put a radiotelescope, particularly one dedicated to SETI.
No. You've still got the Sun right there. Lunar L3 would be a good place to put a radio telescope, as it's dark for half the month (no solar interference) and the Moon shields you from Earth-based interference.
Solar L3 isn't particularly great for anything. It's pretty much the least useful Lagrange point.
Actually that is the classical mathematical definition of stability of a fixed point of a dynamical system -- if you start close you stay close.
Well, it's kinda like that. With a pendulum, there's a restoring force back to the point of equilibrium. With L4/L5, there's a restoring force about the point of equilibrium.
With a pendulum, you're always guaranteed to pass back through the equilibrium point - the mean displacement is always zero. With L4/L5, that's not true.
The description of L4/L5 as a valley isn't really correct. If you displace from L4, you go into an orbit around L4. You don't go back through it.
The L1 and L2 points aren't *stable*, so it's not clear to me a priori that space elevators to those points from the Moon would work out so well.
Geosynchronous orbit isn't stable either - if you push away from it, you don't come back. But an elevator to there is stable, because it's anchored to the planet - so moving radially outward, tension pulls you back inward. Moving inward, the planet's rotation pulls you back outward. Same goes for each of the other directions. It's exactly the same for the lunar elevators to L1/L2.
Putting a lunar elevator there is an excellent way of avoiding propellant. It's also most likely extremely cheap, since all you need is a really long Kevlar cable.
It's 150 years. The page you most commonly see is wrong - it confuses days and years.
To be specific, it's 1/(Omega*sqrt(3*M_1/5*M_2)).
Omega is 2*pi/year (angular revolution rate of the Earth). M_1 is Earth, M_2 is the Sun, and Google says that when you add in the rest it's 150 years.
You can find a good derivation of it here.
Long story short, your space elevator would begin wrapping itself around the Earth in very short order.
Sorry, I meant affixed to the Moon, not affixed to the Earth. The reason it'd be cheap is because the Moon's gravity is much less than Earth's - so you'd only need something like Kevlar to be strong enough.
None of the Lagrange points can really be "occupied". None of them are stable in the classical sense (i.e. a fixed point in space that everything falls down to). SOHO, WMAP (and in the future, JWST) will all be in orbits about the Lagrange points.
Just because there's one thing there doesn't mean there can't be others. Plus, the ones we're mentioning here are just the solar Lagrange points. The lunar Lagrange points are all unoccupied (as far as I know...). The lunar L1/L2 are terrific places for a cheap, easy to build space elevator.
The derivations are linked on a page off of Wikipedia.
a grange.html) for L3's timescale.
It's a little too technical. Though it is interesting that they don't have the timescales - I might add those. It's also interesting that one of the pages Wiki links to screws up days and years (http://www.physics.montana.edu/faculty/cornish/l
The "actually" was because I didn't think you stressed it quite enough. It's more than just "most orbits". It's all the lowest energy ones.
Especially when you realize that if you're transferring cargo, you're almost guaranteed to use the IPS transfers, it's pretty much a given that when humanity starts actively mining asteroids, we're going to need something at almost all of the Lagrange points - both the Earth/Moon and the Earth/Sun ones. Except the Earth/Sun L3. That one sucks.
In fact, by far the most intelligent thing is what was suggested a bit ago by Jerome Pearson. Two lunar space elevators. Since (lunar) L1/L2 are stationary points, and the Moon is rotationally locked, you can build elevators to them (and it'd only take Kevlar, not nanotubes). It's so ridiculously obvious, that I can't imagine that it won't happen, unless there's a dynamic instability someone hasn't thought of.
Completely avoids the entire stability problem.
(Lagrange! Not LaGrange! It scares me that our own military can't even bother looking up in a damned encyclopedia how to spell a person's name.)
L3 is actually pretty stable - on a period of about 150 years. It's just that it's in an amazingly useless orbit, so who cares if it's stable or not.
The webpage that you linked to screws up days and years for L3.
Actually, the Lagrange points are terribly huge chokepoints - the (apparently) lowest-energy transfers (the Interplanetary Superhighway) all pass through Lagrange points.
This makes the Lagrange points ridiculously useful for future cargo transit through the Solar System. Transfers on the Interplanetary Superhighway cost almost no energy whatsoever. So you could easily imagine staging points at the Lagrange points of several major bodies, holding probes or cargo until a proper path opens up, and then sending something off.
The Genesis mission was one of the first to take an Interplanetary Superhighway path. (Honestly, those orbits drive me nuts. I understood Hohmann transfer orbits. I liked the fact that they were lowest energy. It was obvious. And then while I was still in classes, someone had to come along and prove the whole thing wrong.)
L1 and L2 are unstable on the timescale of 23 days.
L3 is unstable on a timescale of 150 years. That is, it's pretty stable for satellites, just not for planetary bodies. Of course, it also happens to be a friggin' useless orbit, as it never has line of sight visibility with Earth.
L4 and L5 are stable, so long as the mass of the larger object is greater than 24.96 times the mass of the smaller object. (Yes, it's really that odd number: it's actually 25*((1+sqrt(1-4/625))/2) ).
L4 and L5 are actually strange. They don't act like classical stability points, like most people think. If you push something away from L4/L5, it doesn't come back to L4/L5. It does, however, begin to orbit L4/L5, and those orbits are stable.
I'd be much happier if we conquered the Lagrange points first.
It's not capitalized oddly. It's just spelled Lagrange. As in, Joseph Louis Lagrange.
The big problem with positrons is storing them. Unless these people have a major new idea to get around the Brillouin limit on Penning Traps
They do. It's not a major new idea, since it's been around a while. They're trying to stabilize positronium.
Smith isn't a complete crackpot - he was a professor at PSU when I was there, and was always trying to push limits on Penning traps. He actually built several very small positron traps as well.
That's complete bull. This is completely unrelated to the halting problem - mainly because I'm not suggesting that you could create a program that would recognize *all* compilers, guaranteed.
You could imagine a compiler that looks for string matching to several C constructs, and if it finds that in a program, it inserts a quick first-stage program which checks its arguments to insert the backdoor, then if it doesn't have them, it continues with the rest of the program, otherwise, it spits out the preformed code it's supposed to. Would this be undetectable? No way. Would that guarantee that it would be found? Also no way.
I think that was Ken Thompson's original point, actually.
And mine as well. The point is that open source doesn't preclude really bad things from happening. It just makes it much, much harder to hide them.
Using the compiler. The C compiler of which you speak only recognized itself and the kernel - any other code that you compiled was not affected, which means that a compiler that you wrote from scratch would not be affected by this back door.
But that idea is easily extendable to a compiler that can recognize other compilers (via language commonalities) as well. It's much much harder to imagine, but it's definitely possible.
There will always be ways around a simple implementation of such a backdoor, sure, but that doesn't mean that in theory you don't have this problem.
In a closed source compiler, there is zero chance.
Not really. You could always disassemble the compiler binary, and examine the assembly. Or just examine the machine code, and find it.
Now, if your response to this is "well, that's far too difficult" then go and read the linked speech by the grandparent. The "backdoor compiler" that was being talked about has no record in the source whatsoever. The backdoor exists simply because compilers are almost always compiled by compilers and run on computers, and so there's a possibility that viral code from the very, very first compilers could remain around for a long time.
Open source is not a guarantee for compilers. It's just much, much harder to put something undetectable in it.
An important note here is that it's not like you can say "well, Intel can't be forced to know what their competitors implement or don't implement".
You're not supposed to check the vendor ID string to determine whether or not feature sets exist. If you want to know if a processor supports MMX, it's just(blatantly stolen from http://www.gamedev.net/reference/articles/article
This isn't about instruction timing, which sure, they can't be expected to find out about. But these are standards that they themselves published, and they are blatantly ignoring those standards. In fact, they're going out of their way to ignore those standards - it's a lot more effort to check the vendor ID string than just to compare a single bit in the CPUID register.
However, the games must be designed well. In Hot Shots Golf it takes 10 seconds max to load a course to play it. If a racing game took 30 seconds to load a track, no one would play it more than twice. The developers need to be VERY careful with this.
That, of course, is the big mistake. Sony is leaving it up to the developers to cover for this, and that's a huge mistake - because portable games are cheaply made. They always have been. They're (by necessity) simpler than full console games, which means that they'll be put out quicker, and with less testing, than the full console games. This shouldn't be the way things are - but it is.
Racing game that took 30 seconds to load a track? Yah. The PSP has one. Midnight Club 3 takes 70 seconds on average to load a track. And the tracks are only 150 seconds to play!
That's kindof the whole point. The system will get the reputation that the developers give it, not the reputation that it could have if the game was designed well. Even the GBA isn't immune to this - first generation games were very hard to play because they used a poor color palette, and so the GBA got a terrible reputation for having an awful screen. Later games were better, but the damage had already been done.
The onus should be on Sony, not on developers. They never should have let Midnight Club 3 see the light of day - it makes the PSP look horrible. But I think it might be too late.
Mennonites still hold onto the traditions except that they accept "modern" lifestyles - they own cars, TVs, computers, and so forth, but still honor the traditional dress and religious beliefs.
The traditional dress bits are choices, as with most things in the Mennonite church. So some Mennonites will wear traditional dress (like my grandmother) and some will not (like my aunt).
As for technology, same thing goes - some Mennonites use cars. Others don't. It's pretty much just a very "cautious" view of technology, which is probably pretty wise, mind you, in the sense that they don't let technology change who they are.
There are Mennonite churches all over the place, even as far out as Carlisle and as far north as Selinsgrove (not that those names mean anything to people who are not from the area).
There are Mennonite churches all over the place. There are some areas that tend to be more concentrated. Near Eastern Mennonite University in Virginia, for one, in eastern Pennsylvania, eastern Ohio, around Chicago (hours around), but they're pretty much spread all over.
Honestly, the percentage of Mennonites that you'd confuse for Amish probably diminishes every year.