aolnerd

yeah, felt that at the shore

We're looking for even cheaper bandwidth for streaming audio. Can anyone recommend a vendor to provide 150mbit+ bandwidth on a vps platform or rented server platform?

FWIW, I'd love to see support for icecast or shoutcast streams.

Thanks to all contributed to this clever hack. MP3 on all browsers, without flash, is a really worthy goal.

But I'm hearing sputtering, myself. Are you guys going to carry this to a production-capable system?

Those docs refer to ephemeral storage. I haven't seen any claims by Amazon or test results that indicate it is also true for EBS volumes. I have been meaning to test this myself.

Another thing to consider is that EBS offers snapshot backups and is therefore not functionally equivalent to the ephemeral disk which is not durable.

Ephemeral disks offer more predictable performance, especially on the largest instances, however they will not provide the random iops of a raid set of EBS volumes.

Do you RAID them? What size instances do you use? EBS seems susceptible to poor performance when there is contention on your instance's shared network card or contention on the EBS device itself.

Vacuums use sequential IO, so it makes sense that you max out pretty quickly.

Nice work. It would be nice to know which projects have production sites that store the primary copy of data in these projects, as opposed to a secondary copy that is used for fast reads.

I signed up for a newegg.com alert and immediately purchased a 160GB X-25M g2 for ~$450 minutes after they announced they had stock. I put it in a late 2006 mac mini (1.8GHz Intel Core 1 duo) and it has transformed the feel of the computer. There are far fewer pauses. Big apps launch instantly. Extremely satisfying.

The only problem is that it started reporting S.M.A.R.T. errors.

keep multiple snapshots so that you can recover files after you delete them yourself.

#!/bin/sh

AWS_ACCESS_KEY_ID=<>

AWS_SECRET_ACCESS_KEY=<>

BUCKET=<>

DIR=<>

S3SYNC=/usr/bin/s3sync.rb

DAYS_TO_KEEP_BACKUPS=30

# colons in path confuse s3sync

DATE=$(date +%F_%H-%M-%S)

NEWEST=$(/bin/ls -r $DIR | grep -v current | head -1)

# copy the newest copy of files into a new directory, creating hardlinks instead of duplicate files

cp -al $DIR/$NEWEST/ $DIR/$DATE/

# sync the s3 bucket against the new directory

$S3SYNC --recursive --make-dirs --delete --no-md5 -v $BUCKET: $DIR/$DATE/ 2>&1 | grep -v 'Could not change owner'

# update the "current" symlink link

test -e $DIR/current && rm $DIR/current

ln -sf $DIR/$DATE $DIR/current

# remove snapshots older than DAYS_TO_KEEP_BACKUPS days

find $DIR -maxdepth 1 -type d -mtime +$DAYS_TO_KEEP_BACKUPS -print0 | xargs -0 --no-run-if-empty rm -rv

it's analysis, not an advocacy for a bubble

http://krugman.blogs.nytimes.com/2009/06/17/and-i-was-on-the...

I find that xargs is the most convenient way to achieve parallelism for quick and easy batch work. Just write your script to receive its unit of work as a command argument (or as multiple args if starting a process is a heavy operation). Use any language. Utilize all your cores.

You are of course correct, but that's not related to what I'm getting at.

My question raised the point that the server would not be able to tell the difference, after an interruption, between session state that the client will hope to resume and session state that should be discarded. That state would accumulate until some routine cleared it out.

When you start a local shell, you can generate some session identifier (export DURABLE_SESSION=$RANDOM) and put it in your environment. Then have your ssh client send it to the server with "-o SendEnv DURABLE_SESSION".

One question is when does sshd know when to ditch interrupted sessions.

Last-Modified: Fri, 01 Dec 2000 21:15:34 GMT