DragonFly users List (threaded) for 2005-12
Re: Fwd: How do I instal Dragonfly BSD from a hard drive - rather than CD?
Emiel Kollof wrote:
Forwarded to the users list (The forwarded post is below) and also a reply to
this guy. I know it's a troll, but I thought it was way too funny for you
guys to miss. It nearly made me choke on my morning coffee. This guy owes me
a new keyboard because coffee | nose > keyboard.
Heck for this reason alone I'll bite ;)
Emiel, you are too easily amused... ;-)
Installing in windows is not possible, was never possible, and will never be
possible. DragonFly is not a windows application. It's a full blown operating
system that wants absolute control over your hardware. It's way easy to just
dedicate a partition for DragonFly and just boot from network/cd and install.
Spiritually correct, ;-) ... but technically inaccurate.
Not that I recommend it, BUT DragonFly should be comparable to other
*n*x in this regard:
- I have run FreeBSD under Connectix / Innotek beta Virtual PC on OS/2
Warp 4.X host.
- Likewise FreeBSD and Linux under eCS SVISTA beta. (eCS host)
- Likewise FreeBSD and Linux on Mac OS X, VPC 5.X and 6.X
- Also OS/2 on Mac OS X host with VPC 5.X & 6.X
The only one that actually seems to be able to 'pierce the veil' of the
virtual machine is OS/2, which takes around three hours to convince that
the emulated environment can be used. No surprise, given the way it
tests hardware before installing.
As Connectix sold VPC to MS between VPC 5 and 6, all of the above should
be as do-able on an NT-family WinBox as any other.
So DragonFly BSD should be no less 'installable under Windows' than
FreeBSD or Linux,
i.e - while the 'guest' OS has full use of what it perceives as its own
hardware, the 'VPC' is itself a task under the host OS.
Needless to say, there are other alternatives to VPC or SVISTA when the
host is Unix/Linux.
Handy for the wandering sysadmin to do with emulation of client
environments on a single laptop.
There is however, another very practical use for development:
The VPC can be stopped and stored in a 'frozen' state.
In this mode, VPC stores the *entire* emulated environment, machine,
data, memory, CPU register and program-counter, etc. in a container file.
That container file can be e-mailed to a co-worker with a compatible VPC
environment, and opened in the identical state as when frozen. But half
way 'round the world.
That might yet be of value for debugging, and partly because the
emulated machine is 'standardized'.