> It takes more energy to make H than what you get from burning it.
And it takes more energy to charge a battery than you get back out of it. What's your point? You're just another one of the hordes who just doesn't get what the "hydrogen economy" is all about. Hydrogen is an ENERGY CARRIER, not an ENERGY SOURCE. It's a battery substitute that's more environmentally friendly, has a higher energy density, and "recharges" much more quickly.
> I bought the ethernet card and plugged it in. No problems.
I have the same setup, but enough of the "no problems" already. For your average non-techie consumer wanting Ethernet there ARE problems galore with the SA1: willingness to void warranty by opening the unit, obtaining the right size Torx screw driver (which not exactly a common household item like a Philips driver), cutting the right-sized hole into the back of the unit to snap in an RJ45 socket and obtaining said socket and wiring it to a patch cable stub (or just drilling a hole into the back and running a patch cable straight from the card to the outside and having it all look like shite and be prone to having the cable pulled too hard and unplugged or unseating the card), obtaining and installing the necessary Linux software to serve up shows from the box, editing the init script to start it all up, and hoping that after all this the box still works right.
Yeah, no problems at all for your average Best Buy customer.
You're trying to apply the UNIX console app metaphor to GUI apps, and that doesn't really work. When the entire user interface of an app are an input and an output stream, and they both only handle text, then yes, you can string a bunch of apps together that can operate in chain fashion on these streams, especially if they can understand each other's output formats. But in the GUI world this particular concept of UI IO streams becomes a lot more complex and even meaningless. You have to abstract the interfaces through which applications communicate a whole lot more, and even so applications need a whole lot more specialized knowledge about each other in order to interact effectively. Enter the notion of plugins or extensions. In some respects a plugin architecture extends the UNIX app chain paradigm to the GUI world, allowing multiple pieces of code to operate on the same data. But it is also much more complex and powerful, and requires a much more elaborate and explicit contract between the apps.
Anyway, the key point I'm trying to make is that something like Firefox with a set of extensions in many ways continues the UNIX app chain paradigm, because it provides modularity and separation of function and allows multiple pieces of code to operate on one shared data set. But to an end user it also masquerades as a monolithic app because they really only see one integrated GUI, so you could argue that it provides the best of both worlds.
It's a simple matter of word inflation, or padding if you will. It has less to do with the increasing complexity of the subject matter (although that can certainly be the case) and more with the ever more bombastic expectations and requirements of thesis papers. If Einstein or any of his similarly illustrious contemporaries were to publish their papers today for a modern university, trust me, they would dwarf your paper in every respect. We're living in the days of 100 page press releases and 1000 page court "briefs", with tables of contents of tables of contents and bibliographies of bibliographies and endless amounts of boilerplate text of every imaginable nature. If your research included any statistical analysis I'm sure your paper is brimming with iterations of regression analysis and the requisite page-filling tables and charts. Back in Einstein's days you stated your name, included a description of your new insights and your signature, and you were pretty much done.
Yes, but the pollution happens spread out over wide areas, while the "unpollution" happens localized. There is no hose going from your tailpipe to the hydrogen generating plant. That exhaust still spends part of its life as smog in some urban area. Your "no net effect" is too large a frame of reference, sort of like sampling the universe every few billion years and concluding that not much happened during its lifetime, because most life appeared and disappeared during the sampling interval.
Overall there is a considerable gain to be expected. And don't forget, fuel cell technology is still in its early stages, while internal combustion has already experienced over a century of improvements.
And also pollute when reunited. Hydrogen has the very desirable quality of generating virtually no pollution, and providing an endlessly repeatable cycle. There is no doubt that there are still issues with the use of hydrogen, it's not a completely solved problem, otherwise we'd already be driving it. But most research money appears to be going into hydrogen, so I would think it's still the most long-term promising approach.
> if everybody in the world would be scrapping car after two years, > we would be in seriously deep shit.
Like I said elsewhere, we're talking manufacturer life cycles. If VW or Toyota didn't release a new model every 2-5 years, they wouldn't make enough money to stay in business. Eastern European manufacturers didn't operate on a market principle, so this revenue stream wasn't that important to them. This explains why a Lada or Trabant was sold essentially unchanged for decades.
> Life cycles for cars in the US are much longer than two years.
We're talking manufacturer life cycles here, not how long the car will be on the roads. Most manufacturers release a new model every 2-5 years. In terms of revenue stream to them, that's what matters, not how long the car is driveable.
> The only thing hydrogen is good for is to reduce emissions from the > vehicles themselves, but you only end up pushing the pollution to > power generating stations, which we'll need a lot more of if the > 'hydrogen economy' takes off.
Except that you're missing a critical piece here: since hydrogen extraction facilities are very large and stationary (something most cars are not), they can use fuels that would simply not be an option for the cars themselves, such as wind, solar, wave or nuclear power. And even if you do keep producing hydrogen by burning fossil fuels, because of the size and relatively low number of production facilities you have the economic luxury of investing in technologies that burn fossil fuels more efficiently and transform waste into more benign forms than would be feasible in the cars themselves.
Although your idea seems nice on the surface, if car life cycles were much longer than 2 years (say, 30-40 years like in Soviet Russia), the manufacturers simply wouldn't have the cash for the steady stream of innovation that gave us our much safer and more economical cars today. And unlike software that we're so cynical about, there has been true and steady innovation and incremental improvement in cars for a long time, at least overseas.
> If a mob of people walked into your house and started pocketing > all your possessions, would you "negotiate politely" with them > because there's more of them than of you? Or would you call for > law enforcement?
If Guido was pinning me to the ground while his buddies were doing said pocketing, I think I would be quite open to negotiations. Nay, I would welcome them heartily.
The trick in minimizing server traffic is to come up with the right remote data granularity--i.e. don't fetch too much or too little data on each trip. At one extreme you'd fetch essentially your entire database in a single call and keep it around on the client, wasting both its memory and the bandwith to get data that will mostly go unused. At the other extreme you simulate traditional APIs, which typically get you what you want in very piecemeal fashion, requiring one function call to get this bit of data, which is required by the next function, which in turn returns a struct required by a third function, and so on until you finally have what you really want.
The happy medium is somewhere in between. Come up with functions that return just the right amount of data, including sufficient contextual data to not require another call. For a contacts-type app you would provide functions to read and write an entire user record at a time, as well as a function to obtain a list of users with all the required columns to display them in a single call. You will generally find it more bandwidth and client-side processing efficient to taylor the remote functions towards the UI that needs them, fetching or uploading just the required data for a particular application screen or view. Once you have a decent remote function architecture you will have no doubt considerably less server traffic, since practically only raw data makes the trip anymore.
...that conventional storage water heaters are a religion. I have rarely seen so much energy and emotion expended as their adherent do to fight the evil that is tankless water heaters.
Comcast has done something similar with outsourcing Usenet access. As a side effect, there is a monthly free download quota (1GB?), beyond which you have to pay. Lucky for me that doesn't affect me much, since my main use of Usenet is as a programming reference, for which Google Groups is almost perfect (though their search syntax could certainly be more powerful). But that's just me, and it certainly sucks that Usenet is being deprecated in such subversive ways. Its main strength from my point of view is that it concentrates so much information in one seamless repository. Once it's gone, you have to rely on a disparate collection of forums and hope that Google can search them all equally efficiently, which is currently certainly not the case.
Slashdot Mirror
> It takes more energy to make H than what you get from burning it.
And it takes more energy to charge a battery than you get back out of it. What's your point? You're just another one of the hordes who just doesn't get what the "hydrogen economy" is all about. Hydrogen is an ENERGY CARRIER, not an ENERGY SOURCE. It's a battery substitute that's more environmentally friendly, has a higher energy density, and "recharges" much more quickly.
I'm surprised that The Fast And The Furious didn't make it on their list, since it's such as "classic" amongst the meathead crowd.
> Um, you're talking about the Series 1.
Um, so is he.
> I bought the ethernet card and plugged it in. No problems.
I have the same setup, but enough of the "no problems" already. For your average non-techie consumer wanting Ethernet there ARE problems galore with the SA1: willingness to void warranty by opening the unit, obtaining the right size Torx screw driver (which not exactly a common household item like a Philips driver), cutting the right-sized hole into the back of the unit to snap in an RJ45 socket and obtaining said socket and wiring it to a patch cable stub (or just drilling a hole into the back and running a patch cable straight from the card to the outside and having it all look like shite and be prone to having the cable pulled too hard and unplugged or unseating the card), obtaining and installing the necessary Linux software to serve up shows from the box, editing the init script to start it all up, and hoping that after all this the box still works right.
Yeah, no problems at all for your average Best Buy customer.
You're trying to apply the UNIX console app metaphor to GUI apps, and that doesn't really work. When the entire user interface of an app are an input and an output stream, and they both only handle text, then yes, you can string a bunch of apps together that can operate in chain fashion on these streams, especially if they can understand each other's output formats. But in the GUI world this particular concept of UI IO streams becomes a lot more complex and even meaningless. You have to abstract the interfaces through which applications communicate a whole lot more, and even so applications need a whole lot more specialized knowledge about each other in order to interact effectively. Enter the notion of plugins or extensions. In some respects a plugin architecture extends the UNIX app chain paradigm to the GUI world, allowing multiple pieces of code to operate on the same data. But it is also much more complex and powerful, and requires a much more elaborate and explicit contract between the apps.
Anyway, the key point I'm trying to make is that something like Firefox with a set of extensions in many ways continues the UNIX app chain paradigm, because it provides modularity and separation of function and allows multiple pieces of code to operate on one shared data set. But to an end user it also masquerades as a monolithic app because they really only see one integrated GUI, so you could argue that it provides the best of both worlds.
It's a simple matter of word inflation, or padding if you will. It has less to do with the increasing complexity of the subject matter (although that can certainly be the case) and more with the ever more bombastic expectations and requirements of thesis papers. If Einstein or any of his similarly illustrious contemporaries were to publish their papers today for a modern university, trust me, they would dwarf your paper in every respect. We're living in the days of 100 page press releases and 1000 page court "briefs", with tables of contents of tables of contents and bibliographies of bibliographies and endless amounts of boilerplate text of every imaginable nature. If your research included any statistical analysis I'm sure your paper is brimming with iterations of regression analysis and the requisite page-filling tables and charts. Back in Einstein's days you stated your name, included a description of your new insights and your signature, and you were pretty much done.
> why should your prefered defintion of "hacker" win instead of the one that you seem to agree is most common?
In that case I am going to use the OTHER other definition of hacker--one who makes furniture with an axe--and call you both fools!
> well to wheel efficency of an Electric Vehicle is roughly equivalent to 50 MPG
LOL! Efficiency is measured in %, not in MPG. How many MPG does a fossil power plant get, full throttle down?
http://science.howstuffworks.com/fuel-cell4.htm
"They who give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety."
-- Benjamin Franklin
So according to you, there is no smog, and everything is peachy with the carbon cycle. Indeed.
Yes, but the pollution happens spread out over wide areas, while the "unpollution" happens localized. There is no hose going from your tailpipe to the hydrogen generating plant. That exhaust still spends part of its life as smog in some urban area. Your "no net effect" is too large a frame of reference, sort of like sampling the universe every few billion years and concluding that not much happened during its lifetime, because most life appeared and disappeared during the sampling interval.
These total system efficiency calculations have already been done, they're of course at the basis of any serious research.
howstuffworks figures:
http://science.howstuffworks.com/fuel-cell4.htm
Wikipedia fuel cell article:
http://en.wikipedia.org/wiki/Fuel_cell
Overall there is a considerable gain to be expected. And don't forget, fuel cell technology is still in its early stages, while internal combustion has already experienced over a century of improvements.
> and are used in existing vehicles
And also pollute when reunited. Hydrogen has the very desirable quality of generating virtually no pollution, and providing an endlessly repeatable cycle. There is no doubt that there are still issues with the use of hydrogen, it's not a completely solved problem, otherwise we'd already be driving it. But most research money appears to be going into hydrogen, so I would think it's still the most long-term promising approach.
> if everybody in the world would be scrapping car after two years,
> we would be in seriously deep shit.
Like I said elsewhere, we're talking manufacturer life cycles. If VW or Toyota didn't release a new model every 2-5 years, they wouldn't make enough money to stay in business. Eastern European manufacturers didn't operate on a market principle, so this revenue stream wasn't that important to them. This explains why a Lada or Trabant was sold essentially unchanged for decades.
> Life cycles for cars in the US are much longer than two years.
We're talking manufacturer life cycles here, not how long the car will be on the roads. Most manufacturers release a new model every 2-5 years. In terms of revenue stream to them, that's what matters, not how long the car is driveable.
> The only thing hydrogen is good for is to reduce emissions from the
> vehicles themselves, but you only end up pushing the pollution to
> power generating stations, which we'll need a lot more of if the
> 'hydrogen economy' takes off.
Except that you're missing a critical piece here: since hydrogen extraction facilities are very large and stationary (something most cars are not), they can use fuels that would simply not be an option for the cars themselves, such as wind, solar, wave or nuclear power. And even if you do keep producing hydrogen by burning fossil fuels, because of the size and relatively low number of production facilities you have the economic luxury of investing in technologies that burn fossil fuels more efficiently and transform waste into more benign forms than would be feasible in the cars themselves.
Although your idea seems nice on the surface, if car life cycles were much longer than 2 years (say, 30-40 years like in Soviet Russia), the manufacturers simply wouldn't have the cash for the steady stream of innovation that gave us our much safer and more economical cars today. And unlike software that we're so cynical about, there has been true and steady innovation and incremental improvement in cars for a long time, at least overseas.
Rats, for a moment there I thought they came up with a new shot to fight cocaine addiction. No such luck...
Ugh, more celebrity gossip? No, thanks!
It looks about as cheesy as the rest of Mac OS X, past or present. Candy buttons are candy buttons, regardless of degree of shine.
> If a mob of people walked into your house and started pocketing
> all your possessions, would you "negotiate politely" with them
> because there's more of them than of you? Or would you call for
> law enforcement?
If Guido was pinning me to the ground while his buddies were doing said pocketing, I think I would be quite open to negotiations. Nay, I would welcome them heartily.
The trick in minimizing server traffic is to come up with the right remote data granularity--i.e. don't fetch too much or too little data on each trip. At one extreme you'd fetch essentially your entire database in a single call and keep it around on the client, wasting both its memory and the bandwith to get data that will mostly go unused. At the other extreme you simulate traditional APIs, which typically get you what you want in very piecemeal fashion, requiring one function call to get this bit of data, which is required by the next function, which in turn returns a struct required by a third function, and so on until you finally have what you really want.
The happy medium is somewhere in between. Come up with functions that return just the right amount of data, including sufficient contextual data to not require another call. For a contacts-type app you would provide functions to read and write an entire user record at a time, as well as a function to obtain a list of users with all the required columns to display them in a single call. You will generally find it more bandwidth and client-side processing efficient to taylor the remote functions towards the UI that needs them, fetching or uploading just the required data for a particular application screen or view. Once you have a decent remote function architecture you will have no doubt considerably less server traffic, since practically only raw data makes the trip anymore.
...that conventional storage water heaters are a religion. I have rarely seen so much energy and emotion expended as their adherent do to fight the evil that is tankless water heaters.
> Why would the kid sue someone's pants specifically?
Sue their pants OFF. You know these kids nowadays, they can never get enough pr0n, even if they have to sue for it.
Comcast has done something similar with outsourcing Usenet access. As a side effect, there is a monthly free download quota (1GB?), beyond which you have to pay. Lucky for me that doesn't affect me much, since my main use of Usenet is as a programming reference, for which Google Groups is almost perfect (though their search syntax could certainly be more powerful). But that's just me, and it certainly sucks that Usenet is being deprecated in such subversive ways. Its main strength from my point of view is that it concentrates so much information in one seamless repository. Once it's gone, you have to rely on a disparate collection of forums and hope that Google can search them all equally efficiently, which is currently certainly not the case.