DougBarth

If I'm reading this proposal correctly, locks will still be needed within multithreaded guilds to guard mutations against complex object graphs.

Here's my reasoning. Since the GVL is insufficient to guard against data races on Ruby 2, under the guild system, locks would be needed to guard against concurrency issues if multiple threads are present.

It would seem like the intention would be to replace usages of Thread with Guild to avoid the concurrency issues inherent with threaded code. Will there be API support to create a Guild that only allows a single thread?

I can answer only some of these questions. :)

Why not upgrade Xen? We run on cloud VMs, so we aren't in control of the version of Xen that's being used. Patch the kernel? Honestly, we don't have the expertise to take on that level of effort. We're hiring though. ;)

It was indeed. We poked at this issue off and on for several months by multiple engineers before figuring it out.

Nice. We'll be doing the same shortly.

How many nodes did you deploy? Are they within a single DC or cross WAN? Do your clients write to all nodes, or just one? Basically, how much can you share about your topology?

heh, well, that's a bit harder /c most of our team is remote, but you're right. John, you get a cookie on Friday!

Nice work John! My favorite feature is seeing a graph of historical run time. Really helpful to figure out how a job is doing performance wise.

We've been using Puppet to manage our servers for some time now. As a group of developers doing our own operations work, we've found puppet both good and bad.

Setting up puppet was relatively straight forward. We had the puppetd auto-updating our servers for a while, but ultimately decided to manually run it when deploying changes. Managing zero-downtime changes was more error prone with it running.

Some aspects of Puppet have over time proved frustrating to us. The top annoyance is we never quite figured out a good way to test our puppet changes before checking them into git to deploy them to our puppetmaster. That has lead to a number of "fixing errors" type commits. The second annoyance we've found is actually highlighted as a feature: no implicit ordering of operations. While it might sound great to be able to reorganize your configs without fear of breaking the deployment, we've found that the tradeoff is that you don't find out that your configuration doesn't define its dependencies correctly until you try to kick a new server after spending months incrementally adding to your existing servers. For us, at least, having an implicit top to bottom ordering would lessen that headache.

Despite some of these headaches, simply having our configuration in version control is a huge win for us. We can setup a box much more easily, and we have a comment trail of why changes were made.

I work at Signal with John. I hadn't heard of GeoCouch before, so thanks for the tip. The service that uses Mongo isn't core to our application, so we're probably unlikely to change. MongoDB has been working quite well for us so far.

We integrated PagerDuty with scoutapp.com and pingdom.com. Works great.

It's visually improved, but functionally, it's not much better and in some ways, worse.

Besides the lack of mobile support, looking at train schedules is not more difficult. My preferred stop is only in service on certain routes. Therefore, depending on the time, I may need to use a different station. Determining my options requires two tabs and mental comparing the departure times.

A coworker who rides the express trains out of the city noted that there is no indication of which departures are express, leaving one to do the math to see if their ride will be 20 minutes or an hour.

Awesome. This is so much better than Metra's own site.

A nice addition would be cross reference their service updates for any delay information.