Contract law is law. Also, there's actual copyright statute that says you can't create and distribute a derivative work. This has often been interpreted by the courts to mean you can't make a tool that easily enables others to do so. While running this on your own copy of something is not against statute, it may be a breach of contract.

If you think that statutes are all of the law, then you don't understand the concept of law in pretty much the entire former English colonies, most of which operate at least partly under common law and precedent.

You own it if you write it, if you pay someone under contract to write it for you to own, if you purchase the ownership and copyright interests in the code, or if the copyright is assigned to you.

You don't own Photoshop. Adobe does.

A program that could process 100 MB of data in five seconds can now process 500 MB of data in five seconds. That's a 400% increase in the amount of data it can process per unit of time. People are just really bad at wording this sort of thing for some reason. I think that reason is probably that math and language are taught largely independently and as if one never interacts with the other.

In a constantly growing market worth billions a company doesn't have to displace one of the top two in order to grow. They should focus on not being a joke of a distant also-ran before they worry about asserting any newfound dominance.

Google's model is to tie their platform to their other platform. The Google Play apps and the Play Store must be installed on Android systems for them to be called Android. All of those tie back to Google.

While Microsoft might get into hot water for tying back to their desktop exclusively, they have apps for iOS and for Android. They have Outlook.com, Exchange, Visual Studio (which can make phone apps!), Office for mobile, Sharepoint, etc that they can push.

While you're saying they won't succeed, that's not the same as saying that what they want to try is the same as what Apple's doing. Giving up most of the Nokia hardware business means they've given up on the vertical single-source solution pretty thoroughly.

I'm not a meteorologist, but this is my understand: It depends on the size and temperature of the particles, and potentially on their shape and concentration. If the particulate matter is too hot and in the air too thick, not enough water vapor condenses on each to form droplets heavy enough to fall.

I think what they are saying in this case is once the particles cool and thin a bit, they end up carrying that moisture with them until the condensation is complete. Hitting a mountainside and mixing with the cool air above is a perfect trigger to release the rain.

Large rain events often happen when a warm, wet mass of air mixes with a cooler, dryer mass of air that can't hold that level of moisture. The particulate matter is just one of a number of variables.

Distinction without a difference, really? Do you think Apple has a healthy ecosystem of devices that only includes first-party devices? No. Apple has only first-party devices. You can't buy an iOS phone from a non-Apple source. Google has the Nexus but the vast majority of Android phones are from other vendors. That's what a software company calls a "healthy ecosystem".

Basically the announcement reads "We want Windows Phone to be delivered the way Windows on the PC always has been: by every OEM out there".

"We are moving from a strategy to grow a standalone phone business to a strategy to grow and create a vibrant Windows ecosystem that includes our first-party device family,"

This isn't Apple envy. They didn't say they want to focus on one offering. They said they want a vibrant ecosystem that includes their first-party devices. They've learned that when you're making the bulk of your OS's phones yourselves, there's little incentive for competitors to license your software. However, if you make a reference model, or maybe a couple for different market segments, and license cheaply and liberally, then you can really grow the influence of your OS.

Microsoft successfully killed any relevance Symbian still had. They killed Meego. Firefox and Ubuntu are still on the horizon. They didn't kill Android of course, and won't at this point. iOS is another juggernaut. MS wants to play the game Google has been playing, because they won't beat Apple at theirs.

In the US we love big machines. The Queen Mary, the Spruce Goose, the continuous asphalt pavers, the Liebherr T 282 B giant dump truck (although Liebherr is a Swiss company), the Boeing 747-400 and Lockheed L-1011 wide-body passenger jets, the massive Abrams tank, the Nimitz-class aircraft carriers, the 280mm towed howitzer M65 "Atomic Annie", and such are examples.

See how I slipped a Swiss-built monster in there? Well, the US and Japan aren't the only ones. Germany has a 31 million pound excavator. The largest plane is made in Russia by Antonov. South Korea builds some of the biggest cargo ships.

So while, yes, giant robots are a big thing in Japanese art the urge to build huge machines is all over the industrialized world. The US and Germany have never been afraid of large engineering feats. The US has a whole industry of using remotely piloted craft for actual combat.

I don't think Japan needs to focus so much pride on this one little competition as a cultural identity issue. It's not like a US firm is going to enter a contest designing and building a robot with the intent of a face-saving loss or an honorable tie.

"Career" is still hyperbole. A project may fail. It may even be one job at stake. It wouldn't end a career.

So, assuming a make-or-break project for an employer are the stakes, here's what I'd do. First, I'd do an initial evaluation whether doing this on Linux is actually worthwhile given the alternatives on other Unix platforms. Second, I'd pick something for safety over performance. Given the budget, I'd pay for development on one of the OSS versioning filesystems to do clustering or one of the OSS clustering filesystems to do versioning.

I'd probably check to see if frequent snapshots are valid rather than per-file per-write versioning. That turned out to be the case in this thread. That gives many workable and fairly conventional options on Linux.

If per-write versions were really that important, and it really had to be on Linux, and really had to be shared as well, I'd probably alter my application to write through git libraries at the application level. If not git, then maybe Mercurial or Bazaar. If I didn't have control over the application, I'd look into inotify to do commits based on those writes.

If it really needs to be in the filesystem, really needs to be on Linux, and really needs to be per-write versions, I'd use something like NILFS2 on LVM with a SAN-backed LVM, and have read-only access shared out over NFS or CIFS.

No matter what I chose as my primary target, I'd choose a couple other alternatives and test the hell out of all three. I wouldn't greenlight anything for production until I was happy.

Really, if your employer expects anything less stringent on their production infrastructure than a full testing and development cycle and blames the implementors for failures of overspecified and undertested software as ordered by management, then you want a new employer anyway.

"ATM0" is your friend. It shuts the modem speaker off entirely including during dialing. "ATL0" works on some modems but not others (like internals with the sound piped through the sound card).