I was thinking exactly the opposite - It seems to me that certain types of creative tasks simply do not lend themselves to lots of iteration and refinement... Writing, for example, tends to get worse the more people mess with it. I'm guessing that movie scripts are the same. Obviously there's room for improvement on most kinds of projects, but I just don't see how you do iteration on writing a story or building a jet engine... at least not iteration in the sense of progressive refinement and adding features as in the agile software sense.
I don't know how LinkedIn's login APIs work, but if they use secure user/pass logins and store authentication tokens on the client side as is good practice then in theory exposing these server side generated hashes wouldn't really compromise the system. The problem is that SHA-1 has been broken
This is one reason you don't send password hashes over the network...
I think you are describing those options incorrectly for his case.
--inplace is the opposite of what he wants. As I understand it --inplace will defeat some of the automatic duplicate range detection and save *space on the server* by not duplicating data during transfer. This does not help with network bandwidth but *hurt*. He probably doesn't care about space on the server, he wants his files mirrored quickly.
--update won't hurt him here, but it's probably not necessary as you seem to be describing it backwards. If he just mods files on his laptop and rsyncs the newer files on the laptop will of course get transferred. The only reason to use --update would be if he modded files on the server at home *and* on the laptop and preferred to keep the ones at home.
We had to wait about three years to get the last doubling from 2TB to 4TB for commercially available internal disks. I seriously doubt we'll get *four* more doublings in the next four years.
I mirror data and test it periodically with rsync using the dry-run (-n) and checksum options (-c) to do a full comparison. I usually have more confidence in a new disk after I've done this a few times.
I actually thought it was a joke when I first saw the headline. This has the be the most unfortunate timing of a product release ever. Long live the Sabre (er, Paypale) Pyramid!
Some of the rides at Disneyland have started taking advantage of this idea by moving the passengers along on a moving beltway (kind of like at the airport) next to the ride... So you board the ride without the ride having to slow down at all... e.g. the Buzz Lightyear ride does this and I recall that it worked pretty well.
Apple obviously already has some kind of deal in place with Google for maps... They've used Google maps since day one. And Google has always charged for high volume use of its other APIs... e.g. geo-tagging. This is a non-story.
They suck. Let's have an option to hide them or demote them.
I can think of dozens of things that they are dying to use that power for: Pumping 4x the pixels for a high resolution display, doing processing related to speech recognition (even if the matching is done server side), running spotlight indexing on local content as you download it... (e.g. your email and docs from the cloud), playing HD video while doing all of the above, supporting a "mission control" style app switcher with live previews and spaces style switching, supporting airplay in the background while you are using the iPad for something else (maybe even someone else controlling it), games with really good physics simulations (which are dominating the app store and making apple millions)
A real engineer can speak to this better, but there is a big difference between the "near field" where you are actually coupling magnetically/capacitatively with the source and radiation which transmits energy over an arbitrary distance. I believe if you are stealing power by putting a big coil next to a power line you are essentially making half of a transformer and directly drawing power through it... whereas if you are at a greater distance all you can do is intercept radiated energy, which is already gone as far as the sender is concerned.
With years of fighting around the ISPs, hosting, and blocking of TPB can someone tell me how it is that the domain name has not just been seized? Haven't other names been grabbed / taken down for more specious reasons?
I understand that taking the domain name would not stop any of this, I am just amazed that they haven't tried...
Does anyone know what was involved in "dumping ROMs"? I would have assumed that the private key was buried in the hardware and not directly accessible via software... From his description it sounds like it was just stored in ROM and software obfuscated. If that was the case it seems odd that it took six years for someone to find it...
LightPeak is a much cooler name... and less ambiguous as a search term... and less childish sounding.
So the question then is whether JS having a runtime can allow it to work around the lack of type information in the code. Runtimes can do things like observe the type usage and "optomistic inlining" that in some cases may compensate for the loose types. But there may always be cases where there is a penalty for loose types.