Some time ago there were a version of PuppyLinux able to work seamlessy as LiveCd and as a VirtualMachine.

To do that, it used to include a qemu windows binary in the ISO image.

Being able to have the same chance on Win and Mac and have it in the LiveCd would be great.
I don’t think the LiveCd space constrains would allow that, but it would be pretty cool. Or would be cool at least to have a slightly bigger image to be used just on USB pens or DVD.

There should be a brainstorm idea open about this.

ps: “subscription manager” wordpress plugin will make you a better person

Many hackers (including myself) contribute to scratch their own itches, but designers and artists often have other motivations for contributing their work, such as exposing people to their artwork. These people are not interested in submitting hardware bug reports or learning new tools, they simply may want to contribute artwork created with the proprietary tools they own and love. As long as the work they produce is not in proprietary formats, I see no reason not to welcome their contributions.

I don’t like the idea of “forcing” users to use free software in a particular way. If people are interested in working on this and users are interested in using Ubuntu this way, so be it.

Ideally, everyone, including designers, would boot Ubuntu, and contribute using free software tools. I think this is a great way for designers to get their feet wet and start contributing. I imagine that as they contribute more and more, they will become more invested in Ubuntu and will want to actually boot it and check out free tools. Forcing these sometimes skiddish users with strong preferences for proprietary tools and operating systems running on specialized hardware to jump into the deep end doesn’t seem like a practical solution to me.

As mentioned by Evan there are some restrictions when using VBox (or other VMs), yet I am sure that eventually Wubi will be replaced by a VM implementation (I am the author of Wubi), but…

Even disregarding current technical VM limitations, I think that the biggest drawback of a VM approach is what many probably consider as a feature.

The inconvenience of having to reboot in order to swap OS is actually an _advantage_, because it forces the user to try and perform usual tasks with the tools available in the new OS as opposed to swap OS on the fly in order to send an email or a twit. When they have to perform a quick task, the cost of swapping into a more familiar environment outweighs the cost of exploring the alternatives. And so they gradually become confident with the new environment.

Nor do I do think that using a VM in a sort of “seamless mode”, i.e. as a provider of extra applications, is particularly appealing. Seamless mode is great when you have to move _out_ of an OS and you have to fill in the gaps, it is not so great when you have to move _into_ a new OS… Even more so when most of those applications have already been ported to the host environment, which would allow you to perform the same tasks without having to deal with shared directories.

Using a VM so that you can create media work in OSX to be deployed and tested on Ubuntu is the only real use case I can think of, but why would someone contribute to something he doesn’t use?

So IMO making it easy to install (and uninstall) a new OS for a quick demo, but _still_ forcing a dual boot is a good recipe.

In this respect, a log-in session straight into a VM environment would be a very interesting approach, but I am not too familiar with OSX internals.

Another approach is to create a UbuntCamp (BootCamp clone) for Ubuntu, by resizing the partition within OSX and targeting the new partition. That will provide a “real” dual boot installation, requiring a reboot for the installer, but from a user prospective, it would be very simple to install and an uninstaller can probably be pulled together as well.

In either case lots of Wubi code (now in python) can be reused. And of course we have the USB creator.

Finally, I strongly disagree with the argument that a VM is good because the Mac hardware is only partially supported. It is _much_ better to have users try partially supported hardware and submit bug reports rather than making them happy in a cocooned environment, and slow down the Linux progress as a result.