This just makes me think my linux display driver problems were not
that bad :)
On Sep 8, 2008, at 9:02 PM, Greg Guerin wrote:
Robert Koberg wrote:
You must spend a lot of time rebooting.
Nope.
Why not just buy multiple machines for your testing purposes?
I do have multiple machines. But I also have more bootable configs
than machines, hence the partitions.
Is it legal to install the same version of OS X on two different
partitions? (I really don't know)
Each machine came with an OS and has a separate license. The older
machines have a series of upgraded OS licenses. The newer machines
won't run older OS versions anyway, so it's moot for them. And the
really old machines won't run the newer OS versions, so that's moot
for them.
As to duplicated installs of the same licensed OS on a single
machine, I see no legal problems. The license basically says it's
tied to the hardware. I'm also allowed to make backup copies, and
frankly, that's how the replicas get used: potentially discardable
backup copies. Since no single machine can boot multiple partitions
at once, there's never a question of having multiple concurrent
running versions of the same license. If in doubt, consult your own
legal counsel.
To me, it's about the same as virtualized bootable installs, just
not as virtualized.
Are you a professional beta tester?
No, but sometimes it seems that way.
There are times when I have to test a new release (OS, Java,
whatever) and I don't want to compromise the existing install. So I
clone the known-good install to a spare partition, install the new
release there, then boot on that. Assuming the entire disk doesn't
get compromised (yeah, it's happened, so backups are also wise),
this approach lets me test the new release but still revert back
without having to restore from a backup, do a re-install, etc. I
just choose the older startup partition and restart. If the new one
works, then I might keep it active, or even migrate to it. If it
doesn't work, then I can kill it and revert back to the known-good
install without ever having to think about how to un-install anything.
There are other times when I have to go backwards in testing, and
run a new version of an app under an old OS or JVM version, to
ensure it's still compatible, or to check that a new work-around is
indeed working around a bug in that old OS or JVM. So just because
a partition becomes outdated doesn't necessarily mean it's useless.
Situations like this come up regularly enough that I have found it
useful to maintain these multiple bootable partitions. It's what
I've found works best for me for getting my work done, where "best"
means my choice of a balance between cash outlay, equipment
upgrades, equipment additions, equipment retirement, and me
performing installs of older or newer software. I think the
alternatives are worse. So compared to the other alternatives, yes,
this is how I want to do it. If the question is whether it would be
better to have bug-free software releases I can rely on without
having to vet them first, then no, multiple partitions is not how I
want to do it. But until the day when all software releases
everywhere are bug-free on all possible configurations, I think I'll
keep doing it this way.
I should also say that I've been doing things this way for years,
since long before Mac OS 10.0 was released. I have a stack of old
SCSI drives with much older Mac OS versions on them, back when 512
MB of mass-storage wasn't a little card you stuck in a digital
camera. Some day I may weld some eye-bolts on some of those drives
and use them as boat-anchors. Right now, most are stacked in my
closet, but two are used to hold up a shelf, and one is a doorstop.
Always check mass and dimensions first, as YMMV.
-- GG
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden