The trouble is that what you really need to test isn't how much coverage of the code you've got, but how much coverage of the possible input space. More specifically, you ideally want to know that each distinct combination of inputs that will cause a different type of behaviour in the code has been considered.

Of course, this is typically an implausibly difficult problem to solve in real world projects. To see why, consider that this article proudly claimed that finding the special case of clearing 4 lines together twice in a row was easy with their tool, and it also said that there were similar combo special cases for 3, 2 or 1 lines, but it conveniently overlooked the possibility of code that ran in all four cases and took the number of lines as a parameter. Testing for any one of those four cases would count as coverage with most tools, but wouldn't guard against implicit conditionals like overflow/underflow that might be relevant to some cases but not others, nor for behaviours that arose only with certain combinations of multiple explicit conditions.

Coverage tools are useful up to a point, but not nearly the silver bullets that these kinds of article suggest.

Yes, silly me, using the same platform for building and testing as approximately 100% of my customers do.

Sadly, the platforms that we geeks like to use aren't particularly relevant to a discussion about software for a mainstream audience, because that mainstream audience isn't running Linux and most of it isn't running OS X either.

I'm well aware of the advantages of using VMs for creating a controlled environment. Unfortunately, that doesn't make my previous observations about licensing any less true.

I don't know what you mean by "development only licensing options" as far as Windows is concerned. There are different rules if you use Software Assurance to sort out your licensing, but that's the only exception to the one VM/one licensed copy rule as far as I'm aware. If you know better, please cite accordingly, as I'm sure plenty of us would like to hear about it.

Add IPX8 to the high specs.

I did manage to find some metrics for disease transmission. There are a variety, but the primary one is R0, the "basic reproduction number". Measles is one of the most communicable diseases, with an R0 of between 12 and 18. Ebola is one of the least communicable diseases, with an R0 between 1 and 2.

Here's a link: http://en.wikipedia.org/wiki/B...

It's Wikipdedia, but contains links to its sources, which are WHO and CDC for the measles number and an international research study published in September for Ebola. The latter suggests that if just half of the Ebola cases could be avoided, the R0 would drop below 1, causing the disease to die out. That means Ebola is so hard to transmit that it's just barely able to continue.

In contrast, Measles is so communicative that it's expected that 90% of the people who come into contact with an infected person will get it.

You're so wrong and so backwards here, it's not even funny.

Cite? I've never heard of, nor have I been able to find, any numeric rating scale for communicability, much less documentation of those two numbers for those two diseases.

Assuming the measure exists, and that those numbers are accurate, I strongly suspect that the scale measures difficulty of transmission, and that lower numbers indicate more communicable diseases. Measles is spread via aerosol transmission, Ebola is not.

Unfortunately, in this case that '????' is something like "develop several years' worth of cross-compilation infrastructure so you can build on your guest OS but run on the host".

Maybe, but unless you condone software piracy, that would require either buying a second Windows licence (unless you have one of the SA schemes that covers using Windows as both host and guest OS) or running something like Linux as your guest OS and figuring out the cross-compilation issues (if that's possible).

With today's software and licensing landscape, I just don't think setting up a custom VM for every project you work on is viable, nor that imposing burdens on that kind of level is the way to encourage skilled but casual/irregular contributors to help your project.

Unfortunately, like too many OSS projects, Mozilla seems to think it will have the only cygwin instance on my system. It therefore assumes it's OK for me to just reconfigure the entire universe according to its preferences, redefine all my paths so the MozillaBuild version of everything takes precedence over anything else that's already installed, and so on.

In reality, I have various other tools installed that bridge the Windows and Linux worlds, including things fundamental to using various version control systems and other everyday needs. As much as I'd like to support Mozilla and be willing to contribute a bit here and there, I'm not going to compromise the development machine I also use to earn my pay cheque just to get their esoteric build system to work.

File it under "stuff that matters".

A lot of arguments for open source are based on things which people outside the project could in principle accomplish, but in practice seldom do. So it's reassuring at least that an experienced developer can build the two most popular browsers from scratch. It means the arguments aren't hollow. I've seen closed source projects that were purchased by companies, only to find out that getting them to build on any computer but the one it was developed on is a serious engineering challenge.

That the process of building these browsers from scratch is somewhat arcane will come as no surprise to any experienced developer. But that it's not so arcane that it's impractical to figure out is good news.

C:\Users\ABG>cd /usr/ports/www/firefox && make install clean
The system cannot find the path specified.

I guess those of us using Windows still aren't going to be contributing much any time soon. :-(

If you think there is no functional distinction between a muzzle loading smooth bore musket and a modern automatic rifle, you are the delusional one.

And the silly pro assault rifle camp assertion that the term was invented by the gun control side it also laughable. The term has been around since WWII as a translation of the German Sturmgewehr (lit. "storm rifle", where "storm" meant "assault" not lots of rain).

Is it unreasonable for the average height of a population to grow by 7" in twenty generations? I should think so. But if you changed your initial conditions somewhat, maybe less unreasonable.

There are roughly 400 genes known to influence height. Imagine we have a small, isolated population that does not interbreed with other populations -- say on an isolated island. This population's average male height is, say 175 cm for men -- roughly the same as the average American. However the population contains all the alleles neede to generate individuals approacing 7' in height. We then take our population and put them under evolutionary pressure; let's say we shoot everyone who reaches the age of 16 and is below average height. It wouldn't many generations for that population's average height to become quite tall, as "tall genes" begin to predominate.

Let's change that initial condition by stipulating that there are no "tall genes" in the initial population. It's still average height, but maybe it lacks both "tall genes" and "short genes". It would be surprising if the genetic height potential for a newborn changed very quickly, because you've got to wait for a lot of "lucky" mutations and twenty generations is not that long.

Let's go back to our successful initial conditions and change something else. This time the population has all the necessary alleles to produce super-tall people, but it interbreeds extensively with a large external population which is not subject to our culling protocol. Under these conditions the population's height increase will be slow, or non-existent depending on the rate at which individuals interbreed with populations not under pressure.

The bottom line: it depends.

Bennett has been posting these long ramblings since a very long time before Dice bought Slashdot. Unfortunately, I think that your complaints are not likely to be heard because Slashdot seems to have had a policy for a long time of not recruiting editors from people who regularly read the site...

You might want to read some news from the last decade. Microsoft started paying dividends in 2003 and has paid them annually. When they started, investors were unhappy because it showed that they no longer thought that the best thing to do to increase value was to invest the money in the company.