phinze

Hey author here - I'm super interested to see if this way of slicing up the design space resonates with anyone.

As someone who has been in and around distributed systems for many years now, I do feel like we're cresting into a new generation of system design that tries to take into account the lessons of the last one. This question of how we reduce centralization of risk while retaining our ability to distribute safety fixes is a rich one I think.

Just had DNS trouble from Chicago. Switched to openDNS.

Just ran through this and quite enjoyed it. It's very different from "A Tour of Go". I really like how he creates a narrative out of test failures. It's by no means effective as a sole source for learning Go, but I'd recommend it to those who have completed the Tour as a way of getting more practice working with Go's various data types.

> What is the difference between the cask installation suggested in the link and the cask installation procedure suggested on the cask home page?

Two differences. One is that we moved to an org repo, so the first form is relying on the github redirect from the move. The other is that the second form relies on the semi-recently introduced "auto-tap" syntax in homebrew.

Functionally they will get you to the same place (we've got code to notice that your remote is pointing to the old repo location and update it), but the second form is newer and cooler. ;)

Hiya - author here. Thanks for the feedback on this stuff! It's always good to hear where it's best to focus improvements.

I'm going to address a few of your points specifically.

> There are no upgrades, in many cases it doesn't work.

It's true that `brew cask upgrade` is not yet a thing. I would very much like it to be. I've been sort of avoiding work on the feature for fear of messing it up. But that's no reason to not try to make something work! :) Maybe I'll use this as an occasion to start digging in and getting my hands dirty.

> At the end of the day, it duplicates some of the Homebrew functionality - some non-GUI packages are getting into Cask, because possibly Homebrew doesn't want them - it's a bit confusing as well.

If the purpose of the project is not clear, that's definitely a problem. I'm not aware of many (any?) purely non-gui apps making it in to Cask. The `Homebrew/homebrew-binary` tap is the place for those. I'll go review our included Casks to make sure things are clear.

> I think efforts should be put into merging into Homebrew instead of keeping it separate.

I can understand this opinion, but I think we may actually end up going in the other direction. The places we share code with Homebrew have been the biggest problem areas for us. We are already 90% code independent from Homebrew, and I think moving Cask to its own world may benefit both the project and the users. But of course that's a conversation to have with the (amazing!) project team.

Alas there is not AFAIK. For all the research I've done on this, the only conclusion I've been able to draw is that the MAS is anti-automation (if not in intent, at least in its current design). :(

> I just want the applications to be copied to my install location and left alone.

If it's a use case that would be useful to people, this is a mode of operation I would definitely be willing to include in the project. Feel free to open an issue (or even better - a PR!) with the idea. :)

> Quite a few of the apps I use (iTerm2, ST3, Chrome, Adium, etc.) update themselves periodically. I wonder how Cask deals with that?

Sparkle-based self-updating apps will self-update in place. For apps like that, the current policy is to have a Cask version of 'latest', and letting the apps self update.

I've been doing this for some time and I've found it works out AOK. It's nice to be able to click the "Update & Relaunch" and know I'm not messing anything up. :)

Amen to that! Our project is actually independent of the Homebrew team, but we very much model ourselves on the great work they're doing.

In my experience, a day spent pairing, while generally a sort of intense experience, is also filled with little breaks. Your pair gets up to grab a drink; you check your email; somebody turns on a Katy Perry single and you spin around to join a team-wide argument about its merits; etc, etc. :)

While nearly 100% of your time is _dedicated_ to pairing, I'd say the percentage of time you both spend actively sitting at the computer working on a task is roughly equivalent to what you'd do as an individual. Which is to say, it varies. But it never really feels like you can't do side things; the vibe is very flexible and casual.

For deploys and emergencies, it's almost always a pair attacking the problem. Even if just one developer is doing most of the driving, the pair is still able to learn, catch typos, diagnose, etc.

Meetings can definitely end up splitting pairs, which becomes yet another incentive to try to minimize them.