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.
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.
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:
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).
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.
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.
Everywhere i read i see posts from astroturfers pretending to be very concerned about their privacy. Lambasting Google for all they are worth and trying to purport them as a very evil and vile company.
The thing is, Google hasnt got half of the information many other sources has like twitter, facebook etc.
Let's see. I am very concerned about my online privacy and manage my own mail server. I don't have a Facebook account and only used my Twitter account for a couple of days total. I use Google search engine, Google maps and for professional reasons have an Adsense account. Here's what Google can know about me:
the content of emails I send to my friends using a Gmail account and that they send me (even if I never use Gmail myself)
my search queries
the Adsense enabled web sites I visit, even if I browse them directly or through another search engine
the Google Analytics enabled web sites I visit, see above
my physical position and where I plan to go (through my itinerary searches in Google maps)
bonus (because of my Adsense account): my full name, address and bank account
They can correlate all these data and know and remember more about me than I myself do. All in the hands of a single company which can integrate all these data in a single database (for ease of consultation by themselves, government agencies etc.)
That's not astroturfing, it's simple understanding of facts.
if I make to much money for example $60,000 @ 22% = $13,200 tax. I figure a way to spend it that will benefit me and be deductible from my income (lease a vehicle in my case) so I only make $50,000 @ 15% tax = $7,500 tax.
I think you miscalculated your taxes. If they are progressive as they should reasonably be, going from $50000 to $60000 should only increase the tax rate on the $10000 and not on the whole amount. So if 22% is the marginal rate at $60000, the difference in taxes would be at most the 22% of $10000, that is $2200. If your calculations were right, you would have a tax increase of $13200 - $7500 = $5700 out of your income increase of $10000, that is a 57% rate.
So yes, you can embed a Java interpreter in C code.
But there's a API documented for embedded Java to unload the VM when you're done with it that turns out to not be implemented
Interesting. Out of curiosity, would it have made any sense in your case to have the Java part running as a separate application communicating with the main C one over some IPC channel (sockets, RPC or something else)?
Funny spelling mistake. The Ferrari model is "Testarossa", which means "Redhead" in Italian. "Testarosa" means "Pinkhead" instead, which doesn't strike me as particularly cool;-)
Numbers are easier to compare than dates. They are also international, while dates aren't. 07.01. means 1st of July in some countries and January 7th in others.
These are easily solved by consistently using a big-endian format, which makes date comparison the same as the lexicographical one.
Quick, how many releases were between 2.6.20 and 2.6.24? Good.
Which doesn't tell you whether the releases encompassed a whole year of development or just four consecutive small bug-fixes within the same week.
Now quick, how many days were between January 17 and March 11? And... how many releases?
Why would you want to know how many there were? Do you make a point of not skipping a single one? But if I remember that some serious vulnerability was found out in February, I will know that it's advisable to upgrade from the January version to the March one.
Who cares how old it is? If it works and isn't known to have any stability or security issues (or at least not ones that affect your use of it), does it matter?
You might know it has some issue because it's older than six months and you remember a security advisory came out two months ago.
The 2.15% of you who are aware that there is a world outside your borders may have noticed that no one else plays "American" football.
[...]
The 98.85% of you who were not aware that there is a world outside your borders should count yourselves lucky.
...
The 1% of you who are both aware and not aware that there is a world outside your borders should make up their minds.
Slashdot Mirror
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...
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.
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.
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 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.
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:
Citation needed.
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.
Out of all the continued denialism, I'll just point out that one.
...which starts with:
What we need is a working unlocked and jailbraked IPhone
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.
Everywhere i read i see posts from astroturfers pretending to be very concerned about their privacy. Lambasting Google for all they are worth and trying to purport them as a very evil and vile company.
The thing is, Google hasnt got half of the information many other sources has like twitter, facebook etc.
Let's see. I am very concerned about my online privacy and manage my own mail server. I don't have a Facebook account and only used my Twitter account for a couple of days total. I use Google search engine, Google maps and for professional reasons have an Adsense account. Here's what Google can know about me:
They can correlate all these data and know and remember more about me than I myself do. All in the hands of a single company which can integrate all these data in a single database (for ease of consultation by themselves, government agencies etc.)
That's not astroturfing, it's simple understanding of facts.
Call me when he finds a way to determine the email after gravatar starts adding a pinch of salf to the hashed emails...
Call me when gravatar starts adding a pinch of salt to the hashed emails ;-)
On the other hand, his lawyers should have adviced them better.
It's a bit like IT consultants advising you to buy expensive services you don't need: they are acting in their own interest and not in yours.
if I make to much money for example $60,000 @ 22% = $13,200 tax. I figure a way to spend it that will benefit me and be deductible from my income (lease a vehicle in my case) so I only make $50,000 @ 15% tax = $7,500 tax.
I think you miscalculated your taxes. If they are progressive as they should reasonably be, going from $50000 to $60000 should only increase the tax rate on the $10000 and not on the whole amount. So if 22% is the marginal rate at $60000, the difference in taxes would be at most the 22% of $10000, that is $2200. If your calculations were right, you would have a tax increase of $13200 - $7500 = $5700 out of your income increase of $10000, that is a 57% rate.
Interesting. Out of curiosity, would it have made any sense in your case to have the Java part running as a separate application communicating with the main C one over some IPC channel (sockets, RPC or something else)?
Cheers
That worked quite well, it seems ;-)
Can money buy you a Ferrari Testarosa? Yes.
Funny spelling mistake. The Ferrari model is "Testarossa", which means "Redhead" in Italian. "Testarosa" means "Pinkhead" instead, which doesn't strike me as particularly cool ;-)
These are easily solved by consistently using a big-endian format, which makes date comparison the same as the lexicographical one.
Which doesn't tell you whether the releases encompassed a whole year of development or just four consecutive small bug-fixes within the same week.
Why would you want to know how many there were? Do you make a point of not skipping a single one? But if I remember that some serious vulnerability was found out in February, I will know that it's advisable to upgrade from the January version to the March one.
You might know it has some issue because it's older than six months and you remember a security advisory came out two months ago.
The 1% of you who are both aware and not aware that there is a world outside your borders should make up their minds.