peat dot org

There’s a discussion going on right now on several prominent blogs: who should own the comments on blogging and forum systems? Is it the people who post the comments? Is it the people who run the blogs? What does it mean to own a comment, anyway?

These are interesting questions, but I think they miss the core issue that bloggers and commenters have mismatched expectations about what can and can’t be done with their contributions. Even when such issues are spelled out in terms of service agreements, the legal language is opaque to most of us humans who just want to discuss the issue at hand.

Creative Commons addressed a similar issue for communicating usage and distribution rights. It’s easy to use, accommodates a wide range of rights, and is legally vetted. A similar system could provide a convenient way to help bloggers and commenters communicate their expectations around how their contributions are handled.

I’d love to put a set standard icons in the comment area of my blog that make it easy to understand how I want to engage with the people who visit my site. For example: I allow comments to be edited by the author, I reserve the right to delete comments, and I don’t claim copyrights on comments.

The goal is to give visitors an easy way to decide whether to participate in a discussion.

Unfortunately, I’m not a lawyer, nor an icon guru, nor a prominent blogger — but I’d love to help anyone who is flesh out these ideas a bit more.

Interested? Feel free to leave a comment!

I’ve been talking with a bunch of people about releasing the next version of UpSale as an open source project, and I want your opinion on the matter.

We’ve managed to find a niche that doesn’t seem well served by existing open source projects — light weight ERP tools for small businesses that make and sell their own products. Our customers deal with the same sorts of supply chain, manufacturing, marketing, sales, and customer relationship issues that big companies face, but on a different scale, with different priorities, and restricted financial and technical capabilities.

I have a burning desire to see small upstarts upset the status quo, especially when it comes to local businesses with an eye for sustainable products. Stepping up and embracing open source makes a lot of sense for how we run our business, how we want to serve our customers, and empowers independent developers and the small business community as a whole.

All that said, there’s a lot that goes into sponsoring and building a successful open source project, and we don’t want to jump in unprepared. I’m poking my friends and colleagues to see what sorts of things make open source projects attractive and successful, and I’d love to hear from the folks who read my blog as well.

Your thoughts?

Do you have suggestions for what to include in a kick ass OpenSolaris AMI, geared towards deploying Ruby on Rails apps?

I’m working with the folks at Sun to build an Amazon EC2 AMI for Rails developers. The plan is to put together an environment that makes deploying production Rails apps relatively easy. My inclination is towards a Rails stack that includes Nginx, Mongrel cluster, Capistrano, MySQL and some common gems and services — maybe RMagick, and/or ImageScience? Memcached?

Let me know what you want, and I’ll see what I can do about it!

A few days ago I wrote about my initial impressions of the OpenSolaris on Amazon EC2 beta. It was a little frustrating, however, the people who are running the program at Sun got in touch with me, and we spent some time talking on Friday morning about the experience.

The upshot of the conversation is that I think they’re headed in the right direction. We worked through some of the IPS and documentation issues I was having, and chatted about what they’re working on over the next few weeks. Specifically, they’re in the process of building and releasing a set of AMIs built on OpenSolaris that target specific application environments — for example, GlassFish for the Java EE folks, or Ruby on Rails.

The first AMI they provided (ami-0c41a465) is just a blank slate, a trimmed down OpenSolaris 2008.05 installation. Those who are interested in the Apache/MySQL/PHP stack can tinker away by installing the ‘amp-dev’ package.

I finished the call feeling good about where the project is headed, and impressed by the people I spoke with. In fact, I’ve volunteered a little time to help put together the Rails AMI next week. If anyone has any favorite gems or other Rails goodies they’d like to see installed, let me know!

For more announcements about the OpenSolaris on EC2 program, head over to their blog at http://blogs.sun.com/ec2.

Looks like the fine folks behind Ignite Portland are looking for speakers for Ignite Portland 3. This is a great opportunity for anyone who wants to share an interesting idea with a theater packed full of enthusiastic Portlanders. I had a great time presenting at Ignite Portland 2, and can’t recommend it enough.

So, go sign up now!

I spent some time playing with OpenSolaris on EC2 this weekend, and I’m a bit disappointed — partially because of OpenSolaris, and partially because of how the beta program was set up.

But, good news first. I’m glad to see Project Indiana released, and EC2 is an easy way to take it for a test drive. All of the packages I tinkered with could be DTraced to my heart’s content, and it’s definitely a great improvement for debugging and monitoring of apps in the EC2 environment.

Bad news? First, all of the beta instances I booted were very slow. I’m sure this has to do with the provisioning of hardware for the beta program, and not with OpenSolaris itself. The beta servers are separate from the main Amazon servers, and I expect the speed will be on par with Linux when the beta period ends. Regardless, it does make the experience pretty frustrating.

Second, OpenSolaris openly touts their great package manager, but the selection of packages downright sucks compared to the Linux distros available on EC2. If you’re deploying anything more than a basic web stack on OpenSolaris, you’re going to be building a lot of software by hand, and that can be a frustrating experience on any Solaris.

Regardless, I could get PHP and Rails apps humming along just fine (although I’ve had a lot of practice). While OpenSolaris feels stable and DTrace is great, I spent way more time getting a system up to speed than I would have with Ubuntu or CentOS. The over-utilized servers didn’t help much either.

I do have hope for the future, tough. None of the issues demonstrated fundamental flaws in OpenSolaris or EC2, and I expect all of these problems to be fixed in time. The OpenSolaris team has obviously put a lot of work into this release, and I’m looking forward to seeing how the platform evolves.

One thing I haven’t been able to play with is ZFS. I’m interested in benchmarking ZFS on the persistent storage service, and a little excited to see what happens when several storage reservations are ganged up into a single ZFS pool … although I’m not going to go anywhere near that situation until the basic performance issues are resolved!

Update: I just wanted to clarify the package situation — the shortage of packages is only on the basic EC2 image for OpenSolaris 2008.05, not on the standard distribution you download from the OpenSolaris site.

Update: I had a follow up call with the OpenSolaris on EC2 team.  More thoughts here.

Almost all of the apps I build rely heavily on graphs — not pretty charts, but rather networks of people, places, things, or concepts that relate to each other in different ways. I’ve been looking for alternatives to standard table oriented relational databases, and the most interesting project I’ve found so far is Neo4J.

The concept behind Neo4J is simple, and it’s relatively easy to get started with if you’re comfortable with Java. The basic semantic concepts you work with are nodes, relationships, and properties. For example, Peat (node) is friends (relationship) with Howard (node). Nodes and relationships both support freeform key:value properties, so I could set a birthday on the Howard node, or a note about how we met on the Friend relationship. Very simple and flexible.

The real power in Neo4J is in it’s traversal system — complex graphs are pretty useless without being able to pull information out of them, and SQL based systems pretty much suck at handling complex queries through nested or recursive structures. Neo4J’s “traversers” are much simpler to build, and feel pretty darned quick.

What I’m really enjoying is the simplicity of the system. The API only describes 12 classes, and there’s only 3 or 4 you need to be familiar with. The jar file weighs in at under half a meg. The “hello world” example is readable straight out of the gate. There’s even a command line shell for exploring your data. Simple concepts. Easy to learn. Small foot print.

Pretty cool stuff.

If your work involves designing and building systems that rely heavily on relationships, Neo4J is definitely worth checking out. Caveats? As of May 13th, it’s still in beta — but it looks like the 1.0 release is around the corner.

Well, after two (good) years with wordpress.com, I figured it was time to bring peat.org back home.  I wanted more control over the layout and code … and it’s just more fun, anyway.

So, update your bookmarks and your feeds!

Blog — http://peat.org/

RSS — http://feeds.feedburner.com/peat/

I ran across this error message when I made a slight mistake when booting an OpenSolaris image on EC2:

Client.InvalidParameterValue: Invalid value 'solaris.indiana' for kernel profile.
Supported values are [default, solaris, freebsd].

I’ve been waiting for this since EC2 was announced. Anyone have more information on the status of FreeBSD on EC2?

Interesting news this week — along with the release of Project Indiana, Sun is also providing limited access to OpenSolaris images running on Amazon’s Elastic Compute Cloud. I’m keen to try it out, but at the same time I’m a little skeptical about the whole thing.

I have high hopes for Project Indiana. After working with Joyent Accelerators, there are a lot of things I like about Solaris (the service manager, ZFS, DTrace, etc.) and a lot of things I don’t like (awkward package management, very DIY for relatively simple things).

Indiana running on EC2 instances is a good way to introduce people to the platform, but it’s a bummer you have to register with Sun and get their permission before jumping in the pool. I hope the waiting list isn’t too long. I’m itching to play.

Hopefully Indiana on EC2 is lean, mean, and easy to get started with … but I have my doubts that it will be a replacement for my current Ubuntu AMIs. I don’t have any super custom configurations, I just don’t think EC2 isn’t the kind of environment where Solaris really shines — EC2 is lots of little servers, not a big box with a bunch of cores and spindles. Regardless, I’m an optimist, and I look forward to being proven wrong.

I’m waiting on access to the Project Indiana AMIs. I’ll report back as soon as I get my feet wet.

Update: I’ve been accepted to the beta program, but I don’t think I can do a test drive until this weekend. More information then!