Actually, I'd prefer to use the famous Black Swan approach: Suppose someone were to claim "There are no white swans." I can disprove this negative quite easily. I just check in a few nearby ponds and rivers, and the first swan I find will almost certainly be white. They're not all that common hereabouts, but I know a few places where I'm likely to find one or more. I will have then disproved the negative claim.

And I will have also incidentally disproved your negative statement that "[Y]ou can't disprove a negative." ;-)

This does remind me of the old observation that "All generalizations are false."

I've seen this described by economists: In the early 1900s, there was a huge increase in the "productivity" of horses on farms. This was, of course, due to the introduction of machinery. The farms' output per horse thus increased. But it didn't benefit the horses much.

Now it's a century later, and we've had a huge increase in factory productivity, as measured in output per worker. This is not much benefitting the workers. And we'll likely suffer the same fate as the horses.

For the past couple decades, much of the work has been done by humans, but they've mostly been the humans in the poorest parts of the world, where people are willing to work for starvation wages. This probably won't last long, as the production methods become better and more fully mechanized, and it becomes pointless to use humans at all in manufacturing processes. But productivity per worker will be at an all-time high.

Nah; we don't blame you. It's the folks running your government that want it. They see a good chance of raking off a few hundred million $$ in the process (what's that in yuan or córdobas?), into their secret bank accounts in other countries. But they don't expect you to see any of the benefits, which will mostly go to the officers and stockholders of the shipping corporations. You will see the destruction and pollution of the construction, though.

Well, you don't seem to have read my post very closely. ;-) I clearly stated " All the (publicly released) evidence seems to support the conjecture ...". I don't know how you could misread this so badly.

Actually, a better fruit than oranges would be bananas, at least here in the US, where sales figures say that the banana is by a good margin the most-sold fruit. If one were to visit hundreds of American homes and sneakily look around for visible fruit, there's a good chance that all you'd see is bananas. It would thus be reasonable to make the conjecture that Americans seem to eat no fruit other than bananas, and to ask if anyone has evidence to that other fruit are actually eaten by Americans.

This is pure silliness, of course. Our kitchen counter currently shows a mango and a zucchini sitting there in plain view. But maybe we're outliers in this regard, openly and brazenly displaying non-banana fruits so that any visitor can see them. In political circles, this could easily get us labelled as radical extremists. I suspect that there are millions of other non-banana, alternative-fruit-eating citizens of this country, but I can't prove this. (And there is also a bunch of 5 bananas sitting on a counter in the dining room.)

So where might I find the evidence that government secrecy has been used for something other than coverups of official wrongdoing? I notice that nobody seems to have replied with pointers to such information. I suspect that secrecy might sometimes have actually been to our advantage, but I can't point to anything to support such a suspicion. All I can find is arguments that it is beneficial, without supporting evidence.

(See also the Black Swan metaphor for more on the general problem.)

Of course, but putting it that way wouldn't be as funny. ;-)

Actually, in one of my recent jobs, I spent a day or so going through an app's use of malloc(), which was used a lot to save data structures for a short time, then free() them. I replaced these calls with calls to a pair of routines that "freed" a chunk by putting it on a list of similar-sized chunks, to be re-used later. The result was a program that was maybe 5% bigger in most runs, but ran between 4 a 5 times faster. This reduced the task from typically a day or so down to a few hours. The client was very happy with the result. Sometimes it's worth paying a (competent ;-) programmer to do things like this. And sometimes it' not worth it.

(Yes, the program had been spending up to 80% of its time inside the malloc() and free() routines. They are a lot cruftier and slower than most people would guess. ;-)

One advantage of the increases in speed and memory is that you can use the practical approach of writing quick-and-dirty prototypes. If it's "good enough" and not used much, you might as well leave it that way. If it's used a lot, you can study the code, and find ways of optimizing it.

But that's not nearly as funny as observing that the study and optimization part is rarely done, with results that most of us old-timers know well: It seems like the modern super-fast machines take as long to do most tasks as they old, slow machines did 20 or 30 years ago. The only real change is often just the flashy graphics surrounding the output (and lots of unused white space on the screen).

OTOH, I did just look at the local weather radar images on my laptop, and checked with google traffic for congested areas. Couldn't do those things 20 years ago.

Huh? Has it ever been used for anything else? Can you present the evidence?

In pretty much all the cases I've ever read about, a "whistleblower" who reveals "secrets" has always been exposing government wrongdoing. All the (publicly released) evidence seems to support the conjecture that the only actual function of government security is to hide criminal activity (usually but not always against their own citizens). If you believe it's ever used for anything else, maybe you could give us links to the evidence ...

Actually, I have several friends who've had houses built, and the builders occasionally bring prospective clients around to look at the houses. They say they've always invited the people in (when they've been home), and let the builder give them a tour of the house.

Maybe the builders don't have a legal right to do this uninvited, at least not inside your property line. But if the builder is open and friendly about it, and it doesn't happen too often, most people are reasonable and will cooperate. Some companies would even cooperate with such "guided tours".

My house was built before I was born, so this doesn't really apply to me. But we've had a few visits by previous owners (one the daughter of the first owners from 60 years ago), and we've been happy to show them what has become of their house and yard over the years. We also had a small addition put on, and the builders once brought some people by to look at it, which we cooperated with. (They liked the shelving and cabinets I'd added to the room. ;-)

I've faced this a number of times, usually dealing with some extensive collections of C tools that I've collected/written over time. What I've done is make it clear (in the code, in the documentation, and in my descriptions for clients) that I and others have published this material under a GPL. I tell them that they have a simple choice: They can pay me to rewrite the parts they need from scratch, in which case they'll own the code. Or they can save a few months of billable time by using the existing code, which they are free to use as they like, but it would be illegal for them to change the license or attributions. I also make it clear that any improvements we make will go back into the public "tool pool" which is passed around freely within the developer community, though of course the actual code for their own applications will be theirs and private.

So far, after a short bit of thought, they've all chosen to go with the "open" tool set. This has sometimes led to a few of them asking me (in private ;-) if I know of other "free" tools that they could nab when nobody's looking. I grin and tell them about a few.

The only thing at all tricky is making sure you keep the "free and open" stuff strictly separate from the proprietary, contract stuff. Keep them in different directories, different .so files, etc. But that's usually not all that difficult in practice.

And sometimes they even realize that having their company's name on a few pieces of open low-level tools is good PR with the developer community. But most of them never get this far into the subject. They just understand that they've saved months of time on a project by using code that already exists.

Not really. Yeah, the hardware guys have done a great job of making their part of the stack smaller and faster as the years have flown by. But the software guys have done an even better job of erasing the hardware speed increases by more than matching each with memory- and cpu-consuming bloat.

Much of this is due to the attitude that "We don't need to be efficient any more, because the hardware is so fast and there's so much memory available." There is no processor so fast or memory so large that programmers with contempt for efficient design can't easily saturate both of them, and then complain that the machine is just too slow and there's not nearly enough memory.

And as long as management continues to rate software developers by lines-of-code (the only software thing that they seem to know how to measure), this isn't going to change. Increasing the line (or char) count of my code is always trivial. In fact, I have perl scripts to do the job for me, for many of the common programming languages. ;-)

(I have fond memories of one project in which I rewrote a few core routines to be about half their original size, producing roughly a 10x speed improvement. It became clear that the management considered my "contribution" to have a negative measure. I'd decreased the code base. I found a new job. ;-)

If the Earth ever unfolds its wings, we insignificant surface parasites are in for a wild ride.

Funny, I have a printer plugged into my linux (Ubuntu) box that supposedly does double-sided printing, but many hours of digging around in TFM pages, googling, and experimenting were utterly unsuccessful at getting any 2-sided pages printed. The CUPS there even admitted to me that the printer does this, but I have yet to discover a way to make it actually happen.

There's also the problem that, for the past year or so, only other linux systems can use this printer. Various Macs see it and think it's working, get no errors, but their files never print, and I get popup print windows saying "Network host '<hostname>' is busy; will retry in <N> seconds...". This state is permanent, with N slowly increasing. Google gets lots of matches for that error message, but I've never found anything saying how to fix the failure. The logfiles on the linux box show no connections at all from the Macs. (My suspicion is that recent updates on the Macs quietly blocked the ability to talk to CUPS servers and/or linux machines. The linux boxes can all use each others' printers, and the few Windows boxes can use them, too, so it's apparently not CUPS that's failing.)

Not quite; it also fixes several undocumented holes in Windows security.

None of these holes are actually known to MS, because the hackers who found them were wary of prosecution if they told anyone - especially the MS security people - what they knew.

(If you were JAPH, you'd know this when you read the code.)

Nah; it'll be the typical approach of finding the "hackers" that expose security holes, then firing and/or prosecuting them to teach them (and their friends) the traditional lesson: We don't want to hear about our security problems. We'll continue to punish you hackers until you give up.

In my experience, this approach is the usual one that corporations use with their own developers. It's why the smarter developers tend to avoid working on security-related stuff. They want to keep their jobs, stay out of jail, etc. The result is the current security mess. Anyone with a grain of sense understands why it's such a mess.

(And no, after one such experience, I've never accepted another task that involved implementing security. I write routines to test everything I develop. If my test routines are treated as criminal evidence against me, I don't write the test routines - or the software that they were designed to test. If you don't understand this, I'm not gonna be developing software for you. And your software will be full of holes, because other developers also understand what your attitude means to them. ;-)

Anyway, I've found it "interesting" that this discussion doesn't seem to be mentioning the implications of the way that programmers are treated when they report security problems. Maybe because the people who understand the issue think it's too obvious to comment about ...

And biologists might argue that that's absurd, because wheat wasn't created by "nature", but rather by millennia of human selection. Wheat is a different species than its wild ancestor; it's an "artificial" (i.e., human created) species than can't survive in the wild without human assistance. Similarly with the other major grains, which are all very different from their wild ancestors, are are artificial in the same sense.

This isn't to say that criticisms of Monsanto are wrong, of course. But making bogus biological arguments really doesn't advance the cause, because actual scientists are likely to speak up and point out the technical errors in such bogus arguments.

Heh. I was tempted to reply to the poster of the claim that Monsanto is French by suggesting that they're actually a giant international corporation with no loyalty to the French or any other government, nation or people. Now I can respond to the claim that they're American in the same way.

Monsanto doesn't have our interests at heart; they have their officers' and stockholders' interest at heart. Many people here on /. have explained not only why this is, but why it's Right in our theoretical regulation-free market, which would be best in this best of all possible worlds, y'know. So I won't go into that. I'll just suggest that you consider it when reading about their actions.