Bits on Bytes bits on solaris, programming, and all things tech

This blows my mind every time I read it.

ZFS has been designed from the ground up to be the most scalable file system, ever. The file system itself is 128-bit, allowing for 256 quadrillion zettabytes of storage. All metadata is allocated dynamically, so no need exists to pre-allocate inodes or otherwise limit the scalability of the file system when it is first created. All the algorithms have been written with scalability in mind. Directories can have up to 2⁴⁸ (256 trillion) entries, and no limit exists on the number of file systems or number of files that can be contained within a file system.

Source: ZFS Administration Guide

Does anybody else out there hate the fact that if your Gmail label is too long it gets cut off? I thought Gmail supposed to be up with the times. Would it kill them to have fluid column widths?

For example, my indiana-discuss mailing list label gets cut off just before I can see how many unread messages I have. It’s annoying. Stupid color boxes, I don’t even use them.

I am now officially addicted to TrackMania United. If you have a Steam account I highly recommend you get this game. You can also play TrackMania Nations for free if you wanna try it out first.

My purpose for doing this was to automate file transfers between servers. So I needed a secure copy method (SCP) without prompting for a password (SSH keys). I’ll call my two systems production and backup. I need to be able to ssh from production to backup without it prompting for a password.

On production generate your private/public key pair:

chris@production ~$ ssh-keygen -t dsa

Generating public/private dsa key pair.
Enter file in which to save the key (/export/home/chris/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /export/home/chris/.ssh/id_dsa.
Your public key has been saved in /export/home/chris/.ssh/id_dsa.pub.
The key fingerprint is:
bd:cf:bb:c0:30:1c:c3:5f:74:80:3b:f0:1f:82:20:bb chris@production

Put the public key file (id_dsa.pub) on the remote system you will be ssh’ing to as the authorized_keys2 file in the .ssh directory of the user you will be using to ssh:

chris@production ~$ scp ~/.ssh/id_dsa.pub backup:.ssh/authorized_keys2

Or append it if you have a preexisting authorized_keys2 file.

That’s it. You should be able to ssh from production to backup with whatever password you entered in the key generation process (or none if you didn’t enter one).