The Adventures of Systems Boy!

Confessions of a Mac SysAdmin...

Should Labs be Dual-Boot?

With today's official arrival of Windows-on-Mac, the question has already been posed, both online and to me personally. All day long people have been emailing and stopping by my office to talk about this development. It's truly incredible. And, of course, one person even suggested, as I knew someone would, that we purchase all Macs for the lab and make everything dual-boot Mac OS X and Windows. This is not the first time something like this has been proposed. In fact recently students were clamoring for dual-boot Linux/Windows systems (though what they really wanted was more Windows and fewer Linux systems). This issue just keeps coming up, and at this point I'm starting to wonder if it's not a terrible idea, and how to best implement such a thing.

My arguments in the past were essentially threefold: 1) Users who are less technically inclined would be put off by dual-boot systems, and we're really trying to make things simpler around here, so complicating the boot process was maybe not the way to go; 2) Building two systems for every computer equals twice the work; 3) Maintenance and troubleshooting system problems becomes exponentially more difficult. Let's address these point by point.

Inexperienced User Issues
I worry that new or inexperienced users would find the dual-boot process intimidating. While I still think this holds true to some extent, I must admit the bootloader provided by Apple looks astoundingly easy. Downright appealing in fact. I would expect nothing less from Apple. I think this minimizes, but does not negate, the difficulty factor for new or less experienced users. But I'm also on a big push here in this lab to simplify the way things work in general (in the grand Apple tradition). Currently everything from logging in to file sharing is just too complicated. And needlessly so. Making all our systems dual-boot would only add to the confusion. So if we ever added this wrinkle, I'd want to vastly simplify what we currently have first.

Twice the OSes Equals Twice the Work
Any computer that is dual-boot must have both Windows and Mac operating systems installed on it. Each OS must also have a full suite of applications installed. Thus, building such a system would require twice as much work as its single-boot counterpart. If there were a way to build one dual-boot system and then clone it to our other computers it would greatly simplify things. But something tells me that it won't be that easy. I have a feeling the Mac will not be able to clone the Windows partition, making rollouts an absolute nightmare. If it turns out not to be so bad, it will do a lot for recommending the dual-boot paradigm. But we shall see.

Maintenance and Troubleshooting Issues
A dual-boot system is not only twice as much work to build, it's also twice as much work to maintain. Any update that needs to be applied, be it system or software, must be done from the appropriate OS. So if a system is booted in Windows, and I have Mac updates to perform, I have to physically walk over to that system and boot it into the Mac OS before I can perform the update. Any system or hardware problem the computer might have must also go through additional new layers of troubleshooting. And if the fix requires any sort of wiping of the hard drive, restoration of the affected system will be twice as difficult as it would on a single-boot machine. Not to mention the fact that, although this probably wouldn't be the case, it is possible that a dual-boot system, because of its complexity, would be less stable than a single-boot computer.

Pros and Cons
So I ask, should the lab be dual-boot? After thinking about the above points I would answer no. At least not our lab, and at least not yet. There are situations in which multi-tasking scenarios are desirable, but there are also situations in which dedicated systems are preferable. In our lab we have a pretty good balance of dedicated Windows and Mac systems. We have enough of each system so that every user gets enough time in his or her operating system of choice. Systems are continually in use, yet no one is fighting for resources. We don't need more Windows machines, and we don't need more Macs. So the only advantage I can see to a dual-boot lab is the convenience of choosing your OS from any computer. The potential drawbacks are many, however: greater confusion, system instability and significantly more work for our systems staff, to name a few.

I can see situations in which dual-boot machines would be a huge windfall. Specifically, if you have a limited computer budget, you now have the capability of getting twice the bang for your hardware buck with an Intel Mac. Every computer can essentially be two computers, as long as it's an Intel Mac. But our computer budget is not limited, and there may still be good arguments for using non-Mac hardware for a lot of the things we do here. So I don't see lab-wide dual-boot systems for our lab anytime in the near future.

But then again, you never know.

UPDATE:
Looks like I'm not alone. Other lab administrators chime in. Here's a choice quote from rambleon.org's Jay Young that sums up exactly how I feel about all this from a sysadmin point of view:
"It’s hard enough for any one of us to keep one Operating System maintained, let alone two. Especially when you have to restart the whole system to get to the other one."

Right on, brother!

Labels: , ,

« Home | Next »
| Next »
| Next »
| Next »
| Next »
| Next »
| Next »
| Next »
| Next »
| Next »

1:55 AM

you are wrong    



3:04 AM

While I agree it's twice the effort, if you don't have this automated already you're in deep trouble. If you do, then all you have to do is reboot a room of machines and then run your updates on the other side as needed. I don't know if there is a way to script this remotely yet, but I'll place bets it will be done in short order. Once a remote "reboot the lab" setp is in place, then you can easily switch the lab between classes, or switch individual machines as needed when people come in.

As to the issue of end-user support that has been brought up elsewhere - what support? Do you support Linux on their PC's? Unlikely. Similarly, why should ou be expected to support Windows on the Macs?    



3:44 AM

I'm a little unclear what you're referring to when you speak of having this automated. Having what automated? Rebooting the workstations? I do not do automated reboots of workstations. That sounds insane to me, at least for our work environment (which is a full-time, 24 hour production lab, not just classrooms).

Or do you mean automating the updating of system/application software? Again, this is much more complicated to automate if you have no idea what state a machine is in at a given time. There's an update to Photshop for Mac? Well, now I have to find all the Macs that are running Windows and reboot them into OS X before I can install the update. Those machines are now offline to any Windows users. What a drag. Dual-boot systems complicate the automation process for software updates immensely.

Yes, it's also very easy to reboot a room full of Macs (though not very easy to get 20 people to log off of those Macs at any one particular time). But this too becomes far more difficult when some of those Macs are running OS X and some are running Windows. Now I have to figure out which block of machines is running Windows, and which is running OS X and then reboot each block into the desired OS with the appropriate tool for the given OS. Again. Twice as much work.

Now, if it were twice as much work for a huge amount of benefit, then fine. That would be worth my time. But the benefits are extremely minor: Users can run their choice of OS from any machine. Well, so what? Users aren't really having trouble getting on Windows or Mac boxes in my lab. I would see no improvement in system availability. So this doesn't really help me much, and it causes me a lot more headache.

It's a complicated solution to a problem that, frankly, we don't have.    



3:47 AM

Dear Rex,

Um... No I'm not...

-systemsboy    



11:26 AM

Yes I agree-twice the effort to do lab updates and support two systems on one computer. I support 185 computers. Making 100 dual boot increases my support to say about 285 computers. Being the entire/only IT person in my department makes this just not possible.

Keeping CS3 and the Apple system software updated requires going to each machine and logging in as an admin user. You can't use Remote Desktop to to the Adobe updates.

Also lets address the cost issues. If you want to run Microsoft Office on both operating systems you have the extra costs for both licenses. Plus you will need to pay for the Windows operating system license and also pay for the Apple OS system upgrades as well.

Extra cost, extra work, and no real need to have dual-boot computer labs kills the entire idea of having dual-boot labs.    



11:55 AM

Toast,

Tell it brother.

If you're not aware of this series I've been working on, you might want to take a look. It's all about managing OS and software updates as much from the server/network as possible. Might be some tricks there you don't already have.

Or maybe you do, in which case, good for you.

-systemsboy    



2:22 PM

Been a long user of Netboot along with Mike Bombich's apps: NetRestore and Carbon Copy Cloner.

Never was able to get the a Windows partition to work using NetRestore but since I've only got three users(including myself) that have a dual-boot system I've given up trying.

As far as using Package maker I'd spend as much time creating and testing the package as doing Adobe CS updates so I don't bother...

Doug aka Toast    



2:31 PM

Doug,

It's true, PackageMaker does not seem to help much with Adobe updates. Unfortunate. Mostly, I end up skipping them.

-systemsboy    



» Post a Comment