After the Nth time someone as approached me talking about flaws in BIND's random number generator I just have to ask myself, why the hell do the bind people, with no real cryptographic knowledge, think they can write their own? Bind doesn't seem to even have an option to use the OS's PRNG.
I had an interesting discussion with Amit regarding all the hacks people (including the Bind people) do to try to roll their own random number generator and it prompted me to review our own IP randomization code (and the 'off' default). After review I was decidedly uneasy about its secureness, mainly because it was trying to use an algorithmically generated cycle for a tiny namespace (16 bits, actually 15 the way it was coded). The problem with the IP sequence space is that you can't just randomize it, you also have to ensure that sequence numbers are not immediately repeated. DNS has similar issues.
I gave up trying to improve the algorithm and decided to throw in the towel and allocate 128KB of memory to do a look-ahead running shuffle of the 65536 possible sequence number using the system's PRNG. It's not possible to do better then that, frankly. We also decided to turn on ip randomization by default.
So that brings me back to the question: Why the hell doesn't bind have an option to use the system PRNG? Not all systems have a good random number generator, but I trust ours far more then the junk coded into bind. For that matter, I don't really mind if bind ate another 128K of memory to secure its own sequence space, if that is what it takes.
I know enough about cryptology to know that I am not a cryptographer. But regardless of that, I can still get a good feel for someone else's code and what BIND does scares me. The y need to change their code to default to something more secure, even if it is memory intensive. If they want to give their users the option to use the less memory intensive algorithm that's fine with me, but the default needs to be more secure.
DNS has its own design issues, but that is no excuse for software to exasperate them.
I don't think they have much of a choice. They have to check for game hacks, cheats, and key loggers. If they don't then cheaters basically get free reign over the game and destroy their subscriber base (similar to how hacks put the final nail in Diablo's coffin), and tens of thousands of people who get key-logged wind up blaming Blizzard instead of Microsoft for their woes. It's really an act of self-preservation for Bliz.
Why should we care? Only a complete fool actually stores sensitive information on a Windows box anyway. Oh wait, that's most of the population... well anyway I still don't care.
It's not really possible to do this. DC requires considerably larger wires unless you really bump up the voltage, otherwise you wind up with very serious losses from wire resistance. Plus nobody wants to have 1000+ VDC wiring going throughout their home, there are serious safety issues. If you look at history you will find that, in fact, DC came first but quickly lost out to AC due to wiring, wiring losses, and safety issues.
Maybe we will start to see more DC when we get low-cost room temperature superconducting cables. Running DC over superconducting cables is actually used in a few places in the U.S., by large power companies, because it is extremely efficient (when you have a superconducting cable) and requires no synchronization.
Be careful here. In California, which is where I live too, it doesn't get dreadfully hot like it does in the midwest, or at least not for more then a few days a year usually. A solar array of the size normally needed to reach net-zero with the power company doesn't even come close to being able to generate the power needed to run even small whole-home air conditioning systems. As long as the AC is only used a few days out of the year (which is typical in California), then you can still reach net-zero over the whole year. But in somewhere like Texas you wouldn't have a chance. AC is usually not in the cards if you are trying to achieve energy independence.
The real question here is how will these panels stack up to current poly panels with regards to their life span? All solar panels degrade over time - that is, produce less power as they get older. Rule of thumb for a poly panel is around 25 years. While there are many types of panels only a few are actually in mass production and have the required life spans. If you are looking to install solar now, polycrystalline panels are what you want to get.
1.5 to 2 KW worth of panels is enough to run a typical house unless you have a machine room. Even if you use more power then your panels can produce, it's actually all to the good because it means the panels are recovering the highest-tier electricity costs for you, dropping you down to a lower tier with your utility company.
You don't want batteries unless you are off-grid, and most people will be on-grid. There are many grid-tie solutions available and costs have come down considerably over the years. Batteries are of course essential if you are off-grid but knowing the many hackers here I'm sure many of you would like to be able to disconnect from the utility completely, survive blackouts, and so forth... but generally speaking, the batteries and equipment required to do that adds a lot to the cost of the system and involve considerably more maintenance and worry.
A straight grid-tie system is completely maintenance free. I literally have not had to touch my system since the day it was installed. I just pop into the garage and stare at the cumulative power display every so often:-)
It took them long enough. I exchanged email with the NYTimes years ago about the whole issue of paid internet subscriptions. I told them right out that it wasn't going to work but they didn't listen. I can't imagine how many readers they lost because of that move. It's nice to see them finally come around.
Even so, it is a sign of our times that news sources are being forced into these lower-revenue situations. The quality of the news we get has been degrading slowly for decades but the internet has seriously accelerated the problem. Most news stories these days are factually incorrect and contain very little actual information. They operate more as one big rumor mill wrapping a tiny bit of first-hand reporting and content.
Will the new consumer-driven news mechanic work? So far its been a disaster (and here I am not talking about the NYTimes but the state of news in general). Right now we have 24-hour coverage of trivial things like OJ Simpson and Britney Spears and virtually no coverage of the issues that matter the most to our future.
Here's the problem. Where did the Linux folks get the code from? Did they get it from OpenBSD, after OpenBSD had integrated it into their framework and augmented it? Or did they get it from the original FreeBSD work that Sam did?
If they got the code directly from Sam's distribution then Sam clearly allows them to relicense it with the GPL only.
If they got it from anywhere else, for example if they got it from OpenBSD CVS repository after OpenBSD made changes to it and after OpenBSD decided to use the same ability to select the license to select BSD, then they can't.
I think part of the confusion here is that people are so angry about how the GPL is being used (or not used) by the commercial world the angst is bleeding over into the BSD world. But there really should be no confusion because BSD code has been used in proprietary commercial products for decades. Literally 30+ years. Not only that but many of the people using BSD code in proprietary settings are the very people that constructed and used the license way back in the 80's. And they did all that in the 90's. Anyone remember Ingres? So, no, there is no confusion.
The plain fact of the matter is that the GPL's viral nature is not helping the cause of open source at all. All it is doing is making it possible for the authors of pieces of GPLd code that become very popular to make the code proprietary, simply by stopping work on the GPL'd version. Having written several large pieces of OSS code myself I know very well that 99.9% of the people who use and talk about open source products are not in any position to take advantage of the open nature of the source code and even very good software can rot in place once the original developers stop working on it. All the GPL does is make the code rot faster. The vast majority of GPLd code used in the commercial world is used simply as a base on top of which proprietary applications run. Oops.
Again, the problem here is not the license, it is that people do not know what the intent of the original author was. That is, I haven't seen an email or posting from the original authors (is there one somewhere in this mess?) clarifying their position on the matter. It is the ethics of the situation that matter the most to the open source community and the ethics that matter most to me.
Frankly I am at a complete loss as to why these folks want to dual-license the code anyway. I see no advantage to the open-source community in doing so.
Your statement does not contradict mine in the least. So my 'argument' doesn't fall on its face in the least. Rather, you didn't bother to read or understand my posting. I personally have no knowledge of what the original author's intent was. If you do, then post the email in question and that will be the end of the matter so far as I am concerned.
There's a lot of confusion here, but one thing that is set in stone is that if there is a BSD license on a piece of source code, that license cannot be physically removed from the source code.
If you look at source from projects like FreeBSD, OpenBSD, NetBSD, and my own DragonFly project, as well as virtually any other large BSD project, you will find that a huge number of source files contain multiple licenses. Nearly all such licenses are BSD-derivative. The issue here is not the presence of multiple licenses but instead how they should be interpreted.
I and all the open source authors I know have always interpreted the presense of multiple licenses as a union of license terms as it pertains to the portions of the source file created or modified by the authors in question. For example, if you went back in the CVS history of a source file and pulled at that older version of the code, potentially with fewer licenses attached to it, then you would be able to operate on that older version of the code and be bound only to the licenses that existed at that time. Another example, if person A builds a piece of software and applies the BSD license to it, and later on person B makes changes (or not) and adds the GPL to the code (if we assume for the moment that this is legal to do)... then all you have to do to get out of the GPL is to simply use a version of the source file where the GPL is not present. That's it. Even if the added GPL were interpreted as being illegal that still does not give you the right to use the second author's modifications to the work when you refuse to accept the license. However, neither does it necessarily give the second author the right to use the original author's work, and that is what Theo is arguing right now. and I think Theo is correct in this case.
But again, regardless of how you interpret the legality or how you interpret the existence of multiple licenses in a piece of source code, the BSD license CANNOT be removed from that code, ever, by anyone except the copyright holder, for any reason.
So in my view it is 'ok' to make modifications to a piece of open source code and slap on your own license for those modifications as long as the existing licenses allow it and as long as the original authors intent is to allow it. I have always interpreted the BSD license as allowing that because that is always how BSD developers have always interpreted the presence of multiple licenses in BSD code in the past. BSD developers have always been very careful to not accept patches that add incompatible licenses for no good reason, and have always been careful to not use someone else's work in ways that was clearly not intended by the original authors, legal or not.
The spirit of the intent of the original author is what counts the most in the open source world. It is not a legal definition. It seems very clear to me that the ORIGINAL authors of the code that was relicensed do not wish it to be relicensed under the GPL. In the open source world, that trumps everything else. If they don't want it to be relicensed, then it can't be relicensed, period, regardless of the legalese. It is unarguable in the court of the open source world.
Now copyright law has its own interpretation of how licenses in derived works operate, even on the definition of what 'derived' means. From a purely legal standpoint -- that is, if one were to sue in court, the interpretation is going to be different from the interpretation of the open source community.
No matter what the legal interpretation is, though, I would not consider anyone creating a derived work from that code base and relicensing it under the GPL against the express wishes of the original authors to be part of the open source community any more. If these people are expressly going against the wishes of the original authors their modifications should be censored by our community, period.
Really. Just about every one of you. You think code grows on trees and every programmer in the world who doesn't subscribe to some crazy religeous mantra is an immoral thief. You think that some random unnamed company is somehow stealing your future if they happen to not want to contribute their changes back. In fact, you all seem to think that these companies are somehow adding such a huge improvement to code X, Y, and Z that the open source world couldn't duplicate it. You think the entire world consists of large immoral corporations and OMG WE NEED A LICENSE TO PROTECT US FROM THEM! Or what? What utter and complete nonsense.
Those of us who actually WRITE code will universally agree on the primary moral issue: You don't remove someone else's copyright, period. End of story.
Its always possible to spec very reliable parts, as well as over-engineer equipment to handle degredation. It just costs a lot more for those sorts components verses the mass-produced junk you see in most consumer electronics. The market is there, its just a lot smaller.
There's still computing equipment out in the field going strong that I designed 20 years ago. They were 68000 based computers with dynamic ram, with everything overengineered by 2x (including running the cpu at 1/2 the clock frequency in production that it was tested at during burn-in, specing resistors for far more current then they were expected to handle, refreshing the ram at 2x the required rate, specing capacitors for almost 2x the voltage they were expected to handle, and throwing a dozen zeners all over the motherboard to protect all the regulated voltage busses). Virtually unbreakable. One even operated for over two weeks completely submerged when a station got flooded before corrosion shorted it out. Some scraping and A good washing in a washing machine (no heat), and after careful drying and replacing a fuse it was ready to go again!
Actually the rovers do have some nuclear elements in them. They have a couple of nuclear decay heaters which put out a watt or two to help keep the electronics compartment warm. Since they work off decay, they are always on.
But not for power generation. The solar cells have been a big success, now it is just a matter of how long the wheels and outside wiring will last. And some of the electronics have radiation sources for operation which decay too (but can be compensated for).
This is kinda silly. If you only have a few keywords you don't need anything sophisticated. If you have more then a few but not more then a few dozen its usually easiest just to arrange them in a linear array and do an index lookup based on the first character to find the starting point for your scan. More then that and you will want to hash them or arrange them in some sort of topology such as a red-black tree.
Generally speaking hashes are very cpu and cache-inefficient beasts, especially if one can reap the benefit of the locality of reference you get with other schemes. Hashes are easy to implement, though, so if you have a lot of keywords and there is either no locality of reference anyway or you don't care about the performance, a hash works just fine.
Insofar as strings go, once you get beyond a certain point its easiest to just hash the string on the front-end, deal with any collisions on the front-end as well (aka implement a string table and modify the hash value for one of the strings if a collision occurs), and then simply reference the string via its hash value in the remainder of the program instead of actually doing any further string comparisons. As an extention of this one can use a larger 64-bit hash and consider any collisions to be fatal. This is extremely viable for a language parser given that the chances of a collision actually occuring are so low you might only get one, or even zero, across the entire domain of source code in existence today.
If you have a fixed set of keywords, then a 16 or 32 bit hash is usually sufficient to avoid collisions. At this point you just generate a header file with the values and switch on them. e.g. hv = hash(str); switch(hv) { case KEYWORD_FOR:... case... }. This is equivalent to the use of some sort of data structure but it winds up being coded and optimized directly by the compiler, and it's very easy to understand the resulting source code.
A large number of programmers can make minor modifications to small software applications.
A medium number of programmers can make minor modifications to medium-sized software applications.
Very few programmers can make any sort of modification to very large software applications. Very, very few.
Bind is a very large, complex piece of software. A good portion of that complexity is due to poor documentation and badly designed algorithms (a problem I've had with bind from the first release on through today), but at this point the majority of the complexity is due to feature creep. I still use bind simply because I do not have the desire to write a replacement for it, and because the only other really good DNS package has a copyright and licence on it that makes it virtually unusable. Software gets stale as it gets older... if I can't keep software up to date after the original author has lost interest then I have no interest incorporating said software, no matter how good it is.
Why the hell is bind trying to implement its own random number generator? It's a piece of junk compared to the random numbers modern BSD OS's generate via libc.
The issue has nothing to do with the number 80, and everything to do with readability and understandability. Most projects require certain limitations to terminal width for just that purpose because it has been amply shown in the past and continues to be shown today that when you DON'T put such restrictions on submissions you wind up with an unreadable mess.
This is the same problem we have with idiots who set their hardware tabs to '3' and expect anyone trying to read their source files to do the same, or who decide that comments should be tabbed out to column 100 regardless of anything else. People do all sorts of crazy things and it might work if every single line of code in a project is your own, but certainly doesn't work when you are incorporating submissions from dozens of different people.
You very, very quickly hit diminishing returns on your ability to efficiently read and understand a source file as you increase the number of columns. Increasing the number of rows is not a problem and actually improves one's ability to read and understand the contents of a file. But increasing the number of columns doesn't work the same way. Usually all it does is create a mess if you actually try to fill in all that space.
80 is not too small, and not too large, not really. That's why projects continue to use it.
-Matt
We already have an ability to run tcp over high bandwidth x delay-product links, its called Selective Acknowledgement (SACK), its implemented by everyone with a clue, and it works just fine.
Also, DragonFly and FreeBSD have had server-side bandwidth delay product band-limiting code in place for years to deal with the most common congestion point, which is the LANWAN interface. Combine that with fair-share scheduling and you don't have to run RED on the routers bordering your server farm. Leave RED where it should be... in the middle of the internet, not on the edges.
New Reno is possibly the most idiotic congestion control algorithm ever devised. It's not hard to do better and still be friendly to the mesh.
AE1 - CPU to memory copy with FST with numeric and null segment exceptions may cause GP faults to be missed and FP linear address mismatch. In otherwords, a segmentation violation will be missed and a write will be allowed to proceed. This will not effect OSs using page tables for protection, which is all OSs. Sounds bad but doesn't sound like it will effect existing OSs
AE2 - Code segment violation may occur if a code stream wraps around a segment. No program does this on purpose, and OSs will just seg-fault the program if it does. The intel errata says it could be exploted by a virus but I don't see how by its current description. Maybe there is something they aren't telling us.
AE3 - POPF/POPFD that sets the trap flag (aka when single-stepping a program) may cause unpredictable behavior. Holy shit. This one is serious.
AE4 - REP MOVS in fast string mode continues in that mode when crossing into a page with a different memory type. This means that when crossing over from a cacheable page to an uncacheable page, the I/Os remain cacheable. And vise-versa. This will never happen on purpose so the question is whether it can be exploited in some way, and the answer to that is not that I can see.
AE5 - Memory aliasing with inconsistent dirty and Access bits may cause a processor deadlock. This means a PTE with 'D'irty set but with 'A'ccess not set. FreeBSD and DragonFly always set the A bit when setting the D bit and will not be effected but I don't know about other OSs. This is a very serious bug though.
AE6 - VM bit will be cleared on a double fault exception. Double faults are usual fatal for the whole machine so unless they can occur in an emulation mode (where the double fault is being emulated). Check your OS. FreeBSD and DragonFly do not try to resume after a double fault and do not take faults in VM mode and are not effected.
AE7 - Incompatible write attributes in page table verses MTTR may consolidate to UC. Not a big deal, doesn't happen unless something has been misprogrammed.
AE8 - FXSAVE after FNINIT without an intervening FP instruction may save uninitialized values for FDP and FDS. This isn't an issue unless the data being written represents a security leak of some sort, such as a portion of the state of another program's FP unit. This could be a security issue with regards to one program snooping another program's cryptography. Statistical snooping possible through this sort of mechanic has been shown to be effective in recent years.
AE9 - LTR can result in a system hang. Well, BSDs don't really use LTR all that much and the conditions required just will not happen on BSD or probably linux either. A break point must be set on the cache line containing the descriptor data? Not from userland!
AE10 - Invalid entries in the page directory pointer table register may cause a GP fault. Not an issue.
AE11 - REP MOVS operation in fast string mode continues in that mode when crossing into a page with a different memory type. Not an issue.
AE12 - FP inexact result exception flag may not be set if the #inexactresult occurs in any FPU instruction with certain instructions occuring afterwords. This is a very serious bug that only compilers can work around (and probably won't).
AE13 - IFU/BSU deadlock may cause system hang. I've no idea what IFU and BSU is.
AE14 - MOV with debug register causes a debug exception. Sounds like the worst that happens here is a program seg faults if this condition is hit while the program is being debugged.
AE15 - INIT does not clear global entries in the TLB. Oh, joy. Intel says that BIOS writers would know of thise errata and cod efor it, but insofar as I know this could be an issue when starting up APs.
AE16 - Use of memory aliasing with inconsistent memory type may cause system hang. It shouldn't be possible for this to happen with a modern OS. It means mapping the same physical page of memory with different memory contr
AI65 - Thermal interrupt does not occur if DTS reaches an invalid temperature. What the hell is an invalid temperature? A disconnected sensor or something? It doesn't sound like something a userland thermal-generating loop can exploit but the errata is not detailed enough to know for sure.
AI79 - REP/STO in specific situation may cause the processor to hang. BIOS patchable. The errata mentions an uncacheable memory store. If this is a pre-requisit then only user programs with access to/dev/io or memory-mapped bus space can exploit it. So e.g. something like XOrg, but not the typical user program. Worse case seems to be a system freeze. Still, this is something to be concerned about.
AI43 - Concurrent MP writes to non-dirty page may result in unpredictable behavior. This one is extremely serious. It effects any threaded program and possibly even programs which are no threaded. This would cause me to not purchase the cpu. It says that a BIOS workaround is possible (aka microcode update).
AI39 - Cache access request from one core hitting a modified line in the L1 cache of another core may cause unpredictable system behavior. What the hell? Are they out of their minds? This is a big-time show stopper. It says it can be fixed with the BIOS (aka microcode update). I sure hope so.
AI90 - Page access bit may be set prior to signaling a code segment limit fault. This one is pretty serious. This cannot occur on most operating systems because the code segment is set to be unlimited and access is governed solely by the page tables. In 64 bit mode emulating 32 bit operation the problem might occur if a bit of code wraps the segment. There are possibly issues in other emulation modes, such as VM86 mode. The effect of setting the page accessed bit will not make a page accessible that was not previously unaccessible, but it will result in unexpected modifications to the page table page and numerous operating systems may free such pages to the page-zerod page list under the assumption that they cleaned the page out when in fact there may be a page table entry with the access bit set (meaning the page wasn't completely zerod when freed). That could cause problems.
AI99 - Updating code page directory attributes without tlb invalidation may result in improper handling of a page fault exception. This one doesn't look too serious, it just means the wrong exception will be taken first, meaning that the OS will probably seg-fault the program. If the OS corrects the issue and retries, the correct exception will be taken on retry. All BSDs that I know of handle page fault exceptions generically and will not be effected. Of greater concern is what sort of modifications to a page directory entry now require TLB invalidations? On FreeBSD and DragonFly, and I assume most BSDs and probably Linux too, page directory entries usually transition between only two states and a TLB invalidation is made when a page directory entry is invalidated, so they wouldn't be effected by this bug.
I couldn't find an exact errata reference but it looks like a ring 0 issue to me too, which means that the OS either doesn't trigger the conditions required or the OS can work around the problem. Some such issues can be fixed in microcode, some have to be dealt with by the operating system.
There are several known TLB issues that are rather serious which all OSs have to have workarounds for. The most serious issue is that reducing the access permissions in a page table entry (such as turning off the valid bit or making the entry read-only) on one cpu can race another cpu's TLB trying to access that same entry. The race can cut an instruction into two pieces on the other cpu and (if e.g. a read-modify-write instruction) result in fireworks. All modern operating systems have to synchronize page table invalidations across all cpus that might be using the page table in question. So, e.g. in a heavily threaded environment if a page table is shared across three cpus invalidations made in that page table requires all three cpus operating systems to synchronize (usually with an IPI) to guarentee that none of them are accessing memory governed by the page table entry being changed. Kernel virtual memory is even worse, since that is shared by all cpus, which is why its better to just keep a cache of mapped memory instead of constantly mapping and unmapping pages in KVM.
There are also serious issues with global pages and mixed TLB entries when switching from small pages to large pages, issues when operating in compatibility modes, issues when using address wrapping. Most of these issues only occur with absurd code sequences, such as an instruction which wraps the address space (which will never occur in real life so can be ignored as long as the issue does not cause a failure in the security model). 90% of the errata is not an issue in a nominally running environment.
In the old days of dialup our biggest problem were USENET pornsters just staying connected 24x7 downloading part x/y of god knows what, essentially taking an entire phone port out of service.
In anycase, I don't know why people believe that a few bucks a month guarentees them unlimited bandwidth. If you want guarentees, or you can't sleep at night, pay for commercial service.
I've had a T1 going into my home for years, paying around $300/month for it. The T1 itself is guarenteed bandwidth but you usually do not terminate it at the phone company. Instead the T1 gets terminated at an ISP (which can be the phone company but is usually not). Well, ok, in REALITY the T1 is usually bundled into a T3 or fiber and THEN terminated at an ISP, but the bandwidth is still guarenteed up until the ISP. You don't go into a packet switch until you hit the ISPs network and it doesn't really matter until you hit the ISP's backhaul to the internet. At that point there is usually so much bandwidth that you get the full T1 rate 'to the internet'.
I have experimented with DSL, but it doesn't compare. For one thing, I serve out a lot of data... my T1's pipe is usually 100% full in the outgoing direction all the time. I can't afford to have hicups. I had a backup DSL line for a while but the outgoing bandwidth sucked rocks. For another, the T1 is considered a special business line and when something goes wrong, the phone company hops on it immediately (though I still have to talk to two entities.. the phone company and the ISP). Still, things get fixed fairly quickly compared to a normal phone line.
Is it worth $300/month for 1.5 MBits in both directions with guarenteed bandwidth and guarenteed quick service? It probably wouldn't be for your run of the mill power user, but for someone like me who is serving out an open source project and managing half a dozen domains, web sites, and mail for friends and family, I just can't afford to have too much downtime or unmanaged bandwidth.
I still have to research a possible cable solution. I haven't heard of the cable company having a guarenteed bandwidth service with that much uplink but who knows, maybe they've done it while I wasn't looking. I dunno about reliability, service, or ping times, though. I kinda like having a 4ms ping.
I wish there were fiber on my street. Maybe some day.
Solar water heating is very inexpensive and environmentally friendly (because no solar cells are actually needed, just something to soak up the sun's heat and a heat exchanger). You generally want to get a closed system heat exchanger, with a separate fluid loop, and not actually loop the water heater's water through the solar unit.
Battery backup is *NOT* inexpensive, nor is it environmentally friendly. Only lead-acid batteries have the kind of capacity required and they need maintainance and space and have relatively short lifespans (5-10 years typically). They require a separate charging system and a transfer switch. In short... if you have a good connection to the utility, putting together a battery system is not worth the cost.
The cheapest most environmentally sensitive solar electric system are standard solar panels and a direct grid-tie inverter. Not the shingles or any of the other experimental junk... they just don't have the life span or the efficiency. Zero maintainance, very long life. This is what I have on my roof.
In terms of (almost) zeroing out your electricity bill with net-meetering... well, it is fairly inexpensive if you have a newer home with energey efficient appliances. My system is somewhat bigger then a standard home needs, 2.5KW, and I can't zero out my electricity bill because I have a machine room. Note however that no solar system can even come close to the electricity requirements of a home Air Conditioner. If you need air conditioning you will never be able to zero-out your electricity bill with a standard 'home' solar electric system.
Solar Cell Manufacturing has gotten a lot better over the years. The environmental cost for manufacturing a panel is something like 6 months now vs the 30 year+ lifespan of the panel. Direct grid-tie inverters take up very little space and require no maintainance whatsoever. Generally you want to use a high voltage inverter, where the solar panels are linked in series instead of in parallel. Such inverters are a lot less bulky then LV systems (and the wiring is a lot less bulky too because it is high-voltage and low-current instead of low-voltage and high-current). My recommendation is a Sunny Boy direct-tie inverter. Never use an inverter which requires a fan.
Some states, in particularly California, have extremely good rebate programs. The Federal tax credit is crap.
Neighbors of mine have tried the shingles, and have tried flexible solar mats on their roofs, with terrible results.
Slashdot Mirror
After the Nth time someone as approached me talking about flaws in BIND's random number generator I just have to ask myself, why the hell do the bind people, with no real cryptographic knowledge, think they can write their own? Bind doesn't seem to even have an option to use the OS's PRNG.
I had an interesting discussion with Amit regarding all the hacks people (including the Bind people) do to try to roll their own random number generator and it prompted me to review our own IP randomization code (and the 'off' default). After review I was decidedly uneasy about its secureness, mainly because it was trying to use an algorithmically generated cycle for a tiny namespace (16 bits, actually 15 the way it was coded). The problem with the IP sequence space is that you can't just randomize it, you also have to ensure that sequence numbers are not immediately repeated. DNS has similar issues.
I gave up trying to improve the algorithm and decided to throw in the towel and allocate 128KB of memory to do a look-ahead running shuffle of the 65536 possible sequence number using the system's PRNG. It's not possible to do better then that, frankly. We also decided to turn on ip randomization by default.
So that brings me back to the question: Why the hell doesn't bind have an option to use the system PRNG? Not all systems have a good random number generator, but I trust ours far more then the junk coded into bind. For that matter, I don't really mind if bind ate another 128K of memory to secure its own sequence space, if that is what it takes.
I know enough about cryptology to know that I am not a cryptographer. But regardless of that, I can still get a good feel for someone else's code and what BIND does scares me. The y need to change their code to default to something more secure, even if it is memory intensive. If they want to give their users the option to use the less memory intensive algorithm that's fine with me, but the default needs to be more secure.
DNS has its own design issues, but that is no excuse for software to exasperate them.
-Matt
I don't think they have much of a choice. They have to check for game hacks, cheats, and key loggers. If they don't then cheaters basically get free reign over the game and destroy their subscriber base (similar to how hacks put the final nail in Diablo's coffin), and tens of thousands of people who get key-logged wind up blaming Blizzard instead of Microsoft for their woes. It's really an act of self-preservation for Bliz.
Why should we care? Only a complete fool actually stores sensitive information on a Windows box anyway. Oh wait, that's most of the population... well anyway I still don't care.
-Matt
Ulp... in fact you are right. I don't know what I was thinking. The only real problem is converting the voltages to reasonable values at the home.
-Matt
It's not really possible to do this. DC requires considerably larger wires unless you really bump up the voltage, otherwise you wind up with very serious losses from wire resistance. Plus nobody wants to have 1000+ VDC wiring going throughout their home, there are serious safety issues. If you look at history you will find that, in fact, DC came first but quickly lost out to AC due to wiring, wiring losses, and safety issues.
Maybe we will start to see more DC when we get low-cost room temperature superconducting cables. Running DC over superconducting cables is actually used in a few places in the U.S., by large power companies, because it is extremely efficient (when you have a superconducting cable) and requires no synchronization.
-Matt
Be careful here. In California, which is where I live too, it doesn't get dreadfully hot like it does in the midwest, or at least not for more then a few days a year usually. A solar array of the size normally needed to reach net-zero with the power company doesn't even come close to being able to generate the power needed to run even small whole-home air conditioning systems. As long as the AC is only used a few days out of the year (which is typical in California), then you can still reach net-zero over the whole year. But in somewhere like Texas you wouldn't have a chance. AC is usually not in the cards if you are trying to achieve energy independence.
-Matt
The real question here is how will these panels stack up to current poly panels with regards to their life span? All solar panels degrade over time - that is, produce less power as they get older. Rule of thumb for a poly panel is around 25 years. While there are many types of panels only a few are actually in mass production and have the required life spans. If you are looking to install solar now, polycrystalline panels are what you want to get.
:-)
1.5 to 2 KW worth of panels is enough to run a typical house unless you have a machine room. Even if you use more power then your panels can produce, it's actually all to the good because it means the panels are recovering the highest-tier electricity costs for you, dropping you down to a lower tier with your utility company.
You don't want batteries unless you are off-grid, and most people will be on-grid. There are many grid-tie solutions available and costs have come down considerably over the years. Batteries are of course essential if you are off-grid but knowing the many hackers here I'm sure many of you would like to be able to disconnect from the utility completely, survive blackouts, and so forth... but generally speaking, the batteries and equipment required to do that adds a lot to the cost of the system and involve considerably more maintenance and worry.
A straight grid-tie system is completely maintenance free. I literally have not had to touch my system since the day it was installed. I just pop into the garage and stare at the cumulative power display every so often
http://apollo.backplane.com/Solar/
-Matt
It took them long enough. I exchanged email with the NYTimes years ago about the whole issue of paid internet subscriptions. I told them right out that it wasn't going to work but they didn't listen. I can't imagine how many readers they lost because of that move. It's nice to see them finally come around.
Even so, it is a sign of our times that news sources are being forced into these lower-revenue situations. The quality of the news we get has been degrading slowly for decades but the internet has seriously accelerated the problem. Most news stories these days are factually incorrect and contain very little actual information. They operate more as one big rumor mill wrapping a tiny bit of first-hand reporting and content.
Will the new consumer-driven news mechanic work? So far its been a disaster (and here I am not talking about the NYTimes but the state of news in general). Right now we have 24-hour coverage of trivial things like OJ Simpson and Britney Spears and virtually no coverage of the issues that matter the most to our future.
-Matt
Ok, I've read the entire threat on linux-kernel.
Here's the problem. Where did the Linux folks get the code from? Did they get it from OpenBSD, after OpenBSD had integrated it into their framework and augmented it? Or did they get it from the original FreeBSD work that Sam did?
If they got the code directly from Sam's distribution then Sam clearly allows them to relicense it with the GPL only.
If they got it from anywhere else, for example if they got it from OpenBSD CVS repository after OpenBSD made changes to it and after OpenBSD decided to use the same ability to select the license to select BSD, then they can't.
It's that simple. Where was the code taken from?
-Matt
I think part of the confusion here is that people are so angry about how the GPL is being used (or not used) by the commercial world the angst is bleeding over into the BSD world. But there really should be no confusion because BSD code has been used in proprietary commercial products for decades. Literally 30+ years. Not only that but many of the people using BSD code in proprietary settings are the very people that constructed and used the license way back in the 80's. And they did all that in the 90's. Anyone remember Ingres? So, no, there is no confusion.
The plain fact of the matter is that the GPL's viral nature is not helping the cause of open source at all. All it is doing is making it possible for the authors of pieces of GPLd code that become very popular to make the code proprietary, simply by stopping work on the GPL'd version. Having written several large pieces of OSS code myself I know very well that 99.9% of the people who use and talk about open source products are not in any position to take advantage of the open nature of the source code and even very good software can rot in place once the original developers stop working on it. All the GPL does is make the code rot faster. The vast majority of GPLd code used in the commercial world is used simply as a base on top of which proprietary applications run. Oops.
Again, the problem here is not the license, it is that people do not know what the intent of the original author was. That is, I haven't seen an email or posting from the original authors (is there one somewhere in this mess?) clarifying their position on the matter. It is the ethics of the situation that matter the most to the open source community and the ethics that matter most to me.
Frankly I am at a complete loss as to why these folks want to dual-license the code anyway. I see no advantage to the open-source community in doing so.
-Matt
Your statement does not contradict mine in the least. So my 'argument' doesn't fall on its face in the least. Rather, you didn't bother to read or understand my posting. I personally have no knowledge of what the original author's intent was. If you do, then post the email in question and that will be the end of the matter so far as I am concerned.
-Matt
There's a lot of confusion here, but one thing that is set in stone is that if there is a BSD license on a piece of source code, that license cannot be physically removed from the source code.
If you look at source from projects like FreeBSD, OpenBSD, NetBSD, and my own DragonFly project, as well as virtually any other large BSD project, you will find that a huge number of source files contain multiple licenses. Nearly all such licenses are BSD-derivative. The issue here is not the presence of multiple licenses but instead how they should be interpreted.
I and all the open source authors I know have always interpreted the presense of multiple licenses as a union of license terms as it pertains to the portions of the source file created or modified by the authors in question. For example, if you went back in the CVS history of a source file and pulled at that older version of the code, potentially with fewer licenses attached to it, then you would be able to operate on that older version of the code and be bound only to the licenses that existed at that time. Another example, if person A builds a piece of software and applies the BSD license to it, and later on person B makes changes (or not) and adds the GPL to the code (if we assume for the moment that this is legal to do)... then all you have to do to get out of the GPL is to simply use a version of the source file where the GPL is not present. That's it. Even if the added GPL were interpreted as being illegal that still does not give you the right to use the second author's modifications to the work when you refuse to accept the license. However, neither does it necessarily give the second author the right to use the original author's work, and that is what Theo is arguing right now. and I think Theo is correct in this case.
But again, regardless of how you interpret the legality or how you interpret the existence of multiple licenses in a piece of source code, the BSD license CANNOT be removed from that code, ever, by anyone except the copyright holder, for any reason.
So in my view it is 'ok' to make modifications to a piece of open source code and slap on your own license for those modifications as long as the existing licenses allow it and as long as the original authors intent is to allow it. I have always interpreted the BSD license as allowing that because that is always how BSD developers have always interpreted the presence of multiple licenses in BSD code in the past. BSD developers have always been very careful to not accept patches that add incompatible licenses for no good reason, and have always been careful to not use someone else's work in ways that was clearly not intended by the original authors, legal or not.
The spirit of the intent of the original author is what counts the most in the open source world. It is not a legal definition. It seems very clear to me that the ORIGINAL authors of the code that was relicensed do not wish it to be relicensed under the GPL. In the open source world, that trumps everything else. If they don't want it to be relicensed, then it can't be relicensed, period, regardless of the legalese. It is unarguable in the court of the open source world.
Now copyright law has its own interpretation of how licenses in derived works operate, even on the definition of what 'derived' means. From a purely legal standpoint -- that is, if one were to sue in court, the interpretation is going to be different from the interpretation of the open source community.
No matter what the legal interpretation is, though, I would not consider anyone creating a derived work from that code base and relicensing it under the GPL against the express wishes of the original authors to be part of the open source community any more. If these people are expressly going against the wishes of the original authors their modifications should be censored by our community, period.
-Matt
Really. Just about every one of you. You think code grows on trees and every programmer in the world who doesn't subscribe to some crazy religeous mantra is an immoral thief. You think that some random unnamed company is somehow stealing your future if they happen to not want to contribute their changes back. In fact, you all seem to think that these companies are somehow adding such a huge improvement to code X, Y, and Z that the open source world couldn't duplicate it. You think the entire world consists of large immoral corporations and OMG WE NEED A LICENSE TO PROTECT US FROM THEM! Or what? What utter and complete nonsense.
Those of us who actually WRITE code will universally agree on the primary moral issue: You don't remove someone else's copyright, period. End of story.
-Matt
Its always possible to spec very reliable parts, as well as over-engineer equipment to handle degredation. It just costs a lot more for those sorts components verses the mass-produced junk you see in most consumer electronics. The market is there, its just a lot smaller.
There's still computing equipment out in the field going strong that I designed 20 years ago. They were 68000 based computers with dynamic ram, with everything overengineered by 2x (including running the cpu at 1/2 the clock frequency in production that it was tested at during burn-in, specing resistors for far more current then they were expected to handle, refreshing the ram at 2x the required rate, specing capacitors for almost 2x the voltage they were expected to handle, and throwing a dozen zeners all over the motherboard to protect all the regulated voltage busses). Virtually unbreakable. One even operated for over two weeks completely submerged when a station got flooded before corrosion shorted it out. Some scraping and A good washing in a washing machine (no heat), and after careful drying and replacing a fuse it was ready to go again!
-Matt
Actually the rovers do have some nuclear elements in them. They have a couple of nuclear decay heaters which put out a watt or two to help keep the electronics compartment warm. Since they work off decay, they are always on.
But not for power generation. The solar cells have been a big success, now it is just a matter of how long the wheels and outside wiring will last. And some of the electronics have radiation sources for operation which decay too (but can be compensated for).
-Matt
This is kinda silly. If you only have a few keywords you don't need anything sophisticated. If you have more then a few but not more then a few dozen its usually easiest just to arrange them in a linear array and do an index lookup based on the first character to find the starting point for your scan. More then that and you will want to hash them or arrange them in some sort of topology such as a red-black tree.
... case ... }. This is equivalent to the use of some sort of data structure but it winds up being coded and optimized directly by the compiler, and it's very easy to understand the resulting source code.
Generally speaking hashes are very cpu and cache-inefficient beasts, especially if one can reap the benefit of the locality of reference you get with other schemes. Hashes are easy to implement, though, so if you have a lot of keywords and there is either no locality of reference anyway or you don't care about the performance, a hash works just fine.
Insofar as strings go, once you get beyond a certain point its easiest to just hash the string on the front-end, deal with any collisions on the front-end as well (aka implement a string table and modify the hash value for one of the strings if a collision occurs), and then simply reference the string via its hash value in the remainder of the program instead of actually doing any further string comparisons. As an extention of this one can use a larger 64-bit hash and consider any collisions to be fatal. This is extremely viable for a language parser given that the chances of a collision actually occuring are so low you might only get one, or even zero, across the entire domain of source code in existence today.
If you have a fixed set of keywords, then a 16 or 32 bit hash is usually sufficient to avoid collisions. At this point you just generate a header file with the values and switch on them. e.g. hv = hash(str); switch(hv) { case KEYWORD_FOR:
-Matt
A large number of programmers can make minor modifications to small software applications.
A medium number of programmers can make minor modifications to medium-sized software applications.
Very few programmers can make any sort of modification to very large software applications. Very, very few.
Bind is a very large, complex piece of software. A good portion of that complexity is due to poor documentation and badly designed algorithms (a problem I've had with bind from the first release on through today), but at this point the majority of the complexity is due to feature creep. I still use bind simply because I do not have the desire to write a replacement for it, and because the only other really good DNS package has a copyright and licence on it that makes it virtually unusable. Software gets stale as it gets older... if I can't keep software up to date after the original author has lost interest then I have no interest incorporating said software, no matter how good it is.
-Matt
Why the hell is bind trying to implement its own random number generator? It's a piece of junk compared to the random numbers modern BSD OS's generate via libc.
-Matt
The issue has nothing to do with the number 80, and everything to do with readability and understandability. Most projects require certain limitations to terminal width for just that purpose because it has been amply shown in the past and continues to be shown today that when you DON'T put such restrictions on submissions you wind up with an unreadable mess. This is the same problem we have with idiots who set their hardware tabs to '3' and expect anyone trying to read their source files to do the same, or who decide that comments should be tabbed out to column 100 regardless of anything else. People do all sorts of crazy things and it might work if every single line of code in a project is your own, but certainly doesn't work when you are incorporating submissions from dozens of different people. You very, very quickly hit diminishing returns on your ability to efficiently read and understand a source file as you increase the number of columns. Increasing the number of rows is not a problem and actually improves one's ability to read and understand the contents of a file. But increasing the number of columns doesn't work the same way. Usually all it does is create a mess if you actually try to fill in all that space. 80 is not too small, and not too large, not really. That's why projects continue to use it. -Matt
We already have an ability to run tcp over high bandwidth x delay-product links, its called Selective Acknowledgement (SACK), its implemented by everyone with a clue, and it works just fine.
Also, DragonFly and FreeBSD have had server-side bandwidth delay product band-limiting code in place for years to deal with the most common congestion point, which is the LANWAN interface. Combine that with fair-share scheduling and you don't have to run RED on the routers bordering your server farm. Leave RED where it should be... in the middle of the internet, not on the edges.
New Reno is possibly the most idiotic congestion control algorithm ever devised. It's not hard to do better and still be friendly to the mesh.
-Matt
Now the core duo/solo errata.
AE1 - CPU to memory copy with FST with numeric and null segment exceptions may cause GP faults to be missed and FP linear address mismatch. In otherwords, a segmentation violation will be missed and a write will be allowed to proceed. This will not effect OSs using page tables for protection, which is all OSs. Sounds bad but doesn't sound like it will effect existing OSs
AE2 - Code segment violation may occur if a code stream wraps around a segment. No program does this on purpose, and OSs will just seg-fault the program if it does. The intel errata says it could be exploted by a virus but I don't see how by its current description. Maybe there is something they aren't telling us.
AE3 - POPF/POPFD that sets the trap flag (aka when single-stepping a program) may cause unpredictable behavior. Holy shit. This one is serious.
AE4 - REP MOVS in fast string mode continues in that mode when crossing into a page with a different memory type. This means that when crossing over from a cacheable page to an uncacheable page, the I/Os remain cacheable. And vise-versa. This will never happen on purpose so the question is whether it can be exploited in some way, and the answer to that is not that I can see.
AE5 - Memory aliasing with inconsistent dirty and Access bits may cause a processor deadlock. This means a PTE with 'D'irty set but with 'A'ccess not set. FreeBSD and DragonFly always set the A bit when setting the D bit and will not be effected but I don't know about other OSs. This is a very serious bug though.
AE6 - VM bit will be cleared on a double fault exception. Double faults are usual fatal for the whole machine so unless they can occur in an emulation mode (where the double fault is being emulated). Check your OS. FreeBSD and DragonFly do not try to resume after a double fault and do not take faults in VM mode and are not effected.
AE7 - Incompatible write attributes in page table verses MTTR may consolidate to UC. Not a big deal, doesn't happen unless something has been misprogrammed.
AE8 - FXSAVE after FNINIT without an intervening FP instruction may save uninitialized values for FDP and FDS. This isn't an issue unless the data being written represents a security leak of some sort, such as a portion of the state of another program's FP unit. This could be a security issue with regards to one program snooping another program's cryptography. Statistical snooping possible through this sort of mechanic has been shown to be effective in recent years.
AE9 - LTR can result in a system hang. Well, BSDs don't really use LTR all that much and the conditions required just will not happen on BSD or probably linux either. A break point must be set on the cache line containing the descriptor data? Not from userland!
AE10 - Invalid entries in the page directory pointer table register may cause a GP fault. Not an issue.
AE11 - REP MOVS operation in fast string mode continues in that mode when crossing into a page with a different memory type. Not an issue.
AE12 - FP inexact result exception flag may not be set if the #inexactresult occurs in any FPU instruction with certain instructions occuring afterwords. This is a very serious bug that only compilers can work around (and probably won't).
AE13 - IFU/BSU deadlock may cause system hang. I've no idea what IFU and BSU is.
AE14 - MOV with debug register causes a debug exception. Sounds like the worst that happens here is a program seg faults if this condition is hit while the program is being debugged.
AE15 - INIT does not clear global entries in the TLB. Oh, joy. Intel says that BIOS writers would know of thise errata and cod efor it, but insofar as I know this could be an issue when starting up APs.
AE16 - Use of memory aliasing with inconsistent memory type may cause system hang. It shouldn't be possible for this to happen with a modern OS. It means mapping the same physical page of memory with different memory contr
Ok, lets look at some of these.
/dev/io or memory-mapped bus space can exploit it. So e.g. something like XOrg, but not the typical user program. Worse case seems to be a system freeze. Still, this is something to be concerned about.
AI65 - Thermal interrupt does not occur if DTS reaches an invalid temperature. What the hell is an invalid temperature? A disconnected sensor or something? It doesn't sound like something a userland thermal-generating loop can exploit but the errata is not detailed enough to know for sure.
AI79 - REP/STO in specific situation may cause the processor to hang. BIOS patchable. The errata mentions an uncacheable memory store. If this is a pre-requisit then only user programs with access to
AI43 - Concurrent MP writes to non-dirty page may result in unpredictable behavior. This one is extremely serious. It effects any threaded program and possibly even programs which are no threaded. This would cause me to not purchase the cpu. It says that a BIOS workaround is possible (aka microcode update).
AI39 - Cache access request from one core hitting a modified line in the L1 cache of another core may cause unpredictable system behavior. What the hell? Are they out of their minds? This is a big-time show stopper. It says it can be fixed with the BIOS (aka microcode update). I sure hope so.
AI90 - Page access bit may be set prior to signaling a code segment limit fault. This one is pretty serious. This cannot occur on most operating systems because the code segment is set to be unlimited and access is governed solely by the page tables. In 64 bit mode emulating 32 bit operation the problem might occur if a bit of code wraps the segment. There are possibly issues in other emulation modes, such as VM86 mode. The effect of setting the page accessed bit will not make a page accessible that was not previously unaccessible, but it will result in unexpected modifications to the page table page and numerous operating systems may free such pages to the page-zerod page list under the assumption that they cleaned the page out when in fact there may be a page table entry with the access bit set (meaning the page wasn't completely zerod when freed). That could cause problems.
AI99 - Updating code page directory attributes without tlb invalidation may result in improper handling of a page fault exception. This one doesn't look too serious, it just means the wrong exception will be taken first, meaning that the OS will probably seg-fault the program. If the OS corrects the issue and retries, the correct exception will be taken on retry. All BSDs that I know of handle page fault exceptions generically and will not be effected. Of greater concern is what sort of modifications to a page directory entry now require TLB invalidations? On FreeBSD and DragonFly, and I assume most BSDs and probably Linux too, page directory entries usually transition between only two states and a TLB invalidation is made when a page directory entry is invalidated, so they wouldn't be effected by this bug.
I couldn't find an exact errata reference but it looks like a ring 0 issue to me too, which means that the OS either doesn't trigger the conditions required or the OS can work around the problem. Some such issues can be fixed in microcode, some have to be dealt with by the operating system.
There are several known TLB issues that are rather serious which all OSs have to have workarounds for. The most serious issue is that reducing the access permissions in a page table entry (such as turning off the valid bit or making the entry read-only) on one cpu can race another cpu's TLB trying to access that same entry. The race can cut an instruction into two pieces on the other cpu and (if e.g. a read-modify-write instruction) result in fireworks. All modern operating systems have to synchronize page table invalidations across all cpus that might be using the page table in question. So, e.g. in a heavily threaded environment if a page table is shared across three cpus invalidations made in that page table requires all three cpus operating systems to synchronize (usually with an IPI) to guarentee that none of them are accessing memory governed by the page table entry being changed. Kernel virtual memory is even worse, since that is shared by all cpus, which is why its better to just keep a cache of mapped memory instead of constantly mapping and unmapping pages in KVM.
There are also serious issues with global pages and mixed TLB entries when switching from small pages to large pages, issues when operating in compatibility modes, issues when using address wrapping. Most of these issues only occur with absurd code sequences, such as an instruction which wraps the address space (which will never occur in real life so can be ignored as long as the issue does not cause a failure in the security model). 90% of the errata is not an issue in a nominally running environment.
-Matt
In the old days of dialup our biggest problem were USENET pornsters just staying connected 24x7 downloading part x/y of god knows what, essentially taking an entire phone port out of service.
In anycase, I don't know why people believe that a few bucks a month guarentees them unlimited bandwidth. If you want guarentees, or you can't sleep at night, pay for commercial service.
-Matt
I've had a T1 going into my home for years, paying around $300/month for it. The T1 itself is guarenteed bandwidth but you usually do not terminate it at the phone company. Instead the T1 gets terminated at an ISP (which can be the phone company but is usually not). Well, ok, in REALITY the T1 is usually bundled into a T3 or fiber and THEN terminated at an ISP, but the bandwidth is still guarenteed up until the ISP. You don't go into a packet switch until you hit the ISPs network and it doesn't really matter until you hit the ISP's backhaul to the internet. At that point there is usually so much bandwidth that you get the full T1 rate 'to the internet'.
I have experimented with DSL, but it doesn't compare. For one thing, I serve out a lot of data... my T1's pipe is usually 100% full in the outgoing direction all the time. I can't afford to have hicups. I had a backup DSL line for a while but the outgoing bandwidth sucked rocks. For another, the T1 is considered a special business line and when something goes wrong, the phone company hops on it immediately (though I still have to talk to two entities.. the phone company and the ISP). Still, things get fixed fairly quickly compared to a normal phone line.
Is it worth $300/month for 1.5 MBits in both directions with guarenteed bandwidth and guarenteed quick service? It probably wouldn't be for your run of the mill power user, but for someone like me who is serving out an open source project and managing half a dozen domains, web sites, and mail for friends and family, I just can't afford to have too much downtime or unmanaged bandwidth.
I still have to research a possible cable solution. I haven't heard of the cable company having a guarenteed bandwidth service with that much uplink but who knows, maybe they've done it while I wasn't looking. I dunno about reliability, service, or ping times, though. I kinda like having a 4ms ping.
I wish there were fiber on my street. Maybe some day.
-Matt
Solar water heating is very inexpensive and environmentally friendly (because no solar cells are actually needed, just something to soak up the sun's heat and a heat exchanger). You generally want to get a closed system heat exchanger, with a separate fluid loop, and not actually loop the water heater's water through the solar unit.
Battery backup is *NOT* inexpensive, nor is it environmentally friendly. Only lead-acid batteries have the kind of capacity required and they need maintainance and space and have relatively short lifespans (5-10 years typically). They require a separate charging system and a transfer switch. In short... if you have a good connection to the utility, putting together a battery system is not worth the cost.
The cheapest most environmentally sensitive solar electric system are standard solar panels and a direct grid-tie inverter. Not the shingles or any of the other experimental junk... they just don't have the life span or the efficiency. Zero maintainance, very long life. This is what I have on my roof.
In terms of (almost) zeroing out your electricity bill with net-meetering... well, it is fairly inexpensive if you have a newer home with energey efficient appliances. My system is somewhat bigger then a standard home needs, 2.5KW, and I can't zero out my electricity bill because I have a machine room. Note however that no solar system can even come close to the electricity requirements of a home Air Conditioner. If you need air conditioning you will never be able to zero-out your electricity bill with a standard 'home' solar electric system.
Solar Cell Manufacturing has gotten a lot better over the years. The environmental cost for manufacturing a panel is something like 6 months now vs the 30 year+ lifespan of the panel. Direct grid-tie inverters take up very little space and require no maintainance whatsoever. Generally you want to use a high voltage inverter, where the solar panels are linked in series instead of in parallel. Such inverters are a lot less bulky then LV systems (and the wiring is a lot less bulky too because it is high-voltage and low-current instead of low-voltage and high-current). My recommendation is a Sunny Boy direct-tie inverter. Never use an inverter which requires a fan.
Some states, in particularly California, have extremely good rebate programs. The Federal tax credit is crap.
Neighbors of mine have tried the shingles, and have tried flexible solar mats on their roofs, with terrible results.
http://apollo.backplane.com/Solar/