I would think so at least for drive-managed devices as writing to a virtual sector doesn't neccesarily write to that physical sector, seek and read times could be inconsistent throwing the RAID read and write algorithms into dismay. With host-aware or host controlled drives, you could probably tune for better performance matching logs in the FS and stripes on the RAID to fit evenly into the shingles tracks.

And haskell is about 10/10, being able to expressively type functions, and make custom types. Point being some may find 7/10 good enought to catch stupid errors, while letting the code be a bit terser and more readable. I'm not sure the tradeoff is at the couple hundred lines territory, as there are often ways to add in additional type restriction in dynamicly typed languages, and you may just want to start with a quick and dirty prototype as a template for the final version.

But because it is web of trust, names are neccesarily global. I think easier to tweak a blockchain than to get a lot of people to use web or trust properly.

The upfront cost of LED is greater. At zero hourse the cost of ownership is just the bulb price. The question is how long to you have to go into ownership before You make back the extra money you spent up from on the LED vs the CFL. Ya, and LED's are just getting better and better so it won't too long before they beat or match CFL's up front.

Distributed Hash Tables.

The GNU Name System, nameCoin..

Sorry wrong math, Half the hours I quoted. (* 50000 (/ delta-bulb-cost) (delta-electric-cost))

LED vs incandecent yes, LED vs other energy-savign options, not so much. http://irea.coop/userfiles/LED... Using those figures it take 20,000 hrs for the 45@ equivalent and 40,000 hrs to make the return on the 75W equivalent (The pdf has and error for LED bulb expanse for 75W, should be 25 dollars instead of 6.5)

Maybe the wires and towers and stuff, but a big chunk of the retail cost of electricity goes towards the capital and maintainance costs of the generation facilities, which solar alone doesn't decrease the need for. And as you add more decralized and sparadic generation the difficulty of managing the grid increases.

Indeed a closer match of prices and better information would go a long ways to sensible energy developement.

No battery in the world is free. It's hard to ones that cost per kWHr stored and released is less than the grid price of electic. Secondly the peak production or solar peaks before peak demand of electricity (solar noon, vs 3-6 pm in summer, 5-7 in winter) so it's not that usefull to the grid operator, it actually makes his life more commplicated becasue they need fast-start (which are much less effection than continous-run) generation capacity in case of a stray cloud formation, or an eclipse. You may also be being paid for helping the power comany meet renewable enegy mandates though. If some of the base fees were replaces by accumlated peak daily load fees then solar+battery backup could some out ahead. Mix in carbon credits or renewable mandates and you have a good incentive to people to adapt decentralized production

If you generate the power with your own cells and use it there it's the same result as net metering, you made 4kw/Hrs and your electric bell is 4kw/Hrs less than it would have been. The problem is peak solar doesn't tend to meet peak demand, if you were looking at wholesale rate it makes more sense to point fixed direction panels West-Southwest to counter the huge AC loads during the summer time.

If decentralized generation is going to work, what we deperately need is the intrastructure and market to let the decentralized nodes to make meaningful decision about power use. Say start charging home based on accrued based demand, usage, credit for production defering of demand, and load balancing capabilites. A system that can predict usage and tack intellegent action. (Tommorow's going to be really cold, so this house will take X power to heat, and the solar will make A power over Y time, and the local wind farm isn't going to prouce much tommorow so wholesale prices are projected to be fairly high, it's pretty cheap right now so lets fill up the battery bank) (Later that evening... prices aren't going down, let's poll the nieghbors to see if we can justify spinning up block's combined heat-power unit.) (Get ready to start the laundry? you can see the projected cost for that load ... $3? , mabye it can wiat untill tommorow. ) A prototocol to push relevan information to the endpoints where decicions can be more effectively made is needed, that and R+D into devices that can do dectralized power/heat, hydrogen... etc, production, and A legal framework which makes it legal to transfer/share powere over property lines without it going through the local grid monopoly.

For now pick two: cheap, robust, distributed

It would be a really horrible binary format if there wasn't an included newline equivalent.
http://www.freedesktop.org/wik...

Because the format is designed to be mostly append-only you should be able to skip over most corruption in the reader, and the writer should rotate the log file if any corruption is found. Additionally there is a mechanism that lets you know with high certainty weather a section of the file has been corrupted since it was tagged. "Tag objects are used to seal off the journal for alteration. In regular intervals a tag object is appended to the file. The tag object consists of a SHA-256 HMAC tag that is calculated from the objects stored in the file since the last tag was written, or from the beginning if no tag was written yet"

Somebody being the prior maintainers who purposely marked the project as depreciated. Apearently there is a fork called ConsoleKit2, but I'm not confident in it's long-term longevity.

Systemd via journald can actually capture more log info than systemV init, and can gaurantee the authenticity of certain parts of the data, and can pass it to a traditional loggin deamon if you need it to. Systemd is made from modular components, only a small number are required. All systemd configuration files are plain text and configuration is declarative in style (getting rid of a lot of the complexity in prodecural systemV scripts). So far you actually haven't listed a requirement where systemd fails or can pass with trivial modification to the system.

Systemd actually brings back a old favorite feature of Unix. multiseat computing, you can have a single high-end computer drive 2-4 seats instead of a low-end driving a single seat, saving money and reducing wastes at the intitutional level.