Fetishes

Worst Hit Man Ever

My favorite story this month is about the hit man who was allegedly hired by a husband to kill his wife, a 51-year old nurse. The alleged hit man whacked the nurse with a hammer, which only pissed her off, so she strangled the hit man with her bare hands.

http://www.msnbc.msn.com/id/14859827/

It is all very tragic, and yet I am amused by everything in this story, starting with the fact that the husband's first choice was to reconcile with his estranged wife. His second choice was to have her killed with a hammer. That is a man who does not recognize nuance. I wonder how many people in his life have escaped close calls.

Husband: "Hey, Fred, do you have another beer?"

Fred: "All I have is some light beers."

Husband (thinking): I should kill him with a hammer.

My other favorite part of the story is that the hit man carried his alleged client's phone number in his backpack while on the job. I never attended hit man school, but I have to think they teach you on the first day not to keep your client's phone number with you on the job. And on day two they probably cover the basics of not letting yourself get strangled by the lady you are sent to kill.

I can imagine myself in the place of the nurse who did the strangling. Once you subdue a hit man, you really don't want to take the chance of him getting up no matter how much he's promising he won't do it again. It blurs the line of self-defense, but you have no real option but to finish the job once you start. And I suppose if a guy has just hit you with a hammer, you'd probably enjoy making his eyes bug out like a cartoon character. But maybe that's just me.

The other great irony is that the strangler is a nurse. I'd hate to be a future patient who recognizes her face from the news. I'd hold my pee for a week before I'd ask that nurse for a bed pan.

Amazon EBS - Elastic Block Store has launched

Today marks the launch of Amazon EBS (Elastic Block Store), the long awaited persistent storage service for EC2. Details can be found on the EC2 detail page, the press release and Jeff Barr's posting over on the AWS evangelists blog. Also the folks at Rightscale have two detailed postings: why Amazon EBS matters and Amazon EBS explained.

With the launch of the Elastic Block Store we complete an important milestone in offering a complete suite of storage solutions as part of the Amazon Infrastructure Services. Back in the days when we made the architectural decision to virtualize the internal Amazon infrastructure one of the first steps we took was a deep analysis of the way that storage was used by the internal Amazon services. We had to make sure that the infrastructure storage solutions we were going to develop would be highly effective for developers by addressing the most common patterns first. That analysis led us to three top patterns:

1. Key-Value storage. The majority of the Amazon storage patterns were based on primary key access leading to single value or object. This pattern led to the development of Amazon S3.


2. Simple Structured Data storage. A second large category of storage patterns were satisfied by access to simple query interface into structured datasets. Fast indexing allows high-speed lookups over large dataset. This pattern led to the development of Amazon SimpleDB. A common pattern we see is that secondary keys to objects stored in Amazon S3 are stored in SimpleDB, where lookups result in sets of S3 (primary) keys.


3. Block storage. The remaining bucket holds a variety of storage patterns ranging special file systems such as ZFS to applications managing their own block storage (e.g. cache servers) to relational databases. This category is served by Amazon EBS which provides the fundamental building block for implementing a variety of storage patterns.

I have written before about the basic features of Amazon EBS:

• Amazon EBS will be offered in the form of storage volumes which you can mount into your EC2 instance as a raw block storage device. It basically looks like an unformatted hard disk. Once you have the volume mounted for the first time you can format it with any file system you want or if you have advanced applications such as high-end database engines, you could use it directly.


• Developers can create multiple volumes, in size ranging from 1 GB to 1TB. This volume will be created within a specified Availability Zone and will be accessible by your EC2 instances running in that Availability Zone. As to be expected with a volume abstraction only one instance can have the volume mounted at any given time. Volumes can migrate and be reattached to other instances if necessary for failure handling or application migration reasons.


• The consistency of data written to this device is similar to that of other local and network-attached devices; it is under control of the developer when and how to force flush data to disk if you want to bypass the traditional lazy-writer functionality in the operating systems file-cache. Because of the session oriented model for access to the volume you do not need to worry about eventual consistency issues.

However Amazon EBS isn't just a massive volume storage array within an Availability Zone, it provides a unique feature that allows for the creation of novel storage management scenarios: the ability to create snapshots and store those snapshots into Amazon S3. These snapshots can then be used as the starting point for creating new volumes within any availability zone.

We see developers use this feature for long term backup purposes, for use in rollback strategies, for (world-wide) volume re-creation purposes. Snapshots also play an important role in building fault-tolerance scenarios when combined with managing applications using Elastic IP addresses and Availability Zones.

Congratulations to the EBS team for delivering a great service that will help a lot of EC2 customers managing their storage efficiently.

RFC 1925 (rfc1925) - The Twelve Networking Truths

RFC1925 - The Twelve Networking Truths

Network Working Group                                  R. Callon, EditorRequest for Comments: 1925                                          IOOFCategory: Informational                                     1 April 1996                      The Twelve Networking TruthsStatus of this Memo   This memo provides information for the Internet community.  This memo   does not specify an Internet standard of any kind.  Distribution of   this memo is unlimited.Abstract   This memo documents the fundamental truths of networking for the   Internet community. This memo does not specify a standard, except in   the sense that all standards must implicitly follow the fundamental   truths.Acknowledgements   The truths described in this memo result from extensive study over an   extended period of time by many people, some of whom did not intend   to contribute to this work. The editor merely has collected these   truths, and would like to thank the networking community for   originally illuminating these truths.1. Introduction   This Request for Comments (RFC) provides information about the   fundamental truths underlying all networking. These truths apply to   networking in general, and are not limited to TCP/IP, the Internet,   or any other subset of the networking community.2. The Fundamental Truths   (1)  It Has To Work.   (2)  No matter how hard you push and no matter what the priority,        you can't increase the speed of light.        (2a) (corollary). No matter how hard you try, you can't make a             baby in much less than 9 months. Trying to speed this up             *might* make it slower, but it won't make it happen any             quicker.   (3)  With sufficient thrust, pigs fly just fine. However, this is        not necessarily a good idea. It is hard to be sure where they        are going to land, and it could be dangerous sitting under them        as they fly overhead.   (4)  Some things in life can never be fully appreciated nor        understood unless experienced firsthand. Some things in        networking can never be fully understood by someone who neither        builds commercial networking equipment nor runs an operational        network.   (5)  It is always possible to aglutenate multiple separate problems        into a single complex interdependent solution. In most cases        this is a bad idea.   (6)  It is easier to move a problem around (for example, by moving        the problem to a different part of the overall network        architecture) than it is to solve it.        (6a) (corollary). It is always possible to add another level of             indirection.   (7)  It is always something        (7a) (corollary). Good, Fast, Cheap: Pick any two (you can't            have all three).   (8)  It is more complicated than you think.   (9)  For all resources, whatever it is, you need more.       (9a) (corollary) Every networking problem always takes longer to            solve than it seems like it should.   (10) One size never fits all.   (11) Every old idea will be proposed again with a different name and        a different presentation, regardless of whether it works.        (11a) (corollary). See rule 6a.   (12) In protocol design, perfection has been reached not when there        is nothing left to add, but when there is nothing left to take        away.Security Considerations   This RFC raises no security issues. However, security protocols are   subject to the fundamental networking truths.References   The references have been deleted in order to protect the guilty and   avoid enriching the lawyers.

Voting Machines