It appears that OSX 10.8 removed the tar --tape-length flag, and I see no other way to create split tar archives as described in this hint.
One alternative is to create split zip files using the zip tool provided with OS X.
As described in man zip, the resulting files are not just one big zip file that has been split into pieces, and thus they cannot gracefully be concatenated back together as described in another hint, so this differs from simply using the split command. I needed to send files to a Windows user with 7zip, so split was probably out of the question.
To get 4699717632 byte files that would fit on a DVD I used zip -s 4482m output.zip /source/directory
[kirkmc adds: I'm on the road with only my iPad, so I havent been able to test this.]
I have to agree with Erica Sadun, at TUAW, who writes that Basso, the sound used by Notification Center, is horrid. It makes me cringe, and, because of this, I don't use sounds with Notification Center.
But Sadun found that you can change the Notification Center sound with a bit of a hack. If you go to ~/Library/Sounds and place a sound in AIFF format there, and name it Basso.aiff, Notification Center will use that sound. You'll need to run the following Terminal command to relaunch Notification Center (or restart your Mac):
You'll have a much better sound for notifications. I really think Notification Center should not only allow users to change the default sound, but also choose specific sounds for different applications, the same way you can choose a specific ringtone for different callers on iOS.
I like to use images of various quotes as my screensaver, but the default 3-second duration for each slide isn't enough for several of the quotes. After discovering that Apple, amazingly, no longer provides a built-in way to alter the duration of each slide, I set out to figure out how to change it to suit my preference. It works, but it's a bit of a pain, so if anyone knows of an easier method, please contribute.
I found the method on this page from CNET, the author of which apparently found it here. In 10.8, no matter how I tried altering the permissions of the relevant file and folder in the Finder or "unlocking" the file (as XCode refers to it), I could not get XCode (or TextWrangler) to write to the file, so I had to alter the CNET instructions a bit. (Side rant: I feel justified in refusing to resort to the terminal for a simple permissions change, a capability that has supposedly existed in the Finder for 9 major iterations of OS X.) Do the following:
Navigate to this folder in the Finder and find the file called "EffectDescriptions.plist": /System/Library/PrivateFrameworks/Slideshows.framework/Versions/A/Resources/Content/
Option-drag the file to create a duplicate copy and rename it "EffectDescriptions.original.plist" (just in case). Authenticate when asked.
Drag "EffectDescriptions.plist" to the desktop (it will copy).
Open the desktop copy in XCode, TextWrangler, or your preferred text editor.
Hit Command-F to search for the entry called "JustASlide" (this works in XCode and TextWrangler).
Find the sub-entry called "mainDuration." Change its numerical value from 3 to whatever value you prefer (in seconds).
Save the file, close it, and drag it back into the folder you copied it from. It will ask you to authenticate, and then whether to replace the file. Do both. (You did do step 2, right?)
This will set the permissions of the file as they were before.
Go to System Preferences and confirm with a slideshow preview that your change was effective.
As I said earlier, this is an ugly way to accomplish what should be a very simple preference setting, so if anyone knows of a more elegant solution, please share. I toyed with the idea of having a separate screensaver file in my own Library folder, but I wasn't able to determine whether that would work. Given that we're altering this setting in a private framework, it seems to me that it wouldn't.
If you like Notification Center, in Mountain Lion, you may also like its "Do Not Disturb," feature, where you can turn off notifications if you're busy and they get to be a bother. There are a couple of ways you can do this: you can Option-click the Notification Center menu bar icon, or you can scroll down when Notification Center is visible, and toggle the slider to OFF.
On iOS, you can schedule this action, but not on OS X. Ben Waldie, writing at TUAW, posted an interesting AppleScript/Automator solution to this. You can create an Automator workflow, and set it to run in Calendar, so you can have the Do Not Disturb feature turned on and off at specific times. It's a bit ham-fisted, to be sure; it uses a defaults write or defaults delete command, then a killall NotificationCenter command, which is essentially force-quitting Notification Center and allowing it to relaunch. The problem is that if anything goes amiss, Notification Center might not relaunch.
It's too bad that there's no built-in way to do this. But this is a good solution for now, if you really want to turn Notification Center off and on at specific times.
This recently published "File : / / /" bug (see this Macworld article for an explanation) is a huge problem and can be seriously exploited to crash Mac apps, especially Messages. If someone sends you an iMessage (from an iOS device to Messages for Mac), Messages will continually crash, rendering it completely useless.
This is a Warning - please DO NOT SEND a message with that content over iMessage. I do not suggest you test this bug. However, despite these warnings, trolling people will still send it to crash their friend's message machines.
Below are three fixes to make iMessage workable again:
FIRST (and easiest): Send 30-40 (lines of) iMessages back to the sender. The idea here is to lengthen the iMessage log so that the File : / / / message is not loaded when Messages starts up. You can either send these from an iOS device or from a Share button, such as the one in Safari. Continue trying until you can open iMessage again. Then, delete the conversation with Command+Delete.
SECOND: Remove the "chat.db" message database from ~/Library/Messages. This will remove all Messages conversations.
THIRD: Edit "chat.db" to delete the offending message. You will need to do this with an sqlite editor not subject to the crash (most that I tried do not crash). The message will be found in the "messages" table.
[kirkmc adds: This is, indeed, a serious bug, and it's quite simple to send a denial of service attack to someone using Messages. As the poster said, do not try this juts for fun. You may want to try it in other apps just to see that the crash does, indeed, occur, but at your risk and peril. It's really quite surprising that a bug of this nature got through Apple's QA...]
In iCal (10.7.4 and below) there was a Debug menu that among other handy features allowed the enabling of iCal to use the system highlight color for today. The feature still exists in Calendar (10.8 and above), but must be added manually to the preferences.
In order to enable this feature without the Debug menu all you must do is add the CalUIUseSystemHighlightColorForToday key to the ~/Library/Preferences/com.apple.iCal.plist preferences file using any plain text editor (both TextEdit and TextWrangler would work).
First quit Calendar, then edit the plist, and upon relaunching Calendar it should be using the system highlight color selected in the General» Appearance panel in System Preferences.
[crarko adds: I tried this with the 10.8.2 Calendar.app and I believe it worked. I opened the plist in BBEdit and copied and pasted an existing key/value combination, edited the key to match the name above, and set the value to true. I saw some highlighting respect this, although I can't say I'm completely sure what all the intended effects are. Perhaps the submitter will see this and clarify what to look for.]
While better than Lion's behavior, the lack of a true "Save As..." in Mountain Lion frustrates me. I never really saw anything wrong with the old style Autosave feature, where a temporary file gets saved periodically until you close the original file. I liked being able to edit a document and then retroactively apply all changes since the last save to a new file with a different name and location from the old file.
This is what's wrong with the "Duplicate" command, which, when it duplicates the file, includes all the changes since the last save. This forces the user to be prescient about what sorts of changes they may want to make to the file at some point in the future, whereas the old "Save As..." helpfully allows you to move all your recent changes to a different file. Unfortunately for most Apple applications, you are stuck with the new behavior. However, for TextEdit, there appears to be a way to revert to the software's Autosave and "Save As... " to that used by computers since the dawn of time.
In this hint I described how to turn off the auto-save feature for an application, which at least in TextEdit causes the true "Save As..." menu item to re-appear in the File menu and enables the Command-Shift-S shortcut to act as the real "Save As...," not "Duplicate."
When doing this however, there was one problem: the new sandboxing "feature" of OS X does not allow the old auto-save feature of TextEdit to make changes to the document's working directory, so you get annoying pop-up error messages every time TextEdit tries to make the Autosave file. Here how you can fix that.
WARNING: We will be replacing the developer's code signature for TextEdit in this hint. If you have qualms about disabling security features on your computer, stop reading here.
First, open a Terminal window and make a back-up of the application, in case we break something:
ditto TextEdit.app TextEdit.backup.app
Now, we're going to use codesign to force (-f) the application to use a alternate signing identity (-s). The one we'll use is the dash (-) sign identity. This means the code will use an ad-hoc signing identity, which supposedly means that significant restrictions apply (see the man page for codesign ), but it does seem to allow TextEdit to write to a user's directory so it seems like in this case it's significantly unrestricting the app's permissions. Note that when you do this next step, it will reset the preferences for TextEdit. Also note the second dash after the dash-s, "-s-":
sudo codesign -f -s- TextEdit.app
The normal way to disable the new auto-save is the following:
defaults write com.apple.TextEdit ApplePersistence -bool no
But I couldn't get that to work. The only thing I could think of to do was get rid of the lockfile (not sure this part is needed?) and then copy TextEdit's .plist file to a directory where I could write to it, and then copy it back. Note that in this next part, I am putting a copy of the .plist lockfile and the .plist itself into root's home directory (/var/root) before doing things to them:
That's it! Now go enjoy your favorite text editor behaving the way it should be. This trick won't work for any other applications (e.g., Keynote); the "Save As..." menu item doesn't reappear when you disable the ApplePersistence.
[kirkmc adds: I haven't tested this. The warning at the beginning should be sufficient for anyone squeamish about trying something like this.]
First, I needed to put two drives in my Mac. I already had a Crucial M4 SSD and 500GB HD so I a bought hard drive caddy and put my 500GB Momentus XT in it.
That was the easy part. Now how to make them work? In Jinx's article you can read that GUI Disk Utility does not offer needed functionality. It's available only in command line version, diskutil. But from my previous installation I remembered that there is access to terminal in OS X's recovery mode.
It was downhill from there. Create a logical volume group, get the UUID and create the volume. The OS X Installer recognized the volume and installed nicely. After the whole process was over, I did tests similar to those that Jinx mentioned and the drive does, indeed, behave like a fusion drive - files used more often end up on the SSD and less used are shuffled to the HDD.
[kirkmc adds: I don't usually run hints that don't explain things, but the first article linked above goes into great detail. I'm tempted to try this out, as my Mac mini has both an SSD and a 750 GB HD, but I'd need to move all the files - my music collection - from the HD to an external drive. I might try and get to it this week.]
If you have Twitter handles for your friends and colleagues in your Contacts, you can easily view tweets those people have made. Just open a card in Contacts, click on Twitter, then choose View Tweets. If you have the official Twitter app installed, it will open displaying tweets from that person. If not, a web page will open on the Twitter web site.
You can also tweet to someone from OS X by clicking on Twitter, and choosing Tweet, as long as you have set up your Twitter account in the Mail, Contacts & Calendars pane of System Preferences.
While viewing tweets is nice, it would be even better if they could open in one's favorite Twitter client. But that would presumably involve hacking Contacts. Anyone interested in trying to figure it out?