Git is more difficult than it ought to be, but until now I couldn’t put my finger on why

I was doing some mundane Linux command line work when I had my flash of insight. I’ve been using Linux for years, but I almost made a typical newbie mistake with the mv command. I wanted to rename a file:

mv /path/to/old_name new_name

Urp! I stopped, because this would not have just renamed the file, but moved it into my current directory as well. And then I recalled the typical mv tutorials which usually explain how the unix filesystem works, and how with that understanding, mv’s behavior makes sense.

In other words, mv combines two conceptual functions into one thing, simply because that’s the underlying implementation.

And I realized that this kind of “implementation leakage” occurs with many git commands. The non plus ultra evidence is the excellent post, Git Reset Demystified by Scott Chacon. It’s about git’s equivalent to svn revert — a very important function, undoing your changes. But even though Scott is very knowledgable about git and even authored the book, Pro Git ♢, he

…never strongly understood the command beyond the handful of specific use cases that I needed it for. I knew what the command did, but not really how it was designed to work.

It’s no wonder that ordinary git users don’t fully grasp these commands. In a final unintentional confirmation of my theory about git’s problems, Scott presents this 6×4 table as a learning aide:

Like studying German verb conjugations

Another example is the well written O’Reilly book Version Control with Git ♢. By necessity, It teaches the internal implementation of git before explaining how to fully use it. Or, as David Eisinger says,

…until you wrap your head around its internal model, it’s easy to wind up in a jumble of merge commits or worse.

Fixing git: two ideas

• The aptitude route. (Specifically, the command line use.) Originally, one needed to remember to use apt-get install but switch to apt-cache search to look up packages, due to implementation details. Now, however, both functions are available via one high level command line interface, aptitude. Legit is the only one I’ve found so far and looks pretty good. I’ve begun writing up my own ideas about what a front-end would have as well.
• Git command aliases. Git supports the creation of new commands via its alias feature. This might not be a bad route, if it’s flexible enough. LOLA’s a great example.

See also

• A great related post: On git and usability
• Michael Feathers takes the opposite point of view: My Satisfaction with Git: No Abstraction.

Some of the best-designed and officially featured WordPress themes aren’t built to handle mid-volume traffic. Just one incoming link from a semi-popular page can take your server down.

A New Blog for a Web App

The featured "News" theme that crashed my server

Everything started out smoothly. Like thousands of developers do every day, I set up a new WordPress installation to support a new web app I’m getting online. I’ve got a Linode 1536 which is perfect for this ♢. It has gigs of free disk space and 800MB of unused RAM just for cache. And these virtual servers are fast. Mine hosts about 15 Rails and WordPress apps and the system load never gets up to 1.0.

For me, the hardest (and most fun) part of setting up a new blog is choosing the theme. I didn’t want to waste time, so I looked only at WordPress’s one-page “featured” themes list and chose News — a conservative theme with personality.

I wrote a few posts to get started, posted a link to one on Reddit, and went to sleep.

I Woke Up but My Server Wasn’t There

The network traffic graph gives a dramatic view of the server crash

At around 9am, I was in for a shock: no web pages were loading and it took 2 minutes to simply ssh in. There were about a million Apache processes running and the system was out of memory. Checking on Reddit, I saw that the post was getting a good amount of traffic: it was at the top of the r/programming subreddit. It had a couple of hundred up-votes; a lot, but certainly not an apocalypse. So this was odd. I also saw that someone reposted it to the Hacker News. (Nice!) Except that the posts were only noting that the site was offline (Not nice.)

Discovering the Culprit: the Theme

A helpful Hacker News reader suggested “Caching is your friend”. That was my first thought as well. WordPress by default is just a PHP app, doing a lot of repetitious work with every request. But that didn’t feel right. This was a brand new blog, after all, and the requests were all for one simple page.

It’s good Bluebox Now was able to solve its problem and move on. It’s just too bad it had to suffer through what I imagine were at least a few stressful days and sleepless nights. All over an issue that could have been avoided through a careful trademark search.

Definitely.

And I’ll mention that I’m the creator of the trademark search iPhone app, Quisitive.

Amazon AWS EC2 Billing Options

I’m a fan of AWS, but there is definitely a steep learning curve to it. There are so many neologisms and so much complexity; it reminds me of Amazon’s Kindle offerings vs. the iPad.

This is difficult to do, but it’s an interesting question. There are two main ways to write a blog: (a) at a blogging platform like wordpress.com, or (b) at a personal / corporate custom web site.

The only methods I know of for identifying the blogger in scenario (a) are

1. A subpoena;
2. detective work, i.e. using clues in the content to figure out who & where the person is.

In the case of (b), the custom web site, it’s a lot easier. This is because the blogger will probably be connected to the registration of the domain name as well as the organization itself.

Another idea: I once identified a person who was stalking a friend by looking at technical clues in emails the stalker sent. I did it by examining the usually-hidden portions; the “message headers”. So if your victim has received emails from the antagonist, they could contain helpful info.

Note that if this is a copyright, trademark, or possibly even defamation matter, then the person’s identity isn’t as important. One can deal directly with the webhost and ISP using DMCA-style takedown notices.

I’m interested in how all my apps perform, not just the web browser. The Mac is smart and will use every extra leftover bit of RAM to speed everything up.

RAM in computers is like kitchen counter space: the more space you have, the less shuffling around you need to do, and the more time you can spend cooking.

How I tested

I used my Mac running OS X 10.6.8 (Snow Leopard with all updates). Disabled all plugins in the browsers, and noted the Real Memory used by several browsers for typical usage. I double-checked the results by running each test on each browser twice.

Task 1: Startup the browser, go to reddit.com in one tab and stackoverflow.com in another.

Task 2: After finishing task 1, load three more typical sites I use: google mail, google docs, and washingtonpost.com.  Pull up a Wapo article and scroll through it.

Results

Lower numbers are better.

What the numbers mean

Mac users who do the kind of web browsing I do can save 100 – 200 megabytes by choosing their web browser wisely. People can potentially save even more RAM, if these savings continue linearly with increased usage — e.g. 10 or 20 tabs open. The extra couple of hundred megabytes can make a big difference if the computer is doing other RAM-intensive work such as running a VM.

The browsers broke out into three groups, as I’ve shown in the table. Raven, the new browser for Mac deserves a serious look. They sponsor Dan Benjamin’s 5by5, which is how I heard about it. I’m going to start using it for daily tasks and see how it holds up. I’m also going to revisit Opera (I haven’t used this new version yet) and see how it is as a browser compared to Safari, against which it performed nearly identically.

One part of the holding isn’t surprising: Purchasers of WoW aren’t owners but rather licensees of the software. But the other part is much more interesting and I think it narrows the basis for the Jacobsen v. Katzer holding.

Then

Remember, Jacobsen was about a Java developer who licensed his model train source code under the Perl Artistic License. A company copied it, but not according to the terms of the A.L. The case turned on whether the broken license terms were covenants or conditions. The court ruled they were conditions and thus there’d be liability for copyright infringement — as opposed to simply breach of contract. This is because, as pre-conditions which the defendant didn’t adhere to, there was no contract and thus the defendant’s behavior was copyright infringement. So in that case, conditions in a software license leading to liability for copyright infringement is a good thing, if you like open source.

And now

But now in Blizzard, the court found that the broken terms were covenants, which worked out for the defendant, MDY, who avoided secondary copyright liability. The court found its way there by interpreting the contract. But the opinion then states (jump to page 16—that’s where it gets good) that policy dictated that result as well: it would be a bad thing to allow software manufacturers to label any old term as a “condition” in order to use the hammer of copyright law. And so they seem to limit this legal strategy:

Were we to hold otherwise, Blizzard — or any software copyright holder — could designate any disfavored conduct during software use as copyright infringement. . . .We conclude that for a licensee’s violation of a contract to constitute copyright infringement, there must be a nexus between the condition and the licensor’s exclusive rights of copyright.

But sometimes (Jacobsen) conditions are a good thing.

So now the questions are, is this dicta? Or a re-statement of existing law? Or instead, a new narrowing of the condition/copyright liability theory? And even if so, would it affect another Jacobsen-like case? Do the current crop of open source licenses’ conditions contain an appropriate “nexus [with] exclusive rights of copyright?”

See Also

Open source software and the covenant-condition dichotomy [Internet Cases]

The new .CO domain has several benefits.  Because it is new, there are more available domain names available for consumer registration.  The higher price should help preserve this increased availability by reducing speculators’ bulk purchases and website “parking.”  Also, the .CO already has a meaning for non-U.S. residents, e.g. the BBC is found at www.bbc.co.uk.  In addition, the shorter length and greater availability of the .CO mean that some surprisingly short and catchy names are available and ready for purchase. Finally,  people looking for a website online are changing their method of searching. Increasingly, web visitors start their search at a search engine page instead of an “address bar.”  Therefore, a highly ranked site (be it a .COM or .CO) will be found regardless of its domain name or ending.

Benefits aside, a new TLD still has its drawbacks. There is currently a lack of awareness in the marketplace regarding the .CO.  A .CO address may look like a typo, as if the “m” was left off unintentionally, or potential visitors to a site might not trust a .CO address as much (or as little) as they’d trust the more widely used and longer available .COM’s. Another important potential drawback that will probably unravel as time goes on is the possibility of trademark disputes between different owners of a .CO and .COM with the same leader. It is something to keep in mind if you’re currently interested in buying a .CO. Whether or not this will develop into a trademark problem, we shall see in the (likely) very near future.

Consumer awareness of .CO will grow faster overseas due to its existing recognition, thus domestic recognition should not fall far behind. In the future, at least the short-term, the .CO will become a reasonable alternative to .COM’s that are either unavailable or too expensive to buy off of others.