Clearing the underbrush can *reduce* the amount of CO2 to be produced. Pull and chip that brush, don't burn it. Use the chips as ground cover to better protect seeds and hold water, both which promote good tree growth. Chips can be used in playgrounds instead of sand or dirt, particular chips from softwood brush. When my father was in the forest service, they cleared out brush "by hand"; the only time they lit any fires was when they needed to set a backfile to halt or steer a moving path of flame.

I suggest you increase your range of research. Specifically, find the study for the Tahoe Basin showing how the suppression of forest fires has increased the fuel load in the forests of the basin for the past 30 years. More fuel means hotter fires. Also, add "fire ecology" to your search parameters. In this one respect, man *has* affected the ecology, by suppressing limited fires that eat up the excess fuel that can lead to large crown fires and "firenados."

And where do you get your information? A wildfire may not be burning above-ground, but the fire can continue underneath the topsoil. Forest fires are not considered "out" until they have been thoroughly soaked with water over a period of months. In the Sierras, that's after the first big snowstorm of the season. Snow captures the heat and melts, and the resulting water will go into the root tunnels and snuff what's left of the fire. And the loss of coverage *can* affect climate, but only in a local area and not on a continent, let alone the planet. But that doesn't affect your premis: a single fire does not "climate" cause.

It's most annoying, and couter-productive, to audit code when the lack of formatting gets in the way. The first thing I do when I get a piece of messy code is run it through a beautifer first. In one case, that one action made the bug shine like the sun on a clear day. Who audits using diffs? The audit needs to cover ALL the code.

You've looked at the "code changes"? I did, and found many of the alleged changes to be reformatting, to make the code easier to audit. Some of the changes are to pull out portability cruft on long-dead platforms. But you go ahead and view OpenSSL as dead to you -- that's your choice. As for "untested code changes", are you sure? This appears to be part of a process, not a rush to release.

Mr. Anonymous Coward:

What changes are you referring to? The changes I see are good re-factoring: clean up formatting, remove dead code, add missing bounds checks

Are you volunteering to do the code audit?

Massive rush? Evidence, please.

Security testing clearly hasn't been done before? Evidence, please. The counter-evidence is that the security testing tools were found not to work in this one particular case, and that problem has been patched. Security testing costs money; how much have you donated to the project?

Heartbleed exposes a problem, it doesn't invalidate the concept of Open Source. For one example that made world-wide news, there are hundreds of examples of open-source "wins" that never rose about the journalistic "noice" because it worked properly, and didn't make any waves. The mainstream says "who do we blame, who can we sue?"

And how do you manage projects, particularly open-source projects? Does early disclosure bother me? Yes, as the admin of a group of servers. Would I be comfortable if this were done behind a wall? No. We need all the eyes we can get looking at the problem. And you need to be more explicit: are the bugs that you are complaining about being exposed exploitable in some bad way? Examples, please.

SUMMARY: It's bad, but not as bad as you make it out to be.

1. clean up
2. tighten up
3. inspect
4. test
5. field test

In a clean-up operation, you don't vet each change, especially when the change is reformatting instead of a real code change. It's clear from the commits I've looked at that the people doing this are working to eliminate the cruft that inevitability builds up in any project as it matures. See http://en.wikipedia.org/wiki/C... -- you take baby steps, and check your work as you go.

In the process of clean-up, of re-factoring, one may find and fix subtle bugs, such as the missing bounds check that is at the heart of, um, heartbleed. Elimination of the custom memory management in favor of the native OS code (particularly when the OS takes pains to clear out free memory -- which would have stopped heartbleed cold on some platforms) decreases the complexity of the code, and -- arguably -- makes it easier to read. Replacing clumsy code with better-crafted code that does the same thing but far more clearly makes it easier to read. Removing out-dated portability hacks removes a lot of chaff so the wheat is easier to see. But you can't do this all in one commit and expect not to stub your toe.

Repeat as necessary

When the clean-up tighten-up passes are complete, and the cruft is mostly gone, the developers then need to comb through the code looking for issues missed in the first pass, and brokenness caused by unfortunate re-factoring. It happens. Also, error patterns will pop up when the code is reformatted to a single standards. Further, because people are looking not just at syntactic content at this point, but semantic content, comments can be added to document any awkward or un-obvious constructs.

An integral part of examining the code is the development of test cases for the scaffolded version of the code. This needs to check for conformance to the RFC, and also explore what happens with intentionally malformed packets. This is the crucial step which appears to have been missing or incomplete with the pre-heartbleed OpenSSL code. Code inspection will catch stuff; test cases will expose those problems that were missed during the inspection. This process assumes that the program is structured in such a way that scaffolding is possible from a library of the code base, so each function, or small set of functions, can be tested in isolation. I find, in my own work, that I typically write several thousand lines of code during development to ensure that each major function works as expected -- and that code lives on as scaffolded test code so that when I make a change I can test it against a known set of test cases. (Sometimes, you have to change the test , or add tests, because the function changes or a bug sneaks through, but then you have a check-and-balance to minimize issues.)

You ask "Who is watching the watchers?" The answer is an easy one: as usually happens, management will work to solve yesterday's problems. I fully expect, when the work is finished, that the security researchers will pounce on the "new and improved OpenSSL" to find the bugs and holes that didn't get fixed during the current round. They struck gold once -- and like most gold bugs, they will mine the same hill until they go broke, just like the 49ers did.

One interesting effect is that Coverity [coverity.com] made improvements in their code-scanning product. (See comments above this one.) The net effect is that all the products scanned by Coverity products will benefit. Which further answers your question: we now have improved computer watchers, too.

For the times I want to watch live sports, I go where there is no cost to watch: a sports bar. Living where I do, another possibility is the sports book. The only disadvantge is I have to share the bathroom, and the drinks cost more. I've been off cable for more than ten years. Really haven't missed it.

Another benefit: we can see the sequel, Office Space 2, and see how Initech inflates the work needed to solve the spoofed-source problem. Will it end in another fire? Will Milton come back?

You need to look up how laser-pumped headlights work. The light isn't coherent outside of the bulb assembly. The laser fires into a phosper, which then generates the wide-spectrum illumination. So the FBI wouldn't be interested, although I would watch using high-beams on a hill.

Oh, wait, this is slashdot. Where facts get in the way of a good joke...

But they can file bugs with CentOS, which can then be upstreamed to the original authors so the bug gets taken care of. Yes, there is no formal support from the CentOS team, but I've been quite happy with the community support I've received the few times I've run into trouble.

My main use of CentOS has been for my mail server. It's still running CentOS 4; I'm working to build a new server with CentOS 6 when I have some spare cycles. That will upgrade both the OS and the hardware, the hardware getting a little long in the tooth.

Does it? Really? I don't think so. It isn't "government regulaton" that is driving my desire to replace incandescent light bulbs with LEDs -- it's the long-term cost savings and the elimination of bulb-changing hassles. I shun CFLs because they represent a hazard to the environment I live in, so out they go. My shift is driven by market forces, not by rules enforced with the working end of a gun.

What the new proposed law does, as I see it, is slow down the rate of rule-making to something approaching sanity. The new rules and regulations are coming so fast and furiously that keeping up with them is a full-time job in and of itself.

SCIENCE is all about showing your work, and having others verify that the work is accurate. When the raw data is labelled "proprietary" or the analysis methods "trade secrets", yet the summary of that data/analysis is presented as justification to force changes on people, that's not a good use of science. Indeed, it's bad government.

To add to the problem of climate "science", there is quite a bit of elitism applied to the judgements of articles -- if you aren't a member of the "club" you are not allowed to play. This has led to some very interesting criticism of contrary work on non-scientific grounds. That's what feeds my skepticism of the "crisis". When a non-environmentalist criticism of the models used to "measure climate change" (remember when the mantra was "measure global warming"?) leads to a knee-jerk "he doesn't know what he's talking about," I cringe.

I personally witnessed what open, transparent science can do. The clean-up of Lake Michigan was based on transparent science, and carefully-considered enforcement against those who polluted the waters. No esoteric regulations, just prove-beyond-a-reasonable-doubt science. Effective.

If you think things should change, find a way -- other than regulation or other use of violence -- to move people to less harmful activities. Make it part of their self-interest to do so. You don't need government to make a difference.

I used to write articles for magazines as a full-time job. When I first started using the outliner MORE, I found that the task of writing became much, much easier: I would outline the article, then fill in text for each outline item. When I was finished, I would then export the text and there was my article. It let me design the articles top-down, just as a EE designs a circuit top-down. Moreover, as the article would develop, I could shift things around very easily without having to do massive cut-and-paste exercises.

Software design? I do that top-down mostly. I design the top level with functions, then fill in the functions. Lather, rinse, repeat as many times as you need to. The result is a piece of software that is highly maintainable.

One of my biggest complaints about "graphical" programming is that you can't have much on the display -- you end up paging *more* than with a text-based system. It isn't the text that's the problem; its the lack of top-down designing on the part of the human.

Now, one system that I absolutely loved working with had an IDE (text-based) where you deal in layers. When you click on the function name, the function itself comes up in different windows. I found that paradigm encouraged small, tight functions. Furthermore, the underlying "compiler" would in-line functions that were defined only once automatically. (You could request a function be in-lined in all cases, like in C, if you needed speed over code size.)

http://en.wikipedia.org/wiki/R... Look up "M" in the table. In the dim dark past, probably before you were born, printers were using "M" to mean "thousand". And I too have been on Slashdot for a fair amount of time, for what it's worth.

The patent: http://www.google.com/patents/US7986426

Another view: http://stop-project-paperless.com/wp-content/uploads/2012/04/Patent-US7986426.pdf

Analysis of the patent: http://www.patentbuddy.com/Patent/7986426

The dispute of the patent: http://www.ricoh-usa.com/news/news_release.aspx?prid=1052&alnv=pr

Dispute filing: http://www.sutherland.com/portalresource/Ricoh_institution_decision.pdf

Possible prior art:

http://en.wikipedia.org/wiki/Xerox_DocuShare

http://bitsavers.trailing-edge.com/pdf/xerox/xns/XNSG058504_XNS_Introduction.pdf (1985)