Tag Archives: leopard

Apple worse than Microsoft regarding browser policy

Many thanks to the Multi-Safari project for working allowing one to use Safari 3 on a system that had been upgraded to Safari 4.

For some reason, Apple chose to not let one uninstall Safari 4 once his system has been upgraded to it. Removing Safari 4 with AppZapper still would not allow me to reinstall Safari 3. Had it not been for Multi-Safari, I’d still be having my issues.

So why did Apple choose such a Microsoft-like approach to the browser? I should be able to uninstall the OS-included browser firstly, and secondly, I should be able to then reinstall the prior version of the same browser.


VMware OS X Bug & Forest Fires

From VMware Forums: Avoid potential data loss due to Apple bug and “Optimize for Mac OS application performance” preference

After I made my last post about my Fusion VM issues, B.G. of VMware contacted me suggesting that I confirm my Fusion optimization settings. Unfortunately, it had nothing to do with it as I already had configured for Optimize for virtual machine disk performance. (Thanks anyhow again B.G.) I’m fortunate to have a decked out MacBook Pro (2.6 GHz Intel Core 2 Duo, 4GB 667 MHz DDR2 SDRAM and a 200GB disk (because size does matter): I planned this laptop explicitly to run OS X/Fusion (with all my sub-OSs), Ubuntu and Vista (GFI/Boot Camp).

Prior to posting here, I was at the VMware web site for an update for Fusion and/or Tools/openvm-tools that I might apply prior to updating Leopard. In any case, I’m about to do the Leopard 10.5.3 to 10.5.4 update that I’ve tested already and have three backups to protect against the worst case (and I’ve tested one of them – better than total trust, eh). I’m not too worried because my key files are replicated through more than just the three backups (to multiple offsite hosts).

New life from the remains of a scorched forest.

Sometimes I have a silly desire to want my systems to die in an update. Having witnessed, read about or fixed so many OS update failures in my life, it’s a bitter-sweet event that one can make the best of. Similar to the results of the forest fire I saw outside my family’s home in Pine, the “scorched OS” event is sad but awesome at the same time… the cycle… the chance to begin anew, fresh…

Mac VMware Fusion and Linux Machines Blip

Oddly, after updating to the newest VMware Fusion on my MacBook Pro, EVIL gremlins decided to attack my VMs. Little pests they can be.

For the record, I updated from Fusion 1.1.2 to 1.1.3 prior to completing 10.5.2 to 10.5.3 Leopard update which fixes a notorious , wicked bug (system lockups under intense disk usage). Of course running as many windows/tabs as for I am famous in my circles on my host and guests combined, frequently pegs my disk I/O. Afterall, isn’t that for what preemptive multitasking exists – to maximize your productivity and that of your system by combining workloads with safe, proportionate resource assumption.

For the uninitiated into VMware, it’s guests, the hosted Virtual Machines, best perform and function with a package called VMware Tools. The VMware Tools package handles some pretty core items such as connected state of the hardware (e.g., audio and network controller), time synchronization, and virtual disk management (e.g., shrinking). VMware makes excellent tools for their Windows hosts and satisfactory versions for non-Windows systems such as Linux and BSD. I’ll cease my foray into VMware here and get back to the point.

When one upgrades a VMware host, there is a period which the guests will be running the old VMware Tools on the new version of the host. Additionally, on non-Windows systems, you must compile the Tools packages yourself. I don’t like to rush to conclusions, but it would seem that this combination alone may not have played well together. As a result of a short run the following occured across my VM guests.

  • My CentOS virtual machine became non-responsive.
  • My Ubuntu virtual machine’s network PCI interrupt became permanently disabled.
  • My KNOPPIX virtual machine became non-responsive until reboot.

I rebooted the CentOS guest and needed to run massive filesystem repairs (ultimately, I chose to restore to a backup).

The Ubuntu machine is a long story but the way I resolved the issue was to add/hook into another set of network cards, leaving the original momentarily. The new controllers came up on alternate PCI addresses and work fine under the old and recompiled binaries.

KNOPPIX is just nice – it will always be one of my favs… I just rebooted it of course.

I hadn’t had my other VMs in use and need to rebuild their tools (BSD-based)… I build them on a different system like a good boy so I can install them straight off the bat.

All is well… this only reinforces the need to have regular (and tested) backups for more than just your data. Your time is worth it let alone the mitigation of risk.