No quantitative social indicator here. If you are trying to imply that if there are incentives for profit people may behave dishonorably, by golly, you are right. I can thing of the three profit-related types of problems:

• evildoers bury evidence of evildoing (hiding)
• evildoers try to bolster false evidence of evildoing (planting)
• evildoers try to swamp the site with irrelevant stuff (denial-of-service)

All three of these can be solved with well though-out moderation and rate-limiting. In any case, I really cannot see how opening up information for public scrutiny can be bad for the public, as long as the information is factually accurate and no private personal information manages to slip through.

The worse thing that can happen is that nobody turns up to actually look at this data. Being from an academic background, I can assure you that many academics would be happy to get their hands on real-world data with things to find in it. For companies, proving that the arch-nemesis has bad accounts can be a bargaining point -- and an incentive to keep clean accounts. Journalists would be happy to get their hands on more stories. The list goes on.

So this makes transparency a bad thing?

I would argue the opposite. The more facts you can collect that prove that things need fixing, the more likely you will be to convince others to your point of view. Access to the data cannot only "help" SEC to fix problems, it can also force them to do so, given a high enough level of public outcry.

This much is obvious - the more transparent an institution, the easier it is for outsiders to find fraud or other problems. Where privacy is not an issue, I wholeheartedly support making as much data as possible available (in analysis-friendly formats) to as many people as possible. Data.gov is a great initiative. On the other hand, while it is good to open things up to fresh air and external review, blindly trusting on "the crowd" to do your work for your poor, understaffed self does not sound like due diligence. The key word in the title is "help". Staff professionals are expected to pick the most promising traces and do full investigations that lead to prosecution. With more transparency, public opinion will hopefully badger them on if they falter.

The article itself talks about moderation systems that allow the crowd to separate wheat (real cases of fraud) from chaff. In many crowdsourcing initiatives, a bad moderation system has resulted in a swamp of duplicate suggestions and some great internet humor, but little of actual value. A worse risk is that of concerted action by special interest group minorities, which could bury findings considered "negative" by group members and bolster those that furthered the group's agenda, giving this agenda a false legitimacy by appearing to come from "the crowd".

Think of it as a lock on a door. The door can still be opened by somebody who is motivated enough, but the fact that there is a lock raises the bar, and makes the trade-off less favorable to the would-be cheater. Leaving the door unlocked, on the other hand, punishes those that are honest, and can make them re-evaluate their honesty (hey, look, everyone is doing it!).

Asking questions on how things work in your code is another measure that raises the bar. As a TA, I applied both: an automated plagiarism detection program (http://tangow.ii.uam.es/ac - GPL'd and entirely client-side, unlike MOSS) and individual, written exams with very concrete questions regarding the code (eg.: "describe the data-structure you used to implement feature X" or "which of your methods would you need to alter to implement feature Y"). The exams were very short, and intended to be filled just after the code had been turned in, so that there was not a lot to memorize.

It was still possible for someone to cheat -- but, hopefully, it would have required so much effort as to be not worth the trouble.

The technical term is Normalized Compression Distance, and, on source code, it works even better when you tokenize the programs first (so that whitespace, identifier names and comments cease to be a factor).

Here is a program that does just that, and has pretty graphs showing who is way more similar to whom than chance would have it: http://tangow.ii.uam.es/ac . It is in active use in several courses at Spanish universities.

Sikuli is certainly not commercial-grade UI testing software. It was never intended to be, this is academic software written to explore ideas, rather than to polish them to perfection. Also, it is not a "general" programming language. The previous posters that compared it to video-programming are right: not all programs have to target complicated algorithms and data-structures, there is plenty of space for automating "simple stuff".

As an idea, I find the readability of the code particularly interesting. Sikuli code is about the closest you can come to self-explanatory, step-by-step instructions on how to achieve whatever a particular program does. Add a few comments to the most arcane steps, publish those programs to an online repository, and presto! executable step-by-step tutorials.

Yes, the developers may have to address the variability of themes on people's desktops. It is certainly possible to do so (for instance, by keeping a list of mappings from any of a set of "supported" themes to a "canonical" theme, which would be used in all examples), but, as far as ideas go, I really think that Sikuli is a very refreshing idea.

I've fantasized with asking my students to use a VCS to submit their code as it gets written. Of course, in Computer Science, this would be educational beyond the "controlling their times" sense. And could be used as a collaboration tool within each student team.

The only thing keeping me back is the maintenance headache.I would have to setup accounts for each student, and build the initial projects, too; yes, this can be partially automated. And the extra burden of explaining how to use the system (they only learn about VCSs, in an abstract way, in their 7th semester...)

[tongue-in-cheek] You are totally correct. We should trust people entirely. I say, do not even read student essays, just ask them what mark they deserve. Actually *reading* the essays would reveal a blatant lack of trust. [/tongue-in-cheek]

Never mind experience, never mind the fact that dishonesty tends to spread if rules are not enforced (as initially-honest persons may decide that they too are entitled to the personal benefits of dishonesty, even if the community starts to rot). A rotten community is *not* where you want to study or teach.

Academic achievement is not only personal growth. It has a very real meaning in the job market. Handing out diplomas to people who have weaseled their way through the system can only discredit the institution that issued those diplomas, and by extension, anybody holding them, even if they were honest.

I would have more patience with academic dishonesty if the only problem was students cheating themselves. But the whole system suffers when plagiarism goes undetected.

Manually signing things is cumbersome because (a) you have to be within arm's reach of the signature's destination, and (b) because it takes a certain amount of time to sign each paper.

These folks seem to have a (complex) system to create signatures remotely, addressing (a). If you record and play back what comes into the signing machine, you would also have (b) - at the expense of an even greater security headache. I really hope they are keeping the connection encrypted. And kudos to them on account of imitating fine manipulation.

But signatures as authentication are more than flawed. Only a specialist can distinguish between a valid signature and a forgery of any quality, and there are few specialists. About the only saving grace of signatures is that they are low on technology - anyone can sign, and anyone can "low-leve-verify" a signature.

If you are going to use a machine and a secure communications channel for identification -- use cryptography.

Also, if whatever the machine signs in your name is going to be legally binding, you had better be very sure that the machine is signing what they tell you that it is signing. I can imagine all types of mischief with blank checks instead of "book covers". An advantage of being (a) within arm's reach of something is that you can easily examine what it is that you are signing.

Great comment, should be up-modded.

On the other hand, you forgot to account for sail array maintenance costs, additional crew training, and the extra risk of sail failure in the event of harsh weather - not that I have much of an idea of sailing, but the investment is not completely risk-free. Most container ships don't have sails on them, and diesel engine expertise is much more widely found than sail array expertise; this makes maintenance harder that it could be.

There is bound to be a first-mover risk (as well as rewards) to the venture.

I disagree about math in general. Proving theorems requires a lot of creative thinking. You may be thinking about good old canned integration formula substitution; but there are parts of math that are every bit as challenging as writing clever code.

On the other hand, few get to the interesting part of maths, or to the interesting parts of history (when you learn that there is only rough consensus on certain events, but very little certainty), or have teachers that are willing to explain that much of what we currently "know" about the world around us is still open to new answers.

Too many teachers treat their textbooks as the Holy Writ, and fail at stimulating curiosity and critical thought. Teaching the experiments is nice, because it allows you to get a glimpse at the long sequence of stumbles that have lead to present science. I would love to lay my hands on an "introductory physics" textbook of a few hundred years in the future.

No, not at all. Economy, understood as "interchange of goods and services" is certainly not zero-sum. There can be many levels of dynamic equilibrium, and it is both possible to have almost everybody be poor (have a look at the history books - they were human back then too) and to have almost everybody live in abundance -- with identical inputs in terms of people involved and natural resources tapped.

Certain things multiply the efficiency of an economy, and benefit all involved. Technology, for instance, allows a lot of physical labor to be avoided. A working justice and health system allow economic actors greater confidence in the safety of their investments and their persons, and results in more economic actions (instead of hoarding assets for an uncertain future).

Economy is not (only) about money. There was economy before money. Money is only a very useful mechanism to exchange goods and services efficiently, and a handy measuring rod -- even it its length changes constantly.

You write that "The science shows that free markets cause peace", and that lack of economic freedom causes both poverty and war. But correlation is not causation.

I can also argue that poverty and war cause lack of economic freedom: poverty can be seen as a lack of property (or means to acquire it), and there can't be much of a free economy, without circulation of property and means. War destroys civilian lives, property and freedoms, and results in poverty for those involved. Not exactly the recipe for a free economy.

Or you can conclude that free markets, individual freedoms and peace are all positively interrelated. I have the hope that China will need to embrace political freedoms as its markets grow, if only because lack of these freedoms results in a suboptimal economy: free press and political accountability are the only way to stem corruption and reward good risk-taking.

Sure, Java has a great security model and will not cause buffer overflows. But you have to write it in (duh) Java.

The fun part about NaCL is that it can eat existing (C, C++, pick-your-own compiled language) code with only minor modifications to the compile chain, as long as that code does not make weird system calls. Just make sure that the compiler does not echo any of the 'forbidden' instructions, aligns jumps to 32-bit boundaries, and uses the prescribed instruction sequences for jumps and system calls. And they provide modified versions of GCC that do just that. The paper also says that, in their experience, modification of most programs they tried was, at most, a problem of "a few hours".

If I had to port an existing app to run as a sort of browser plugin, guess what sounds better: a full rewrite in Java, or a few changes to the Makefile. Because *that* is the selling point of NaCL.

Not an expert in biology, but unless these contaminated areas have been contaminated for a very long time (read tens of thousands of years), and are quite large, the chances for life to have sprung up seem very, very slim. Current life needed millions of years to gain a firm foothold and start building up complexity. Lucky meteorites aside, starting from zero is bound to be hard.

If the experiment succeeds (here or elsewhere), and something "life-ish" is found, the results will still be tricky to classify. Can a given chemistry lead to increasing complexity, or is it just a dead end? Without hindsight, this seems like a very difficult question.