Password: hedgehog, no doubt.

Would you like your food data shared with your insurance company? How about your weight? Your BMI went above 22 this month. Not good, lower it or else. Your running? You didn't meet your jogging goals for the week. That's it, we're raising your health care premiums. That's a lot of beer you're drinking, and you put a lot of miles on your car, so it looks like we'll have to cancel your auto policy because statistically you're likely a drunk driver.

If you say "OK, share my data", it can go a lot of places you may not intend.

Except he did not stop there. That's the problem. Allow me to re-state his original premise.

For a currency "X" there exists an amount "Y" at which (or below) no one will sell accurate bug reports to you.

When X = "pennies" and Y = "2" you can see how it works. Would you spend your time looking for bugs and reporting them for a possible payout of two cents per report? So at that point I can agree with him.

BUT THEN HE TRIES FOR A FALSE COROLLARY.

For a currency "X" there exists an amount "Z" at which (or above) people will sell accurate bug reports to you.

He uses X = "dollars" and Z = "10 million" there.

The reason it is a false corollary is that it depends upon a bug's existence being based upon the amount offered to find it.

All of the people talking as if I had said there were "literally infinite" bugs in a product are missing the point.

No. They understand and they are explaining to YOU where YOU are wrong.

I said, very clearly, that of course the number of bugs is not literally infinite, but I was considering the case where there are so many bugs which can be found for $X worth of effort, that it's unrealistic to find and fix them all in the time frame before the product becomes obsolete anyway.

And that is where you are wrong. YOU are claiming that a very specific HYPOTHETICAL situation is same as the general ACTUAL situation.

Your HYPOTHETICAL situation is 100% divorced from the ACTUAL situation.

In the ACTUAL situation there are a finite number of buffer overflow bugs in any specific program and those buffer overflow bugs can be found and fixed WITHOUT another buffer overflow bug appearing. And it is EASY to find the MAXIMUM number of buffer overflow bugs by searching the source code for every instance of a buffer being used.

Finite AND countable AND fixable.

The fact that there are dozens of people responding as if I had said "literally infinitely many bugs" does not make their point any more valid.

No. They are pointing out that YOU have made that assumption even though YOU keep denying it.

Because once you admit that the number of buffer overflow bugs is finite AND countable then there exists a point where they can ALL be fixed. And you keep denying that that is possible.

Well, theoretically yes.

"Theoretically". Got it.

But do you think that Apache could ever reach a state in practice, in the world we actually live in, where you couldn't find a new vulnerability in it for $10 million worth of effort?

Emphasis added.

So now you're conflating a real-world situation with a hypothetical situation ... no. You do not get to mix real-world and hypotheticals in the same sentence. No one is offering $10 million and no one is likely to offer $10 million.

IF someone would offer $10 million for buffer overflow bugs in Apache then a lot of people would comb through the code and check each instance of a buffer for an overflow bug. All the buffer overflow bugs would be found.

After that, finding ANOTHER buffer overflow bug would not be possible IN THAT CODE BASE. No matter how much money was offered. Because all the instances should have been checked and identified.

Someone would have to submit code that included a NEW buffer overflow bug in order for a NEW buffer overflow bug to be discovered.

No matter how much money was being offered. No "theoretically" about it. It's Computer SCIENCE.

Do you really believe that if you offered a $10 million prize to anyone who could find a vulnerability in the Apache web server, that you would reach the point where people weren't finding and reporting new ones...

From your inclusion of "really believe" I'd say that your question was rhetorical.

And wrong.

At $10 million per buffer overflow? Yes. There would be a finite number of buffer overflows that would be found and fixed.

At $10 million per X category of bug? Yes. There would be a finite number X's that would be found and fixed.

Therefore, unless you assume an infinite number of categories of bugs, all the bugs would eventually be fixed.

Because the code base comprises a finite number of bits and there is a finite number of ways that those bits can be run.

My point is that if there are (effectively) infinitely many bugs...

No need to read any further because that is an incorrect assumption.

There cannot be an infinite number of bugs (effectively or otherwise) because there is not an infinite about of code NOR an infinite number of ways to run the finite amount of code.

From TFA:

(He confirmed to me afterwards that in his estimation, once the manufacturer had fixed that vulnerability, he figured his same team could have found another one with the same amount of effort.)

Then he was wrong as well.

There are a finite number of times that buffers are used in that code base. Therefore there are a finite number of times that buffers could be overflowed. If someone went through the code and checked each instance and ensured that an overflow situation was not possible then it would not be possible.

"Infinite" does not mean what you think it does.

Is there a statement in the article that you think is incorrect?

You missed the point of the post that you are replying to. But since you asked ...

You can visualize it even more starkly this way: A stranger approaches a company like Microsoft holding two envelopes, one containing $1,000 cash, and the other containing an IE security vulnerability which hasn't yet been discovered in the wild, and asks Microsoft to pick one envelope.

That makes no sense. Why would a security-researcher offer to pay MICROSOFT for NOTHING?

Microsoft should be paying the security-researcher.

It would sound short-sighted and irresponsible for Microsoft to pick the envelope containing the cash â" but when Microsoft declines to offer a $1,000 cash prize for vulnerabilities, it's exactly like choosing the envelope with the $1,000.

Wrong again.

Not PAYING $1,000 is NOT the same as getting an ADDITIONAL $1,000.

If I have $1,000 and I do not buy something for $1,000 I still have $1,000. But if someone gives me an envelope with $1,000 then I have TWO THOUSAND DOLLARS.

You might argue that it's "not exactly the same" because Microsoft's hypothetical $1,000 prize program would be on offer for bugs which haven't been found yet, but I'd argue that's a distinction without a difference.

No. It's wrong because in your example Microsoft ends up with an ADDITIONAL $1,000 from a security-researcher.

A lot of the animosity towards Monsanto comes from their overall behavior. Creating the terminator gene is first to mind. Next are the numerous allegations about misconduct: complaints that they do inadequate studies, they hire certain researchers expecting certain study outcomes, that they tamper with study results, and that they have bribed government officials. However, most of those reports come from the wacko anti-GMO crowd (who are really a bunch of anti-anything idiots), so it's hard to know if there's a shred of truth to any of the complaints.

The biggest gripe I have is their drive to produce pest- and herbicide-resistant crops. Every one of these is putting other farmers' crops at risk, because they're creating pesticide-resistant super-bugs and herbicide-resistant super-weeds. Those bugs and weeds don't limit themselves to Monsanto-seeded fields, they're natural organisms that spread, and those bugs are now attacking non-Monsanto crops, and the weeds are infesting non-Monsanto fields. Monsanto knew this was going to happen from the start of the program, they estimated it would take about 20 years for it to happen (it actually took less than 10 for the corn rootworm to evolve Bt resistance), yet they went ahead and did it anyway.

Had they focused their modifications only on creating high yield and high nutrition crops, instead of trying to fight the resistance battle, their overall agricultural activities would have been a lot more responsible.

but vikings are more ancient than this.

however, if this is what they used their copper for it might explain why they(northern tribes) had to start using reindeer parts for everything.

in britain you can still keep it(the war on drugs). there's plenty of other substances to keep fighting against.

besides, situation with mj in britain is that if you get caught with a joint/small bag pretty much nothing happens(compared to some other countries where they will raid your property..).

anyhow, it would be pretty easy to entrap these guys, to extract money from them. setup the lights and cameras, wait with your crew and boom, they pay or go to prison for extortion.

LED lamps do not put out nearly as much heat as High Pressure Sodium (HPS) lamps. I have a (disconnected) 400W HPS that I could easily have cooked on the top of the reflector, and probably broiled meat directly beneath it. I replaced it with a 144W LED floodlamp, and now I can hold the operating heat sink in my hand; the glass lens pane on the bottom is at room temperature. I am no longer concerned about fire safety in my house.

One major difference, though, is I'm growing orchids, which require far less light than cannabis. I need only two 144W LED floodlamps to illuminate a 72 square foot area. The pot growers will cram as many 400 W lamps in a grow operation as they can, sometimes a dozen or more in a single small room, whatever they can draw from the circuit breaker panel. They'll keep a large external vent fan running year round, including the dead of winter, to keep the room from igniting.

If I were to grow pot, I'm sure I'd need a lot more light fixtures, but even a dozen LED lamps in the same room probably wouldn't risk burning my house down.

Oracle consultants were in the midst of the mess, they saw the failings, they repeatedly reported to the state that the project was going off the rails, and yet they still managed to cash their paychecks.

Had the consultants actually threatened them with "either you hire a professional to do the systems integration or we're off the job," and had they then removed themselves from the failing project, they'd be 100% blameless. But they didn't walk away, they just wrote some CYA memos and collected their money.

Oracle gets to take as much blame as anyone for their mess.

That would be fine if it were true, and if it were the end of it. But it's not. The enablers take over. If the bad ideas aren't stopped early by facts, their owners proceed down whatever path they've concocted, and the further they get without objection the more convinced they are that it's the correct path. An enabler will not tell them they're on the wrong path; or they'll say it once, but never correct them again for fear of losing their job (only a blocker says "you're still on the wrong path".) Without honest feedback about the mistakes being made, you can go a long way before realizing that you've led yourself astray.

One big problem is the belief that all problems can be stopped by governance processes. Therefore, all these processes are designed to be a form of change prevention. The idea is that by preventing incorrect changes, you avoid risk. But a process cannot distinguish between an incorrect change and a valuable change until after it has executed, so it must slow them all down equally. A process also handles the unknown poorly - it is designed to handle only certain changes, and everything else is awkward or not streamlined.

Change approval processes also encourage lies. When someone has to get a change through a process, they will tick whichever checkboxes will get them through the process with the least amount of effort, struggle, or paperwork; they will not voluntarily tick the box that ensures a microscopic review of their change, even when it may be appropriate.

Worse than all of the above, governance processes are hugely inefficient in that they're after the fact: create a large pile of changes, try to deploy it, then wait around days, or weeks to learn only then that the changes aren't approved. The feedback from governance is so late that the developer has long moved on to other tasks. Stakeholders get their changes in months instead of minutes.

Another sign the process is off the rails is if the disapproval is issued due to failure to follow the process, not with problems in the task being attempted. Too many failing processes leads further around the vicious cycle of process 'improvement', that then creates a process to follow the process, inserting delays into the delays. (Yo, dawg, I heard you like process, so I put process in your process...)

If you ever want to read a story about how bad process can get in the real world, read Red Plenty by Francis Spufford. He tells an interesting tale of just how far the Soviet Union's bureaucracy went, including goofiness such as one process that valued a machine by weight. The more modern machine that doubled production weighed less than the older machine it replaced, therefore the older machine was more valuable, and the budget rules that ensured progress did not permit replacing a more expensive machine with a cheaper machine.

Instead of after-the fact governance process, strive for continual, automated testing, starting with Test Driven Development. Have a repeatable method for delivering products that have quality built in from their very design. Once you've established the trust, you can minimize the processes. Something else valuable is a fail-forward philosophy: if you acknowledge that bugs will happen no matter what ("Failure is always an option"), you can often survive by putting in place the ability to recover from defects within minutes by being able to push out new patches. So instead of trying to avoid all risk by using a big process, you can get away with minimal process by accepting a little risk. This is a great approach because everything moves fast, especially the delivery of benefits.

I'm guessing you're heterosexual then?