lusis

Yep. I got in on the RHAT F&F deal thanks to some bug reports and a patch here and there.

I made the stupid mistake of allowing coworkers to buy some shares through me but I wasn't fully aware of the tax burden. Basically everything I made myself went in to paying the taxes on everyone else's shit. What little was left I had to give to my family to help with other bullshit.

That's not what I'm saying at all. In fact I was pretty clear about that fact.

What I said was that I, personally, am going to be writing more personal tooling in Go. I was pretty clear that our team is NOT switching off Python. It's in the last section entitled "This isn't a switching story"

Graylog2 only handles syslog and its own protocol (GELF) for accepting log events. Graylog2 uses ElasticSearch for data storage. Logstash can use ElasticSearch or just send the data elsewhere.

The Graylog2 web interface is pretty awesome and it has some neat stuff built in. Logstash ships with a fairly spartan web interface though we're going to replace it with a ruby port of Kibana in the future.

Logstash can accept data from GELF senders (via the gelf input plugin I wrote) or send to gelf receivers (like Graylog2).

Graylog2 is awesome, don't get me wrong. I just had to bail on it when it was still on MongoDB because I couldn't justify the cost of instances needed to get a MongoDB instance that could hold more than 4 hours of data.

Logstash and Graylog are complimentary. Most people, myself included, we're originally using Graylog2 in conjunction with Logstash.

Graylog2, though, had problems with it's original implementation based on capped containers in MongoDB. It has since moved to ElasticSearch.

There are both gelf inputs and outputs for Logstash so you can send your logs to Logstash as if they were going to Graylog2 and do additional munging and still send them out to Graylog2 from there.

You might underestimate the size of deployments of logstash. Mailchimp runs logstash in a pretty sizeable cluster for all traffic coming into HTTP front-ends. I can think of quite a few sizeable logstash installs that I can't mention.

Please don't call logstash "an open source splunk". It's no such thing. Splunk still has features that logstash doesn't have (yet). Logstash has quite a few features that Splunk doesn't have.

Jordan had never seen (or to my knowledge has yet to see) splunk at all. I don't know about Pete. Myself, I haven't used Splunk since trying a very early release once in the very first days of it.

Point being, Logstash doesn't call itself an "open source splunk". In fact I've considered adding an output to SplunkStorm to Logstash.

Do I think Logstash is better? Yep. Do I know people who swear by Splunk? Yep. Competition is healthy.

This is why my vpn setup is done via Rackspace. I gave up fighting this backwards ass approach to the problem.

Got a really good shot last night playing outside with the kids:

http://yfrog.com/o03xqzsj

Not bad for a cellphone camera.

Oh wow. I didn't realize until postrank told me that my post had made it to HN. I'll answer some comments below (and I have another post in the works.

The problem is people are still confusing two issues.

1 - The mass assignment rails issue was resolved as soon as could be after it was reported 2 - The public key form update vuln was NOT reported and used, NOT to attack github but to make some point to the Rails team.

The second issue was the one github had been talking about in the original blog post. They handled it as soon as it was discovered.

In so far as they responded as quickly as possible, yes they had it in hand.

For those who don't know, nats is at the core of cloudfoundry. It's a great tool if you're in an all ruby world. The author wrote messaging software for Tibco before vmware so he knows his stuff.

Having said that, 0mq is probably a better choice these days since it's cross language. Still you can build some fun stuff with nats.

We had a discussion about the original blog post over on IRC.

I'm not going to tone down my talks (unless it's inappropriate for the audience) but I normally won't include it in a slide. There's a difference for me verbally and putting it down "on paper".

I want people to pass around my slide decks. A slide deck full of vulgarity is probably not going to get passed around. However I probably cussed like a sailor during the same presentation.

Good to see a local gang representing!

TMTOWTDI.

Ruby, for all the problems it can cause, gives you. More than one way to solve a problem. Yes, it sometimes makes it harder to dive into other's code but I happen to enjoy the expressiveness.

Mind you I love some of the things about python too. Namespacing being one of the primary ones. Another is that, short of advances pythonfu (like django does), I can usually pick up someone else's code and dive right in.

Python has amazing access to mathematical and scientific libraries as mentioned. However with ruby, I would punt to the Java ecosystem via JRuby if I needed that.

It's a lot like design patterns. Some patterns don't fit in all languagea but that's usually a case of the language itself giving you another way. Mixins in ruby are a good example.

This is a horrible idea. Detecting things like publish date is incredibly difficult. I can totally understand the aversion to wanting to generalize tags but this one is, IMHO, appropriate.

IMHO, the thing that bothered me about the whole exchange was that it could have been avoided with a little bit of common courtesy. Instead it turned into a "oh let's go roll that pull request".

I picked up pretty early on that antirez wanted to know the "why" first since one of his stated goals was keeping deps to a minimum. What could have been a nice productive discussion about crypto standards was fucked up by ego, asshattery and language barriers.

Oh and github pull requests are TOTALLY the appropriate place to have those kinds of discussions =/

Feel free to correct me then. I have YET to work anywhere in any industry (financial primarily) that stated we had to have specific hardware up and running as part of an SLA.

It's an "SERVICE LEVEL AGREEMENT" not a "SERVER LEVEL AGREEMENT".

You don't need to "understand" why someone would use Android anymore than I need to understand why someone uses iOS.

But if it helps you sleep at night, I simply dislike iOS. I dislike the UI. I dislike the keyboard. I dislike the interface (non-UI stuff).

I enjoy using android much more.

Rollbacks are a myth. You can never rollback. Always be rolling forward. Enabling a culture and environment that allows for small frequent changes solves that problem.

The way to not impact a customer is to make deploys trivial, automated and tolerant to failure because everything fails.

Triviality has nothing to do with it.

Nothing in your SLA says you have to have servers 1, 2 and 3 available. It says you have to have service X available. You can do that with out taking a downtime hit.

There is a better way. It's to stop deleting and start deprecating. Write your code in a backwards compatible way. If your storage engine, whatever it is, can't handle it then switch storage engines.

The author makes some amazing points that I'm surprised intelligent people are missing.

Let me give an example. We are currently migrating from storing blobs of data in Voldemort (a key/value store) to storing them in S3. They should have never been in there in the first place but whatever. We're going to do it with "zero" migration time. In fact we're already doing it.

- Set up a job that copies existing data in Voldemort to S3.

- Deploy a minor release of our code that multiplexes the current writes to both Voldemort and S3.

- Continue migrating existing data

- When existing data is finished migrating, deploy a new release that forces all traffic to S3 instead of Voldemort.

- Profit

People need to learn to do things like dark launching and feature flags. Dark launching let's you exercise new code paths with no impact to the user. Feature flags give you the ability to enable to features to some or all of your users. Feature flags are awesome ways to A/B test as well.

People need to stop doing stupid shit like redefining what some property means mid-release and instead define NEW properties and deprecate old ones in subsequent releases.

Same goes for schema changes. If some part of your code base cannot tolerate an additional column that it doesn't need, that's a bug.

You can also adopt some configuration management that allows you to provision duplicates of the components you're deploying so you can swap back and forth between them in the case where you might have a breaking release. That's what we do and it's one of the upsides of using EC2.

All of this requires discipline and dedication but the benefit is so worth it. You have to stay on top of dependencies. You can't let bitrot take hold by going 4 major revisions without upgrading some package. We did and it bit us in the ass.

This is why we adopted the swinging strategy of duplicating our entire stack (takes about 30 minutes depending on Amazon allocation latency) on major upgrades.

It's not so much what I consider to be missing as what others don't seem to be finding in them that encourages them to bolt on functionality into "incompatible" tools:

http://blog.lusis.org/blog/2011/08/22/the-configuration-mana...

A little while ago is a bit of a stretch. BOTH communities have moved far and beyond the state of things in that article.

The fact of the matter is that X vs. Y is ENTIRELY subjective. It isn't a sporting event where there's a clear cut way to call a winner.

Some people like Puppet. Some people like Chef. Anyone trying to decide between ANY software - whether two competing client libraries or something as critical as configuration management owes it to themselves and the company to try all the options. The one that's best is the one that encourages you to adopt configuration management.

CFEngine is the "granddaddy" of configuration management. It's been around something like 17 years at this point.

CFEngine spawned Puppet spawned Chef (rougly speaking)

I never got involved with BCfg2 or lcfg so I don't remember the history behind.

The correct answer to this entire question is "yes". Use whichever tool encourages you to adopt proper configuration management.

Yes, there's a gap that the current crop of CM tools don't address (and why we see new versions of capistrano clones with a bit of system management sprinkled in) but the three major tools right now - Puppet, Chef and CFengine are all at a state where they address 95% of the use cases for system management and automation.

If you are unhappy with Merb then convert it to pure rack or sinatra and send a pull request. It works and it's seriously as low of a priority as I can imagine. The server is nothing more than an API endpoint. You can (and people have) rewritten the entire server component in Python.

I can't recall the name off hand and my googlefu is failing me but there's a theory that says a system that supports multiple political parties eventually evolves (or devolves) into two parties.

I think there's a business correlary as well.

Markets aren't designed to support more than one or two players. There's not enough market share in a given space for it. Eventually you'll have first, second and everyone else. The people in first and second may change but there's always a disproportionate market share between number 2 and the rest of the pack.

You might want multiple COMPETITIVE players but you will rarely see it. Eventually the minor market folks will quit because it makes no sense financially to continue in the space.

The article covers it but those are different C-based Ruby VM implementations:

- 1.8 is MRI

- 1.9 is YARV

- 1.8 plus performance patches is REE

Well in my case I have a rule. I don't friend anyone on facebook I've never met personally of that I'm currently working with. Everyone is pretty understanding about it.

I think I've found a healthy balance. I don't use twitter for generally personal stuff (except for the occasional twitter commiserating with other parents) and I don't use Facebook for any technical stuff.

My blog is mostly technical and the only place I'm even linked to the company I work for is LinkedIn.

I don't HIDE that fact that the two "personas" are connected but I try to keep a separation in place. My family and most of my friends don't care about the technical stuff and most of the people in the various OSS communities could give two shits about my kids pooping in the potty.

Shit, I've even got two about.me profiles.