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.

I doubt my life will ever depend on the OP's needs of a versioning distributed filesystem.

If I had to pick some combination out of that which I've seen work well with my own eyes, I'd share NILFS2 over CIFS or NFS, possibly with DRBD underneath LVM underneath the NILFS2. I've never done that exact combination. I have run NILFS2 on top of LVM, and I have run DRBD underneath LVM. I've shared lots of things, including NILFS2 and various other FSes on LVM over CIFS and NFS. I've never done DRBD under LVM with the NILFS2 filesystem on top, though. I wouldn't be scared to recommend testing it, but I wouldn't rush it into production that way.

Contrary to popular rumors, there are a number of ways to do what you want. I can't vouch for all of these combinations working and wouldn't be too optimistic about tackling some of them. The more advanced stuff can take quite a while to ramp up to speed.

If you don't mind FUSE as an intermediary, there's gitfs that uses git as a file system (which is kind of is anyway, beyond being just a VCS). It creates a new version on every file close. You can point it to a git remote on the same machine or across a network which lives on any filesystem.

You already found that there are some non-mainline kernel modules for filesystems like next3, ext3cow, or tux3 that do versioning on write. NILFS is actually in the kernel these days (since 2.6.something) . More information about NILFS2 shows that it's somewhat slow but that it is in fact a stable, dependable file system.

Subversion has a feature that you can put WebDAV in front of it, mount the WebDAV as a filesystem somewhere, and every write creates a new revision of the file in SVN. That gets you networked and versioned. This works similarly to gitfs but uses WebDAV. You could if you wanted use dav2fs in front of that to treat it like a normal file system again.

You can then share any of these over SMB with Samba. Or you can shared them via NFS.

If you need really high-end, fast, replicated network filesystems you can use any of the clustered storage systems that will use a storage node's underlying files with any of these below that, but that will put your revisions underneath everything else rather than on top. Then there's using something like gitfs with the remote on top of, for example, DRDB, XtreemFS, or Ceph (for example even across CephFS which presents Ceph as a normal POSIX filesystem). This latter option puts your revisions closer to the user and then each revision gets replicated.

I've personally never used some of the more exotic combinations listed here. You could in theory put NILFS2 on LVM with DRBD as the physical layer (since DRBD supports that) and then serve that file system via Samba (CIFS) or NFS which I would expect to work well enough if slowly.

Obviously you're going to have to have a line connected already to have long distance service on it. Voicemail or caller ID are generally among those "select services" in the US. I would imagine if we spent all day digging through the fine print it's not that big a deal.

Well, if someone really wants to pay by the minute instead of $10 per month for unlimited to Canada and the US or $37 per month for unlimited calls to almost anywhere in the world it's either because they almost never call outbound long distance or they're not very bright.

I wouldn't consider that plan to be the baseline cost. Most people are going to pick unlimited.

Yeah, buddy. I'm still paying $10 per megabyte for my hard drives and $50 per megabyte for my RAM. My cell phone still cost $7000, and my long distance calling is still $0.25 per minute.