Let me expand on why modifying the original files is (IMHO) a bad idea, independently of my proposed solution.

When you edit an image, you should keep the original version anyway, because otherwise you are going to lose information. In this case, you are not modifying the original file, but creating a derived work (for which, I agree, you would want the same tags applied automatically based on some image matching algo).

If you change multiple copies of an image independently, you need to merge those changes somehow. Basically, you end up with the problems concurrent revision systems solve (and the complexity that entails). Merging two database tables with a common simple structure is a trivial task.

Deduplication is much easier if files don't change. I have the exact same file in two directories: delete one copy. I have two files with an almost identical image but different tags, cropping or other. That needs manual intervention and is error prone.

Twenty years from now, I prefer to still have the picture I took, rather than a version with some cropping, some sepia filter applied when I thought it was cool, a few rotations randomly applied by the image management program du jour and a re-encoding or two for measure. I'd also rather avoid relying on the backup software I used twenty years ago and I may have stopped using in the meanwhile to retrieve a previous version.

Having said this, it's as usual a question of compromises. Just use the one which better works for you and your workflow.

If anybody wants to implement such a system from scratch, I would advise against modifying the image files, since that makes deduplication and backups harder (you backup a file, than tag one copy and now have two different files).

Building on some ideas I'm using in a backup software I'm working on (please take a look and give feedback if you have some time to spare) I would suggest associating tags and exif info to an hash value of the image files. This way, getting info about a file would be: read file -> compute hash -> retrieve info on that hash.

For quick lookups from hash to file, you can have another table storing the paths where the file with the given hash was seen.

So, table 1 (image metadata) would look like:

d012f68144ed0f121d3cc330a17eec528c2e7d59 | holiday 2013
d012f68144ed0f121d3cc330a17eec528c2e7d59 | dog running
d012f68144ed0f121d3cc330a17eec528c2e7d59 | vote:5
...

while table 2 (hash to file lookup) would look like:

d012f68144ed0f121d3cc330a17eec528c2e7d59 | /home/user/pictures/2013/IMG_123.JPG
...

This way, metadata (table 1) is in a simple and future-proof format, provided you don't modify the original files, which I think is a bad idea anyway. Besides, this doesn't impact your ability of organizing pictures in folders whatever way you like. The only issue can be the need to refresh table2 every now and then.

Just my 2c...

I have been working on a backup software for similar scenarios (in my case: picture and email folders, partially replicated on a few PCs). Tha idea is: copy files redundantly on different computers and external drives and keep track of what file was seen where. The program is called file4life and I have recently made it public: http://www.file4life.org/ The basic usage is:

file4life -i
> scan /some/dir
> backup -s 10G /some/backup/drive

Of course there is also a restore operation :-)
I need beta testers and someone to build and try it on POSIX systems other than Debian. Currently there is no Windows version, which would require a bit of work, given the difference in filesystem layout.
On the website there is a contact email and I'd be super glad to have some feedback on it.

But the newest and chinest MacBook always have some killer feature that nobody else have. For a long time, the instant hybernate (that would always work, and not crash the machine once every other lid closure) was a killer.

At my last job I was given a Mac and one of the several annoyances coming from several years of Debian was the time it took it to suspend (in the order of 1-2 minutes, versus about 4 seconds in my Debian laptop). I wonder whether they had removed this "instant hybernate" feature or whether it was some software problem specific to my machine. Or maybe the Mac played tricks on me, detecting my lack of love ;-)

In my very first attempt in '96, I tried Debian but some process in crontab would trash my disk (the locate update, IIRC), so not knowing any better I moved at once to Red Hat. After using it for a while (a couple of years) I gave Debian another try, fell in love with it and to this day it's my distro of choice.

A really good proof would be able to show a solution for n dimensions, where n > 2, but all we have as a proof is an exhaustive enumeration of the possible networks in 2 dimensions.

The four color theorem only makes sense in 2 dimensions, since for 3 and more no number of colors is enough. To visualize this, just take any number n of spheres in 3D, add appendices to them so that each sphere touches all the other ones, without intersection, fill-in the voids with whatever you want (by thickening the appendices or with a new region) and you end up needing at least n different colors.

I agree, but in such cases, isn't the solution to make current "fun" languages more "enterprisey" by improving the back-end toolchain?

I have found a very good mix of fun and "enterprisey" in Scala. Runs on the JVM, excellent Java interoperability, statically type-checked with some level of type inference and a very dynamic feel.

I live in Turin, next to france, and we DO import nuclear energy from france [...] and France is Upwind from us, so I would laugh my head off if it wasn't sad.

Even if I understand your point of view, you should admit that the risk/benefit estimate for someone NOT living close to the French border will have been very different from yours (take Sicily as an extreme example).

...and so did all my friends, including quite a few with a degree in Phyisics and an open mind. Apart from the universal issues on nuclear power and the soundness of a decades long investment starting from scratch, consider that:

• Italy is densely populated (much more so than the United States). A worst case scenario would be much worse than in a semi-desertic area;
• there is a widespread involvement of various mafias with politics and business (including construction and waste treatment);
• in some places (see Naples and thereabouts) we are not even able to regularly process domestic garbage, so that it accumulates in urban streets, due to lack of organization and the interests of said mafias;
• the current government, in favour of a move towards nuclear, and actively pushing for it out of the blue in the recent months, has a very negative track record and its choices are usually dictated by a private interest of the Prime Minister and his associates, with great expense for the Country;
• the minister who was to be in charge of the contracts for new nuclear plants, Claudio Scajola, resigned some time ago because it was found he had received a bribe in the form of partial payment for a flat in central Rome. He had the courage to declare that "if he would find that someone had partially paid for the apartment without him knowing, he would give up the property". That's the kind of people who would be managing the nuclear future of Italy, weren't it for the results from yesterday.

There is evidence that their claims are true (e.g., someone named Jesus did exist in the past, and there is significant evidence that he was executed by the Romans).

Citation needed.

there is no continuous mapping from R to RxR or RxRxR

Apart from the obvious examples of continuous mappings (just map the whole line to a single point or embed it any way in the plane or space), you might be interested in this article on space-filling curves, describing continuous surjective mappings from the segment to the square. Variations of those can be used to construct continuous surjective mappings from the segment to R^n for any n, i.e. curves filling the n-dimensional space (no point left out). A very interesting and counterintuitive fact of Mathematics, yet easy enough to grasp with only a limited background.

...which starts with:

Now, not the best example of an open platform, I would say.

I have recently started working on my first project in Scala and I think the situation is quite similar to the Python/C one. Scala is a much more pleasant language to write in, having type inference and a much more dynamic feeling, and in cases when there is no specific library for a task at hand you can just tap into the gazillion Java packages.