Can't be done.
From Blogger, there's no exit:
Blogger Help : How do I cancel my account?: "How do I cancel my account?
We do not currently have a way for users to delete their own accounts...
Blogger Help : How do I cancel my account?: "How do I cancel my account?
We do not currently have a way for users to delete their own accounts...
MacInTouch: timely news and tips about the Apple MacintoshArt is apoplectic, but those who've followed Palm's swan dive into misery [1] know that that their "doers and visionaries" abandoned ship long ago. They're running on fumes now.
Art McGee raised a red flag about more file-permission abuse by bad installers:
I have just examined the contents of the Palm Desktop 4.2.1 Revision C package installer, and I have come to the conclusion that either PalmOne is intentionally trying to damage our computers, or the software is a trojan horse that someone uploaded in place of the real software.
After the program files are installed, the installer runs a shell script called "postflight" that attempts to "fix" any permissions issues which may prevent the program from running properly. Unfortunately, the script violates the most basic programming principle in the universe - thou shalt not alter the files of programs other than thyself - and it does it so blatantly that I can only assume malicious intent. At the end of the script, it runs a final set of commands to change permissions (The "$2" variable is replaced at runtime by "/"):..
While any bad changes to the "/", "/Applications", or "/Library" directories can be easily fixed by repairing permissions or issuing another single command, the most OUTRAGEOUS and potentially damaging change is the last one:
sudo chmod -R 775 "$2Library/Application Support"
sudo chown -R :admin "$2Library/Application Support"
The "/Library/Application Support" directory is where many programs place critical system-wide configuration and program files that are referenced on an as-needed basis. This is a directory whose permissions should NEVER be changed or altered, lest you end up breaking many of your installed apps. In particular, all sorts of system-level programs such as Anti-Virus and Disk Utilities place parts of themselves there, and any changes to their permissions will prevent them from loading at boot time. Even more dangerous, some programs place symbolic links from that directory to "/System/Library", and running a chmod command that recursively drills down that directory could end up completely trashing your entire system...
Reviving Failing Drive
MacInTouch Reader
I recently managed to recover data from a failing hard disk using a rather unusual technique, which has come to be known as "the freezer trick".
The symptoms exhibited by my failing 80GB IBM DeskStar seemed quite odd when you think of hard disk failures. Usually failures are sudden and complete. However, in my case, a week ago I noticed strange pauses in operation (most obvious in iTunes playback, as my music was stored on that drive) that lasted up to 30 seconds at a time. I suspected maybe some background operation such as Spotlight had taken excessive CPU and/or disk time, but Activity Monitor didn't provide any clues. I then checked Console, and eventually I started seeing I/O errors referring to my IBM drive. At this point, I suspected a directory error and repaired the disk using Disk Utility. The intermittent access problems persisted but running Disk Utility actually turned up nothing wrong with the drive. Furthermore, SMART status always showed "Verified". I started backing up data from the drive.
Still, I had intermittent problems accessing the drive. Eventually, the disk would disappear and become unmounted. Disk Utility would actually not list the drive anymore. This also resulted in the Slave drive on the same bus disappearing at the same time. The only remedy was to restart, and it would operate normally for a while again. I then thought perhaps something was wrong with the Ultra ATA bus. So, I tested the IBM drive on the IDE/ATA bus by swapping it with the DVD-ROM drive on that bus. The slave disk worked fine, but the IBM drive still showed problems. I therefore suspected the IBM drive as having the problem.
At this point, following another failure, it would no longer spin up on restart. I left the drive overnight and figured it would be OK the next day. It wasn't. At this point the drive was inoperable, but I still needed to back up some of its data. Time for last resorts.
I remembered the recent posting of a tip on MacInTouch about whacking the drive with a wooden mallet or screwdriver handle. I tried this, and it didn't work. I suspected "sticktion" as the drive appeared to make noises, but wouldn't spin up. I then searched the Internet for ways to revive an IBM DeskStar (aka "DeathStar" on many forums). I soon came across mentions of "the freezer trick", which was actually also mentioned on MacInTouch as well. Several people reported limited success in reviving "stuck" disks (from IBM and others) by using this method.
Essentially, in "sticktion" cases, the mechanical parts seize up, and a couple of methods may work to free them again (if only temporarily). "The freezer trick" is to put the drive in a sealed ziploc bag or wrap it in plastic food wrap, and put that in your freezer for a couple of hours. (I also put that inside a plastic case so that it wouldn't stick to the freezer.) This causes the mechanical parts to contract, hopefully freeing whatever is stuck. To my astonishment, it actually worked! I was able to backup all of the remaining data from the drive. The key is to keep the drive spinning. Once it spun down or went to sleep, it would not spin up again. I re-froze the drive for an hour and it worked again on reconnection. Obviously, people should only try this method as a last resort, and only in "sticktion" cases.
Additionally, I remember from a very long time ago (maybe 15 years) I had ongoing sticktion problems with an external SCSI hard drive that could be remedied by placing it in front of a dehumidifier for a couple of hours.