reminds me of http://www.endofworld.net/

Definitely retarded (see http://en.wikipedia.org/wiki/Hanlon's_razor).

Replicators in Stargate: http://en.wikipedia.org/wiki/Replicator_(Stargate)

ZFS keeps a history of the last 256 uberblocks in four different places in the pool. So even if all copies of the most recent uberblock got corrupted, it could still fall back to one of the older ones. You'd maybe loose the last few minutes of work, but that's not nearly as catastrophic as loosing the whole pool. It could fall back, but it doesn't, it rather panics the kernel. This is where a userspace fsck would help, for examply by giving you the choice to safely invalidate the last uberblocks. I was not feeling very comfortable when I wrote the dd/ud script that automated that task, but I had nothing to loose at that point.

The silent corruption was just an example. It doesn't matter what causes the corruption. But _if_ you end up in a situation like the admin or me, you have to resort to such ugly tricks to recover your pool. And that is something I'm not willing to accept on a production system - or any system at all for that matter.

Even if you have a 100% bugfree drive firmware, silent data corruption is still possible (resilience against silent data corruption is one of ZFS's selling points!). Filesystems that can't handle that simply have no place in todays world. The problem is that one flipped bit can cause ZFS to think that the whole pool is unusable - even though it keeps redundant copies of the metadata which it then completely ignores! What for does it keep the copies then?

Every disk will corrupt eventually, it's just a matter of time. Not even the best hardware will help you there. So the question is, how well does the filesystem catch these errors and correct them. It turns out, ZFS is really bad at this, as it can get into a state where you can't even import the pool (where zpool either stops with an error and in worse cases causes a kernel panic). There have been numerous bug reports on the zfs mailing list and the opensolaris bug tracker. So far nobody seems interesting in fixing those. My pool got corrupted in such way. I had to manually poke around the filesystem and invalidate metadata until zpool was able to import the pool. Something that a 'fsck' could have easily done, but Sun refuses to create such tool because, according to them, ZFS is robust enough. All credits go to this guy who had the idea to invalidate the uberblocks directly on the disk: http://opensolaris.org/jive/message.jspa?messageID=318457#318457

http://www.apple.com/safari/features.html - Safari 4 introduces the Nitro JavaScript engine, an advanced bytecode JavaScript engine that makes web browsing even faster. In fact, Safari 4 executes JavaScript up to 6 times faster than Internet Explorer 8 and up to 4 times faster than Firefox 3.1.

Of course two different users can't connect to the same screen session. That would be a big security risk. Look into /var/run/screen and you'll see that only you have access to the directory where your screen sockets are stored. Maybe it's possible to fiddle with the file permissions, but I wouldn't recommend it. Just create a new use that all the people have access to and tell them to use 'screen -x'