Last night I decided to upgrade my "experimental" partition from 10.0.4 to 10.1. This is where I test things on OS X before committing them to my production box. As part of the process, I decided to split the drive into a few partitions, as I had a lot of unutilized space. So I ran Disk Utility, partitioned, installed 10.0, upgraded to 10.1, configured a bunch of stuff, and then booted back to my production 10.1 environment. When I went to select my standard Classic partition, this is what I saw:
There were two problems here. The first was that everything was greyed out, the second was that my normal Classic partition didn't even show up! They grey-out problem didn't surprise me, as none of the listed volumes have OS 9 installations. But there were at least three other partitions that did, and they were nowhere to be seen.
Things I tried to fix the problem included copying a 'good' OS 9 to the missing partition (no change); specifying the OS 9 partition as the Startup Disk (as it was visible there), then checking Classic again (no change); and booting on the missing partition and then restarting in 10.1 (no change). Finally I gave up and did a clean install of OS 9.1 and 9.2.1 on the missing partition. Restarted in X and ... no change! Argh!
To save everyone else a ton of time, you may not have to do what I did. At least in my case, the problem seems to have been caused by a bug in the Classic prefs panel, not any issue with Classic itself or my partitions. If you have more than a few partitions (I have about ten total across three drives), the Classic panel in System Prefs doesn't seem to display scroll bars or arrows ... and it didn't seem to respond to the arrow keys, either. After some random clicking in the box and moving my scroll wheel and hitting the arrow keys, I managed to get the box to scroll ... and found the "missing" Classic partitions off the bottom of the display area!
So if you think you've lost a bootable Classic from the Classic prefs panel and you have a large number of partitions, make sure it's not a scrolling problem before investing time in a more complex solution! I'll try to investigate a bit more over the weekend to see if I can figure out exactly when it will and will not scroll ... and I've filed a bug report with Apple :-).
While logging in this morning after doing some work on another drive, I happened to notice that the Finder's keyboard navigation works in the login dialog box. If you have multiple users, just hit the first letter of the user's name, and that user will be highlighted. Hit enter, type the password, enter again, and you're logged in. No mouse required!
If you'd like to put your Mac to sleep while sitting at the login screen, there's a way to do it ... at least, there is if you have an eject key on your keyboard. Control-eject will bring up a "restart, sleep, or shutdown" dialog box, even while logged out. So just log out and then hit control-eject, and you can put your machine to sleep.
It also works, of course, while logged in. I'm not sure of any workarounds for non-eject-key keyboards. Anyone?
The ability to log in as root (versus using 'su' in the terminal) still exists in 10.1, but the mechanism is better hidden than it was in previous OS X releases. In my opinion, that's a Good Thing, as you should probably be logging in as root only if you really really know what you're doing. But enough of the lecture on the dangers of root...
To login to OS X 10.1 as root, first login as your normal Admin user. In the Login pane, click the Login Window tab, and then check the box that reads 'Show "Other User" in list for network users'. Logout after saving the change. When the login box reappears, you'll see "Other User" as an option. Click it, and you can enter "root" as the username followed by the root password.
In over a year of OS X usage, I have not yet had to login to the system as root to accomplish any tasks. But if you do need to (and there are some valid reasons), this is how it works in 10.1.
The window server has a cool feature in OS X 10.1 that isn't enabled by default (though it will be in an upcoming update, as I understand it): window buffer compression.
A little background. Under OS X, the contents of each window are saved in a buffer, so that they can be updated instantly, and also so that the cool transparency effects in Aqua are possible. This is a good thing, to have a fully buffered window manager -- however, it uses a lot of memory.
In 32 bit mode ("Millions" in System Preferences), a window that is 800 pixels wide by 600 pixels high uses up 1.9mb of RAM. When you consider that there are usually over 100 windows open when you're using OS X (not all windows are visible), you start to realize that this can start to add up in terms of RAM usage.
The more windows you open, the more RAM they use up, the more that virtual memory will have to page in and out while you use your applications to do work. This can cause slow-downs as the disk grinds to do the virtual memory paging.
So what Apple did was they implemented a compression mechanism into the window server. When a window's contents haven't changed for a given period of time, the window server compresses them, so they take up less memory. Since it uses a compression method that doesn't require the buffer to be fully decompressed to do compositing (dragging a window around, updating the screen, etc.), you won't notice a slowdown with this compression turned on.
In fact, because less memory is being used up by the window buffers, more RAM will be available for your applications, with will mean less virtual memory paging, and may in fact result in speeding up your machine. Additionally, since less data needs to be read (it is compressed, after all!), things like updating windows may be faster as well.
If you are a power user who has lots of windows open, you might consider giving this hack a shot. I'm using it, and getting compression ratios of about 8.5:1 (in other words, my window buffers are using 8x less RAM than they normally would).
Read the rest of the article for the details on implementing window compression.
Andrew Welch / el Presidente / Ambrosia Software, Inc.
I've discovered that X programs are prone to misbehavior when you make them try to operate on aliases.
The most painful example was when I tried replacing Exploder 5.1's bookmarks.html file with an alias to the one I used under 9... Exploder thought the file didn't exist, and wrote out its default bookmarks.html, which overwrote the original file! Luckily, I had a semi-backup and was able to rebuild from it.
Also, the Dock simply doesn't understand the concept of having an alias to a folder in the dock - after installing 'Classic Menu', I tried to replace the pseudo-apple items folder I had in the Dock with a link to Classic Menu's folder, and the Dock wouldn't do the click-and-hold thing that it does with an actual folder. It's fine with a folder full of aliases, and does the right thing there, but not when the folder itself is an alias.
So... while aliases are a traditional tool for managing different programs that need the same info, be very sure to back up any data you try to alias before testing, as it seems that X's support of them is not quite as transparant as 9's was.
Recently, Open Door Networks published a widely-reported security alert concerning Apple's implementation of WebDAV access to the iDisk in 10.1. The essence of the security hole is that your password is sent in cleartext, where it could be interecepted by anyone sniffing the network.
While I agree this is a fairly major security issue, I had other problems with iDisk in 10.1 -- speed, or the lack thereof. It seemed that, at least on my connection, webDAV access crawled. The disk would mount quickly, but copying even a modest 400K file could take minutes at times. This used to take five or ten seconds.
It turns out that the solution is posted on the advisory page at Open Door Networks. Simply use Appleshare to connect instead of WebDAV. Under the Go Finder menu, select "Connect to Server" and enter afp://idisk.mac.com. You'll get a username and password box, after which you can mount your iDisk like any other Appleshare volume.
This isn't a perfect solution -- it takes me longer to connect via Appleshare (the Finder gets the spinning rainbow disk until the connection is made), and the 15-minute time restriction comes into play again. However, it's worth it in exchage for greater security and the speed increase I get when actually transferring files.
Read the rest of the article if you'd like to know how to make Appleshare access to your iDisk just as easy as WebDAV access.
Some users have noted that access to the preference panels from both the menu bar (under the Display menubar icon) and the Apple menu (Dock -> Dock Preferences) is broken in 10.1. Instead of opening the specific preference panel, they actually do nothing. The same thing may occur in other programs that open system preference panels.
It appears this is caused by the actual preference panels losing their association with the System Preferences application. Although I haven't seen a cause listed anywhere, the cure is relatively easy. Thanks to some anonymous poster on one of the various OS X boards, here's what you need to do to repair them:
In the Finder, navigate to the /System/Library/PreferencePanes folder on your OS X hard drive.
Select any one of the panes and do File -> Show Info (command-I). Then pick the "Open with application" drop down item. If you're having this problem, it will probably read "Not Applicable" as the application to use. This is what we'll fix.
Click on the icon next to Not Applicable and select "Other...". When the file dialog comes up, change "Recommended Applications" to "All Applications". Scroll down and select System Preferences and hit the "Add" button.
You will get a warning box stating "You don't have privileges to change the application for this document only." It goes on to explain that if you make this change, it will affect all documents with the "prefPane" extension. This is exactly what we want to do, so hit "Continue".
That should do it; your preference panels should now be usable from the menubar and Apple menu. I have not experienced this glitch, but the fix has been tested and verified by a number of people already.
In the thread The inseperable duo on the Macworld forums, aRichboy noticed some odd behavior in Cocoa apps. Namely, he was unable to edit certain character sets in some text input boxes. These character sets are known as ligatures.
So what's a ligature? Ligatures are two or more letters that run together in typesetting. Some common ligatures include ff, fl, ffi, tt, and ae. Apple has this to say about ligatures in its Cocoa developer docs:
"Text and Font Support: When you add the necessary objects to your user interface in Interface Builder, your application automatically gains many capabilities related to text editing:menu selection of font families, sizes, and styles and textual attributes such as alignment, kerning and ligatures;..."
What this means in every day use is that you may find yourself occasionally unable to edit a character you've just typed in. In testing last night, it appears to only affect the "fi" and "fl" ligatures. To see this 'feature' in action, open mail.app and start a new email. Type an email address like "email@example.com" in the "To" field. Wait a second or so with the cursor at the end of this string, then hit the back arrow (not the delete key!). The cursor will jump over the "fl" pair, not allowing you to insert anything between them.
This behavior is only exhibited with proportional fonts; monospace fonts in the body of a plain-text email, for example, are not affected.
Not really a bug, but a feature that might surprise you if you're not aware of it. Thanks to aRichboy for pointing it out.
Ever since I upgraded my Powerbook to 10.1, I've been experiencing a hang on boot-up when the OS indicates "Starting Directory Services". This delay has been as long as five minutes or more.
I wasn't getting this on my G4 tower, so I knew that it wasn't necessarily a 10.1 thing, but something that 10.1 brought out. I looked through my message logs (/var/log/message.log) and saw that lookupd was attempting to contact a lot of other machines and failing (lookupd is a software agent that acts as a network information broker).
I also remembered that I had been fooling around with lookupd, trying to set up an ad filter for web browsing and had added a directory called "locations" in my Netinfo database as part of that. I removed the directory using Netinfo Manager and now my Powerbook boots and shuts down quicker than it ever did, even in OS 9.
[Editor's note: This specific tip may not affect a lot of users, but the general tip is to make sure you check the log files to see what's happening to your machine, wether it's a startup stall or any other abnormal behavior.]