Other posts related to mac-os-x

For the past few weeks, I’ve been teaching a course on Windows Server 2008. As part of the course, it’s pretty common that I need to create (and delete) a large number of Windows Server 2008 machines. Because of all the different configurations (and the fact that installing from a CD or DVD takes a lot of time), I’ve found it very helpful to create ISOs for the installation of the operating system.

On Windows 7, this is really easy. There is a nifty plugin called ISO recorder which automates the process of creating an ISO file from disk. To get started with it, you download the applet, install it, and right click on the disk that you wish to capture. Out comes an ISO that you can mount in VMware or VirtualBox.

But as much as I like Windows 7, I don’t actually use it very often. Most of the time, I’m doing things with Linux or Mac OS X. Luckily, it’s pretty easy to create disk images on Mac OS X, as well.

Disk Utility (available under Applications > Utilities) can be used to create disk image files. To do so, open the program, click on the disk that you want to make an image of, then click on the “New Image” button.

Type in a name for the image and specify where you would like for it to be saved.

Finally, before clicking on the “Save” button, set the the “Image Format” option to “DVD/CD Master.”

Voila! After a few short minutes, you have a copy of the disk that you can burn to CD/DVD (for students), or to keep as a backup.

Unfortunately, though, the format that the Mac uses for the disk image is .CDR. The most common format for CDs and DVDs is .ISO (and sometimes .IMG). ISO and IMG can be directly mounted in a VMware or VirtualBox, CDR cannot be.

Luckily, it’s also pretty easy to convert a CDR image to ISO. You can do this with “hdiutil”, a command line program. Here’s how:

I’m a software whore. I love to play with new programs and experiment with new features. I think it’s exciting and interesting to try new stuff.

However, there is also a side-effect of my little liaisons. Because I’m not faithful to any one program, I have very little loyalty to either operating systems or applications. If there is something new and shiny, I’m going to play with it.

It also means that I get frustrated with limitations. Because I move between different programs so frequently, there’s little incentive for me to stay with one over another; unless, that is, it works really well.

This is the reason that, about a year ago, I decided to move from Thunderbird (my email client at the time) to Evolution (an alternative that comes with the Gnome desktop). At the time, I was frustrated with how Thunderbird handled schedules and calendars.

Local calendaring was more or less acceptable, but it was really hard to work with remote services such as Microsoft Exchange or Google Calendar. The support could (at best) be called “experimental”. Task and appointments didn’t update reliably, and it would only worked when you had a connection to the internet. The net effect was that your calendar in Thunderbird wasn’t really able to talk to your cell phone.

Now, for some people, this might not be a big deal. For me, however, it was an enormous problem and I simply could not find a workaround. So, I left Thunderbird behind and decided to use Evolution instead.

For the past year, I’ve been very happy with Evolution. After it’s been configured to have a unified inbox, Evolution is imminently useable. It handles calendars, tasks, contacts and email; all the things that a collaboration program is supposed to do. It might not have all of the bells and whistles of other clients like Thunderbird, Mail.app (Mac OS X) or Microsoft Outlook, but it works well and I’ve had few complaints.

Regular, scheduled reports are a a good way to ensure progress on a complex project. There is just something about the need to routinely show what you’ve done and explain delays that helps people overcome procrastination and actually do their work.

This is particularly true for projects where there might not be another readily available incentive (such as a course grade or future employment). It’s a tactic I’ve successfully used with fickle students and I’m discovering that it’s equally effective with fickle developers (like me). Thus, I’m writing the first monthly progress report on LyX-Outline.

In case you’re new to the entire idea of regular reports, here’s what you can expect: a summary of recent progress, announcements, miscellaneously useful information, and conjecture about things that still need to be done. Read on for more …

In 2007, an engineer at Google named Amit Singh released one of the best programs for Mac ever written. It was amazing, incredible and even a little magical; and most Mac users probably never even realized it existed. It was called MacFuse.

MacFuse was a very interesting program. It took something very old (the computer filesystem) and made it new again, and thereby changed the world.

In the bad old days, writing file systems was the stuff of nightmares. It required blood sacrifice, misery and pain. If you messed up big, it could crash an entire computer system. If you only messed up a little bit, it would “only” result in data corruption and the loss of digital memories.

Fuse/MacFuse changed all that, though. Instead of requiring that an aspiring file systems developer work at the level of the kernel, it allowed for the work to happen in the “user-space”. This meant that the implemented file system code could be run by non-privileged users, and for all intents and purposes the file system was nothing more than a simple program.

By greatly simplifying the process of writing file systems, MacFuse opened the doors to all kinds of innovation. The code got incorporated into virtualization packages such as VMware Fusion and Parallels; and other developers made it available to end-users through projects such as MacFusion. MacFuse made it easier for users to connect their computers in new and interesting ways. If you wanted to connect to Wikipedia, or Google, or Flickr via a MacFuse plugin, you could.

It was file exchange Nirvana; and then, Snow Leopard killed it.

In fairness, I should probably point out that Snow Leopard killed lots of things. It caused old programs to stop working, corrupted data, and destroyed user accounts outright. From its release, Snow Leopard has been a gigantic mess. (Until quite recently, that is.) And though Apple has fixed some of the bugs (since version 10.6.3, things have gotten a lot better), there are some very important programs (like MacFuse) that still don’t work, and this caused problems. In the case of MaFuse, the problems have have come to (somewhat) impact my personal and professional lives. To be more specific, the broken state of has been hampering the release of Time Drive (my backup program). For, you see, the most recent version of Time Drive requires a Fuse plugin for one of the new features to work correctly.

On Linux, there isn’t a problem. The debian package system downloads sshfs and, boom, you’re ready to go. On Mac, though, it doesn’t work at all.

It doesn’t even pretend to work, and I find that to be rather annoying. More than annoying, actually. I find it to be aggravating, infuriating and it makes me want to hit someone. But as much as I would like to engage in violence, that is not going to solve the problem. And I very much wish to fix the problem. So … I did.

With the help of various online postings, I patched the MacFuse source code and created a version that is compatible with Snow Leopard. I also figured out how to build a command line copy of sshfs so that Time Drive will work. The combination of these two actions both made me feel better and even made Mac OS X feel like a magical platform again. (Well, almost.)

The remainder of this post will describe how you can get these things working for you. It will cover where to get the files, how to install them, and a brief guide to life simplification via MacFuse.

Note: After nearly a year of compatibility problems, Nokia and Apple have released versions of Qt and Snow Leopard (respectively) that are able to run PyQt. This article explains how to install PyQt using the precompiled binaries available from the Nokia website and the PyQt bindings from Riverbank computing. Installation instructions for Leopard can be found here.

To install PyQt on Mac OS X Snow Leopard is a four step process. First, download and install the GCC compilers and associated utilities available in Apple’s XCode development environment. Second, install the Qt framework from Nokia. Third, download and compile the SIP binding generators from Riverbank computing. Finally, compile and install the PyQt bindings themselves.

XCode and Qt

The easiest way to get the most current version of the GCC compilers and associated tools is to download the XCode package from Apple at the Apple Developer Connection (ADC). ADC requires that you have an Apple ID and account, which are both free. After you log-in, download the XCode developer tools package. Given its size (nearly 1 GB), this may take awhile.

While waiting for the XCode tools to download, you can also begin downloading the Qt binary installer from the Trolltech downloads page. As of this writing (May 26, 2010), the only version of Qt that runs well on Snow Leopard is version 4.7. For that reason, I strongly suggest downloading the Qt 4.7.0 beta. (Do not download the Qt 4.7.0 Carbon version, as Apple is dropping support for Carbon in the near future. It is also believed that many of the previous compatibility issues were due to the deprecation of the Carbon frameworks.)

Once XCode has finished downloading, run the package installer. It will ask you to select the destination drive and what components of the software you would like to install.

This will automatically install and configure the GNU tool chain. Once it has finished, you can access the tools by going to the “/Developer/” folder on the root of the drive.

After XCode has finished, run the Qt installer.

The Qt installer package will automatically place the tools and other things that you will need in the same Developer folder where the XCode tools and frameworks are located. This includes the Qt developer tools, documentation examples and header files. If you only wish to run Qt programs, it is not necessary to install the documentation and examples and you can deselect them by clicking on the “Customize” button of the “Installation Type” panel.

SIP and PyQ

SIP is a program that makes it easy to create C++ bindings for Python. You can find the source code at Riverbank’s SIP download page. Since you will be using the 4.10 (or greater) of PyQt, you should probably download the latest developer snapshot (version 4.10 or greater). Be sure to get the Linux/Unix source code, rather than the Windows source. You will also need the latest source code snapshot for PyQt 4.7, which is also available from Riverbank.

After you have finished downloading the source files, move them to a folder in your Users directory. I have a special directory entitled “Applications” where I keep the source code for programs that I have manually compiled. Note: The rest of the steps will be done from the Mac OS X terminal.

After you have moved the source code for both SIP and PyQt to this new directory, extract it by using the tar utility with the x and f options (tar –xf):

First, we need to compile and install SIP. The default configuration will move the compiled files to a directory where Leopard can’t read them. So, we will manually need to specify the destination directory using the –d flag:

cd sip-4.8
python configure.py –d /Library/Python/2.6/site-packages

After the configuration is finished, run make and sudo make install:

make
sudo make install

Once SIP has finished installing, we need to repeat the process for PyQt. From the sip-4.10 directory, change to PyQt:

cd ..
cd PyQt4.7

Next, run the configuration script specifying the path to the installation directory for the python bindings:

python configure.py –d /Library/Python/2.6/site-packages/

Then compile and install:

make
sudo make install

Since Qt is a rather large framework, it may require between 15 and 30 minutes to fully compile.

Imagine how awesome it would be if this announcement read: “Time Drive has been completely rewritten from scratch (yet again) to take better advantage of the paradigms of modern computing! Version 0.3 has hundreds of updates and new features which will make your life easier and more fulfilled!”

There’s just one little problem … such an announcement wouldn’t necessarily be true. (Marketing hyperbole, I never knew thee!)

The truth is this: Time Drive is a simple backup program that does a good job of backing up your data. It offers a nice list of potential backup options ranging from an attached hard drive to a computer over the network or across the internet. It makes it easy to search for and restore a lost file.

In short, Time Drive seeks to change the world by making an act of computer maintenance more convenient. I’d like to think that it Just Works.

But the real test of a program isn’t how well it works, but how easy it is to fix when broken. A good program does what you want, but a better program helps you get back on track when things go wrong. Back when I was looking at other backup programs available for Linux, this was my number one frustration. Most of the applications would work (for the most part), but I could never troubleshoot or repair problems when they happened. There just wasn’t enough information available.

For an example, let’s take SBackup. It’s a lovely little program, with one horrible flaw. You have absolutely no way of knowing if it is working. It doesn’t keep log files, it doesn’t notify you if a backup job failed. It doesn’t let you know if it is running. Its simplicity is actually symptomatic of a flaw: it’s incomplete.

These were problems that I desperately wanted to avoid with Time Drive. And now that I’m announcing version 0.3 of the program, I’d like to think that I have. So, instead of marketing hyperbole and false promises, here’s the real announcement:

Time Drive 0.3 includes a number of refinements that make it easy to both backup your data and to figure out why a backup might have failed. It’s better, easier and more refined. In the rest of this post, I’ll explain why.

As much as I love Apple’s Time Machine, it’s a hard drive pig. If not carefully watched, the little porker will use every spare byte of free space it can. What is particularly obnoxious, however, is that you might not realize you have a problem until it is too late and you’re backup drive is filled to capacity.

Take my situation as an example. I have a single MacBook Pro notebook with a 250 GB hard drive. Most of my files are text based and on the smallish side. In comparison, my networked backup is a hefty 1.5 terabytes. The combination of small hard drive and large backup drive had me thoroughly convinced that I wouldn’t have to worry about free up space for years.

I was wrong.

Because of the size of the backup drive, I like to keep other files on it – mostly music and video files – so that I have a duplicate copy. But earlier this week, I got a nasty surprise while trying to add an album I had just downloaded from Amazon Mp3. The Mac informed me the backup drive was full.

As you might guess, I found this to be very confusing. How could the drive be full? Sure … I had three or four hundred gigabytes of music and video files on it, but there was no way that the Time Machine backup could be over a terabyte in size … Could it?

This situation didn’t smell right, so I decided to investigate. I mounted the backup drive and tracked down the Time Machine sparsebundle and confirmed the impossible. My Time Machine Backup was a whopping 1.15 terabytes worth of disk space. “How in the world could the backup be so large?”, I asked myself. “Time Machine is supposed to be an incremental system. 1.15 terabytes is big enough to hold every bit and byte on my computer four and a half times over!”

First, I got annoyed; then, I got angry. What really tipped the scale toward seething fury, however, was failing to find any straightforward way of getting the space back. Yet another spectacular example of Apple’s “simple over useful” approach to computer design!

After the first bout of obscenities, I came to a simple conclusion: I could publicly express my dissatisfaction with Apple’s product line or I could go about trying to find a solution. Publicly spouting off was unlikely to help much, so I opted for the latter option. What follows is a brief summary of what I learned.

While Mac OS X shares many things in common with other Unix operating systems, it also has a couple of missing parts. This can make installing software more difficult when compared to Linux or other *nix variants, and unfortunately, Duplicity happens to be one of those cases.

But just because it is more difficult to install Duplicity on Mac doesn’t mean that it isn’t worthwhile. Duplicity is one of the best command line backup programs available anywhere. Using the same program, you can backup to a local hard drive, FTP server, over SSH or even to Amazon S3. It uses the rsync algorithm, which means that backups happen quickly and only the parts of files that actually changed get copied. Subsequently, backups are smaller.

Nor does it mean that installing Duplicity is actually all that hard, it’s just a bit tedious. Like many other *nix programs, Duplicity requires a number of additional programs (called dependencies) that you will have to search out and install separately. To make that process easier, this article explains how. Below, you’ll find links to the download pages and instructions for how to compile each of Duplicity’s dependencies on Mac OS X. The instruction set has been tested both on Mac OS X 10.5 (Leopard) and Mac OS X 10.6 (Snow Leopard).

Regular readers of this blog might accuse me of having a deep seated resentment against iPhone, Mac OS X and Apple in general. The only problem, of course, is that resentment is the wrong word. Disillusionment and disgust are much more accurate.

You see, purchasing a Mac computer was one of the single biggest disappointments of my young technical life. I had been promised so much!

If you read the ramblings of online pundits or dedicated Apple purists, you will know that switching to a Mac brings a Zen like state to your computing. It will make you more productive, more creative, more organized, more intelligent and possibly even more attractive.

Except after nearly three years of owning one and using it more or less daily, I’ve come to a simple conclusion: my MacBook Pro, in addition to being a lovely paperweight, is a computer. Nothing more, and quite possibly a whole lot less. (Were it just a computer, I might even be able to use it the way that I want, instead of capitulating to the desires of a mega corporation.)

In fact, I’ve further decided that there is only one possible way that you can possibly claim that a Mac is easier to use than a PC (short of using mind altering chemicals, that is). You must choose to stay within Apple’s suffocating glass greenhouse and allow Apple to decide what you can do and dictate precisely how you will do it. The Apple experience demands nothing less.

Want to run that piece of software that worked just fine until you installed Apple’s latest glorified service pack? Sorry, that isn’t going to happen, either. “Backwards compatibility prevents us from creating innovative and utterly amazing ™ new user experiences.”

Or want to use that iPhone program that was approved at the highest levels, and then rejected without explanation? “We just can’t allow that. It could result in user confusion.”

In contrast, when something goes wrong on a PC, people – rightly, might I add – blame Microsoft. Microsoft makes a disgusting amount of money from their software; and in a sane world, money buys accountability. We pay the CEOs of large corporations obscene salaries and even more ludicrous bonuses to fix problems. If there’s a malfunction, someone is reassuringly responsible; if there’s a disaster, someone is handily available to be lynched.

Except, reality breaks down within the Church of Apple. If a Mac user has a problem, you can rest assured that she will blame herself. You just know that a technical glitch couldn’t possibly be because Apple made a mistake, or the product contains a flaw. Apple merchandise is loving crafted and precisely engineered! And the omnisicient Steve Jobs thinks of absolutely everything!

Is it really so hard to see that Apple’s technical accomplishments represent the pinnacle of human accomplishment? Or that every contact with the Holy Church is divinely sublime?

It is positively convenient to drive 50 miles to the nearest Apple store, wait for more than an hour because the iDisciples can’t keep to their appointment system, and lose your computer for a week and a half because a computer repair service doesn’t stock hard drives. You get to talk to a human being, who will insult you to your face rather than over the phone! If you can’t get it to work, that’s your problem. You’re obviously not smart or cool enough to be an Apple person.

In Apple’s pristine little world, it’s just inconceivable that Apple’s products might not be nearly so desirable as the punditocracy claims. It’s blasphemy of the highest order, requiring that thorough penance to be administered by the all-too enthusiastic congregation of assorted hippies, losers and online freaks. Any individual who so much as implies something negative about Apple deserves theaccusations of bias – defined as anything less than a total willingness to sacrifice their firstborn’s blood on the iAltar – that will plague them for the rest of their public life.

After all, Apple has never done anything to encourage resentment or anger. They’re far too busy voiding warrantees, sabotaging relationships and having a party to promote the thousands of invisible (albeit refined) features and APIs of their near-perfect operating system. As a result, it’s simply incorrect to assert that I resent Apple. Until such time as they do something improper, I’ll just have to classify my feelings as disillusionment and disgust.

When it comes to most things, starting fresh is a blessing. The reason for this is rather simple, when starting over you don’t have to worry about baggage. After all, baggage is only valuable when on holiday; otherwise, it just slows everyone down.

This is especially true for software. Over time, computers tend to accumulate a rather potent type of digital baggage that can be very difficult to get rid of. And that digital garbage results in inconsistencies that can cause enormous – and usually unforeseen – problems.

However, even though starting fresh is usually the best option, that isn’t always true. Sometimes, it’s better to risk the problems and incompatibilities. For example, starting over may mean that you destroy hours worth of customization, or that you lose work already created because the older version are not compatible with the new.

Unfortunately, the general rule is also somewhat true of Time Drive. So, if you were one of those stalwart and brave individuals who decided to experiment with Time Drive 0.1, this post is for you.

In the last few days, I have been in touch with a number of people who have experienced a number of said inconsistencies and problems. And while several of these problems ended up providing insight on mistakes made during development, some of the others were changed on purpose. That is to say, the so called “bug” was actually a feature.

After fielding a couple of particularly angry e-mails, however, I thought that it might be good do a formal write up that describes how to work around these incompatibilities. And while no one likes to squash bugs or fix things that previously worked, rather fortunately, every one of these problems can be overcome with a little bit of effort and patience.