It's sad how stupid reporters report wrong "news", the error gets repeated all over the Internet, and finally lands in Slashdot whose editor didn't know the original news report was wrong.

The 16-year-old girl did not invent a previously-unknown theorem. What she did is to re-invent a theorem which Euclid already listed and proved over two thousand years ago (http://aleph0.clarku.edu/~djoyce/elements/bookIII/propIII9.html). But Euclid listed hundreds of theorems, most have simple and basic proofs, and most of them are never specifically taught. In this case, the girl was not taught this theorem, but she thought that she could have used such a theorem in her homework, so she went about proving it (with help from her teacher, who was also not familiar with Euclid's mention of this theorem).

The girl's proof is different Euclid's, but still very simple and elementary, and is in no way a profound addition to Mathematics. But this girl is still admirable, in that she had the creativity and resourcefulness to imagine a "new" (to her) theorem, and to go around proving here - rather than sticking to the "cheat sheet" of theorems she was taught in class. This girl definitely deserves an A in her math class, but not worldwide mention on news classes.

Of course, it's not her fault, but rather that of the reporters who blew this story out of proportions, and reported this stuff as a new theorem, a breakthrough, or other irrelevant adjectives - without checking the validity of this "story" with any Mathematician worth his salt. This "story" should never have made headlines, and definitely not slashdot. But the girl still deserves praise, and of course an A :-)

"Perfect" is an exaggeration, but the human's one win does demonstrates the computer is not vastly superior to the human. If *I* was to play against this computer, I would loose in each and every game. 100% of the games. I didn't even write "99.999%" because I couldn't win a single game against a vastly superior software. Go is not a game of chance, so my "luck" would not have let me win even once. But the Go champion did win some games against the software, so apparently they still are at a comparable playing level (even if one is slightly better than the other). So the software isn't "perfect" at beating humans. Yet.

There are plenty of "non-combat" soldiers, just as you have "non-programmers" in a software company: Every organization have people who are in charge of supplies, medics (like you said), people who fix vehicles, people in charge of HR, and in the particular unit involved (a canine unit), I guess people who train dogs and care for them. As you would expect, *all* of these people, as soldiers, got some sort of basic military training, including how to use a gun - but most of them probably haven't touched a gun since. A couple of "non-combat" soldiers wondering around lost look very different from a platoon of heavily armed combat-trained soldiers with some sort of mission...

Obviously, if the attackers would have caught them, they could have been killed with those stones and petrol bombs - or even bare hands. This has happened before, to Israelis who were less lucky.

This doesn't sound like retaliation, but simply extraction of the two innocent individuals who were surrounded by an angry mob who didn't want to disperse and was actually happy (!?) to engage the armed soldiers who came to extract the two.

You can also have private cloud storage, namely NAS: In my home I already have a 3 TB NAS attached to the home network, and all the devices in my home (computers, streamers, cellphones, etc.) can use movies, photos, music, etc. stored on that shared disk. This made it un-important for individual computers to have huge hard disks: My wife's computer has a 2 TB hard disk, which remains 95% free, for example.

So it makes sense that in the future you'll have the really big (and chip low $/GB) disks only in NAS devices, and all other computers, devices, etc., will have smaller disks with less concern to the $/GB and more concern for reliability, speed, power consumption, etc.

If they promised storing an unlimited number of photographs, it doesn't mean they need to promise that each photograph can be of unlimited size. The number of people who have 1 GB bona-fide photos is vanishingly small, and Amazon is of no obligation to serve them.
However, the next step from "abusers" would be, of course, to store huge files as many separate photos on Amazon.
But I'm not sure why "unlimited" is the point here. If they did limit it to 15 GB (like Google drive's free storage), the abusers could still save 15 GB of non-photo files on this service. This would be less of an abuse?

In previous news in slashdot, an alleged Israeli spy vulture was caught by Lebanon.
The Israelis claimed this was ridiculous, that it was just an innocent bird.
But now we know the truth: the vulture was really out to get Lebanese drones!

Indeed! I was really surprised to read this headline, which implied that "incremental upgrades" are no longer being supported. It turns out, however, that the poster simply has a completely different concept of "incremental upgrade" than I do: For him, the normal upgrade is just "upgrade", and an "incremental upgrade" is when the distro forces you to upgrade in several small steps instead of one big step. The plan is to stop forcing you to take these small steps. And that's it! Upgrades - the normal upgrades that have always been supported - will NOT be dropped.

The rename issue is actually *very* important. It's not likely that you'll have a lot of independent renames, but something very likely is that you rename one directory containing a lot of files - and at that point rsync will send the entire content of that directory again. I actually found myself in the past stopping myself from renaming a directory, just because I knew this will incur a huge slowdown next time I do a backup (using rsync).

But this is *not* what the article appears to be measuring. He measured that the time to synchronize a changes were nearly identical in rsync and "ZFS replication" - except when it comes to renames.

Reading this article, it seems that this "ZFS replication" is very similar to rsync, with one straightforward addition:

Rsync works on an individual file level. It knows how to synchronized each modified file separately, and does this very efficiently. But if a file was renamed, without any further changes, it doesn't notice this fact, and instead notices the new file and sends it in its entirety. "ZFS replication", on the other hand, works on the filesystem level so it knows about renamed files and can send just the "rename" event instead of the entire content of the file.

So if rsync ran through all the files to try to recognize renamed files (e.g., by file sizes and dates, confirming with a hash), it could basically do the same thing. This wouldn't catch the event of renaming *and also* modifying the same file, but this is rarer than simple movements of files and directories. The benefit would have been that this would work on *any* filesystem, not just of ZFS. Since 99.9% of the users out there do not use ZFS, it makes sense to have this feature in rsync, not ZFS.

Exactly. Moreover, it becomes impossible to compare prices of two competing networks. You can't say "AT&T charges me 10 cents a minute, Spring charges me 15 cents a minute, so I'll chose AT&T" - instead, one company might nominally say their price is 10 cents a minute, but during 90% of the day, or in the area where you work, it will claim there is congestion so it will actually charge you 50 cents a minute.

I guess you needed to also take the "advanced cryptography" course, where they would teach you that if you use stand(time(NULL)) and then make the time at that moment easily guessable (e.g., by leaving behind a file created at the exact same time), your supposedly-unguessable seed becomes easily guessable...

That is a common misconception. When DVD CSS (the DRM on DVDs) came out, they claimed it was to stop piracy. That was a joke - it only took the effort of one pirate to strip out the DRM and create an unencrypted file, and from then on the movie becomes available to pirates, and "casual", "low-skilled" pirates started copying *those* unencrypted fils, not the original DVDs. All these pirates needed to know was how to copy files - they didn't need any special "hacking" skills.

Moreover, not only did CSS not stop DVD piracy, movie producer started to use it to limit users with things that have nothing to do with copying - for example region coding (you cannot play a movie you bought legally in another country) and unskippable ads (in some places in the video, fast-forward did not work). And who didn't have to suffer this crap? Of course, the pirates. The pirates - either copying files over bittorrent or buying a DVD from some pirate DVD manufacturer - will get a DVD without all that crap. What a wonderful business move.

It's gotten to the point where the first thing I do after getting a DVD is to rip it to an unencrypted file, delete the silly "FBI warning" and ads, and save that file. I don't need my children to see FBI warnings and ads before watching a movie I paid for. Nothing in "copyright" law allows the copyright holder to force me to watch this crap - any more than book manufacturers can force me to read the first page of the book every time I want to read it.

You are missing the point... Even if JPEG implements DRM, it doesn't force you to use DRM on the photos you create. You can still take photos, draw images, etc., and not enable DRM on them. So people who currently create JPEGs can continue to use them and don't need to "switch". The problem with DRM is when other people put them on the images they send you. E.g., you browse some website and you see there a DRMed JPEG. How can you "switch" to PNG here?? You didn't create this JPEG, someone else did it, and they did so deliberately.

What users can do, however, is to not even try to get their content from the official publisher (because it uses some annoying DRM) but rather get the same content from a "pirate" which broke this DRM and converted the content to a more useful format. This is what people have been doing for years for video. I, for example, never use actual DVDs any more (my living-room "DVD player" is stash away in the attic) - I always rip my DVDs to an unencrypted ".vob" file before watching them, and avoid all sorts of region locks, mandatory ads, and other crap the publisher thought he could force on me in the pretense of "copyright".