Back to top


Greggles, Gregorybeans, Frijoles, Beans

Software management on Mac: Why is it so bad for users?

Compare all these different ways you have to install and update software on Mac:

  1. The app store - obviously this is what Apple wants, but they have rules about what can and can't go there and the rules don't match the rules their customers want (e.g. easy in-app purchases) but instead what Apple wants (more money).
  2. Download software from a website and install it. This works OK, except that the vendor has to get a key that is verified by Apple (which has its own legal paperwork for the developer to pretend they read). If they don't get a key then the user has to follow this Apple knowledge base article that includes advice to control click, use the context menu, answer a dialog and then it will work. That was simple, right?
  3. If you downloaded software from a website, it might update itself (For me, Sublime, Source Tree, and Adium all do this). OR, you might have to periodically go back to that website and see if a new version is available and then download and install it (Looking at you, Dropbox).
  4. Homebrew, Macports, etc. What is this, Gentoo? Since when is compiling source all the time a user friendly idea.
  5. My favorite scenario? When I need to get software X which comes via one channel. But I have to also get something it requires which comes via a different channel. Rough.

The App Store is clearly the most user friendly option, but as a user or developer I have no control to adjust its behavior. I can't say "Get stuff from the official Apple channel but also get new software and updates from the Dropbox website.

Glossing over the issues with unsigned packages, having a variety of different methods to install software that are inconsistent with each other means I have to spend more time remembering and researching the software.

People Involved: 

Why I Love working at

For the past 1 year, 1 month, 1 week and 1 day I've been working at I love it. I've had a lot of great jobs in my career so far, but this is one that is truly extraordinary.

I'm currently pretty enthusiastic about a set of quotes from Jeff Bezos compiled at, so I'm sprinkling some of those through this post.

What is doing?

Our CEO put it like this in a recent interview he gave: is the world’s first likeable financial company. We make payments fun, fair and fashionable. offers Visa cards and MasterCard cards featuring card art and amazing perks from the best brands in the world, like Star Trek, Elvis or The Walking Dead.

And...that's a good description of what we do. But, what do I think we're doing that is exceptional?

  • We're using a ton of open source software and contributing back where we can. That just warms my heart :)
  • We're doing everything with an eye towards scalability. We have a lot of card designs and many more are coming. Some of our designs are big and some are small. We still want to delight the people with a "small" brand because to them that brand is their life.
  • Bezos said "Your margin is my opportunity." and we're following that. We aren't aiming to be the cheapest provider, but we are undercutting a lot of other providers with what we believe is a much better product. That will help us scale and as we scale big we win. It feels great to provide a product that is competitive with other options available to our typical cardholder.
  • Since we're scaling big, we sweat the small stuff. We review contracts to see how we can squeeze pennies or fractions of pennies out of different transactions.
People Involved: 

Warning: 100% uptime (or 99.9%) is a marketing trick - don't fall for it

We recently were reviewing proposals from two vendors. One vendor claimed 100% uptime. Another vendor claimed 99.95% uptime. Our SLA to customers is below both of those numbers, but 100% feels better than 99.95% right? So we should go with 100% right?

My experience is that the uptime number in an SLA is purely for marketing purposes. Pure. Marketing. Purposes. If you read 100% and think the service will be online for 100% of the time? Shame on you.

The really important thing is the detail behind the SLA. Here are a few tricks I've seen that make a 99.999% SLA roughly worth nothing.

  • What are the exclusions? Most service providers are hosted somewhere (Amazon? Physical space?) that has it's own uptime guarantee. If that provider goes down is your SLA still in effect? Many SLAs exclude acts of nature like a hurricane that can take down a single provider.
  • What do you get when the number is broken? Some contracts give you a credit. Some give you cash. Some give you a credit that is worth your monthly cost multiplied by the percent of time they were offline. Is that worth much to you?
  • Do you get more if the outage is persistent? If a service dies for an hour that's a problem. If it dies for a day that is horrible. I want to be compensated more if the outage is prolonged.
  • Whose monitoring counts? What kind of monitoring? I've had times where my monitoring (Pingdom) showed a site was offline for hours, but internal monitoring showed it was fine. I got no credits.
  • What counts as "down" - if the service is online but taking 10 times longer than normal to process requests, is that OK? What if the service is online but network connectivity is degraded?
  • How are periods of downtime calculated? An SLA I read only counted a full hour of continuous downtime as real downtime. Many outages are 10 minutes here, 20 minutes there. I want to be compensated for those as well.
People Involved: 

Arcs of involvement in Drupal (or open source)

I've been working with Drupal since 4.6 and was somewhat involved in the process of making 4.7. That was about 8 years ago. Here are some truths I've learned in that time.

There is at least one arc to people's involvement: people go up and people go down

Think about your involvement in Drupal. Did it start at some level, stay at that level, and continue at that same level indefinitely? Probably no. You are somewhere on an arc of involvement. You may be on a mini-arc within a bigger arc. When you first heard of Drupal you didn't immediately jump in and file bug reports and help do usability studies and write documentation. You tried it out. Then you did a little contribution and you liked it (or hated it) but your involvement probably kept increasing for a while. Right now maybe you're headed up or down - maybe you're involvement is decreasing right now because of a big project at work but you know it will increase 2 months from now because your next project will make it easy to contribute to a given module (or core?). Let's look at some real world arcs of involvement.

Let's look just at Drupal Core involvement. I've used the data from marvil07 which includes analysis on commits to the main branch of core (originally CVS and then migrated to git) since 2000. Here are the top committers for the years 2000 to 2003, inclusive:

Person Commits
Dries 2341
Kjartan 334
Steven 157
jeroen 102
natrak (pseudonym of Kjartan) 82
ax 9
Jeremy 9
Marco 6
Kristjan 4
moshe weitzman 4
Al 3
Gerhard 2
Gabor Hojtsy 2

Holy cow. I only recognize 8 of those 13 people, but they are the foundations of Drupal for the first quarter of it's life. Let's look at the next 3 years: 2004 to 2007.

Person Commits
Dries 3537
Steven 1048
Gabor Hojtsy 894
drumm 655
killes 557
chx 331
webchick 124
pwolanin 93
People Involved: 

Ways you can give feedback, ranked by usefulness

Below is a ladder of feedback, ranked by usefulness in ascending order:

Levels of useful feedback:

  1. Silence (i.e. not giving feedback)
  2. X is bad.
  3. X is bad because Y
  4. ...instead I suggest Z
  5. ...instead I suggest Z because Q
  6. ...instead I suggest Z because Q. I'm happy to help with that.
  7. ...instead I suggest Z because Q. I've already done some (or all) of the work.

Earning bonus points

Regardless of which level you're on, you can get bonus points by following some simple tips:

People Involved: 

New option for funding Drupal contributors: Gittip

OK, so it's not really "new." It's a little over a year old, but the Drupal community on Gittip just recently got over 150 people which is the threshold where Gittip starts displaying members of the community.

So, congratulations to the Drupal Community! (and to Gittip).

Why is Gittip a useful tool for the Drupal community?

I think a lot of people want to give a little support (via money) to the people who work on Drupal but there is a lot of friction in the way of giving money. Does the person use Paypal? What is their PayPal email? What if you only want to give someone $10? The friction of that whole transaction far outweighs the $10 gift.

There's also a mismatch in the action: most payment systems like a check or PayPal are used one-time (again, because of the friction) but the benefit from a contribution and the desire to pay back that benefit live on for as long as you have a Drupal site. A lot of these topics are discussed in an old Lullabot Podcast where they point out that if every active user of Views gave Earl a few dollars for their use of he'd have a bit over $2 million.

My perspective is that it hasn't been easy enough for people to give that money and the friction is holding them back. Gittip solves a lot of these friction problems and the timing problem by making it easy to do small recurring payments to anyone on github or twitter.

One example that Dries requested: let's help AlexPott extend his "unemployment" and let him focus his genius on Drupal 8 core development!

What does the evolution of our use of Gittip look like?

Among the people who have joined the Drupal community on Gittip:

People Involved: 

Setting up OpenSWAN for Site-to-Site VPN - Ubuntu 12.04 and Cisco ASA 5520

I recently had to setup OpenSWAN on Ubuntu to be part of a site-to-site VPN with a Cisco ASA 5520. There are a few resources I used to get me there. It was hard to find these resources so I'm keeping track of them for myself and in the hopes it helps someone else.

My requirements were:

  • local ike peer IP address:
  • remote ike peer IP address:
  • remote: also want all addresses in 123.45.0/24 to be addressable

  • Authentication: pre shared key

  • Encryption Scheme IKE
  • Diffie Hellman Group: Group 2
  • Encryption Algorithm: AES-256
  • Hashing Algorithm: SHA1
  • IKE Negotiation Mode: Main mode
  • Lifetime (for renegotation): 480 minutes

  • Phase 2 Encapsulation: ESP

  • Phase 2 Encryption Algirithm: AES-256
  • Phase 2 Hashing Algorithm: SHA1
  • Perfect Forward Secrecy: No PFS
  • Lifetime (for renegotiation): 480m

And here is roughly what my /etc/ipsec.d/connection.conf looks like:

conn i2c

People Involved: 


Subscribe to RSS - Greg