Slashdot Mirror
Hot Multi-OS Switching — Why Isn't It Everywhere?
First time accepted submitter recrudescence writes "Slashdot readers might remember the Touchbook announcement from Always Innovating stirring up a lot of excitement in the Slashdot community back in 2009 (almost a year before the iPad was announced and essentially killed this off, and way before the Asus Transformer, which is essentially the same idea). The company's new product seems to support Hot multi-OS switching, supposedly with a minimal performance penalty. What seems strange to me is, why haven't other developers jumped in on this already? Macs, for instance, made a huge campaign of their products' new ability to finally support Microsoft Windows, yet (disregarding emulation options) they're still limited to booting to a single working system at any time."
Do you mean a pirated copy?
People have been doing this for ages, it's called virtualization. There are even modes which seamlessly integrate application windows running under different operating systems, and to share folders. So this allegedly new technology appears to be a step backwards.
> All OS are running on the 2.6.32 Linux kernel, and got several optimizations to take benefits of the advanced instructions available in the chipset.
>
> Note that you will not be able to install Windows OS or Mac OS on the Touch Book or the Smart Book.
Yes, you can do some cool things with linux. Including switching out the userspace pretty quickly. That's all that this looks like. The kernel isn't changing, from the looks of it.
Macs, for instance, made a huge campaign of their products' new ability to finally support Microsoft Windows
New? Finally? Apple's Boot Camp utility has been installing MS Windows and Apple supplied drivers on Mac hardware since 2006.
made
In the past tense.
Inconsistent design is generally considered a bad thing.
For non-techies, switching operating systems is akin to learning a foreign language. You're lucky to get a typical Windows user to even try Linux or OS X long enough to become minimally proficient. Software like VMWare utterly baffles most people, and expecting them switch between OSes with different file structures and interface paradigms every time they start an app is an accident waiting to happen.
"Why can't program X see my USB stick?" ...
"Why won't program Y print to my printer?"
"Where did all my files go? I can't even find the C drive!"
"Why isn't my headset working?"
"Why do I need Windows Updates on my Mac?"
How can I believe you when you tell me what I don't want to hear?
Probably Not going to be coming to joystick ports anytime soon; but is considered a feature of interest for things like high speed NICs, GPUs, and other such devices
With the IOMMU virtualization in current Intel and AMD chips, any PCI device can be slaved to a VM. The trick is that things like joystick ports aren't usually their own device, but rather hang off of a PCI bridge that can't handle single-root virtualization, but is part of an aggregate root device that can. So, you wouldn't always be able to pick and choose just one device.
In Linux, use "lspci -vt" to see the device tree. Any device that is just one level off the root can generally be slaved to a to a VM. I use this feature for an eSATA card and video capture cards and it works fine.
Here's the thing - multi-OS is confusing for people. No one is clammering for it because no one is going to get a device and then figure out how to load another OS on it. Think about it - how many people do you know (outside of your circle of geeks) that has a clue you can even load another OS? No manufacturer is going to preload two OS's. And, the geek community really isn't large enough to support sales of consumer devices.
People seem to be perfectly content having multiple devices. I don't know anyone who really uses Bootcamp, but I know quite a few Mac users that also have a Windows laptop laying around in case they need to use it, or the occasional VM. (Most Mac users I know seem perfectly content telling their PC brethren "I can't open that" and making them resend it in another format rather than try to figure out why their overpriced, shiny toy can't do something.) In the tablet world, there's not a lot of interoperability needed because there always seems to be An App For That.
----- obSig
VMs may do the job, but they take so much RAM!
What they don't hog, though, is CPU time when they're merely sitting idle. The joyous fruits of hardware-accelerated virtualization, indeed!
And if RAM usage is a problem for you, then I might suggest you stop buying RAM from OEMs. I bought a used i7 board and CPU from my boss, and populated it with 24 GB for about $180, and this was several months ago. Doing so today would cost even less.
Point is, I can't think of a situation outside of running several VMs that would require more than 4 or 6 GB for the average power user today, and even if you are running VMs, stretch that to 8 GB (which would cost you about $50 for RAM) and go on your merry way and virtualize your heart out.
Boot Windows, Linux, and ESX over the network for free.
Your reply is "I personally am happy with my OS"?
Uh.. we're really happy for you (I guess) but miss the point much?
Some people figured out how to use rEFIt do that with Linux and Mac OS X. But too many people used this without understanding what they were doing, and the rEFIt author was annoyed with having to support that, so he fixed rEFIt such that it would no longer permit this.
/, /usr, and /home are likely to always be busy.
The main reason it cannot work is the file systems. If you have the same file system mounted read/write in both systems you are going to corrupt it. Read only access would be fine except from two problems.
Some journalling file systems cannot be mounted read only. If you tried to do this with ext3 (that's the journalling file system I have the most experience with), the ext3 driver will not respect the request to mount the file system read only. What will happen is that the first system will leave the file system in a busy state. The next one that was supposed to only mount it read only will see that the file system was not cleanly unmounted and will mount it read/write, then clean up the file system, and then remount it read only.
So, even if you thought you had configured it correctly, the OS instance that was only allowed to read still wrote something. Then you switch back to the one that is allowed to write, and since it doesn't know that something has changed the disk contents behind its back (and it wouldn't have been able to deal with it, even if it had known about it), the next write is potentially going to corrupt the file system.
The other problem is that even if you can mount the file system completely read only, the file system driver still doesn't expect the contents to change underneath it, so once you have been in the OS instance that is allowed to change it, and then switch back, bad things may happen.
To some extent you can get around the problems by unmounting file systems before hibernating and mounting them again when restoring. But if the file system was busy and couldn't be unmounted, you will be in trouble. In particular stuff like
The safest approach would be to not access any file system from both systems. But that makes sharing data between them hard. If you were virtualizing and had both running at the same time, you could use networking file systems. But that isn't going to work when they are not running at the same time since one is always hibernated.
You have a bit of the same problems with USB attached file systems. I guess those are unmounted when the system is hibernated, but I don't know what systems do if the USB stick is busy at hibernation time. You can probably mess up things badly if you put a USB file system into a situation that is almost impossible to handle.
If you have a USB stick with no important data on it, then you can make the following experiment.
Continue in this way by alternating which machine gets to write until the media is full. Notice that at no point do you move the USB stick while the system is running, you only move it while both machines are hibernated. My guess is that you will find that management of free space gets messed up badly, and the two files will be claiming to own the same physical areas of the media.
Removable file systems tend not to be busy all the time and not likely to get into such bad situations unless you put them into challenging situations like I described. But there are file systems that you expect to be mounted and busy all the time while the system is running. On those the risk of such problems is much higher.
Do you care about the security of your wireless mouse?
Man, the slashdotters are sure keeping me laughing today. Why in the world would you EMULATE an x86 PC on x86 hardware?
Man, I got tears in my eyes from that one...
I do not fail; I succeed at finding out what does not work.