"That makes your scenario even worse. The storage size we came up with was incredible and we were looking at it to reduce the grid connection without even attempting to go fully green and found it infeasible."
That brings up an interesting question. How much storage is needed to back up a given amount of non-dispatchable storage like wind and solar? The short answer seems to be everywhere and always an infinite amount. That would seem to make planning a bit difficult.
You're probably right that much/most vehicle charging will be done at home or maybe even at work. But I think that just means that we don't need drive up charging stations on every second street corner. Doesn't affect the sizing of individual charging stations?
"Would it be feasible to put the panels above the station? "
That's what the artistic conception in the article shows.
My best guess. A typical sedan (e.g. a Toyota Camry) is a bit less than 5m long and 2m wide = 10 square meters.. If we assume that there's about twice that much space for each stall, that's 20 square meters of panel per charging station. Theoretically, there's about 1kwh per square meter available at high noon in the tropics, but there are a zillion inefficiencies, so lets assume 6 hours of 20% efficient electricity capture = 0.2*6*20 = 24kwh per stall per day. I think that's roughly comparable to Solandri's analysis above.
Not very promising. But maybe I've done something really wrong. Feel free to fix my arithmetic.
That's roughly what I came up with. But I don't have a lot of faith in my math. And we're being rather generous I think. Remember that this needs to work on a cloudy week near the Winter Solstice with short days and low sun angles.
Not that the concept is necessarily unworkable. But maybe we need 2067 technology and costs not 2017 technology.and costs, for it to work.well.
I see a fair number of solar arrays cluttering the landscape in Vermont and Northern New York. I'm a bit skeptical of their effectiveness in Winter due to ice, snow, short days, abundant clouds, low sun angle, etc, etc, etc. But vandalism doesn't seem to be an issue.
Like a Canadian comedian once pointed out -- drive by shootings aren't all that big a problem in places where rolling down the car window risks frostbite and no one hangs out on street corners anyway. Sort of applies to busting up/spray painting solar panels as well.
"A meter of snow also means you're not driving anywhere. So what's your point?"
I take it that you don't live in snow country. Difficult though it may be to believe, major roads, and some minor ones, in populated areas are generally kept open even during major snowstorms. Not that driving when it's snowing 5 or 10cm an hour is any picnic. And it's discouraged except for essential traffic. But it's usually possible.
OTOH, clearing large surfaces like solar arrays where if can't just shove the snow off into a corner with a snowplow is time consuming.
Ice is worse. Much worse. And it's not necessarily transparent if, as sometimes happens, snow is frozen into the surface of the ice.
BTW, Montreal at 46N latitude doesn't get a whole lot of sunshine in December even on (rather uncommon) sunny days. But they have abundant, inexpensive, electricity from hydro dams in Northern Quebec
You're thinking 2000. The original cross licensing was around 1980 when Intel was a much less dominant company and failure was still a (remote) possibility. I don't recall the full details of why the cross licensing was continued into the 21st century. Antitrust concerns and customer pressure? By "customer" I mean the likes of Dell and Compaq, not consumers. No one cared much about consumers back then any more than they do today.
IIRC, Intel-AMD cross licensing dates back to the 1980s when major PC makers insisted that there be a second source for Intel CPUs. Otherwise they would design their hardware around a competitor's (e.g. Motorola) chips.
I yield to no man in my ignorance of IP law, but I'm pretty sure you can't patent an instruction set. You can patent the implementation hardware, or at least a lot of it, but I doubt that restricts emulation. And I'm pretty sure that you can copyright microcode. Patents are only 20 years BTW. OTOH, copyrights last for all eternity (OK, OK... maybe only a century or two).
"This has nothing to do with any of the complaints over IME since this functionality is completely within the user's control."
As I read it, ME is sort of like the Hotel California. You can turn it off any time you wish. But it's still there and running. (Where is it getting it's power from?)
Many excellent suggestions: But I think it's curious that neither Candide nor Alice in Wonderland are cited.
Three others worth looking at if one has somehow missed them.."One Day in the Life of Ivan Denisovich" -- Aleksandr Solzhenitsyn."Zen and the Art of Motorcycle Maintenance: An Inquiry into Values" -- Robert M. Pirsig
. "In Retrospect" -- Robert McNamara. McNamara seems almost unique among decision makers not in having made terrible decisions, but in admitting it and trying to provide some thoughts on what can be learned from his mistakes).
I quite agree. I didn't find "A Catcher in the Rye" to be unreadable, but I could never understand what was so so great about it. I suppose that we are deeply flawed individuals doomed forever to blunder through the literary darkness vainly seeking warmth and shelter..
Sounds very efficient. Have you thought about automating project queue deletion?How about transferring your development from India to Swaziland? I believe that may be the coming thing.
It.s been a long time, but I really had some experience with bug tracking starting back when the earth was young and the IBM Model 026 cardpunch ruled all. And thereafter for a number of decades.
Some thoughts:
The best method depends strongly on project size, personnel and culture. I've seen projects where there are so few bugs, there was literally no need to track them and others that did fine with a list of bugs on a blackboard. And I've seen software with so many bugs,peculiarities,and insanities that the buglist was overwhelming. Look at the situation and pick the simplest solution that might work.
In cataloging, do not try to distinguish between logic errors, flawed specs, user misunderstandings, design changes, etc. What is important initially is whether action is possibly needed, not why. Let the managers/suits prioritize, assign blame, haggle, and leave their usual trail of chaos.
Once you get past two dozen or so bugs, assign each bug a unique ID. Numeric (BUG00666) if you have no good reason to use some other scheme.
[surprisingly often several bugs will turn out to be related. Describing that is mondo-klunky if you don't give the bugs nicknames]
Make sure the bug list(s) are easily searchable for keywords/phrases e.g. grepable on unix.
Don't try to track too much. Probably what you need to know is:
what's the problem?.
what needs to be fixed?.
when will it be fixed ('never' is OK sometimes)?
when was it (purportedly) fixed?
status (unless you maintain separate lists for new, to be fixed, thinking about it, fixed but not released, etc,etc,etc.
NOTE: too many catagories or lists can get way out of hand.
NOTE: Watch out for creeping beancounteritis. Trying to deal with a bug tracking system with 40 or more mandatory fields for every bug will probably result in it not being used most of the time.
Record the results of analyses (e.g. Those Mayan(?) characters in the display are because terminfo or the Registry is wrong (again)), somewhere. How likely doesn't matter. text in the bug list, links to emails, etc. You'll likely have to track from bug to analysis fairly often, so finding the analysis from the bug needs to be easy. The other way is usually less common so maybe you can live with keyword searching or some such.
NOTE: Erratic formatting of the lists above is courtesy of Slashdot. It manages to screw up plain old text, OL, UL. and I'm tired of arguing with it. I intended something more readable. That's about it.
Don't overlook the $40 fee for slapping a seal on the battery compartment that certifies that the battery has been checked and if it's actually a bomb, it's a cleverly made bomb.
"When airline travel becomes (literally) a pain in the ass, teleconferencing will grow big-time."
You'd think so. But airline travel has been an increasingly miserable experience for decades. Hasn't really done all that much for teleconferencing so far. I think perhaps we (you and I) underestimate humanity's capacity for pain and tolerance for aggravation.
(Probably explains why people still use Windows as well)
Looking at pictures of the thing, it looks more like a engineering test jig than a prototype of anything. Probably some PR guy invited some press guys in to watch while the engineers were running the motors up a few times and making some measurements on some subsystems. I doubt they ever intended for it to get more than a meter or so off the ground.
They seem to have a fair amount of faith in their work, or they wouldn't be standing anywhere near it when the rotors are spinning. In my experience Japanese engineers are (mostly) not crazy.
I have no idea where they are headed with this project, but I doubt the finished product -- if there ever is one -- will look anything like the thing they were testing.
"If you had a flying car, that worked economically somehow, you would just restrict it to hovering a foot off the ground."
That's called a ground-effect machine, aka hovercraft and they work quite well. You can buy one if you really want one. There are practical uses. e.g. if you happen to inherit a small island complete with creepy mansion in the middle of a swamp from a long forgotten uncle
Those who were around in the days of FidoNet and Compuserve will tell you that they handled communication and even some shopping on minimal hardware and very slow data lines substantially more quickly and efficiently than the current shambles.
I'm increasingly finding myself in the "This Isn't working -- Let's back off and try again" camp.
No, I'm not convinced and no further examples are needed. If you can not secure the code -- and there is no chance whatsoever that you can -- the technology is not suited to an internet used for financial, business, shopping, voting, or command and control applications.
If you can figure out a way to limiting scripting to harmless endeavors like entertainment, chatting and gaming, then fine. But depending on the judgment and good sense of web designers not to use the technology in inappropriate places simply isn't going to work. Judgment and good sense are qualities those folks totally lack.
Why would anyone want JavaScript to run natively in assembly? Sounds like a ton of vulnerabilities waiting to happen. We should be going the opposite direction and eliminating JavaScript altogether.
I infer that the desire for native bytecode is so that malware from websites can run more efficiently and not hog our CPUs.
I don't know why you've been downmoded, You're absolutely correct. Expanding internet attack surfaces is possibly the worst idea since the US decided to fix the Middle East by invading Iraq. Getting rid of ALL scripting would be one modest step toward getting the digital world under control. Sometimes I think mankind has a deathwish.
Slashdot Mirror
"That makes your scenario even worse. The storage size we came up with was incredible and we were looking at it to reduce the grid connection without even attempting to go fully green and found it infeasible."
That brings up an interesting question. How much storage is needed to back up a given amount of non-dispatchable storage like wind and solar? The short answer seems to be everywhere and always an infinite amount. That would seem to make planning a bit difficult.
You're probably right that much/most vehicle charging will be done at home or maybe even at work. But I think that just means that we don't need drive up charging stations on every second street corner. Doesn't affect the sizing of individual charging stations?
"Would it be feasible to put the panels above the station? "
That's what the artistic conception in the article shows.
My best guess. A typical sedan (e.g. a Toyota Camry) is a bit less than 5m long and 2m wide = 10 square meters.. If we assume that there's about twice that much space for each stall, that's 20 square meters of panel per charging station. Theoretically, there's about 1kwh per square meter available at high noon in the tropics, but there are a zillion inefficiencies, so lets assume 6 hours of 20% efficient electricity capture = 0.2*6*20 = 24kwh per stall per day. I think that's roughly comparable to Solandri's analysis above.
Not very promising. But maybe I've done something really wrong. Feel free to fix my arithmetic.
That's roughly what I came up with. But I don't have a lot of faith in my math. And we're being rather generous I think. Remember that this needs to work on a cloudy week near the Winter Solstice with short days and low sun angles.
Not that the concept is necessarily unworkable. But maybe we need 2067 technology and costs not 2017 technology.and costs, for it to work.well.
I see a fair number of solar arrays cluttering the landscape in Vermont and Northern New York. I'm a bit skeptical of their effectiveness in Winter due to ice, snow, short days, abundant clouds, low sun angle, etc, etc, etc. But vandalism doesn't seem to be an issue.
Like a Canadian comedian once pointed out -- drive by shootings aren't all that big a problem in places where rolling down the car window risks frostbite and no one hangs out on street corners anyway. Sort of applies to busting up/spray painting solar panels as well.
"A meter of snow also means you're not driving anywhere. So what's your point?"
I take it that you don't live in snow country. Difficult though it may be to believe, major roads, and some minor ones, in populated areas are generally kept open even during major snowstorms. Not that driving when it's snowing 5 or 10cm an hour is any picnic. And it's discouraged except for essential traffic. But it's usually possible.
OTOH, clearing large surfaces like solar arrays where if can't just shove the snow off into a corner with a snowplow is time consuming.
Ice is worse. Much worse. And it's not necessarily transparent if, as sometimes happens, snow is frozen into the surface of the ice.
BTW, Montreal at 46N latitude doesn't get a whole lot of sunshine in December even on (rather uncommon) sunny days. But they have abundant, inexpensive, electricity from hydro dams in Northern Quebec
You're thinking 2000. The original cross licensing was around 1980 when Intel was a much less dominant company and failure was still a (remote) possibility. I don't recall the full details of why the cross licensing was continued into the 21st century. Antitrust concerns and customer pressure? By "customer" I mean the likes of Dell and Compaq, not consumers. No one cared much about consumers back then any more than they do today.
IIRC, Intel-AMD cross licensing dates back to the 1980s when major PC makers insisted that there be a second source for Intel CPUs. Otherwise they would design their hardware around a competitor's (e.g. Motorola) chips.
I yield to no man in my ignorance of IP law, but I'm pretty sure you can't patent an instruction set. You can patent the implementation hardware, or at least a lot of it, but I doubt that restricts emulation. And I'm pretty sure that you can copyright microcode. Patents are only 20 years BTW. OTOH, copyrights last for all eternity (OK, OK ... maybe only a century or two).
I didn't kill him
In the immortal words of Mandy Rice-Davies (sort of) -- Well, you would say that, wouldn't you.
"This has nothing to do with any of the complaints over IME since this functionality is completely within the user's control."
As I read it, ME is sort of like the Hotel California. You can turn it off any time you wish. But it's still there and running. (Where is it getting it's power from?)
Many excellent suggestions: But I think it's curious that neither Candide nor Alice in Wonderland are cited.
Three others worth looking at if one has somehow missed them. ."One Day in the Life of Ivan Denisovich" -- Aleksandr Solzhenitsyn ."Zen and the Art of Motorcycle Maintenance: An Inquiry into Values" -- Robert M. Pirsig
. "In Retrospect" -- Robert McNamara. McNamara seems almost unique among decision makers not in having made terrible decisions, but in admitting it and trying to provide some thoughts on what can be learned from his mistakes).
I quite agree. I didn't find "A Catcher in the Rye" to be unreadable, but I could never understand what was so so great about it. I suppose that we are deeply flawed individuals doomed forever to blunder through the literary darkness vainly seeking warmth and shelter..
I recall Twain's final published story -- "Captain Stormfield's Visit to Heaven" as being exceedingly funny and quite insightful.
Sounds very efficient. Have you thought about automating project queue deletion?How about transferring your development from India to Swaziland? I believe that may be the coming thing.
It.s been a long time, but I really had some experience with bug tracking starting back when the earth was young and the IBM Model 026 cardpunch ruled all. And thereafter for a number of decades.
Some thoughts:
[surprisingly often several bugs will turn out to be related. Describing that is mondo-klunky if you don't give the bugs nicknames]
NOTE: too many catagories or lists can get way out of hand.
NOTE: Watch out for creeping beancounteritis. Trying to deal with a bug tracking system with 40 or more mandatory fields for every bug will probably result in it not being used most of the time.
NOTE: Erratic formatting of the lists above is courtesy of Slashdot. It manages to screw up plain old text, OL, UL. and I'm tired of arguing with it. I intended something more readable.
That's about it.
Sounds Simple.
Usually isn't Simple
Don't overlook the $40 fee for slapping a seal on the battery compartment that certifies that the battery has been checked and if it's actually a bomb, it's a cleverly made bomb.
"When airline travel becomes (literally) a pain in the ass, teleconferencing will grow big-time."
You'd think so. But airline travel has been an increasingly miserable experience for decades. Hasn't really done all that much for teleconferencing so far. I think perhaps we (you and I) underestimate humanity's capacity for pain and tolerance for aggravation.
(Probably explains why people still use Windows as well)
Why the hell would any sensible person with another option travel to the US? We clearly don't want visitors.
The message is clear. Vacation elsewhere. Do business requiring travel with competitors in countries that don't torment visitors.
"It doesn't matter if makes absolutely no sense..."
Pretty well sums up modern US border security, and air travel in general as well, no?
Looking at pictures of the thing, it looks more like a engineering test jig than a prototype of anything. Probably some PR guy invited some press guys in to watch while the engineers were running the motors up a few times and making some measurements on some subsystems. I doubt they ever intended for it to get more than a meter or so off the ground.
They seem to have a fair amount of faith in their work, or they wouldn't be standing anywhere near it when the rotors are spinning. In my experience Japanese engineers are (mostly) not crazy.
I have no idea where they are headed with this project, but I doubt the finished product -- if there ever is one -- will look anything like the thing they were testing.
"If you had a flying car, that worked economically somehow, you would just restrict it to hovering a foot off the ground."
That's called a ground-effect machine, aka hovercraft and they work quite well. You can buy one if you really want one. There are practical uses. e.g. if you happen to inherit a small island complete with creepy mansion in the middle of a swamp from a long forgotten uncle
Those who were around in the days of FidoNet and Compuserve will tell you that they handled communication and even some shopping on minimal hardware and very slow data lines substantially more quickly and efficiently than the current shambles.
I'm increasingly finding myself in the "This Isn't working -- Let's back off and try again" camp.
No, I'm not convinced and no further examples are needed. If you can not secure the code -- and there is no chance whatsoever that you can -- the technology is not suited to an internet used for financial, business, shopping, voting, or command and control applications.
If you can figure out a way to limiting scripting to harmless endeavors like entertainment, chatting and gaming, then fine. But depending on the judgment and good sense of web designers not to use the technology in inappropriate places simply isn't going to work. Judgment and good sense are qualities those folks totally lack.
Why would anyone want JavaScript to run natively in assembly? Sounds like a ton of vulnerabilities waiting to happen. We should be going the opposite direction and eliminating JavaScript altogether.
I infer that the desire for native bytecode is so that malware from websites can run more efficiently and not hog our CPUs.
I don't know why you've been downmoded, You're absolutely correct. Expanding internet attack surfaces is possibly the worst idea since the US decided to fix the Middle East by invading Iraq. Getting rid of ALL scripting would be one modest step toward getting the digital world under control. Sometimes I think mankind has a deathwish.