But if you're talking specifically about shell or a "native" REPL in a safer language - I also want to scratch that itch. Some day I'll dust off https://github.com/vito/dash :)

During that investigation you discover things (like having to implement your own components) and try to account for how much they'll subtract from the time and energy you save. If the calculus works out, you keep going. If it doesn't, you stop. We kept going, and now we can ship complex features and optimizations to both UIs within a day or two.

For a long time now we've been primarily focusing on the core design, concepts, and architecture at the expense of documentation and introductory material and outreach - we've never had a dedicated technical writer, so documentation is really best-effort. Now that the dust is settling on our roadmap I feel a lot more confident in increasing our focus on onboarding, operability, and developer/user experience in this coming year. :)

Our CLI hasn't really aged well and that's something I'd like to address soon - probably going more in the direction of config files instead of flags/env vars. It'd be a lot easier to document with a proper schema. Thanks for the feedback and sorry the experience is still pretty rocky!

Funnily enough if you leave the tab in the background, the events queue up and when you tab back there are a bunch of cards bouncing around at once: http://i.imgur.com/dNObRGb.png

https://github.com/vito/garden-systemd

I should probably add a warning above the BOSH section though, or even the binaries section.

The trouble is, reality is complicated, regardless of whether it's documented or not. I've found that a lot of open source projects simply don't document things to give an illusion of simplicity; people just forget all the manual labor they had to do after downloading that .deb and installing it across 10 machines and maintaining those machines over time. Our docs cover BOSH as our preferred tool for clusters. If you don't want to use BOSH, just use the binaries and your own deployment tool.

We don't build .debs yet; as soon as we do other people will want .yum, and another will want Docker images, so we built the binaries that will feed into those first, which is often what I look for when kicking the tires on something anyway.

There's a proper Garden Windows backend in the works which we'll switch to at some point once we better understand it: https://github.com/cloudfoundry/garden-windows

Workers are just machines running a container management daemon (much like a Docker daemon) and a volume manager (a custom daemon for managing caches and efficient artifact propagation between containers). Not sure how you got to Cloud Foundry though, it's not really related. Garden lives in the Cloud Foundry GitHub organization, as it's also used by Cloud Foundry, but you don't need to know anything about CF to use Concourse.

Concourse supports Linux, Windows, and OS X. You can see an example of this here:

https://ci.concourse.ci/pipelines/main/jobs/fly/builds/2621

https://concourse.ci/downloads.html

I find these approaches better than risking test pollution, especially when it comes to building VMs and spinning up desktop apps.

For example, [Guardian](https://github.com/cloudfoundry-incubator/guardian-release) is in the works to replace the Linux backend with a thinner runC-based backend.

The main value we get from it is having a nice Go API and not having to overhaul everything using Garden every time some shiny new container tech comes out.

I think the next step from us may be to start building Vagrant boxes that just spin up a worker, parameterized with credentials to register with a Concourse `web` instance. That way you can run Concourse on OS X for iOS testing/etc. and still have all your resources and Linux containerization when you need it via a tiny local VM.