It's actually fairly common for construction projects to run into changes. While nobody requests to turn a shed into a skyscraper, large changes that touch many disciplines occur quite regularly.

The difference between AEC and programming projects is a long history and legal framework that deals with these changes. Projects are given a budget, and that budget is often paid out at milestones--design development, 95%, construction documents, etc. If the owner requests a substantial change, or if a change is required because of unknowable circumstances, the budget is either revised or the work is value-engineered to fit--and this reality is reflected in the contract signed at the beginning.

The problem with programming projects is that there are not very many really good programmers, and programming is not suited to throwing more warm bodies at the problem. AEC is plate spinning, while programming is juggling. You can hire a bunch of folks to help keep the plates spinning, but you can't just send in somebody to help juggle.

If you don't like the 2nd Amendment, perhaps we can interest you in gutting the 1st Amendment?

Come come, now, we can all agree that those evil GUNS and evil VIDEO GAMES are ultimately culpable. Let's all come together and blame things that we don't like.

'Merica.

Auto-documentation is good stuff nowadays. Everything changes so much, and so quickly, that enforced documentation standards lead to better understanding of the underlying API or intent.

(As an example, why is PHP so popular? It's not because it's beautiful, or elegant. It is, however, very accessible, largely due to good documentation.)

Good comments--that are not prescriptive for whatever autodoc tool you use--are invaluable, but bad or marginal ones do more harm than good, especially in interpreted languages. You can condense 4 lines of comments into a 22-character, well-constructed function call/local variable and accomplish the same goal.

That's 75x and 30x respectively - not 7.5 and 3. Your decimal point is off there.

Was about to make a witty reply till i realized i stopped readin slashdot round about the time i got married.

Umm, i am wearing one right now. Sleeping in it just would not occur to me. Plus you have to take it off to charge it. So as a privacy thing, well the only reason it would get you in trouble would be wearing it during sex so you could get the fuel points. Not a security issue that worries me at all. Now the implants.. They might be an issue.

I might be in the minority, but I've learned to love the challenge of taming a beast of a code base.

Coming in and helping out people who don't have *anything* in place and slowly adding order has a satisfaction level all of its own.

Building out a test suite as we document business logic and then planning a refactoring can be rewarding too!

This is the answer, more or less. For small-to-middling forums, reducing spam is pretty easy. A few volunteers to delete the ones that get through suffices for the rest.

It breaks down to 1) keep out easy drive-by spammers, which means registration with a valid email address and some kind of barrier to detour the smarter bots (ReCaptcha and the like); 2) filter posts through Akismet or similar method; 3) have a community large enough and engaged enough to want to zero out spam posts.

The third step is the hardest, and has nothing to do with spam posts.

Try the Guardian Weekly - 3 bucks a copy and about 95% news. Real News.

It's a wonderful technological breakthrough that will thrill about two dozen people. This is a great story for 2003.

Bingo. Heck, with Chrome autofill, it took less time to register and sign than it did to type out this reply.

That is not an approved disposal scheme in the US DoD. Explosives can and do leave pieces large enough to recover information from.

Neither CRLs nor OCSP are intended to mitigate a CA private key breach.

The only control in the system is to revoke the CA root and that can be effected on Windows by issuing a new CTL (as happened to revoke the Diginotar root) that drops the compromised root. The other browsers have similar mechanisms.

The war could well be over by the time DNSSEC is deployed. The Iranian group have developed new attacks and dramatically escalated the sophistication of their attacks. The time between attacks has been weeks, not years. There is simply no prospect of large scale DNSSEC deployment in the next 6 months. the Iranian 'elections' are in March. I can't even see any possibility of deployment ahead of the next presidential election.

Working on both of those.

Not without sounding really whinny.

At this point its water under the bridge, I have changed my mind on what the approach to security should be and so has the industry.

The browser that an Iranian dissident should be using is probably not the same as the one your granny uses to shop online for sex toys. There are security concerns in both cases but the risks and issues are totally incommensurate.

Let me explain. I have been working on Web security now for 19 years. I was present at the original meetings at which the SSL system was proposed, I convened several of the relevant meetings.

At no time was government wiretap a design consideration for SSL. NEVER. In fact to claim this was totally ridiculous since at the time we were fighting a running battle with the FBI and the NSA who were trying to stop us using strong cryptography at all. The original SSL design was limited to 40 bits and was very clearly crackable.

SSL is not designed to be wiretap proof, my proposal and the EIT proposal were stronger in that regard. But at the time the criteria was whether shopping online could be made as safe as shopping in a store. That was the design criteria by which SSL was judged and the design criteria it passed (after they eventually hired some competent crypto people). I was the person who stated the design criteria at the meeting.

Most check CRLS and OCSP.

The problem is what they do when they can't reach that data. All the browsers out there now simply fail silently and go to the site anyway.

For some reason this is seen as a problem with CAs and not the broken browsers. But from the browser providers perspective 99% of their customers are really interested in getting to sites reliably and without fuss and less than 1% are dissidents whose lives might be threatened.

This is not the fault of the guy who writes the code. They only own one small piece of the browser and do not get to make the 'commercial' decisions.

Expecting this to be any different with a DNSSEC scheme is to engage in mystical thinking of a naive variety.