Was Fink, now MacPorts

I started using Apple’s OS X full time quite a while ago, back in the 10.1 days. So long ago that I don’t remember what its codename was, maybe Puma? (I suppose I could look it up.)

Anyway, as a command line geek, I wanted a system where I could build and modify my own software. As most command line geeks know, running through the ‘./configure && make && make install’ steps for each piece of software that you want to play with gets old pretty quickly. So originally, I started using Fink because at the time it was the most mature system.

There are lots of good reasons for using a packaging system, but having a system for automatically fetching and installing dependencies is fantastic if you want to experiment with random code that someone else developed and released. Because chances are, that random code depends on some other random library written by someone else.

There are a number of things that I like about Fink:

  • it worked really well for me — generally, when I found some new software that I was eager to try, the software (or at least its dependencies) was often already ported in Fink
  • the addition of binary packages was a great thing
  • the community was helpful

And some that are kind of stifling, like the rigidness of the Fink motto, “there’s only one way to build a package.” Of course, I understand the argument for it, and that there were various (unsupported) ways to get around it. For a volunteer organization, it’s hard to allow too much flexibility.

When I upgraded to Leopard, I decided to try out MacPorts because of the feeling I was getting from Fink that its support was stagnating. It’s hard to tell where the momentum is without doing some comparison of the traffic / quality of the developer lists. At this point, I feel more comfortable relying on MacPort for my software.

There was an adjustment period. But it was mostly a matter to translating the commands I was used to from fink into MacPorts syntax. At first, it was a little confusing to get thrown into variants coming from Fink, but they make sense. I wasn’t used to checking out the various options before installing a new package. Overall though, the transition was pretty easy.

I started writing my own Portfile [link] recently, so that’s another sign that MacPorts is growing on me.

However, after reading some recent email on the MacPorts developer list, I see the same themes that came up periodically in Fink.

  • what about binary packages (vs. what about security)
  • too many ports and updates, not enough maintainers

I can’t yet tell where these themes are going to go. It really depends on how much the community gets involved in making improvements. From what I can tell, it’s a matter of making contributions (time). The community is definitely open to receive them.

For me, the migration was worth it. I was able to install the software I wanted to use — such as svn, gnupg, git, imagemagick, ragel, scons. It allowed me to prune a bunch of old cruft that I never use anymore. It allowed me to experiment with a different OS X packaging system.

We’ll just have to see what happens next. I’m happy with MacPorts now.

Posted in Software | Comments Off on Was Fink, now MacPorts

Trey’s programming blog

My friend Trey started a new programming blog with weekly Emacs tips. Awesome!

I recently read (and promptly re-read) Steve Yegge’s emacs tips, which is full of good info.

I use Emacs all the time when I’m on Linux, but I rarely hack elisp. I can get around well enough, but there’s plenty of stuff that I know I could be doing better (faster, or more efficiently, or without dropping into the shell) if I had a genuine emacs master looking over my shoulder.

I’m looking forward to exploring some “new-to-me” features.

Posted in Software | Comments Off on Trey’s programming blog

Yet another way to shoot yourself in the foot with C++

Found during pair programming (yes, I do it sometimes):

class Foo {
Foo(bool in);

Foo f = new Foo(true);

Yikes. Didn’t expect that to get by the compiler. But it did. Without even a warning. The compiler was happy to turn “new Foo” into a boolean value and instantiate f, silently letting the memory leak away.

This helps:

class Foo {
explicit Foo(bool in);

But still. Ug. Single argument constructors in C++ are just evil.

Posted in Software | Comments Off on Yet another way to shoot yourself in the foot with C++

New addition

I’ve been a little preoccupied lately with a new addition to the family.

Read all about my son, Caden, on the Bacher Blog.

Posted in Family | Comments Off on New addition

John Doerr on greentech

John Doerr shares his fears about our current direction with respect to climate change.

Watch on blip.tv

via tedtalks in Democracy.

Posted in Technology | Comments Off on John Doerr on greentech

Photos from the babymoon

Something in me cringes a little when I use the word, “babymoon.” Not because I dread the arrival of our boy (June 19th), but because the word itself sounds so faddish.

Anyway, we took a quick trip to Sedona for a long weekend. Here are some photos from the Grand Canyon.

Grand Canyon

Dave on the trail

More can be found in the Bacher gallery: http://daveandkelli.info/gallery/

Posted in Family | Comments Off on Photos from the babymoon

Big company policies

This is ridiculous. My friend Trey works at a big company in Portland, OR.

Move or Quit: “I’ve been working from home for nearly 7 years now. In 2000 I asked my boss if I could work part-time from Corvallis because Mary was moving there. He agreed, and I’ve done work ever since.

The mother organization (12000 employees) has made the decision that people working remotely is not to be allowed. I must either move up to Portland (Santa Clara, CA and Hudson, MA are also allowed) or quit.”

I can imagine that there are a variety of reasons why this big company would want to institute such a policy: security issues, to reduce slack-iness, etc. But rather than forcing people (like my friend Trey) to move, wouldn’t it be better to address the specific security or productivity issues that gave rise to this new “no-tolerance” policy? Or perhaps, in the long run, it’s better for big companies to drive away good people.

(Via Trey.)

Posted in Rant | Comments Off on Big company policies

Web site updates from subversion

It’s not rocket science, but it surprised me just how painlessly I could set up automatic web site updates from my subversion repository. It’s all documented out there on the net, but this is my chance to record how I manage this site.

My testing ground is a working directory. My published web site is a working directory. When I commit a change, the published site is automatically updated to the latest trunk code.

  • Set up the published site as a working directory:

    svn co file:///path-to-my-repo my-web-sitedir

  • Set up the post-commit hook (in /path/to/my-repo/hooks) to run ‘svn update /path/to/my-web-sitedir’. There are more details in the subversion FAQ

Of course, none of that fancy version control applies to these blog posts. Posts are in a database and there’s a plugin for managing versions.

Posted in Software | Comments Off on Web site updates from subversion

Welcome to Squizion

Hello, my name is Dave and I’ll be your host this evening.

This is my first post on the Squizion Software weblog. On this blog, I’ll be writing about topics that interest me: software, Linux, OS X, ruby, my family (ok, should have put that last one first).

Check out About Me if you want to know more about me. And enjoy…

Posted in Software | Comments Off on Welcome to Squizion