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).

Gaffer's, to pick up small items that fall into tight places

Well, if you want frequent filesystem or directory snapshots rather than per-file per-change versioning then your options are much broader.

LVM can do snapshots besides doing disk pooling, and can do a sort of clustering. Btrfs pools disks and does snapshots without the clustering. XFS has indirect support for snapshots -- it allows one to freeze the filesystem and snapshot using the volume manager. Ceph is a highly available clustered storage system with a POSIX FS face and does snapshots. Lustre allows taking LVM snapshots of its MDT and OST filesystems, although doing so often could be a bottleneck. Gluster (since 3.7 or so) actually wraps around LVM's snapshot tools so long as each "brick" is on a thin LVM that contains no data besides the brick.

ZFS does pooling and snapshots. It's supported-ish on Linux both as a kernel module and as a FUSE filesystem. It has much better support on the BSDs and of course on OpenSolaris/Solaris.

It's notable that the Ceph folks recommend Btrfs underneath Ceph as the local filesystem for development and testing but XFS under it (or optionally ext4) for production at the moment.

Getting the network storage enabled without a single point of failure is easy, especially if using a distributed replicated system. Getting versioning to work without a coordination point for the versioning is a much more difficult problem to solve.

I want to note that while many people voice distrust or even disgust with it, FUSE by itself shouldn't disqualify a solution. Lots of high-performance filesystems get their POSIX FS layer via FUSE.

Also, while versioning and clustering are a different problem the similar issue of frequent snapshots and clustering is well solved. Gluster, MooseFS, CephFS (part of Ceph), and others support snapshotting just fine. No matter how frequently you snapshot, it's not quite the same as versioned files. It is often worth comparing the two, but one is not a true replacement for the other.

Something like git that's designed to allow branching and merging is helpful here, but as has been pointed out using a FUSE-mountable file system like gitfs over a git remote is not the cleanest of solutions either. There are application libraries that handle checking things into and out of git pretty transparently, buy altering applications is definitely not the same as doing something at the FS level. All the clients fetch the changes from the repo, and the repo can be cloned elsewhere for backup or stored on a clustered FS itself or whatever. Since gitfs gives every client all the history, all clients have a record of all the versions. I'm tempted to set gitfs up and test it heavily, but I've only barely poked at it before now so I can't say how sturdy a solution it might turn out to be.

Something like NILFS2 or tux3 handles versions but only knows about the one file system. You gain storage reliability by putting it over something like DRBD to replicate the storage, but it's expecting to be a single master of that FS frontend.

So, yeah, it's easy to get either clustering with no single point of failure or to get file versioning. It's a bit more challenging to combine versioning with no single point of failure for the data storage. It may be a downright difficult problem to get the versioning itself to have no single point of failure.

Putting a distributed parallel FS that uses a local POSIX FS on each node, and then using a versioning file system on those nodes is, as I said in a previous post, not ideal. It makes versions on each of the storage nodes, but then your version browsing and restoration is on each individual node. A client app that connect to one or another backend directly, lets you pick a version to restore, then writes that back through the cluster may be a good enough work around in some environments.