Re:GPL'd code available only by request?
on
Phoenix BIOSOS?
·
· Score: 1
Sigh... you are only required to make changes available under the GPL if you redistribute the compiled binary, and you are not required to notify the original source of your changes.
Efficiency does go up at higher light intensity, but the fact that the device must track means that there must be more horizontal space between the collectors to avoid shading. The assertion that less land will be needed would require a dramatic improvement in efficiency to overcome the handicap of increased inter-collector spacing.
Variation in light intensity usually causes problems in photovoltaic array conversion efficiency. Thus, issues such as inter-collector shading and non-uniform concentration lead to reduced overall efficiency, often by far more than the affected area.
It would be nice if non-imaging concentrators could be used as they could be placed closer together in still configuration rather farther apart as the moving trackers have to be placed. However, the severe variation of intensity generated by non-imaging concentrators usually makes them impractical for photovoltaic applications.
So, saving on photovoltaic material does not also mean saving on land.
While I agree that these types of announcements are overblown (they are talking about high-concentration PV here, which is not a good idea to put on roofs at all for structural reasons, and it only responds to about 80% of the available irradiance anyway due to being limited to beam radiation), the ROI is highly dependent on the economic conditions of the owner. Solar can payback fast if you are a large electricity user in the upper tiers of pricing even without incentives, and with incentives the banks are loving it today in many locations. If you are off-grid in a sensitive environment, you may have little alternative... what is the ROI on that? If you are living in a tiny home in a mild climate with no air conditioning, your ROI could indeed be prohibitive... but blanket statements about ROI are NOT "insightful", moderators.
Every time we write a program and create configuration files that the program can read, we are expressing ideas in a "language". Sometimes we express simple ideas using Windows "INI" syntax, and other times we may write more complicated ideas using Perl include files or bash scripts. Many current versions of *nix allow shebang notation (#! followed by the program name) to shorten the invocation "program cfgfile" down to just "cfgfile" at the commandline, which emphasizes how flexible its idea of "programming language" ought to be.
There is no question that a Tower of Babel is hard to manage, but trying to force every programmer to use the same programming language will simply lead to re-inventing elaborate configuration languages. (XSLT, anyone?) A better solution is to have design/documentation reviews at various points during the life of a project to make sure the software is maintainable by the (multiple!) personnel likely to have to maintain it. Failing to arrange for multiple maintainers is much more likely to lead to project failure/obsolescence than allowing proliferation of languages.
Now it's 4:47 in the afternoon. The peak of the peak.
If this were the "peak of the peak" then your argument would hold water. Unfortunately, the actual peak is usually
right around 7pm to 9pm.
This actually makes sense when you realize that 4-5pm a lot of people are in office buildings, which are fairly straightforward to cool in bulk. Then those people go home and start employing power consuming devices such as stoves, washing machines, dryers and lights, most of which add to the electrical demand, and their rejected heat has to be processed by the smaller-and-less-efficient air conditioning systems. Meanwhile, the ambient temperature has only dropped by 10 degrees or so since 5pm.
Why is this moderated "Informative"? I almost thought it was sarcastic... but I fear he is serious.
The amount of sunlight that can be converted on a fully overcast day in the Seattle-Tacoma region is normally in a range of 70 to 80 percent for photovoltaic solar cells in terms of solar energy.
70 to 80 percent of what? Of the efficiency it has when it is operating at full power, perhaps... but quoting percent of efficiency is highly misleading. If this statistic is meant to refer to 80 percent conversion efficiency (an interpretation which the quote does not rule out) then it is deep in the realm of lies, damned lies and statistics.
Cloud cover as you understand it, depends on visible light spectra. The solar cells absorb far wider bandwidths, at least the ones in common use here.
Actually, the spectral response of crystalline silicon photovoltaic devices is remarkably similar to the visible spectrum. Some thin film technologies extend a bit more into the infrared, and their efficiency is boosted from, say, 6% to perhaps 6.5% under cloudy conditions... but since that is an output that is divided by a small input, it is still just a small output. In the annual energy accumulation it doesn't make nearly as big a difference as the thin-film manufacturers would like you to believe.
Go look at the bus stops with LED readouts
As though reading such devices, installed at lowest cost by the people who have an interest in inflating the value of their product, should be convincing? Not.
The fact of the matter is that no matter how efficient a cell is on cloudy days, there just isn't as much energy available on cloudy days as on sunny days. A heavy overcast probably has 15-30% of the energy as a sunny day, which is certainly better than zero but is a major hit if you can't count on some sunny days to "make hay" on.
Also, efficiency matters to people with limited space in which to install solar arrays. Of course, current production crystalline technology has cells with efficiencies in the high teens, but when packaged the overall efficiency usually drops to the low teens for a number of unavoidable reasons.
"To be positive is to be wrong at the top of your lungs." - wow, what an ass you are.
I am just reminding you that being closed-minded makes you look like an ass.
Note that I am not calling you an ass... just that making over-broad statements makes you look like one. You ought to remember as you write that you might be wrong instead of getting too wrapped up in your conclusion that others are wrong.
If rectification (and inversion) were 97% efficient (and perhaps it is), then there would be no way to save 15% on your power used, and switching to DC would be near pointless. Want to modify your statement?
No. Rectification is not necessarily 97%... it is only that efficient when modern active rectification is used... so I would expect significant savings over cheaper, smaller power supplies. The savings occurs because a) they distribute higher voltage than the typical 120VAc, and b) they eliminate the less-efficient rectification stage that occurs inside the individual smaller computer power supplies. So 97% leaves plenty of room for improvement if a couple of 90% efficient stages can be bypassed.
However, on this note I will sign off, because while I can see possible avenues for energy savings in this experiment, I don't know the details of why this demo achieved the results they claim.
That is one way... granted, the most common way, but not the only way.
To get DC you, um, spin a coil in a magnetic field, then rectify it,
then put a huge capacitor on there to flatten out the humps.
Again, that is one way... and it has power factor problems that
make it undesirable for large installations.
There's just no good method for generating DC.
That is a bold assertion. There is a lot of opinion buried in that
value judgement, "good", though.
And even if there were, electric companies aren't going to run two
new phases (DC+ and DC-) to get it to you from the source.
Probably true. They already use high voltage dc for some transmission-level
links, but the distribution system doesn't have to change.
Instead, the power is going to come to near you as 3-phase, then be
rectified. There is a loss in that rectification, but sadly, you can't
eliminate it, just change where it happens. Moving it to the other side
of your power meter will have an advantage since you theoretically wouldn't
have to pay for the losses, although the electric companies would surely
change their rates to recoup this lost money. But note that even if they
don't change their rates, you haven't saved any energy, just not paid for
as much.
You can't eliminate it, but there ARE methods to minimize it that you
aren't admitting to your argument.
So my guess is this experiment bought into this fallacy, that they measured
their power usage at DC levels, found it was lower and reported that as a
win, when without a source of DC power that doesn't involve rectification
it really isn't.
No, they are aware that the same active rectification that is so popular
with variable speed drives (electric motors) due to good power factor can
achieve 97% efficiency.
I'm sure they save some electricity due to the increased voltage. That
reduces current, which decreases power lost. This is the same reason
electric companies use high voltages for power transmission.
Agreed.
The article seems to imply that power supplies convert 120VAC to 381VDC internally. This just isn't true. They never raise the voltage, and 120VAC peaks at 175V or something like that. Even 240V input would peak at 350V. So I don't get this. I think they just messed up a few numbers and really in the experiment connected rectified 240V (UK 240V, which is one phase double high, not the US one 120V phase over another) directly into the power supplies after the point where the rectifier would normally be.
"To be positive is to be wrong at the top of your lungs."
The test obtained 15% at the facility level.
The test was conducted in the U.S.
It is not a stretch to assume that their power-factor-correcting
480VAC input facility UPSs have 380VDC internally.
From what I can tell, going to DC just would save you the cost of lots of little rectifiers in favor of the cost of one big one. To be honest, since the small rectifiers come in commodity ATX power supplies, you're paying almost nothing for them anyway. So I don't see that it's all that valueable to consolidate them.
The equation asserted is: Lower capital cost + higher energy consumption = higher capital cost + lower energy consumption + energy cost savings. This may or may not be true, but they assert that their demonstration showed it was true.
I would recommend that if we wanted to save the most power on servers, we should just go to 3-phase 440V AC power supplies. A new connector would have to be designed, as the current 440V 3-phase connector would barely fit on the back of a tower, and wouldn't fit on a 1U server. This would save the most possible in losses without having to buy
Post is not referring to a Perl interpreter... it is referring to a plugin for an editing environment. The execution environment of the Perl code written using this plugin remains the usual Perl interpreter, which can still be upgraded. Customers of this product who are still using it to develop or maintain code may have to abandon this plugin and/or use a different editor to get context-sensitive support for new versions of Perl... but anyone who purchases a proprietary software product is really only purchasing the right to use that product, and access to future upgrades is not guaranteed. The justification for proprietary license purchases has to be that the product is useful enough in its current form that it will be worth using even if you have to toss it out the window when the context in which it functions changes. (What if MS had changed the plugin API for VS in a new version?) Don't take those pills the salesmen try to feed you that lead you to believe there will always be upgrades... every company is designed to make money, and in the absence of available source code, one option toward that end is always to leave the customer hanging.
a) The "OSI model"[1] is useful for discussing "how things should be", but it has NOT been the blueprint for the development of the internet. TCP/IP was built on a somewhat less-than-academically-correct foundation, but the "Open Systems Interconnect"[2] internet re-engineering effort failed because it included too many requirements up front by people who had never implemented to meet their own requirements.
b) The internet needs government regulation? Which one? Oh, well, don't bother answering, since the internet exists because it was advantageous to agree on certain standard protocols, yet necessary in most cases to invent things on your own without predefined protocols. Regulation can only hinder that process.
I like standards... but the internet is a prime example of why standards should be developed in hindsight.
> > you complain about "yahoos" deciding how often > > you should refresh your cache. > > No, actually I think he was arguing that DNS admins else where should > respect his decisions about how long to cache lookups for his > address/name space... even if they do feel a miniute increase in bandwidth > utilization.
If that is the case, he mis-read my original comments (which I still think clearly described authoritative servers telling "nearby" caching servers how long to cache), and I interpreted his use of the term "infrastructure" to mean his caching server. However, since he later attacked the existing DNS design, I don't think we misunderstood each other... we just disagreed.
> Maybe DNS admins (or the folks who write the bind code) > should set up a decaying/backed-off TTL parameter linked > to the number of queries rather than setting some simple > minded constant parameter.
Unlike congestion relief, I don't think DNS name changes are affected by traffic... they are more of a characteristic of the way IP addresses for the server are handled.
> > prior to a connection, the TCP state tables are > > undefined. > > Not if you get a stale response to your initial DNS query. If you do, > then the problem will be passed on to the resulting network connections > that are attempted by the application to that old address.
My point is that your initial DNS query is a totally separate network interaction than the one associated with opening the connection to the target you REALLY wanted.
The previous poster tried to argue that this is a broken design, but from the network interaction perspective merging the DNS lookup and target connection state table initialization would look identical... that is, a separate DNS packet exchange of some sort would have to have been completed if the local cache was stale before the target packets could be sent, so why bother merging the two?
> servers at google spend most of their life burried under > one type of request or another; what's so damned special > about DNS?
This is a fascinating example of "I can't make up my mind what I want".... here you seem to be arguing that we might as well not have any caching at all (since it isn't special), but below you complain about "yahoos" deciding how often you should refresh your cache.
> Uh, that's what i want... some yahoo out on the internet > deciding how long it should take for me to effect a change > on my infrastructure. That's routing into damage, not around it.
> The point that everyone is missing
I wish your explanation were more clear, then...
> is that client TCP state tables are completely divorced from > DNS's distributed database parameter (TTL) that dictates how > quickly infrastructure can be executed.
prior to a connection, the TCP state tables are undefined. That is precisely when you need DNS data (you have to specify a destination IP address, Holmes!)... and it is also when caching pays off... for YOU. Remember... DNS is distributed... the client isn't the only node that benefits from caching.
> This is a fundamental flaw in DNS and directly impacts > trust relationships on the internet.
Let me get this straight... you could not cache at all, or you could gain some benefit (faster dns response, lower bandwidth use) and still keep your users happy, yet you think it is better to put your ego in the picture and tell your users how often they need to learn of changes? Static IP addresses are getting scarce, bub... and your users are going to want to keep up with the dynamic ones.
> Anyone who tells you > differently either doesn't know what the fsck their talking about > or is in love with the code the wrote....stuff that in your ISC > pipe and smoke it.
Chill, man... one minute you're tryin' to argue coherently, and the next you're usin' fightin' words.
This post is a troll... but in case the poster came by their lack of clue honestly I'll bite...
1) to spread the dns serving load, keeping the answer to "what is the ip address of google.com" in a nearby dns server for "awhile" is a good thing
2) the operator of the nearby dns server could decide that "awhile" is a week... but then your dynamically updated dns entry for your PPPoE connection won't be updated by the time you get to work and want to listen to your MP3s
3) the operator could decide that "awhile" is an hour, and then the authoritative server for "google.com" would be buried in requests
4) Better to let the operator of the authoritative server tell the nearby servers how long "awhile" should be.
The issue isn't that the clueless "nearby" DNS administrators ignore TTLs and do not cache at all... the issue is that they ignore what the authoritative server suggests is appropriate but they cache anyway... so you can't listen to your MP3s because your work computer thinks your collection is still where it used to be a week ago, even though the authoritative DNS entry has changed an hour ago.
I used to agree with this... but am not so sure I do anymore. I have worked with PV in tracking and non-tracking configurations, and mechanical systems to follow the sun accurately enough to obtain temperatures necessary to liquefy sodium (I worked with high-concentration PV) are also subject to wear and tear that reduce their accuracy and incur significant maintenance costs. In addition, any time a cloud comes along it basically becomes nonfunctional. Low temperature thermal is valuable for space heating, and PV is valuable for electricity production, but I don't buy the high-temperature sales pitch.
I do agree that energy efficiency is crucial... but the idea that PV is best used in mobile applications is silly... the power required for typical transportation systems greatly exceeds the radiant power impinging on any reasonable envelope for the vehicle... unless you are in space, where you can really spread out. Whatever power plant you use for the base transportation system should be more than sufficient to supply extra power for any load that would be practical for the PV to supply in such an enclosed volume.
When operating near their design point, most switching power supplies operate at 90+% effiency. Operating at less than 20% of design power can put it into efficiency mud, though. How bad the dropoff in efficiency is depends on the the switcher design. So, avoid oversizing excessively.
DC-DC converters have similar characteristics, though the peak efficiency is often five or ten percent lower. You can't really avoid something like this completely because you need regulated power in the computer.
It can help to reduce the number of conversion steps, though, since each one siphons off some power. Thus, a PV panel feeding an inverter feeding a wall wort feeding an internal dc-dc converter will generally have higher losses than a computer running just with a DC power supply from battery. However, you may find the laptop to be more reliable than a component-based system would be.
Key word is "tracking"... this is a concentrator system that only uses beam radiation directly from the sun. The square foot or so will most likely involve a fresnel lens to concentrate the light on very small, highly efficient cells. Any light not coming straight from the sun (bouncing off of clouds, atmospheric dispersion, or reflecting off of nearby buildings) will simply be ignored by the concentrator, so depending on the tracker orientation you could see terrestrial features (building next door, streets, sunbathers) between the lenses pretty clearly.
Problem: while very small cells can be made much more efficient than the larger cells used in non-concentrating systems, I don't see how they can say "100% efficiency" with a straight face. 30% is pretty hard to get in production cells... even the tiny ones used in concentrators.
Problem: Tracking implies moving parts. Ever see a device with moving parts left out in the baking sun for years? They don't keep moving very well. Tracking the sun in two angles is a particularly expensive and unreliable operation... and if they build millions of these things for office buildings, you can bet a large fraction will stop tracking before long. Ever averaged a couple of "100"s with a whole lot of "0"s? I've seen it, and you get a low production level and a general impression of flakiness, and I am not talking about pie crust.
Problem: Solar cells don't individually produce very much voltage... so they need to be strung together to make an "array" that can produce enough voltage to feed an inverter for connection to the ac mains. Let one cell get a shadow, or the tracking be off a little, and it will be the weak link in the whole chain, possibly eliminating any output from the whole array. Random variation in individual trackers wiil exacerbate this problem to the point where required tolerances for will be... well, intolerable. Yes, bypass diodes can mitigate some of this mismatch, but these things add up very quickly.
Flat plate solar is working today, although it is probably still 50-100% more expensive than Iraqi fuel-oil-produced electricity. It isn't 100% efficient, and if the installer isn't well trained you can end up with a big goose egg, but it is pretty widely usable now. Just make sure your expectations are that the mismatch and other expected losses mean you should be prepared to get 70% of the manufacturer's rated output by the time you read your energy meter, and do the math. (There are a lot of reasons for this apparent overrating... it is just the way this technology works.)
Concentrators, unlike flat plate, are uncommon, difficult to install, and easily disrupted. Don't hold your breath for "100% efficient" solar from these people.
Slashdot Mirror
Sigh... you are only required to make changes available under the GPL if you redistribute the compiled binary, and you are not required to notify the original source of your changes.
Efficiency does go up at higher light intensity, but the fact that the device must track means that there must be more horizontal space between the collectors to avoid shading. The assertion that less land will be needed would require a dramatic improvement in efficiency to overcome the handicap of increased inter-collector spacing. Variation in light intensity usually causes problems in photovoltaic array conversion efficiency. Thus, issues such as inter-collector shading and non-uniform concentration lead to reduced overall efficiency, often by far more than the affected area. It would be nice if non-imaging concentrators could be used as they could be placed closer together in still configuration rather farther apart as the moving trackers have to be placed. However, the severe variation of intensity generated by non-imaging concentrators usually makes them impractical for photovoltaic applications. So, saving on photovoltaic material does not also mean saving on land.
While I agree that these types of announcements are overblown (they are talking about high-concentration PV here, which is not a good idea to put on roofs at all for structural reasons, and it only responds to about 80% of the available irradiance anyway due to being limited to beam radiation), the ROI is highly dependent on the economic conditions of the owner. Solar can payback fast if you are a large electricity user in the upper tiers of pricing even without incentives, and with incentives the banks are loving it today in many locations. If you are off-grid in a sensitive environment, you may have little alternative... what is the ROI on that? If you are living in a tiny home in a mild climate with no air conditioning, your ROI could indeed be prohibitive... but blanket statements about ROI are NOT "insightful", moderators.
Every time we write a program and create configuration files that the program can read, we are expressing ideas in a "language". Sometimes we express simple ideas using Windows "INI" syntax, and other times we may write more complicated ideas using Perl include files or bash scripts. Many current versions of *nix allow shebang notation (#! followed by the program name) to shorten the invocation "program cfgfile" down to just "cfgfile" at the commandline, which emphasizes how flexible its idea of "programming language" ought to be. There is no question that a Tower of Babel is hard to manage, but trying to force every programmer to use the same programming language will simply lead to re-inventing elaborate configuration languages. (XSLT, anyone?) A better solution is to have design/documentation reviews at various points during the life of a project to make sure the software is maintainable by the (multiple!) personnel likely to have to maintain it. Failing to arrange for multiple maintainers is much more likely to lead to project failure/obsolescence than allowing proliferation of languages.
If it is techno-babble I am on it... but as I recall the whole problem with Techno-Babel is the balkanization of babble.
This actually makes sense when you realize that 4-5pm a lot of people are in office buildings, which are fairly straightforward to cool in bulk. Then those people go home and start employing power consuming devices such as stoves, washing machines, dryers and lights, most of which add to the electrical demand, and their rejected heat has to be processed by the smaller-and-less-efficient air conditioning systems. Meanwhile, the ambient temperature has only dropped by 10 degrees or so since 5pm.
The fact of the matter is that no matter how efficient a cell is on cloudy days, there just isn't as much energy available on cloudy days as on sunny days. A heavy overcast probably has 15-30% of the energy as a sunny day, which is certainly better than zero but is a major hit if you can't count on some sunny days to "make hay" on.
Also, efficiency matters to people with limited space in which to install solar arrays. Of course, current production crystalline technology has cells with efficiencies in the high teens, but when packaged the overall efficiency usually drops to the low teens for a number of unavoidable reasons.
Note that I am not calling you an ass... just that making over-broad statements makes you look like one. You ought to remember as you write that you might be wrong instead of getting too wrapped up in your conclusion that others are wrong.
No. Rectification is not necessarily 97%... it is only that efficient when modern active rectification is used... so I would expect significant savings over cheaper, smaller power supplies. The savings occurs because a) they distribute higher voltage than the typical 120VAc, and b) they eliminate the less-efficient rectification stage that occurs inside the individual smaller computer power supplies. So 97% leaves plenty of room for improvement if a couple of 90% efficient stages can be bypassed.However, on this note I will sign off, because while I can see possible avenues for energy savings in this experiment, I don't know the details of why this demo achieved the results they claim.
That is one way... granted, the most common way, but not the only way.
Again, that is one way... and it has power factor problems that make it undesirable for large installations.
That is a bold assertion. There is a lot of opinion buried in that value judgement, "good", though.
Probably true. They already use high voltage dc for some transmission-level links, but the distribution system doesn't have to change.
You can't eliminate it, but there ARE methods to minimize it that you aren't admitting to your argument.
No, they are aware that the same active rectification that is so popular with variable speed drives (electric motors) due to good power factor can achieve 97% efficiency.
Agreed.
"To be positive is to be wrong at the top of your lungs."
The equation asserted is: Lower capital cost + higher energy consumption = higher capital cost + lower energy consumption + energy cost savings. This may or may not be true, but they assert that their demonstration showed it was true.
Post is not referring to a Perl interpreter... it is referring to a plugin for an editing environment. The execution environment of the Perl code written using this plugin remains the usual Perl interpreter, which can still be upgraded. Customers of this product who are still using it to develop or maintain code may have to abandon this plugin and/or use a different editor to get context-sensitive support for new versions of Perl... but anyone who purchases a proprietary software product is really only purchasing the right to use that product, and access to future upgrades is not guaranteed. The justification for proprietary license purchases has to be that the product is useful enough in its current form that it will be worth using even if you have to toss it out the window when the context in which it functions changes. (What if MS had changed the plugin API for VS in a new version?) Don't take those pills the salesmen try to feed you that lead you to believe there will always be upgrades... every company is designed to make money, and in the absence of available source code, one option toward that end is always to leave the customer hanging.
a) The "OSI model"[1] is useful for discussing "how things should be", but it has NOT been the blueprint for the development of the internet. TCP/IP was built on a somewhat less-than-academically-correct foundation, but the "Open Systems Interconnect"[2] internet re-engineering effort failed because it included too many requirements up front by people who had never implemented to meet their own requirements.
n nect
b) The internet needs government regulation? Which one? Oh, well, don't bother answering, since the internet exists because it was advantageous to agree on certain standard protocols, yet necessary in most cases to invent things on your own without predefined protocols. Regulation can only hinder that process.
I like standards... but the internet is a prime example of why standards should be developed in hindsight.
[1] http://en.wikipedia.org/wiki/OSI_model
[2] http://en.wikipedia.org/wiki/Open_Systems_Interco
> > you complain about "yahoos" deciding how often
> > you should refresh your cache.
>
> No, actually I think he was arguing that DNS admins else where should
> respect his decisions about how long to cache lookups for his
> address/name space... even if they do feel a miniute increase in bandwidth
> utilization.
If that is the case, he mis-read my original comments (which I still think clearly described authoritative servers telling "nearby" caching servers how long to cache), and I interpreted his use of the term "infrastructure" to mean his caching server. However, since he later attacked the existing DNS design, I don't think we misunderstood each other... we just disagreed.
> Maybe DNS admins (or the folks who write the bind code)
> should set up a decaying/backed-off TTL parameter linked
> to the number of queries rather than setting some simple
> minded constant parameter.
Unlike congestion relief, I don't think DNS name changes are affected by traffic... they are more of a characteristic of the way IP addresses for the server are handled.
> > prior to a connection, the TCP state tables are
> > undefined.
>
> Not if you get a stale response to your initial DNS query. If you do,
> then the problem will be passed on to the resulting network connections
> that are attempted by the application to that old address.
My point is that your initial DNS query is a totally separate network interaction than the one associated with opening the connection to the target you REALLY wanted.
The previous poster tried to argue that this is a broken design, but from the network interaction perspective merging the DNS lookup and target connection state table initialization would look identical... that is, a separate DNS packet exchange of some sort would have to have been completed if the local cache was stale before the target packets could be sent, so why bother merging the two?
> servers at google spend most of their life burried under
... and it is also when caching pays off... for YOU. Remember... DNS is distributed... the client isn't the only node that benefits from caching.
...stuff that in your ISC
> one type of request or another; what's so damned special
> about DNS?
This is a fascinating example of "I can't make up my mind what I want".... here you seem to be arguing that we might as well not have any caching at all (since it isn't special), but below you complain about "yahoos" deciding how often you
should refresh your cache.
> Uh, that's what i want... some yahoo out on the internet
> deciding how long it should take for me to effect a change
> on my infrastructure. That's routing into damage, not around it.
> The point that everyone is missing
I wish your explanation were more clear, then...
> is that client TCP state tables are completely divorced from
> DNS's distributed database parameter (TTL) that dictates how
> quickly infrastructure can be executed.
prior to a connection, the TCP state tables are undefined. That is precisely when you need DNS data (you have to specify a destination IP address, Holmes!)
> This is a fundamental flaw in DNS and directly impacts
> trust relationships on the internet.
Let me get this straight... you could not cache at all, or you could gain some benefit (faster dns response, lower bandwidth use) and still keep your users happy, yet you think it is better to put your ego in the picture and tell your users
how often they need to learn of changes? Static IP addresses are getting scarce, bub... and your users are going to want to keep up with the dynamic ones.
> Anyone who tells you
> differently either doesn't know what the fsck their talking about
> or is in love with the code the wrote.
> pipe and smoke it.
Chill, man... one minute you're tryin' to argue coherently, and the next you're usin' fightin' words.
*sigh*
This post is a troll... but in case the poster came by their lack of clue honestly I'll bite...
1) to spread the dns serving load, keeping the answer to "what is the ip address of google.com" in a nearby dns server for "awhile" is a good thing
2) the operator of the nearby dns server could decide that "awhile" is a week... but then your dynamically updated dns entry for your PPPoE connection won't be updated by the time you get to work and want to listen to your MP3s
3) the operator could decide that "awhile" is an hour, and then the authoritative server for "google.com" would be buried in requests
4) Better to let the operator of the authoritative server tell the nearby servers how long "awhile" should be.
The issue isn't that the clueless "nearby" DNS administrators ignore TTLs and do not cache at all... the issue is that they ignore what the authoritative server suggests is appropriate but they cache anyway... so you can't listen to your MP3s because your work computer thinks your collection is still where it used to be a week ago, even though the authoritative DNS entry has changed an hour ago.
I used to agree with this... but am not so sure I do anymore. I have worked with PV in tracking and non-tracking configurations, and mechanical systems to follow the sun accurately enough to obtain temperatures necessary to liquefy sodium (I worked with high-concentration PV) are also subject to wear and tear that reduce their accuracy and incur significant maintenance costs. In addition, any time a cloud comes along it basically becomes nonfunctional. Low temperature thermal is valuable for space heating, and PV is valuable for electricity production, but I don't buy the high-temperature sales pitch.
I do agree that energy efficiency is crucial... but the idea that PV is best used in mobile applications is silly... the power required for typical transportation systems greatly exceeds the radiant power impinging on any reasonable envelope for the vehicle... unless you are in space, where you can really spread out. Whatever power plant you use for the base transportation system should be more than sufficient to supply extra power for any load that would be practical for the PV to supply in such an enclosed volume.
DC-DC converters have similar characteristics, though the peak efficiency is often five or ten percent lower. You can't really avoid something like this completely because you need regulated power in the computer.
It can help to reduce the number of conversion steps, though, since each one siphons off some power. Thus, a PV panel feeding an inverter feeding a wall wort feeding an internal dc-dc converter will generally have higher losses than a computer running just with a DC power supply from battery. However, you may find the laptop to be more reliable than a component-based system would be.
Problem: while very small cells can be made much more efficient than the larger cells used in non-concentrating systems, I don't see how they can say "100% efficiency" with a straight face. 30% is pretty hard to get in production cells... even the tiny ones used in concentrators.
Problem: Tracking implies moving parts. Ever see a device with moving parts left out in the baking sun for years? They don't keep moving very well. Tracking the sun in two angles is a particularly expensive and unreliable operation... and if they build millions of these things for office buildings, you can bet a large fraction will stop tracking before long. Ever averaged a couple of "100"s with a whole lot of "0"s? I've seen it, and you get a low production level and a general impression of flakiness, and I am not talking about pie crust.
Problem: Solar cells don't individually produce very much voltage... so they need to be strung together to make an "array" that can produce enough voltage to feed an inverter for connection to the ac mains. Let one cell get a shadow, or the tracking be off a little, and it will be the weak link in the whole chain, possibly eliminating any output from the whole array. Random variation in individual trackers wiil exacerbate this problem to the point where required tolerances for will be... well, intolerable. Yes, bypass diodes can mitigate some of this mismatch, but these things add up very quickly.
Flat plate solar is working today, although it is probably still 50-100% more expensive than Iraqi fuel-oil-produced electricity. It isn't 100% efficient, and if the installer isn't well trained you can end up with a big goose egg, but it is pretty widely usable now. Just make sure your expectations are that the mismatch and other expected losses mean you should be prepared to get 70% of the manufacturer's rated output by the time you read your energy meter, and do the math. (There are a lot of reasons for this apparent overrating... it is just the way this technology works.)
Concentrators, unlike flat plate, are uncommon, difficult to install, and easily disrupted. Don't hold your breath for "100% efficient" solar from these people.