If you navigate to /Library/Printers, you'll see folders for Canon, Espon, and HP printers. There's no real need to keep the printer drivers lying around for printers you don't have, so you can remove the extra folders to free up some drive space. Since these folders are owned by root, you'll need superuser status to delete them.
Once you cd /Library/Printers, you can just type sudo rm -r [directory_name], where [directory_name] is one of EPSON, Canon, or hp (do NOT type the square brackets). Note that if you do this, future use of any of the deleted printers will (obviously) require re-installation of the drivers. Use at your own risk, but my Canon and hp driver folders have been gone for weeks with no real problems.
I had been running in OS 9.1 for a couple of days. When I booted back into OSX tonight and started mail, I was asked for my keychain password. I have never opened Keychain but no problem, I thought, and typed my user password. No go. So how do I get around this issue?"
Rob F. later wrote back with the solution ... so if you're locked out of an OS X application due to a keychain you haven't used, read the rest of the article for instructions on how to fix the problem.
Thanks to Rob for submitting the solution, and my apologies for the delays in getting it published!
This is really only relevant if you've followed the instructions from StepWise on how to configure and install Apache 1.3.19 and PHP 4.0.4pl1. What I discovered was that when you restart Apache, it will basically hang because of an error related to the apxs binary in /usr/sbin (take a look in the Console app for the exact error).
If you want to run your web server with WebDAV capabilities enabled on it, you will need to download the latest version of mod_dav, configure and install it, replacing the pre-installed module for Apache. The information for installing mod_dav can be found on the mod_dav site, but I will summarize it here.
Read the rest of the article for an excellent how-to on installing WebDAV support onto your new Apache...
If you create a PHP page in Dreamweaver or similar Macintosh application, any bugs will be reported as being on line 1, no matter where they are. This is because the PHP parser is expecting Unix style line breaks. Since it doesn't find them, it thinks the entire page is all one line. This doesn't hurt the running of the PHP code, but it does make it very hard to find any typos or other bugs in the code.
The easiest way to fix this is to open the PHP document in BBEdit and Save As. Click on the OPTIONS button, and select Unix line breaks.
Also, if you are looking for a good SQL tutorial, with a live SQL server, check the following URLS:
The macosxhints.com site has taken off, far faster and bigger than I ever would have imagined. As of today, there are nearly 1,100 registered users, pulling nearly 700mb of data per day from the site. This led me to post a message late last night concerning the future direction of the site (you can read the original post in the remainder of this article). Since I have no revenue streams, the costs of maintaining this growing site were looking a bit daunting.
I asked for help and suggestions, and featured a poll offering some alternatives for the future direction of the site. I was amazed to wake up this morning to a number of emails with positive feedback and great suggestions, and over 35 responses to the poll in about five hours' of night time. Thanks to you, the macosxhints readers, I now have several good leads for new providers with substantially lower costs and unmetered bandwidth, which will alleviate my number one issue. A number of you have also donated to help cover the costs of running the site, which I greatly appreciate.
Based on all the input I've received, the future looks good for macosxhints.com. Read the rest of this article if you'd like to see what's going to happen here in the near future (summary - nothing bad!), as well as the story I posted last night.
In some Cocoa applications, if you command-click the toolbar button in the upper-right corner of the title bar, the toolbar will switch between Icon Only, Icon & Text, and Text Only modes.
I haven't had the chance to test this in many applications yet (primarily because there are still so few available), but it does seem to function in Mail, OmniWeb, Address Book, and Project Builder so far.
Unfortunately, it does not work in the Finder, where it would probably be the most useful.
This is in addition to the tips for added responsiveness.
I've been having problems with the Finder holding up on me after waking up from sleep. The Finder is rendered completely unresponsive as the the kernel takes up 50 percent of the CPU cycles. I then remembered what Steve Jobs said a while back about how Unix doesn't like to be put to sleep. I immediately thought the Energy Saver preferences.
Set the hard drive spindown to Never, and most of the large kernel freezeups should go away.
Hopefully this is fixed in 10.0.1, but for now, this is an adequate solution.
Today I noticed a bug (feature?) in the manner in which Classic 9 handles fonts added to its system folder. Theoretically, this should work just as it does in OS 9 - drag the font into the Fonts folder, and any non-running application that is then launched will see the new font. In copying over a number of fonts from my 'real' OS 9 to my 'Classic' OS 9 today, I noticed that they weren't seen when I launched my Classic application. After a bit of troubleshooting, I found the answer.
To make the fonts usable, I had to restart Classic, not just the apps running within Classic. Once I restarted Classic, I had all my new fonts available. I can't decide if this is a bug, or a limitation of how Classic works. In either event, install the fonts first, then launch Classic to save yourself a Classic restart (at least, that's how my machine is working!).