Boot Camp: Shut Up Already

Okay, sure, maybe there's a hint of sour grapes here, my being still Intel Macless and all, but really, please, just stop it already. If I read one more article about Boot Camp — this one included — I'm liable to puke. Just stop. Stop writing about it. It's all been said. It's all been done. You're just repeating yourselves. And it's driving me crazy.

I just clicked a link entitled "Apple to complete Intel transition by end of 2006" on MacFixIt which, rather than leading me to an article about the Apple Intel transition, actually lead to a five page write up on — yup, you guessed it — Boot Camp. I assume somewhere in the five page article is a line or two about the Intel transition and its imminent completion, but if you think I'm going to wade through another opinion piece on how well Windows runs on the Mac, you're freakin' out of your freakin' mind.

People have been running Windows XP on hardware from vendors the world over for, like, seventy billion years now. I can't imagine the experience would be much different on a Mac. And from everything I've read, this is indeed the case.

Sure, it's great we can do it. Just, please, stop writing about it. You're killing me.

Apple Remote Desktop 3

I've been using Apple Remote Desktop since the Classic days when it was called Network Assistant. I've always used it in very basic ways — client control, software installation and remote troubleshooting mainly — but it's nevertheless been an invaluable utility in my sysadmin tool belt. And in the last few years it's gotten nothing but better. For one, starting in Panther, the ARD client was included in the OS install, making installation and setup on a group of clients a trivial affair. Version 2 also included the ability to run UNIX commands on a group of clients, which has made my job about twelve million times easier, so that was, and continues to be, great. In fact, it was this feature that made ARD 2 a must-have for me. Not only did it allow me to perform tasks en masse that I simply couldn't perform any other way, it also filled a lot of holes in the software itself. There is a lot you can do with ARD 2 right from the GUI, but there are a lot of things you can't, though you probably should be able to. Things like enabling file sharing or Appletalk come to mind. Ideally, any setting you can make in a computer's Systems Preferences (or at least in the Network prefs) would be configurable from ARD. This is not always the case, but the UNIX functionality greatly mitigated most if not all of this.

Apple Remote Desktop 3 is the newest version of ARD, and it, like its predecessor, offers what look to be some really great improvements. The interface is now two-paned and sports the new "Unified" look, and tasks are listed in the left-hand pane along with everything else. If you want to view a running task, select it in the left-hand pane and view its progress in the main window. Gone is the third pane containing your task history, and you no longer need to view a task's progress in a new window. Hallelujah! Remote management just got more efficient, and that is, after all, the name of the game. This left-hand pane also sports new organizational features as well. Folders let you group computer lists, and Smart lists can be set up as well to keep tabs on computers with certain properties. These little organizational touches go a long way toward enhancing the usefulness of a product like ARD. Believe me, they're important details when you're managing a group of computers, and are welcome additions to the application.

One of the things I always hated about ARD 2 was that if you, as the ARD admin, locked the screen of a client computer, you, the admin, were locked out as well. This has been addressed in ARD 3 with a new feature called Curtain Mode. Curtain Mode allows the administrator to lock the screen of the client computer, just like Lock Screen did in ARD 2. But with Curtain Mode, the client gets a locked screen while the admin gets complete, unfettered access to the computer. I can't tell you how many times I've wanted this feature. Finally, I can lock down computers but still perform tasks in the GUI.

ARD 3 now offers Remote Drag and Drop, enabling an administrator to drag documents directly to the client. This is a nice productivity enhancement that I'm sure most ARD admins have longed for for awhile. Pure Apple simplicity.

Reports have been enhanced too, and now feature the ability to track application usage and user history. This will be great for monitoring which apps get used most and what users are doing to cause problems on their systems.

Probably the most hailed (and rightfully so) new feature of ARD 3 is automation. ARD is now AppleScriptable in version 3 and also comes bundled with a set of Automator actions. It's only right and proper that an application that's made to perform multiple tasks on multiple computers should be automatable in some way. And now it is.

There are a bunch of other new features, but the above are the ones I'm most excited about. Most of these new feature are things I've always wanted in ARD. In fact their absence in previous versions often left me scratching my head and wondering why they weren't included. They seem so obvious and so Apple. So I'm really glad to see them finally rolled out in the new product. And I'm glad to see that Apple is paying attention to Remote Desktop. It's kind of surprising to me to see constant and significant improvements in a product that's probably not a big money-maker for Apple. But it's great to see. I haven't gotten ARD 3 yet, but I'll be ordering it as soon as budgets allow, and then waiting for it with bated breath. If the hands-on reviews are any indication, It looks like a winner.

Boot Camp Assistant Innards: The "Other" OS

I downloaded Boot Camp yesterday, despite the fact that I don't have an Intel Mac and, therefore, cannot actually run the assistant. But I wanted to try, and I wanted to poke around to, just to see what I could see. The bulk of the Boot Camp Assistant's 80 MBs is taken up by the drivers needed for Windows to use the Mac's hardware, which live on a disk image called simply, "DiskImage.dmg." The rest of the dmg contains the usual binaries, plists and background images common to applications. But I did find one amusing — albeit only slightly — item: The Mac OS X logo image contained in the application is called "MacOSX.png;" the Windows logo is called "Other.png."

Don't know why, but it made me chuckle. Just a bit.

The Mac OS X Logo Inside the Boot Camp Assistant
(click for larger view)

That "Other" Logo
(click for larger view)

UPDATE:
A characteristically awesome article at one of my favorite blogs, Daring Fireball, also notes that the whitespace in the "Other" logo forms a subliminal "X." See, it's not just me.

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!

Boot Camp and Partitioning: Cooler than You Think?

Today Apple released a beta software package called Boot Camp to facilitate running Windows XP on an Intel-based Mac. I'm practically speechless. Which doesn't happen too often.

Apple's Boot Camp Beta: Brilliant!
(click for larger view)

Now we all know a few weeks ago this nut was already cracked by some enterprising young hackers, so we all knew it was possible, and in fact probable that installing and booting Windows on Mac would become a fairly trivial and commonplace happening. There were even rumors that the next version of the Mac OS would provide "virtualization" software for running Windows in an emulated environment from within Mac OSX. But I have to admit I was quite taken aback by today's news. Official support from Apple for installing and running Windows on the Mac.

Brilliant!

Dual Booting
(click for larger view)

One of the best things about all this is the fact that Apple is providing Windows drivers for Mac-specific hardware. So you no longer need to search the internet to find them. But to me, coolest thing is the portion of the assistant that creates the partitions. Here, for the first time in Mac OS history (at least that I'm aware of), we see an Apple-branded utility that will partition your drive without erasing it. It's uber-smart of Apple to provide this functionality for people who want to test this out without the inconvenience of a full system reinstall. But it also has immensely cool implications if partitions are as important to you as they are to me, or if you happen to use an Xserve RAID. I'll explain.

Space Maker: The Caption Says it All
(click for larger view)

I use partitions on my systems to wall-off user data from system data. So I have one partition with all the system components and applications. Root. The boot drive. I try to keep this drive to as reasonable a size as I think I'll ever need, and then create a second partition with my user data: projects, mail, videos, music — everything else, essentially. This partitioning scheme works great, but it breaks down when someone like Apple decides to release a suite of applications that suddenly takes up eight times more space than the previous version. All of sudden, I no longer have enough space on my root drive for all of my applications. A partitioning system like mine fails when I am unable to accurately predict the amount of space all my apps will require, both now and in the future. And this is becoming increasingly common. A utility that would let me dynamically resize my partitions would be a godsend. Now I don't think the partitioner included in the Boot Camp Assistant does dynamic partition resizing, and it probably never will, and I'll just have to roll with it. But I can dream. And there is another area in which a utility like the one in Boot Camp would have immediate benefits.

I have a client who purchased on of Apple's Xserve RAID systems. This is a pretty cool beast. Fast. Stable. Very reliable. But there's a scalability problem, and it's one reason I won't buy one for my lab. When you read the datasheets and the manuals for the XRAID, you're told that drives can be dynamically added to the RAID in the future, should you ever require more storage. Add the new drive and the RAID will, theoretically, add it to the RAID set and you'll have that much more storage space. This is typical of enterprise-level RAIDs I'm told. It's one of the reasons you get them: scalability. But if you ever try to actually do this on an XRAID you'll run into a little snag. You see, while it is possible to add a drive to the RAID system and have the RAID recognize the new drive and add it to the set, the Mac OS host is responsible for partitioning the RAID. So what happens is, you add the drive, the XRAID sees it and adds it to the set automagically, but the Mac does not recognize the additional capacity. The Mac still sees the original partitioning scheme. I've read through the manuals and discussion forums — hell, I even talked to one of Apple's RAID specialists — and it turns out there is no way to grow the XRAID without repartitioning it from the host Mac. And as you're well aware, I'm sure, there's no way to repartition a Mac drive without wiping it. So, you want to grow your XRAID? Well, you'll have to wipe it. And that just sucks.

Boot Camp on PPC: No Boot Camp for You!
(click for larger view)

Apple's RAID specialist told me that they were working on a solution to this. That was about a year ago, and I've heard nothing since. But the partitioning utility in the Boot Camp Beta gives me great hope that a solution is indeed imminent. It may even be here already, if you have an Intel Mac that is. I've tried it, and no, the Boot Camp Beta will not run on a PPC Mac. No surprise there. But if the information on the Boot Camp page is any indication (Apple calls "Space Maker" the "most elegant hard drive utility ever"), a new and improved partitioning utility is on the horizon for the Mac. And I'm just as excited about this as I am at the prospect of booting Windows on my Mac. Maybe more.

It's been a long time coming.

UPDATE:
I'm told by a colleague that growing a filesystem (like on a RAID) and partitioning a filesystem (what the Boot Camp Assistant does) are two different things, growing being the harder and, according to him, requiring a grow-able filesystem, which HFS+ is not. So maybe this is a pipe dream.

Apple has a FAQ up about the Windows installation process for Intel Macs, and there are some interesting things there. Most notable in the context of this article is the fact that Boot Camp Assistant will only work on "an Intel-based Mac that has one hard disk partition." This does not bode well. Still, I remain hopeful that this utility is indicative of possible future utilities that would allow for more flexible, less destruct ive partitioning.

UPDATE 2:
I've been doing some hunting around on Apple's RAID capabilities and discovered that you can now (as of Tiger, I believe) use Disk Utility to create what called a Concatenated Disk Set (also referred to as JBOD, for Just a Bunch of Old Drives). These sets can be combined with other forms of RAIDs as well. Until yesterday I'd never even heard of Concatenated RAID, but apparently it's the oldest form of RAID. Concatenated RAID doesn't have the redundancy advantages of RAID 0 or the performance advantages of RAID 1. All Concatenated gives you is more contiguous disk space. I've read that Concatenated could be used to append a new drive on an XServe to the RAID set, though all it would do would be to add to the set's capacity and would not be a true member of the set. This is recommended as a stop-gap measure more than anything, and it's recommended that the reformat necessary to truly join the new disk to the set be performed later, at a more convenient time. Interestingly, this seems to suggest that a Concatenated RAID can be performed without wiping the disks in question, though I can't find any documentation that states this one way or the other. Also, the disks in a Concatenated RAIDs do not have to be identical, as with other forms of RAID. Concatenated RAID disks can be all different sizes, shapes and colors. As soon as I can find some drive to offer up as sacrifice, I will be testing out Concatenated RAID. I'll let you know what I find.

UPDATE 3:
It appears that a new verb for the diskutil command has been added in 10.4.6. The verb is resizeVolume and it's what allows the non-destructive partitioning done by the Boot Camp Assistant. Don't look for it in the man pages; it's not mentioned there. But if you just run the diskutil programsan arguments you'll see resizeVolume listed as an option. I first read about this on Daring Fireball, which links to a MacGeekery article that outlines, in-depth, the process of using the new option to non-destructively resize volumes. I don't know yet if this works on PPC Macs — the article suggests it's for Intel machines only. But I'm sure going to give it a whirl. I'll post a follow-up on all my partitioning experiments in the near future. Stay tuned!