I guess I agree with you there, though I miss my old iPhone. My G1 seems like a Model T in comparison hardware-wise, but I don't think I can go back to the no-keyboard situation. My old eyes just don't work well enough to find those small keys.
I looked at all the photos of the new phone. Here's some insights from a G1 owner:
- The screen is *exactly* the same model. It's nice, but only 2.5". Every time I hold an iPhone, what really strikes me is that huge 3.5" screen. - They *still* don't have a headset jack. This is possibly the dumbest lack of a feature ever in a smart phone, and they kept it! The non-standard headphones HTC ships suck, you have to have a bulky dongle to use anything else, and you can't charge while listening to music. Sucks, sucks, sucks! - The camera lens appears larger, possibly meaning that HTC decided not to ruin all photos with a crap lens like on the G1. Of course, it could just be the same lens with a new style case. - Being HTC, there's no way this phone has a bigger battery than the G1, and battery life will suck. - The slot for the speaker looks identical the the G1. On the G1, it fills up with lint, and you can't hear calls when there's background noise, like while driving or at a restaurant (much to the pleasure of everyone else).
Until someone fixes the damned headphone issue, the speaker, the camera, and increases the screen size on an Android phone, I'll stick with my crappy G1.
I've had an iPhone, and currently own a T-Mobile G1. In short, Android is a solid competitor (the only competitor IMO) to the iPhone OS. The actual G1 phone however, sucks big time, as GP suggests, though he didn't get close as to why:
- The speaker slot gets clogged with lint, and now I have trouble hearing the phone - While the camera has auto-focus and more pixels than iPhone, HTC screwed up with a crappy lens that ruins all photos - There's no headphone jack. Instead, HTC provides crappy headphones using a non-standard extension to the micro-USB jack - The phone is too thick, and not nearly as sleek or well designed or packaged as the iPhone - The battery is tiny in comparison to the iPhone.
Basically, some US company (Qualcom? T-Mobile?) must have said "Here's the specs for you, HTC", and then HTC delivered on the specs, but screwed up the phone.
While there are fewer users of the G1, there are proportionally fewer developers. Many of the best application spaces are already dominated on iPhone, while they're still open on Android. I believe that future Android phones will gain in market share vs iPhone, making development for Android a wise choice.
Diane has been technology illiterate for her entire career. In general, her heart is in the right place, but as Silicon Valley's senator, she's shamefully lacking in any sort of reasonable understanding of the issues.
Quite seriously, she hears, "let's protect our children", and "let's protect intellectual property", and that convinces her to support Trojan legislation designed to allow telcoms to put toll roads on the Internet.
Here's the skinny on EEStor, so far as I can read.
Their new patent is a clean-up version of their old patent. Unfortunately, it's still a piece of marketing BS. Look at claim 1. It has 15 steps! If you avoid any one of them, you do not infringe. The rest of the patent is similar - not designed to protect, but designed to market an idea.
The physics of EEStor seems to have been replicated by half a dozen other companies, so we can probably begin to believe that the EEStore ultra-capacitors are possible in principle. However, a fully charged EEStor capacitor will explode on impact with about the force of 100 sticks of dynamite. I've thought about this problem for two years, without any solution. Hopefully the guys at EEStor are wiser, but no one else on the Internet has a solution either.
In short, don't bother believing this until you see it.
It turns out that this is not the first time geothermal energy plants have drilled into hot magma. They had a similar experience decades ago in Iceland. Unfortunately, it was a story told to me by a professor at Berkeley in 1985, so I'm not able to google any info on it.
Yep! If you talk to DSP guys, they do this kind of thing all the time. DataDraw allows me to specify which fields of a class I want kept together in memory, and by default, they're kept in arrays of individual properties. I was able to speed up random-access of large red-black trees in DataDraw 50% with this feature, simply because you almost always want both the left and right child pointers, not just one or the other.
Nice to hear from a fellow geek who for whatever reason still keeps an eye on low-level performance.
Not a bad idea, but where would I publish it? I could post it on my Dumb Idea of the Day blog, but no one reads it (which is ok with me). I would certainly be interested in writing an article about coding for cache performance.
Check out the benchmark table at this informative link. On every cache miss, the CPU loads an entire cache line, typically 64 or more bytes. Cache miss rates are massively dependent on the probability that those extra bytes will soon be accessed. Since typical structures and objects are 64 bytes or more, the cache line typically gets filled with fields of just one object. Typical inner loops may access two of those object's fields, but rarely three, meaning that the cache is loaded with useless junk. By keeping data of like fields together in arrays, the cache line will be filled with the same field, but from different objects, often objects that will soon be accessed. This, plus the 32 vs 64 bit object references, and cache-sensitive memory organization (unlike malloc), leads to a 7X speedup in DataDraw backed graph traversals vs plain C code.
Understanding cache performance is critical for fast code, yet most programmers are virtually clueless about it. Just run the benchmarks yourself if you want to see the impact.
The sad part is that improved runtime speed and code readability can be had together at the same time. The reason the DataDraw based code ran 7x faster was simple: cache performance. C, C++, D, and C# all specify the layout of objects in memory, making it impossible for the compiler to optimize cache hit rates. If we simply go to a slightly more readable higher level of coding, and let the compiler muck with the individual bits and bytes, huge performance gains can be had. The reason DataDraw saved 40% in memory was that it uses 32-bit integers to reference graph objects rather than 64-bit pointers. Again, C, C++, and most languages specify a common pointer size for all class types. If the compiler were allowed to take over that task, life would be easier for the programmer, and we'd save a ton of memory.
But then again... what's a mere factor of 7X runtime with today's computers? With the low price of DRAM, who cares about 40%? It's easier to stick with the crud we've used since 1970 (C, and it's offspring) than to bother building more efficient languages. Language research has abandoned efficiency as a goal.
Good point. With solid-state drives coming down the pipe, even that bottle-neck will be somewhat relieved for what most people do (lot's of disk reads, few writes). I write programs to help designers place and route chips. The problem size scales with Moore's Law, so we never have enough CPU power. I'm part of a shrinking population that remains focused on squeezing a bit more power out of their code. I wrote the DataDraw CASE tool to dramatically improve overall place-and-route performance, but few programmers care all that much now days. On routing-graph traversal benchmarks, it sped up C-code 7X while cutting memory required by 40%. But what's a factor of 7 now days?
If you mean this patent then don't worry too much. Apple didn't invent multi-touch (these guys did), nor did they patent the way it's currently used. They patented extensions, such as performing cut and paste with gestures. Why the G1 has no multi-touch is a mystery to me.
I agree with the article that Apple could find itself marginalized by Android in 5 years much like Windows marginalized Macs years ago. However, making it open-source wont help. I agree that users don't care about open-source vs closed-source. What Steve Jobs needs to do is license the iPhone software cheaply or even free. Of course, he wont. I've used both Android and iPhone extensively. Android is a bit behind iPhone, but is on a steeper improvement curve. It will be an interesting five years to watch.
I agree that C++ GUI code (like Valve's Source engine) are better than the old C GUI libraries. C++ is a good fit for describing class hierarchies of GUI widgets. It's not all bad, but not all good, either.
While C++ works well for trees, consider graphs. Two classes, not just one (Nodes and Edges, rather than just Nodes). If there is a C++ database containing a graph, and you want to manipulate that graph, how do you do it? In C++, your life becomes harder than it should be at that point (do you attach void pointers to allow kludged extensions to database objects, or inherit from them directly and do copy-in/copy-out?). The only reasonable C++ graph library I've seen is the Boost Graph Library. If you care for a life of pain, make this the basis of your next big EDA project. Alternatively, if you store those graphs in a DataDraw database, your code is hugely simplified, while running far faster.
I do EDA coding for a living. Life as an EDA programmer is basically all about manipulating graphs. C++ and EDA have never worked out well together, but nor has Java, C#, or any other mainstream language. You need dynamic extension, like Python, but raw-speed, like C. Today, that means DataDraw.
Here's my beef with C++. Average to less-than-average programmers will never understand virtual functions, templates, or (shudder) multiple inheritance. New code is normally written by super-smart programmers who use all that stuff. Then, the B-team takes it over and can't figure out what the heck it does. The code is then doomed to painful process of continuous decay.
C++ was written by PhD's for PhD's. It was never a good fit for the real world. Java is a huge step forward for the world, just not graduate programs. Personally, I have 100 other issues with modern languages, which is why I do all my programming with the DataDraw variant of C.
I haven't used a BlackBerry, so I can't compare to that. However, I use to own an iPhone, so I can compare against the software available there early on. The iPhone had no cut and paste, no ability to download files, but the POP client worked OK. There was also no app store, only a 4-function calculator, and no dial-by-voice. In comparison to the iPhone trajectory, Android looks quite good to me.
IANAL, but my understanding is that you may not legally hack the modem itself or it's software driver. You do not break any law by writing software that manipulates the modem through it's provided driver, so feel free to hack at that level.
Like all cell phones, you are not legally allowed to hack the actual modem. Ultimate protection is at the modem layer.
Personally, I think this is another huge step for Google/Android. I've already bought a G1, and the software from Google rocks. Unfortunately, the hardware from Taiwan's HTC sucks big-time. I'm eagerly awaiting Motorola's Android offering next year, and T-Mobile's G3 roll-out in NC. The iPhone is awesome, but Android is a huge threat.
I'm one of those guys who just dropped XM radio. The commercials they run on may channels really pissed me off. I also got rid of my last Windows machine after Vista came out. Guess what my in-laws got me and the kids for presents this year? A Windows Vista box, and a new subscription to XM radio! Apparently, they're worried about my highly non-conformist streak.
I'm glad to hear about your daughter. My brother had a similar diagnosis when little. I remember my parents trying to figure out how to buy a dialysis machine. He had a "miraculous" recovery. Fortunately for me, I'm in a good position to do well with very poor eye sight, so don't worry about me.
He'd also have to be running the software on a specific day that occurred before it's release. That pretty much meant only the Bill Falk at QuickLogic would be affected.
The software at that point was a half million lines of code, written by just a hand full of guys. We didn't worry if our easter eggs could cause problems... we just prayed the damned thing would work at all! Easter eggs are usually a good idea. They give recognition to people who deserve it, yet do work so obscure that few ever acknowledge it. I even put an easter egg in the original Pascal/DOS version of the Simple Switcher power-supply design software: if you ran strings on the executable, right at the top was a nice blurb about the developers. Programmers are people, too. A pat on the back goes a long way.
The Internet can also be a useful tool in cases of rare diseases. In my case, I'm losing vision rapidly, due to an unusual cone dystrophy. After visiting many Ophthalmologists, the verdict is in: I'm going legally blind, fairly rapidly, and there's nothing that can be done about it. No particular doctor has the time to research exactly what's going on in my case, so the Internet is my friend.
After much research on-line, I think I've found the only published study on-line of anyone with my specific condition. If you Google "Protanopia cone dystrophy bullseye", the top link is a paper from 1995 describing two men with similar problems, one of whom is fairly likely to have the same genetic eye disorder as me (hybrid L/M cones). Of course, the paper simply reported the condition, and possible cause. The doctors are right - there's nothing to be done. At least now, I have some idea of what might actually be wrong. It sucks to be going blind and wonder if it was all that pot I smoked in high school, or a tick bite, or any of a thousand things. When your doctors are clueless, the Internet can still provide some insight, and in my case, provide some comfort.
Any good software company should allow easter eggs. Back in the good-old days at QuickLogic, we had an awesome movie-like credit's screen with something funny about every contributer. At the new company I founded, I've lost control over our easter-egg policy, and they've been removed:-(
There was one funny episode at QuickLogic. Bill Falk was the manager, and he just about had a heart attack any time there were show-stopper bugs found late in a software release process. So, after we already bought something like 4,000 copies of our release on floppies, a very special easter egg went off. It detected if your name was Bill Falk and if it were a specific date, and then invoked some of the worst possible crashes - the stuff that's random each time, and depends on debug mode vs compiled. We all laughed so hard when Bill went ballistic, we never dreamed our easter egg would work so well. After seeing how hard it was on him, we decided never to do that to him again. The next release came around, and this time there was a real show-stopper late-stage bug, and Bill was convinced we'd planted another easter egg. It got pretty ugly.
From some back-of-the-envelope calculations it seems that we already have enough power generation and electrical distribution in the Bay Area and in most places to charge Chevy Volt-like cars overnight on our existing 220V. It might be nice to charge faster than 8 hours, or at work as well as home, but I don't see this as a major technology adoption problem.
The grid and power stations are designed to deliver about 3KW average to each household during peak hours in the summer heat. A single 220 outlet typically can deliver 3KW continuously. A Chevy Volt will need no more than 20KW hours of juice to charge. The math works.
The grid is barley taxed during the night, so this is a match made in heaven. The build-out we really need is an interstate-HVDC grid to deliver renewable power across the country from wherever it's generated. This can't be done at the state level, and will require action by Obama.
Re:No revenge needed. Was:Re:Revenge of the Nerds.
on
American Nerd
·
· Score: 3, Interesting
A wise observation, IMO. I hate to think how mean I was to little girls in the neighborhood before I hit puberty. I think high school is a bit like that - a phase you grow out of.
Still, I can't forgive the rednecks from Stone Mountain. I turned out OK, and I can probably thank the rednecks for part of my drive to succeed (to prove them wrong). But my friends didn't have my luck. Most have never overcome the damage done to their self-image at a young age. I think their lives and all of America would be much better off if we were to build up the self esteem of our most talented geeks.
I read a cool article on being tall. In general, each inch of height is worth about $2K/year in extra income for a guy. However, it doesn't matter how tall you are... what matters is how tall you were when you were sixteen. Guys who sprout in their twenties don't benefit.
I guess I agree with you there, though I miss my old iPhone. My G1 seems like a Model T in comparison hardware-wise, but I don't think I can go back to the no-keyboard situation. My old eyes just don't work well enough to find those small keys.
I looked at all the photos of the new phone. Here's some insights from a G1 owner:
- The screen is *exactly* the same model. It's nice, but only 2.5". Every time I hold an iPhone, what really strikes me is that huge 3.5" screen.
- They *still* don't have a headset jack. This is possibly the dumbest lack of a feature ever in a smart phone, and they kept it! The non-standard headphones HTC ships suck, you have to have a bulky dongle to use anything else, and you can't charge while listening to music. Sucks, sucks, sucks!
- The camera lens appears larger, possibly meaning that HTC decided not to ruin all photos with a crap lens like on the G1. Of course, it could just be the same lens with a new style case.
- Being HTC, there's no way this phone has a bigger battery than the G1, and battery life will suck.
- The slot for the speaker looks identical the the G1. On the G1, it fills up with lint, and you can't hear calls when there's background noise, like while driving or at a restaurant (much to the pleasure of everyone else).
Until someone fixes the damned headphone issue, the speaker, the camera, and increases the screen size on an Android phone, I'll stick with my crappy G1.
I've had an iPhone, and currently own a T-Mobile G1. In short, Android is a solid competitor (the only competitor IMO) to the iPhone OS. The actual G1 phone however, sucks big time, as GP suggests, though he didn't get close as to why:
- The speaker slot gets clogged with lint, and now I have trouble hearing the phone
- While the camera has auto-focus and more pixels than iPhone, HTC screwed up with a crappy lens that ruins all photos
- There's no headphone jack. Instead, HTC provides crappy headphones using a non-standard extension to the micro-USB jack
- The phone is too thick, and not nearly as sleek or well designed or packaged as the iPhone
- The battery is tiny in comparison to the iPhone.
Basically, some US company (Qualcom? T-Mobile?) must have said "Here's the specs for you, HTC", and then HTC delivered on the specs, but screwed up the phone.
While there are fewer users of the G1, there are proportionally fewer developers. Many of the best application spaces are already dominated on iPhone, while they're still open on Android. I believe that future Android phones will gain in market share vs iPhone, making development for Android a wise choice.
Diane has been technology illiterate for her entire career. In general, her heart is in the right place, but as Silicon Valley's senator, she's shamefully lacking in any sort of reasonable understanding of the issues.
Quite seriously, she hears, "let's protect our children", and "let's protect intellectual property", and that convinces her to support Trojan legislation designed to allow telcoms to put toll roads on the Internet.
Thanks for the links. Did you forget Fly the Road?
Here's the skinny on EEStor, so far as I can read.
Their new patent is a clean-up version of their old patent. Unfortunately, it's still a piece of marketing BS. Look at claim 1. It has 15 steps! If you avoid any one of them, you do not infringe. The rest of the patent is similar - not designed to protect, but designed to market an idea.
The physics of EEStor seems to have been replicated by half a dozen other companies, so we can probably begin to believe that the EEStore ultra-capacitors are possible in principle. However, a fully charged EEStor capacitor will explode on impact with about the force of 100 sticks of dynamite. I've thought about this problem for two years, without any solution. Hopefully the guys at EEStor are wiser, but no one else on the Internet has a solution either.
In short, don't bother believing this until you see it.
It turns out that this is not the first time geothermal energy plants have drilled into hot magma. They had a similar experience decades ago in Iceland. Unfortunately, it was a story told to me by a professor at Berkeley in 1985, so I'm not able to google any info on it.
Yep! If you talk to DSP guys, they do this kind of thing all the time. DataDraw allows me to specify which fields of a class I want kept together in memory, and by default, they're kept in arrays of individual properties. I was able to speed up random-access of large red-black trees in DataDraw 50% with this feature, simply because you almost always want both the left and right child pointers, not just one or the other.
Nice to hear from a fellow geek who for whatever reason still keeps an eye on low-level performance.
Not a bad idea, but where would I publish it? I could post it on my Dumb Idea of the Day blog, but no one reads it (which is ok with me). I would certainly be interested in writing an article about coding for cache performance.
Check out the benchmark table at this informative link. On every cache miss, the CPU loads an entire cache line, typically 64 or more bytes. Cache miss rates are massively dependent on the probability that those extra bytes will soon be accessed. Since typical structures and objects are 64 bytes or more, the cache line typically gets filled with fields of just one object. Typical inner loops may access two of those object's fields, but rarely three, meaning that the cache is loaded with useless junk. By keeping data of like fields together in arrays, the cache line will be filled with the same field, but from different objects, often objects that will soon be accessed. This, plus the 32 vs 64 bit object references, and cache-sensitive memory organization (unlike malloc), leads to a 7X speedup in DataDraw backed graph traversals vs plain C code.
Understanding cache performance is critical for fast code, yet most programmers are virtually clueless about it. Just run the benchmarks yourself if you want to see the impact.
The sad part is that improved runtime speed and code readability can be had together at the same time. The reason the DataDraw based code ran 7x faster was simple: cache performance. C, C++, D, and C# all specify the layout of objects in memory, making it impossible for the compiler to optimize cache hit rates. If we simply go to a slightly more readable higher level of coding, and let the compiler muck with the individual bits and bytes, huge performance gains can be had. The reason DataDraw saved 40% in memory was that it uses 32-bit integers to reference graph objects rather than 64-bit pointers. Again, C, C++, and most languages specify a common pointer size for all class types. If the compiler were allowed to take over that task, life would be easier for the programmer, and we'd save a ton of memory.
But then again... what's a mere factor of 7X runtime with today's computers? With the low price of DRAM, who cares about 40%? It's easier to stick with the crud we've used since 1970 (C, and it's offspring) than to bother building more efficient languages. Language research has abandoned efficiency as a goal.
Good point. With solid-state drives coming down the pipe, even that bottle-neck will be somewhat relieved for what most people do (lot's of disk reads, few writes). I write programs to help designers place and route chips. The problem size scales with Moore's Law, so we never have enough CPU power. I'm part of a shrinking population that remains focused on squeezing a bit more power out of their code. I wrote the DataDraw CASE tool to dramatically improve overall place-and-route performance, but few programmers care all that much now days. On routing-graph traversal benchmarks, it sped up C-code 7X while cutting memory required by 40%. But what's a factor of 7 now days?
If you mean this patent then don't worry too much. Apple didn't invent multi-touch (these guys did), nor did they patent the way it's currently used. They patented extensions, such as performing cut and paste with gestures. Why the G1 has no multi-touch is a mystery to me.
I agree with the article that Apple could find itself marginalized by Android in 5 years much like Windows marginalized Macs years ago. However, making it open-source wont help. I agree that users don't care about open-source vs closed-source. What Steve Jobs needs to do is license the iPhone software cheaply or even free. Of course, he wont. I've used both Android and iPhone extensively. Android is a bit behind iPhone, but is on a steeper improvement curve. It will be an interesting five years to watch.
I agree that C++ GUI code (like Valve's Source engine) are better than the old C GUI libraries. C++ is a good fit for describing class hierarchies of GUI widgets. It's not all bad, but not all good, either.
While C++ works well for trees, consider graphs. Two classes, not just one (Nodes and Edges, rather than just Nodes). If there is a C++ database containing a graph, and you want to manipulate that graph, how do you do it? In C++, your life becomes harder than it should be at that point (do you attach void pointers to allow kludged extensions to database objects, or inherit from them directly and do copy-in/copy-out?). The only reasonable C++ graph library I've seen is the Boost Graph Library. If you care for a life of pain, make this the basis of your next big EDA project. Alternatively, if you store those graphs in a DataDraw database, your code is hugely simplified, while running far faster.
I do EDA coding for a living. Life as an EDA programmer is basically all about manipulating graphs. C++ and EDA have never worked out well together, but nor has Java, C#, or any other mainstream language. You need dynamic extension, like Python, but raw-speed, like C. Today, that means DataDraw.
Here's my beef with C++. Average to less-than-average programmers will never understand virtual functions, templates, or (shudder) multiple inheritance. New code is normally written by super-smart programmers who use all that stuff. Then, the B-team takes it over and can't figure out what the heck it does. The code is then doomed to painful process of continuous decay.
C++ was written by PhD's for PhD's. It was never a good fit for the real world. Java is a huge step forward for the world, just not graduate programs. Personally, I have 100 other issues with modern languages, which is why I do all my programming with the DataDraw variant of C.
I haven't used a BlackBerry, so I can't compare to that. However, I use to own an iPhone, so I can compare against the software available there early on. The iPhone had no cut and paste, no ability to download files, but the POP client worked OK. There was also no app store, only a 4-function calculator, and no dial-by-voice. In comparison to the iPhone trajectory, Android looks quite good to me.
IANAL, but my understanding is that you may not legally hack the modem itself or it's software driver. You do not break any law by writing software that manipulates the modem through it's provided driver, so feel free to hack at that level.
Like all cell phones, you are not legally allowed to hack the actual modem. Ultimate protection is at the modem layer.
Personally, I think this is another huge step for Google/Android. I've already bought a G1, and the software from Google rocks. Unfortunately, the hardware from Taiwan's HTC sucks big-time. I'm eagerly awaiting Motorola's Android offering next year, and T-Mobile's G3 roll-out in NC. The iPhone is awesome, but Android is a huge threat.
I'm one of those guys who just dropped XM radio. The commercials they run on may channels really pissed me off. I also got rid of my last Windows machine after Vista came out. Guess what my in-laws got me and the kids for presents this year? A Windows Vista box, and a new subscription to XM radio! Apparently, they're worried about my highly non-conformist streak.
I'm glad to hear about your daughter. My brother had a similar diagnosis when little. I remember my parents trying to figure out how to buy a dialysis machine. He had a "miraculous" recovery. Fortunately for me, I'm in a good position to do well with very poor eye sight, so don't worry about me.
He'd also have to be running the software on a specific day that occurred before it's release. That pretty much meant only the Bill Falk at QuickLogic would be affected.
The software at that point was a half million lines of code, written by just a hand full of guys. We didn't worry if our easter eggs could cause problems... we just prayed the damned thing would work at all! Easter eggs are usually a good idea. They give recognition to people who deserve it, yet do work so obscure that few ever acknowledge it. I even put an easter egg in the original Pascal/DOS version of the Simple Switcher power-supply design software: if you ran strings on the executable, right at the top was a nice blurb about the developers. Programmers are people, too. A pat on the back goes a long way.
The Internet can also be a useful tool in cases of rare diseases. In my case, I'm losing vision rapidly, due to an unusual cone dystrophy. After visiting many Ophthalmologists, the verdict is in: I'm going legally blind, fairly rapidly, and there's nothing that can be done about it. No particular doctor has the time to research exactly what's going on in my case, so the Internet is my friend.
After much research on-line, I think I've found the only published study on-line of anyone with my specific condition. If you Google "Protanopia cone dystrophy bullseye", the top link is a paper from 1995 describing two men with similar problems, one of whom is fairly likely to have the same genetic eye disorder as me (hybrid L/M cones). Of course, the paper simply reported the condition, and possible cause. The doctors are right - there's nothing to be done. At least now, I have some idea of what might actually be wrong. It sucks to be going blind and wonder if it was all that pot I smoked in high school, or a tick bite, or any of a thousand things. When your doctors are clueless, the Internet can still provide some insight, and in my case, provide some comfort.
Any good software company should allow easter eggs. Back in the good-old days at QuickLogic, we had an awesome movie-like credit's screen with something funny about every contributer. At the new company I founded, I've lost control over our easter-egg policy, and they've been removed :-(
There was one funny episode at QuickLogic. Bill Falk was the manager, and he just about had a heart attack any time there were show-stopper bugs found late in a software release process. So, after we already bought something like 4,000 copies of our release on floppies, a very special easter egg went off. It detected if your name was Bill Falk and if it were a specific date, and then invoked some of the worst possible crashes - the stuff that's random each time, and depends on debug mode vs compiled. We all laughed so hard when Bill went ballistic, we never dreamed our easter egg would work so well. After seeing how hard it was on him, we decided never to do that to him again. The next release came around, and this time there was a real show-stopper late-stage bug, and Bill was convinced we'd planted another easter egg. It got pretty ugly.
From some back-of-the-envelope calculations it seems that we already have enough power generation and electrical distribution in the Bay Area and in most places to charge Chevy Volt-like cars overnight on our existing 220V. It might be nice to charge faster than 8 hours, or at work as well as home, but I don't see this as a major technology adoption problem.
The grid and power stations are designed to deliver about 3KW average to each household during peak hours in the summer heat. A single 220 outlet typically can deliver 3KW continuously. A Chevy Volt will need no more than 20KW hours of juice to charge. The math works.
The grid is barley taxed during the night, so this is a match made in heaven. The build-out we really need is an interstate-HVDC grid to deliver renewable power across the country from wherever it's generated. This can't be done at the state level, and will require action by Obama.
A wise observation, IMO. I hate to think how mean I was to little girls in the neighborhood before I hit puberty. I think high school is a bit like that - a phase you grow out of.
Still, I can't forgive the rednecks from Stone Mountain. I turned out OK, and I can probably thank the rednecks for part of my drive to succeed (to prove them wrong). But my friends didn't have my luck. Most have never overcome the damage done to their self-image at a young age. I think their lives and all of America would be much better off if we were to build up the self esteem of our most talented geeks.
I read a cool article on being tall. In general, each inch of height is worth about $2K/year in extra income for a guy. However, it doesn't matter how tall you are... what matters is how tall you were when you were sixteen. Guys who sprout in their twenties don't benefit.