iPhoto 5 has photo sharing like iTunes has music sharing. I’d never run across this before; it’s a nice feature and works just like iTunes sharing does. To turn it on, go into iPhoto’s preferences, click on Sharing, then enable the options you want.
Back when Apple Remote Desktop 1.2 (ARD) was the main tool I used to administer my Macs remotely, I wanted to be able to run Unix commands remotely but needed a delivery vehicle so that I could send them over ARD. The way I found was to use script-only installer packages. Installer packages are Apple’s preferred way to install software, and what their applications show up in. Since Apple also builds ARD, they built in the ability to install software on remote machines using the Install Packages function. The neat thing about packages is that you can have them run a Unix shell script before or after the package is installed. You can even set up a number of scripts and have them run in the order you want them to. Best of all, you can build a script-only installer package where the only payload inside the package is these scripts, with no software to be installed. So, when I needed to run a Unix command on one or more of my OS X boxes, I’d normally build a script-only package and use the Install Packages function to push it out over ARD.
Now, with ARD 2, Apple listened to the piteous cries of its users and built a Send Unix function. This gives you the ability to send a Unix command and get the feedback from the remote machine, without the extra work of building a script-only installer package. This is a Good Thing, but I’m still more a fan of script-only installer packages. Here’s why:
Using an install package to do what you need to do, vs. using ARD’s send Unix command, gives you a couple of advantages:
1. You only need to build it once – I have a couple of packages to
handle turning SSH on or off on ARD-managed Macs. I distributed them for
use by my team. I didn’t need to tell them the command, and I don’t need to remember myself. I just need to push the package called “SSH_On” to turn SSH on, then push the package called “SSH_Off” to turn SSH back off when I’m done. I have a number of packages like that, but that’s the general idea.
2. Shell script packages – Using script-only install packages, I can write
an entire shell script which doesn’t need to stay resident on the target
Mac. For example, I have a Software Update script-only install package. It
does 4 things:
1. Repairs permissions
2. Use the command line softwareupdate tool to get all updates from Apple for that Mac.
3. Repairs permissions again.
I can run all of those tasks separately via Send Unix, but doing it with a package means each machine can run it at their own speed and I don’t have to wait on the B&W G3 to finish while the G5’s been waiting for 10 minutes for my next command. I can push once and be done with it.
3. Send Unix doesn’t doesn’t allow for shell scripting, unless the shell script is already resident on the target Mac – This for me, is the killer advantage script-only installer packages have over Send Unix. You can kick off a previously copied shell script via Send Unix, but you can’t use it without the shell script already being there on the remote Mac. With a script-only installer package, the script is along for the ride.
Send Unix has its place, and I use it frequently. For some ARD functions, however, you can’t beat knowing how to make and deploy a script-only installer package.
One of the much-touted features Apple introduced in 10.4 was Spotlight, its new lightning fast search. Spotlight pores over all the files on your computer, polls the metadata attached to each file, and makes a master index of everything that you have on your computer. Sounds great, right?
Well, not always. Sometimes, there may be items you don’t want searched for and I’m not just talking about porn. For example, do you really want your kids to find your bank records that you have stored on your computer? Or worse, find them and accidentally delete them?
Fortunately, it looks like there’s a way to fix that, beyond using the Privacy tab in the Spotlight preference pane. Anything you don’t want Spotlight to index, put it in a folder and add “.noindex” to the folder’s name. I like this method better than using Spotlight’s privacy because a) you can do it on the fly if needed and b) what’s the point in hiding something if you’ve got a master listing of what’s hidden sitting in the Spotlight preference pane?
Of course, you now still have your (now hidden) file listed in the existing Spotlight database. Want to get rid of it? Here’s how:
In the Spotlight system preferences, go to the Privacy tab and drag and drop the volume you want to re-index into the table. That will erase the index of that volume, as you’ve asked it to now be non-searchable. Just remove the volume from the table, and indexing will re-start and create a new database.
This can also be achieved in the Terminal by using the following command:
sudo mdutil -E /path/to/volume
For example, sudo mdutil -E / will erase the boot volume database. See man mdutil for more options.