Hot Multi-OS Switching — Why Isn't It Everywhere? 239
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."
Virtualization (Score:4, Informative)
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.
This isn't really hot-OS switching. (Score:3, Informative)
> 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.
MS Windows on Mac H/W is not new (Score:2, Informative)
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.
Re:Kubuntu does just about everything I need it to (Score:4, Informative)
Uh.. we're really happy for you (I guess) but miss the point much?
Re:Hibernate and restore? (Score:5, Informative)
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.