Thanks to Loren Finkelstein for submitting this hint to Mac OS X Hints, based off of this other hint at AFP548.com I wrote, which was in turn based off of this hint first published here, which was then published again later in MacTech magazine.
It’s a simple hint, and I’ve taken some criticism for having it appear in so many places, but obviously people find it useful, and that’s the point.
1. Apple will post a happy graphic to the front page of their site with a sentiment like, thanks to our customers for 30 great years.
2. Everyone at Apple will continue their lives as normal.
3. Multitudes of idiots will whine and bitch that Apple didn’t change the entire universe with some kind of product introduction.
4. I’ll be sick of listening to them whine.
Happy 30th Apple!
I’ve written before on this site about using encrypted sparse disk images to store private information. Over time, as things are deleted from those disk images, they can become fragmented, and the image contains blank space between files, which can cause the image file itself to be unnecessarily large. For example, if you have two text files that are each 32K, and 1GB of blank space in between them on the disk, your sparse image will be 1GB in size and only contain 64K of actual data. That’s quite a chunk of slack space. Reclaiming that space is easy, but it may require that you drop a little bit of cash to do it.
The image needs to be defragmented and then compacted. To my knowledge, there is no freeware disk defragmenter for OS X. I use iDefrag ($30) and it does the job well for me. You’ll want to mount the image on the desktop, run iDefrag, and perform a full defragmentation. That will compact all of the data in the image’s filesystem and move it to the beginning of the image.
The next step requires our good friend the Terminal. After defragmenting the image and dismounting it, start /Applications/Utilities/Terminal.app and enter the following:
hdiutil compact /path/to/image.file
This is a different kind of compaction than what the defragmenter performs. In this step, hdiutil scans the image for the last point where data exists, and truncates the empty space after it, reducing the size of the image file.
To continue our example above, iDefrag would move our two 32K files to the beginning of the image’s filesystem. Then hdiutil would slice off the remaining 1GB of empty space after those files, reducing the image’s size to megabytes instead of gigabytes. The size of the final image will vary because there is a certain amount of overhead for filesystem structures.
Here is a great example of what I complained about in the last article:
The headline ends with ?, which, as we all know, immediately makes any sentence or sentence fragment a question whether an interrogative word is included or not, and then the first sentence immediately confirms what, just a few words ago, was supposed to be a question in the headline.
Why does this get such a strong reaction from me? Because I consider a certain minimum level of writing aptitude to be good manners for your readership, and writing grammatically deficient, logically inconsistent pages like this is roughly the equivalent of farting in a crowded elevator. I strongly believe that writing is a direct reflection of the mind, and when writing is poorly structured and self-contradictory, it reveals thinking processes with the same problem. Please give credit to my intelligence, and cause me to respect yours, by writing well.
And now for the standard disclaimer: I’m not a perfect writer, nor do I claim to be. I correct my mistakes. My writing mistakes do not excuse the mistakes of others, nor do they diminish my right (duty?) to critique others’ writing. Perfect or not, I’m a damn sight better than the example here.
Some time ago, I posted these instructions for compiling Minicom, a terminal application that enables your Mac to communicate with serial devices, much the same way Hyperterm does in Windows. Some months after the original posting, Tiger was released, and the instructions I had provided for compiling Minicom on what was then Panther were no longer valid. I’m not a developer and I can just barely muddle my way through this compiling stuff, so I was at a loss to compile a Tiger-comaptible Minicom executable.
In the meantime, I used Zterm. It’s a decent app, but it hasn’t been updated in some time, and I have no idea whether it will work with Rosetta on Intel-based Macs. Because of those factors, I can’t recommend it. Minicom can be installed with the help of Darwin Ports or Fink, but that’s a lot of overhead and trouble for this little app, and frankly, I’ve had both packaging systems fail on my machines within minutes of their initial setup. I don’t trust either of them.
This morning, compiling Minicom on Tiger came back to my mind, and I used our trusty friend Google to see if anyone else had done it yet. I came across this handy page by Mr. Jeffrey Frey which contains - you’re not gonna believe this - an OS X package installer for Minicom!
Minicom 2.1-14 package installer for OS X ( 334 KB, Universal )
If you find this package helpful, take a moment to thank Jeffrey for it.
Knowing that Jeffrey had successfully compiled Minicom on Tiger, I e-mailed him to get the details, which he graciously shared. So for those of you who want to compile Minicom from source, the instructions are as follows:
Start /Applications/Utilities/Terminal.app and change to the Desktop folder.
cd Desktop
Download the Minicom sourcecode.
curl -O http://alioth.debian.org/download.php/123/minicom-2.1.tar.gz
Un-gzip and un-tar the downloaded file.
tar zxvf minicom-2.1.tar.gz
Minicom needs a folder that doesn’t exist by default to store some temporary working files. Let’s create it.
sudo mkdir -p /var/spool/lock
Set that newly created folder to be writable by everyone.
sudo chmod 777 /var/spool/lock/
Change to the src subfolder in the uncompressed minicom-2.1 folder.
cd minicom-2.1/src
In order for Minicom to compile correctly, we have to make changes to a file. Rename that file, because we’re going to replace it.
mv window.c window.c.original
Find all the instances of “BC” in the file windows.c.original and replace them with “Minicom_BC”. Write everything to a new file named window.c.
sed 's/BC/Minicom_BC/g' window.c.original > window.c
Move up one folder level.
cd ..
Configure Minicom for compiling, and specify our recently created folder for some temporary working files.
./configure --enable-lock-dir=/var/spool/lock
Compile Minicom.
make
Install it.
sudo make install
You can safely delete the files and folders containing the source. The Minicom executable is located in /usr/local/bin.
Jeff also provides a script to patch the source and build a universal binary.
For more information about using Minicom once you’ve compiled and installed it, refer to the previous Minicom article, which I’ve linked at the top.
Loading ...
My .Mac Web Gallery
Recent Comments