Lest anyone mistake the above for reality - high efficiency white LEDs still trail behind fluorescents in overall efficiency. Fluorescents are still the king for efficienct home lighting.
There's actually two factors at work here - digital cell phones attenuate their transmit power level based on the strength of the signal they receive. The theory is that if they are receiving a strong signal from a cell tower, they must be very near it physically, so they don't need to use as much power to transmit and be heard by the tower. So the first thing they do is set up a local base station; all the phones will lock in on it because it is the strongest signal around, and they will all reduce their transmit power because the local signal is so strong. So this automatically means your phone will only use the local base station, no other cell towers will be able to hear the weak signal your phones will be putting out.
The region being affected is easily controlled using directional antennas. Most cell towers already use a 120 degree beam spread, so directional antennas are the usual already, but they can certainly use a narrower beam antenna if they want.
As for routing emergency calls, again, the network tells the phone what the phone is allowed to do. No problem there...
Methinks it's time to write a bit of perl script to retrieve the page at movies.yahoo.com and parse the "Top Movies" and "Coming Soon" tables for movie titles. Spit them out in a plain text list, and feed that into a file generator that generates random binary content (or whatever content you feel like.)
Run it from a cron job (scheduled task) once a week and that should keep things hopping...
You haven't thought this through. See my followup.
Ogg Vorbis is nice, that's exactly what I was referring to about a self-rate-limiting stream. But again, that doesn't help BitTorrent because BitTorrent doesn't slice up its data that way.
Think about how the network bandwidth is being used in BitTorrent - I open up connections to as many providers as I can find, and download data from them. Other clients do the same, and try to download data from me. The exact same data will go back and forth across my connection multiple times. And, across the entire network, there are N nodes connecting to as many of each other as possible, a mesh of size NxN, and each of those connections is carrying essentially the same data. As N grows, the amount of resources required to maintain those NxN connections grows geometrically. You cannot sustain that kind of growth rate, the physical network will collapse when the system gets popular enough.
There's also other more immediate practical limits. Many users now are connecting via broadband, which is great, but the transfer speeds you get are asymmetric. So even though you have a very fast potential download rate, your upload rate is very limited. In a bittorrent setup where every peer's download rate is proportional to their upload rate, this means you are inherently unable to utilize your full download capability, because your upload rate cannot match it.
Also, a lot of users are attached to the same network providers. The routers in those networks are transmitting the same data over and over to each of the individual users. That's an unnecessary waste of bandwidth.
A sane approach would be to have a program guide (like TV Guide) published at a well-known URL that tells you what content will be available in what multicast group at what times. Your client software will join the multicast groups of interest at about those times. This informs the routers upstream from you that you're interested in a particular channel. When the multicast begins, the sender just needs to send one copy of the data to its local network, and all of the routers on that network will fan out one copy of the data per target network. This immediately reduces the network resource load from the NxN nightmare to a near-constant value based on the size of the network, as opposed to the number of clients. And in the common case where you have a bunch of broadband subscribers all connected to the same router, the data only traverses that network link *once*, no matter how many subscribers there are. No more wasting bandwidth with N copies of the identical data. And, everyone gets the data at their full download speed.
You may think that bittorrent/suprnova are successful *right now* but they can never hope to reach an audience of millions, the way a TV network does. The internet would melt down long before they could do so.
Any design whose network resource consumption scales based on the number of users is doomed to be a victim of its own success. But the approach I've described will scale efficiently because it's only dependent on the number of routers in the network, not on the number of listeners trying to receive the content.
Any connection-based protocol suffers from scaling problems, especially on the scope this article implies. If you want to do a media broadcast, you should be using IP multicast in realtime. Then you don't need to worry about upload rates either, you get maximal efficiency and data only has to move in one direction around the network.
All of the P2P networks have this problem because they are connection-based and on-demand. A TV network is not on-demand, it's a fixed message delivered on a published schedule. That's the model that works most efficiently, making the most efficient use of the transport medium. For the internet you can be somewhat flexible and start redundant broadcasts at staggered time intervals, but in general, if you don't start listening/downloading when the stream starts, tough.
For compressed video you need to make sure that there are plenty of I-frames in the stream so that people can come in at any arbitrary point and sync up, but that's no big deal. Also if you take this approach you don't need to broadcast multiple streams of the same content at different resolutions/bitrates, the network itself will provide rate reduction by dropping frames that the receiver can't pick up fast enough. (Tho doing that will make the audio pretty noisy; I guess you can do low bandwidth streams if you really want to. Or just do separate bandwidth streams for the audio. That way if one audio stream needs too much bandwidth and is losing too many packets you can just select a lower bandwidth stream instead.)
There has to be something else here than just evolution at work. Humanity developed intelligence as a survival trait, so it doesn't make sense to me that evolution favors thoughtlessness.
Also, in nature, successful viruses do not multiply so rapidly that they immediately kill their hosts - that would prevent the virus from spreading as well. Thus evolution automatically weeds out the most aggressive diseases, leaving only the moderately aggressive to perpetuate themselves.
I see what you're saying, but I don't understand why it is so inevitable.
This is a sincere question - why does a free market only work on short term gain? If you exploit a market to exhaustion (hunt a species to extinction, pump oil to exhaustion, pollute oceans, etc.) then you actually destroy that market. That makes no sense; why don't free markets take the long term into account?
If you wipe out your own market, then you're forced to abandon its remains and create a new market. But if you use a resource at sustainable rates, you can still profit and continue to expand, and you can still create new markets but you can do it at your own pace. If you destroy the resource, you have to switch markets on pretty much an emergency basis, instead of on your own time schedule.
Your statement implies a perception that short term gain for the individual is independent of long term gain for the society. But the fact is, if our ecosystem is destroyed, everyone loses. I don't understand how people get the idea that they can actually prosper at the expense of everyone else - ultimately that's a huge lie.
There's nothing special about this technology at all. It's just a standard compiler whose source language is object code. I wrote the same thing for my Atari ST back in 1987, except it took DOS executables as input and spit out Atari TOS programs as output. In those days, the resulting Atari program always ran faster than the original DOS code. Besides the machine language parser you just needed a memory map and interrupt map, all of which were pretty simple back then.
Sorry, this is completely off-topic, but when I pulled up this story the rotating ad landed on a Microsoft ad - here's a screen shot of what I'm talking about: Microsoft Ad
Is it just me, or does that whole concept seem ludicrous? I suppose it makes logical sense, in a twisted kind of way:
"At Microsoft, our programmers encounter security vulnerabilities each and every working day. Our experience with security is second to none! Not like those silly Linux dweebs who hardly ever see a security vulnerability. Who would you rather go to for security advice - a programmer who has never ever encountered a security hole, or seasoned programmers who run into security holes all day long, every day?"
That tag line should read "Go to microsoft.com today and get a free virus!"
You guys all seem to think that first-person shooters with new never-before-seen surprises around every corner are the only formula for making interesting games.
What ever happened to games that actually focused on *game mechanics* and skill? When Pong was invented, all the graphics effects you were ever going to see were right there on the first screen - no surprises, no easter eggs. Just pure game play. And people played it. For countless hours. Almost every game that followed for the next decade or so was like that - improving the graphics and sound was nice, but the critical ingredient was always the actual gameplay. That seems to be sorely lacking these days.
It seems to me that now is the perfect time for the open source model to blossom in this industry, because there are already mature game engines out there. Rather than focus on story-oriented games that are only interesting one time through, people just need to get back to creating games where the game play takes center stage. A good story makes a nice backdrop to set the stage, but it shouldn't overshadow the play of the game itself.
If your game isn't worth playing any more because its secrets are suddenly public knowledge, then I think your game was never worth playing in the first place. But if you make a game that's challenging and fun to play even after you've heard the story and learned all the secrets, then you've got something.
Environments like MUD have a great potential here, but I think they also prove that not everybody is creative enough to create an interesting game setting. Still, the fact that the tools exist now means that there's no technical barrier to creating a fun game.
A lot of games today have a tight script and a single story line. Once you've worked your way through it once, there's nothing left, it's "solved" and done. But nobody says it has to be this way. You should be able to create a game with no script at all, where you just drop into a world and can follow any path you choose, and every path is different. Today's video games with their incessant scrolling, pushing you ever forward toward the Boss at the end of the Level are just silly. The formula is too rigid and too tired, it's just one step removed from watching a movie where you have no interactive powers at all.
The game engines and other tools now exist in open source to enable someone to create a really great, long-term enjoyable game. People just need to wake up and do it, and open source collaboration is the perfect approach to creating something open-ended like this.
I'm reminded of the Adventure Shell, a Unix command shell modeled after the original text adventure. Instead of writing the next Apache or Samba, someone needs to start writing the next Adventure, and get other contributors to toss in their ideas. Fancy graphics and sound don't make a great game. Ideas do, and nothing enables the advancement of new ideas like open source devlopment.
You're probably right, but if BMG can on the one hand claim that the CD had massive consumer acceptance, then they can't very credibly turn around and claim that piracy hurt their sales of this album, and so they can't credibly claim that hackers out there are a threat.
But aside from that, I think your post is probably a good summary of how the RIAA sees things...
Ah yes, you're right. I believe I owe you an apology. It's been way too long since I've looked at a DECwriter, but I still have bits of an ASR33 in a closet.
No, Sun was just following the standard practice that had already been around for over two decades by the time they hit the scene. Witness the ASR33 Teletype, which first was in use in 1965:
http://www.pdp8.net/asr33/pics/kbd_top.shtml?lar ge
Anybody who thinks computer keyboards "always had CapsLock there" and that *Sun* was doing something different obviously hasn't been using computers long enough to actually know.
While your quoted terms for HDTV are correct, you imply a connection that doesn't exist.
In the HDTV "1080i" and "720p" terms, the number refers to their horizontal pixel resolution, not their frame rate. 720p is 60 frames per second, 1080i is 60 fields per second/30 frames per second.
Your use of "(60p)" is bogus, it's not talking about the same thing.
Irrelevant. Even on ancient manual typewriters it was never placed up there next to the 'A' key. The fact of the matter is that the CapsLock key is not a key that needs frequent access. Even when you use it, it's generally something you'll toggle on for a long stream of characters. Also, you will never press the CapsLock in combination with something else (unless you're entering the Easter Egg for some idiotic game).
On the other hand, the Control key is *always* used in combination with other keys, so moving it from the central row to a corner, placing it further away from a large number of keys, is stupid.
I totally agree that whoever decided to swap Control and CapsLock to their current "Microsoft Standard" locations was a moron.
Hm, the last time I dealt with CASS for an automated mailing, the only requirement was a ZIP+4 barcode. Mixed-case address info was fine, the automated routing equipment only cares about the bar code...
"half human-readable" is just a bit too wishy-washy for me. HTML is human readable, and it does its job pretty well (aside from true horizontal positioning control, instead of faking it with Lists and Tables) but that's because the 'T' stands for TEXT and it's intended primarily for human readable text.
For anything that is meant to be machine-processed, like a low level data format, human-readability is a non-issue. For anything that is meant as general purpose, large capacity data storage, human-readability is a liability because the volume of metadata eclipses the volume of data.
As a slightly better example, ASN.1 is sometimes tedious and even overly verbose, but it is far more compact than XML, is at least as expressive, and is trivial to parse with a simple state machine.
What annoys me about "XML" is that a "Markup Language" is supposed to describe data *for presentation*, that's what Markup is all about. Using it as a general purpose database format is truly a misuse of the SGML technology.
Yes, but 2048*4096*60 still only comes out to 503316480 (480M pixels, instead of 480 million). Not the "28800000000 pixels" that BWJones came up with. There is no 180k x 240k anywhere in the article, that's what I was having a problem with.
A CCD that produced a single frame of 54GB would be somewhat impractical; you would need that much RAM to capture a single image and buffer it for writing to disk/tape. You could read it back in pieces for processing, of course...
Interesting, the numbers you show don't appear anywhere in the article. Instead, I see:
At the heart of the DECam are 60 rectangular (2k x 4k) CCDs, each with 8 million 15-micron pixels. The CCDs, developed at Lawrence Berkeley National Laboratory, are over five times more sensitive at near-infrared wavelengths than conventional CCDs currently used for astronomy.
60 CCDs at 8 million pixels each for a total of only 480 million pixels. There's no mention of color filtration so grayscale is a safe assumption. There's also no mention of resolution but 16 bits sounds good as a guess.
So 960 million bytes per frame, which is only 915.5MB (1M = 2^20).
Ok, sounds great. I hope we'll be seeing flexible amorphous cells at the 50% mark soon, so they can conform to existing body shapes instead of having to specifically engineer flat surfaces to mount crystalline panels.
I think my previous experience with 5% efficient amorphous-Si cells gave me a bad perspective on things. I'd love to have a Tzero and run it primarily off solar, absolutely. The right technology is out there, but it's still not-exactly "off the shelf" yet. Close...
Facts are nice, but you don't need to be a rude ass about it.
I live in LA, which is great re: insolation but terrible re: commute distances; my office is 30 miles from my home and most people live 60-70 miles from their work. People commute into downtown Los Angeles all the way from Lancaster and beyond... 30 miles a day is not realistic. I don't think Los Angeles is the only city where long commutes are a reality, either.
I think you misread my intent as well; people ask all the time why we don't have solar powered cars, and the answer is it makes no sense to put solar panels on cars. The power you can generate from a car-sized solar panel array will extend the car battery range by maybe a few minutes over the course of a day.
re: storing excess power from a home PV panel into a battery bank, yes, that's great during the daytime but you're most likely to use it all up again in the evening. It is hard enough to build a house-sized system with enough power for all of the appliances in the house. It's even harder to build in excess capacity for something as power hungry as an electric car. If you're living totally off-grid, you're going to need more.
For example, the AC Propulsion T-zero is using 6800 18650 LiIon cells to give it a 300 mile driving range. That's a battery array of 100 in series by 68 in parallel, peak voltage of 420V and at 2AH/cell a total of 136AH or 57.1KWH total capacity. The Tzero is really light, this is only 190WH per mile. But let's assume a larger 4 seater and your 340WH/mile figure, with a commute round trip of 120 miles/day. That's 40.8KWH/day. For the 2-seater Tzero it's only 22.8KWH/day, which by your figures (6 hours, 15%) means 25m^2, or 45m^2 for the larger car.
Slashdot Mirror
Lest anyone mistake the above for reality - high efficiency white LEDs still trail behind fluorescents in overall efficiency. Fluorescents are still the king for efficienct home lighting.
There's actually two factors at work here - digital cell phones attenuate their transmit power level based on the strength of the signal they receive. The theory is that if they are receiving a strong signal from a cell tower, they must be very near it physically, so they don't need to use as much power to transmit and be heard by the tower. So the first thing they do is set up a local base station; all the phones will lock in on it because it is the strongest signal around, and they will all reduce their transmit power because the local signal is so strong. So this automatically means your phone will only use the local base station, no other cell towers will be able to hear the weak signal your phones will be putting out.
The region being affected is easily controlled using directional antennas. Most cell towers already use a 120 degree beam spread, so directional antennas are the usual already, but they can certainly use a narrower beam antenna if they want.
As for routing emergency calls, again, the network tells the phone what the phone is allowed to do. No problem there...
Methinks it's time to write a bit of perl script to retrieve the page at movies.yahoo.com and parse the "Top Movies" and "Coming Soon" tables for movie titles. Spit them out in a plain text list, and feed that into a file generator that generates random binary content (or whatever content you feel like.)
Run it from a cron job (scheduled task) once a week and that should keep things hopping...
Sounds like fun. My web site could use a few more page hits anyway, traffic has been low this month...
You haven't thought this through. See my followup.
Ogg Vorbis is nice, that's exactly what I was referring to about a self-rate-limiting stream. But again, that doesn't help BitTorrent because BitTorrent doesn't slice up its data that way.
Think about how the network bandwidth is being used in BitTorrent - I open up connections to as many providers as I can find, and download data from them. Other clients do the same, and try to download data from me. The exact same data will go back and forth across my connection multiple times. And, across the entire network, there are N nodes connecting to as many of each other as possible, a mesh of size NxN, and each of those connections is carrying essentially the same data. As N grows, the amount of resources required to maintain those NxN connections grows geometrically. You cannot sustain that kind of growth rate, the physical network will collapse when the system gets popular enough.
There's also other more immediate practical limits. Many users now are connecting via broadband, which is great, but the transfer speeds you get are asymmetric. So even though you have a very fast potential download rate, your upload rate is very limited. In a bittorrent setup where every peer's download rate is proportional to their upload rate, this means you are inherently unable to utilize your full download capability, because your upload rate cannot match it.
Also, a lot of users are attached to the same network providers. The routers in those networks are transmitting the same data over and over to each of the individual users. That's an unnecessary waste of bandwidth.
A sane approach would be to have a program guide (like TV Guide) published at a well-known URL that tells you what content will be available in what multicast group at what times. Your client software will join the multicast groups of interest at about those times. This informs the routers upstream from you that you're interested in a particular channel. When the multicast begins, the sender just needs to send one copy of the data to its local network, and all of the routers on that network will fan out one copy of the data per target network. This immediately reduces the network resource load from the NxN nightmare to a near-constant value based on the size of the network, as opposed to the number of clients. And in the common case where you have a bunch of broadband subscribers all connected to the same router, the data only traverses that network link *once*, no matter how many subscribers there are. No more wasting bandwidth with N copies of the identical data. And, everyone gets the data at their full download speed.
You may think that bittorrent/suprnova are successful *right now* but they can never hope to reach an audience of millions, the way a TV network does. The internet would melt down long before they could do so.
Any design whose network resource consumption scales based on the number of users is doomed to be a victim of its own success. But the approach I've described will scale efficiently because it's only dependent on the number of routers in the network, not on the number of listeners trying to receive the content.
Any connection-based protocol suffers from scaling problems, especially on the scope this article implies. If you want to do a media broadcast, you should be using IP multicast in realtime. Then you don't need to worry about upload rates either, you get maximal efficiency and data only has to move in one direction around the network.
All of the P2P networks have this problem because they are connection-based and on-demand. A TV network is not on-demand, it's a fixed message delivered on a published schedule. That's the model that works most efficiently, making the most efficient use of the transport medium. For the internet you can be somewhat flexible and start redundant broadcasts at staggered time intervals, but in general, if you don't start listening/downloading when the stream starts, tough.
For compressed video you need to make sure that there are plenty of I-frames in the stream so that people can come in at any arbitrary point and sync up, but that's no big deal. Also if you take this approach you don't need to broadcast multiple streams of the same content at different resolutions/bitrates, the network itself will provide rate reduction by dropping frames that the receiver can't pick up fast enough. (Tho doing that will make the audio pretty noisy; I guess you can do low bandwidth streams if you really want to. Or just do separate bandwidth streams for the audio. That way if one audio stream needs too much bandwidth and is losing too many packets you can just select a lower bandwidth stream instead.)
There has to be something else here than just evolution at work. Humanity developed intelligence as a survival trait, so it doesn't make sense to me that evolution favors thoughtlessness.
Also, in nature, successful viruses do not multiply so rapidly that they immediately kill their hosts - that would prevent the virus from spreading as well. Thus evolution automatically weeds out the most aggressive diseases, leaving only the moderately aggressive to perpetuate themselves.
I see what you're saying, but I don't understand why it is so inevitable.
This is a sincere question - why does a free market only work on short term gain? If you exploit a market to exhaustion (hunt a species to extinction, pump oil to exhaustion, pollute oceans, etc.) then you actually destroy that market. That makes no sense; why don't free markets take the long term into account?
If you wipe out your own market, then you're forced to abandon its remains and create a new market. But if you use a resource at sustainable rates, you can still profit and continue to expand, and you can still create new markets but you can do it at your own pace. If you destroy the resource, you have to switch markets on pretty much an emergency basis, instead of on your own time schedule.
Your statement implies a perception that short term gain for the individual is independent of long term gain for the society. But the fact is, if our ecosystem is destroyed, everyone loses. I don't understand how people get the idea that they can actually prosper at the expense of everyone else - ultimately that's a huge lie.
There's nothing special about this technology at all. It's just a standard compiler whose source language is object code. I wrote the same thing for my Atari ST back in 1987, except it took DOS executables as input and spit out Atari TOS programs as output. In those days, the resulting Atari program always ran faster than the original DOS code. Besides the machine language parser you just needed a memory map and interrupt map, all of which were pretty simple back then.
Sorry, this is completely off-topic, but when I pulled up this story the rotating ad landed on a Microsoft ad - here's a screen shot of what I'm talking about: Microsoft Ad
Is it just me, or does that whole concept seem ludicrous? I suppose it makes logical sense, in a twisted kind of way:
"At Microsoft, our programmers encounter security vulnerabilities each and every working day. Our experience with security is second to none! Not like those silly Linux dweebs who hardly ever see a security vulnerability. Who would you rather go to for security advice - a programmer who has never ever encountered a security hole, or seasoned programmers who run into security holes all day long, every day?"
That tag line should read "Go to microsoft.com today and get a free virus!"
"...so that your end result is worth playing" ??
You guys all seem to think that first-person shooters with new never-before-seen surprises around every corner are the only formula for making interesting games.
What ever happened to games that actually focused on *game mechanics* and skill? When Pong was invented, all the graphics effects you were ever going to see were right there on the first screen - no surprises, no easter eggs. Just pure game play. And people played it. For countless hours.
Almost every game that followed for the next decade or so was like that - improving the graphics and sound was nice, but the critical ingredient was always the actual gameplay. That seems to be sorely lacking these days.
It seems to me that now is the perfect time for the open source model to blossom in this industry, because there are already mature game engines out there. Rather than focus on story-oriented games that are only interesting one time through, people just need to get back to creating games where the game play takes center stage. A good story makes a nice backdrop to set the stage, but it shouldn't overshadow the play of the game itself.
If your game isn't worth playing any more because its secrets are suddenly public knowledge, then I think your game was never worth playing in the first place. But if you make a game that's challenging and fun to play even after you've heard the story and learned all the secrets, then you've got something.
Environments like MUD have a great potential here, but I think they also prove that not everybody is creative enough to create an interesting game setting. Still, the fact that the tools exist now means that there's no technical barrier to creating a fun game.
A lot of games today have a tight script and a single story line. Once you've worked your way through it once, there's nothing left, it's "solved" and done. But nobody says it has to be this way. You should be able to create a game with no script at all, where you just drop into a world and can follow any path you choose, and every path is different. Today's video games with their incessant scrolling, pushing you ever forward toward the Boss at the end of the Level are just silly. The formula is too rigid and too tired, it's just one step removed from watching a movie where you have no interactive powers at all.
The game engines and other tools now exist in open source to enable someone to create a really great, long-term enjoyable game. People just need to wake up and do it, and open source collaboration is the perfect approach to creating something open-ended like this.
I'm reminded of the Adventure Shell, a Unix command shell modeled after the original text adventure. Instead of writing the next Apache or Samba, someone needs to start writing the next Adventure, and get other contributors to toss in their ideas. Fancy graphics and sound don't make a great game. Ideas do, and nothing enables the advancement of new ideas like open source devlopment.
You're probably right, but if BMG can on the one hand claim that the CD had massive consumer acceptance, then they can't very credibly turn around and claim that piracy hurt their sales of this album, and so they can't credibly claim that hackers out there are a threat.
But aside from that, I think your post is probably a good summary of how the RIAA sees things...
If it really isn't noticed, then they've made their point that copy protection is acceptable.
Ah yes, you're right. I believe I owe you an apology. It's been way too long since I've looked at a DECwriter, but I still have bits of an ASR33 in a closet.
No, Sun was just following the standard practice that had already been around for over two decades by the time they hit the scene. Witness the ASR33 Teletype, which first was in use in 1965:
r ge
http://www.pdp8.net/asr33/pics/kbd_top.shtml?la
Anybody who thinks computer keyboards "always had CapsLock there" and that *Sun* was doing something different obviously hasn't been using computers long enough to actually know.
While your quoted terms for HDTV are correct, you imply a connection that doesn't exist.
In the HDTV "1080i" and "720p" terms, the number refers to their horizontal pixel resolution, not their frame rate. 720p is 60 frames per second, 1080i is 60 fields per second/30 frames per second.
Your use of "(60p)" is bogus, it's not talking about the same thing.
Irrelevant. Even on ancient manual typewriters it was never placed up there next to the 'A' key. The fact of the matter is that the CapsLock key is not a key that needs frequent access. Even when you use it, it's generally something you'll toggle on for a long stream of characters. Also, you will never press the CapsLock in combination with something else (unless you're entering the Easter Egg for some idiotic game).
On the other hand, the Control key is *always* used in combination with other keys, so moving it from the central row to a corner, placing it further away from a large number of keys, is stupid.
I totally agree that whoever decided to swap Control and CapsLock to their current "Microsoft Standard" locations was a moron.
Hm, the last time I dealt with CASS for an automated mailing, the only requirement was a ZIP+4 barcode. Mixed-case address info was fine, the automated routing equipment only cares about the bar code...
"half human-readable" is just a bit too wishy-washy for me. HTML is human readable, and it does its job pretty well (aside from true horizontal positioning control, instead of faking it with Lists and Tables) but that's because the 'T' stands for TEXT and it's intended primarily for human readable text.
For anything that is meant to be machine-processed, like a low level data format, human-readability is a non-issue. For anything that is meant as general purpose, large capacity data storage, human-readability is a liability because the volume of metadata eclipses the volume of data.
As a slightly better example, ASN.1 is sometimes tedious and even overly verbose, but it is far more compact than XML, is at least as expressive, and is trivial to parse with a simple state machine.
What annoys me about "XML" is that a "Markup Language" is supposed to describe data *for presentation*, that's what Markup is all about. Using it as a general purpose database format is truly a misuse of the SGML technology.
Yes, but 2048*4096*60 still only comes out to 503316480 (480M pixels, instead of 480 million). Not the "28800000000 pixels" that BWJones came up with. There is no 180k x 240k anywhere in the article, that's what I was having a problem with.
A CCD that produced a single frame of 54GB would be somewhat impractical; you would need that much RAM to capture a single image and buffer it for writing to disk/tape. You could read it back in pieces for processing, of course...
So 960 million bytes per frame, which is only 915.5MB (1M = 2^20).
Ok, sounds great. I hope we'll be seeing flexible amorphous cells at the 50% mark soon, so they can conform to existing body shapes instead of having to specifically engineer flat surfaces to mount crystalline panels.
I think my previous experience with 5% efficient amorphous-Si cells gave me a bad perspective on things. I'd love to have a Tzero and run it primarily off solar, absolutely. The right technology is out there, but it's still not-exactly "off the shelf" yet. Close...
Facts are nice, but you don't need to be a rude ass about it.
I live in LA, which is great re: insolation but terrible re: commute distances; my office is 30 miles from my home and most people live 60-70 miles from their work. People commute into downtown Los Angeles all the way from Lancaster and beyond... 30 miles a day is not realistic. I don't think Los Angeles is the only city where long commutes are a reality, either.
I think you misread my intent as well; people ask all the time why we don't have solar powered cars, and the answer is it makes no sense to put solar panels on cars. The power you can generate from a car-sized solar panel array will extend the car battery range by maybe a few minutes over the course of a day.
re: storing excess power from a home PV panel into a battery bank, yes, that's great during the daytime but you're most likely to use it all up again in the evening. It is hard enough to build a house-sized system with enough power for all of the appliances in the house. It's even harder to build in excess capacity for something as power hungry as an electric car. If you're living totally off-grid, you're going to need more.
For example, the AC Propulsion T-zero is using 6800 18650 LiIon cells to give it a 300 mile driving range. That's a battery array of 100 in series by 68 in parallel, peak voltage of 420V and at 2AH/cell a total of 136AH or 57.1KWH total capacity. The Tzero is really light, this is only 190WH per mile. But let's assume a larger 4 seater and your 340WH/mile figure, with a commute round trip of 120 miles/day. That's 40.8KWH/day. For the 2-seater Tzero it's only 22.8KWH/day, which by your figures (6 hours, 15%) means 25m^2, or 45m^2 for the larger car.