March 30, 2003
created 19 Feb 2001
Preparing your network for Mac OS X
So last time we talked about general preparation work for the full OS X release. This time, we are going to take a look at one of the more specific items you will need to prepare, specifically your network.
OS X is a much more networkable, and network-oriented operating system than previous editions of the MacOS. Indeed, if you look at the lowest level of your system in the OS X Finder, you see two things, the hard drive volumes, and an item called Network. As you add OS X to your environment, you will find your network being used much more heavily and constantly than before. In my own tests, 200MB file transfers proceed smoothly, and quickly, even if you are doing three or four at once.
Not only does MacOS X support AppleShareIP, but you also have things like NFS, Network File System to think about. NFS, the traditional way of networking Unix partitions, is designed to be transparent. In other words, in a traditional Unix you should be able to use NFS without noticing that you are working off a different machine than the one in front of you. Now, in the Apple UI environment, this is not the way things work, and I have yet to see that NFS will be any different. But the point is, that in a Unix-based environment, you can easily be running major applications across a network, while you are running heavy apps locally. Depending on your environment, you may have other people logging into your OS X machine, and using applications they need that are only on your machine.
This is doubled when you consider, that while NFS is primarily for drive access, when compared to products such as XTools, from Tenon, or one of the XFree86 ports, you can now have multiple users on multiple operating systems making use of your Mac's resources from all across your network. So if you have a copy of the GiMP, the open source image manipulation program, on your Mac, someone on a different Mac is going to be able to use it, if you set things up correctly. This is also one of the more exiting features of the BSD base of OS X. The fact that the Mac is no longer a closed box to the rest of the world, or at least your network. If you need more horsepower for a given task, and you have a bright, shiny G4 sitting on a VPs desk, you can now use it while he's not there. The inherent economies that an integrated network gives to Unix are now going to be available to the Mac.
You also have Samba, which is going to provide services from OS X for Windows users. While you aren't going to be running windows binaries on your Mac with Samba, the opposite could happen with PC users. Have a group of PC users that need to get to data on an OS X Mac? No problem, Samba is there. Have a bunch of Mac OS X users that need to use data on Windows boxes? DAVE, from Thursby Systems, and Sharity, from Objective Development are here for you, or will be here for you native on OS X.
Because OS X is designed to make such extensive networking so easy, you have to take a serious look at your infrastructure.
First of all, if you are still using hubs, start looking at switches. Even with a gigabit backbone, shared bandwidth will bring your network to it's knees. Switches also allow you to consider such other networking features, such as virtual LANs, vLANs, Quality of Service, QoS monitoring and allocation, better use of Simple Network Management Protocol, SNMP features, etc. Hubs are cheaper than switches, but you are going to quickly be paying a much higher price in wasted bandwidth and lost capabilities.
Secondly, start looking at making your minimum internal wired connection speed 100Mbps Fast Ethernet. It's standard on every desktop since the iMac, and on every laptop since the 1999 G3 PowerBooks. It's not noticeably more expensive to implement than 10Mbps Ethernet, and the time you save on backups alone will make up for any increased costs.
Take this as a chance to look at upgrading wiring if you can. Not just new wires, but organize things, trace things, find out why you still need that odd connection that's just there. Look into management packages, such as InterMapper, LanSurveyor, netOctopus, Timbuktu Pro, etc. If you are having weird network problems, this is the time to get a product like EtherPeek, and check them out.
MacOS X is going to be a networked OS like nothing the Mac community has seen before. (And no, A/UX doesn't count, neither does AIX on the Network Servers.) If you take the time to plan your infrastructure upgrades, not only will your OS X users benefit, but other OS's on your network will see the benefits as well. In addition, if you take this chance to organize your network, you may find that what you have is a lot better than you thought. Finally, things like video conferencing, internal usage of streaming media, network attached storage, Storage Area Networks are not going to go away. If nothing else, they may get more intense. Preparing now is like getting a ton of cure for that same ounce of preparation.
OS X Prep
created 11 Feb 2001
Preparing for Mac OS X
Now that the GM release of MacOS X is only about six weeks off, network administrators are now faced with how to really handle this new OS. A lot of them are quite concerned with how to handle it. If you are in a pure desktop environment, you have more ways to control the roll out of new environments, those of us with laptop users have to face the fact that some of our users simply will not be able to keep their hands off a new sparkily toy.
So we have to start planning for March 24th now. This means a lot more to administrators with hundreds, or even thousands of Macs than it does to one with only thirty or forty. But nonetheless, there are still some things that apply equally to all.
First of all, recognize that this OS will require more training than any previous release since perhaps System 7. The UI is different, the operational modality is different, the way it's designed to be used is different. Whether you like what has been done to the interface or not, the fact is, OS X is not the same OS we are all used to, and if you are one of the companies that is using NeXTStep or OpenStep, it's not the same interface you are used to either. So you are going to need to take special care to remind users that simply slapping this OS on their Mac is not going to be like going from OS 8.5 to OS 9.0. Ask them to be patient, so that you will have the time you need to deal with all the new issues that OS X is going to raise, and help ensure that they will have a smoother transition to the new OS.
You are going to need to inventory the applications you and your users depend on, and find out what those vendors are doing as far as Carbon, and / or Cocoa versions of those applications. One of the best resources for checking on updates to Mac applications in general, but OS X applications in particular is VersionTracker's OS X page. If an application is running native in the public beta, then start working with it now, see what's changed and what hasn't. As an administrator, you are going to be a, if not the focal point for questions on the new OS, so the more knowledge you have, the better off you are. If you can, start accumulating applications that will help you now, so that you are ready to go when March 24th rolls around. If you have a good relationship with a software vendor, see if you can get on any beta teams for the OS X version of their products. It may not seem like a good use of your time at first, but having hands on experience with a beta release often gives you not only a heads up on any changes in the new version, (and there will always be changes; as a certain science fiction doctor once said, "I know engineers, they just love to change things."), but quite often gives you a chance to find the lesser known features of a product that really take it from merely handy to indispensable. This in turn, helps you help your users get the most out of the new release sooner than they normally would have.
You are also going to need to review your procedures that deal with backup and recovery of user systems. With any new interface, people are going to make the 'newbie' mistakes that they wouldn't normally make. They're going to lose or delete things, or do other minorly catastrophic things that they wouldn't normally do. So if you've been getting by with minimal backups, this is perhaps the time to rethink that. Get familiar with not only the traditional MacOS ways of doing things, but take a look at Unix-based ways of accomplishing the same tasks. While no one way is absolutely perfect, clever combinations of methodologies can produce excellent results, in ways you may not have anticipated.
When I said that OSX will require more training, I wasn't only speaking of user issues. Adminstrators as well are going to have to get at least comfortable, if not adept at using the functionality provided by the BSD plumbing in OS X. While users should never have to use a command line, or the Unix layer directly, as an Administrator, you are missing out on a lot of features and time savers if you do not start learning how to use these things. Remote administration, in OS X, is a lot more capable out of the box than the current MacOS. The first time you are easily able to SSH into a box, and kill a runaway process, so that the user doesn't have to reboot the Mac, you'll know what I mean. (If you don't know what SSH stands for, or how it is used, that's an excellent starting point.) Things like 'top', and 'ps -f |more', and 'kill -9' are going to be a part of your vocabulary. You can resist them as alien concepts that Mac administrators have no need to know, or embrace them as valuable new additions for your toolbox. Personally, I think the latter is the better way to go. You also will find new ways to use existing tools. Those of you familiar with AppleScript are going to find that you have a new world to work with, as you find ways to link the power of AppleScript and shell scripts to get things done. Is it going to be like falling off a boat? Nope, but it'll be worth the work in the end. Change is happening, and we need to start planning for it, not avoiding it, or hoping that it will fix itself for us.
In the next couple of columns, I'm going to start presenting things that administrators need to look at for OS X, and the new challenges it will present us with.
created 7 Dec 2000
The Pentium 4
For some time now, the Mac community has been in a state over the lack of clock-speed improvements in the G4. "We know that's not important, and that the G4 is faster than the Pentium III, but it looks bad, and besides, what happens when the Pentium 4 comes out and is running at 1.4GHz or faster?"
Well, Intel finally released the Pentium 4, and so far, the results have been disappointing to say the least. Simply put, unless you are running Quake III or have the 2 pieces of software that have been rewritten for the Pentium 4's SIMD extensions, you will see almost no improvement over a Pentium III. This is great news for AMD, as the Athlon is easily beating the Pentium 4 at similar clock speeds.
But this is even better news for Apple and Motorola. If you read the reviews, the reasons for the failure of the Pentium 4 to offer any real reason to upgrade can be laid squarely at Intel's "clock speed is all" philosophy. There aren't any real improvements in the Pentium 4 in any area other than allowing for faster clock speeds except for some improvements in the SIMD units.
SIMD is Intel's take on Altivec, although looking at the implementation, Motorola's experience as a DSP maker helped them create a much better implementation. But as with Altivec, unless you recode for the SIMD units, you aren't going to see an improvement there.
What Intel did do is double the pipeline size and added some execution caching steps and other clock speed - related improvements. This is all neat, but it relies on much faster clock speeds, and RAMBUS to work. But in almost any test, even when the Pentium 4 does beat the Pentium III, or the Athlon, if you compare results at the same clock speeds, it's by 5 percent or less in many of the tests. This is not the amazing performance boost that the Pentium 4 is supposed to have. But now we hear Intel saying, "Well, when we get the Pentium 4 to 2GHz, then you'll see the performance increase". Well I would hope that doubling the clock speed gives you something.
But what do you pay for when you put clock speed over everything else? Remember, engineering is a balancing act. For every gain, there is a cost. The trick is, having enough gain to outweigh the costs. Has Intel done this? Well, in many real-world ways, no.
First of all, the Pentium 4 has different power requirements, which require new power supplies. This is annoying more than anything else, and in my world not even a blip, as it's not worth my time to upgrade machines. I end up saving money by buying new machines over trying to do CPU upgrades. But for a home user, it's another expense to consider. Secondly, the Pentium 4 dissipates a lot of power. As in 55 watts of power. To compare, the latest version of the G4 from Motorola only dissipates 6 watts max, and even the previous model G4 dissipates 8 watts max. This is a huge difference. The results of this are that the heat sinks are big enough that Intel is now specifying motherboard attachments for them, so they don't damage the chips, which has happened with some of the bigger heat sinks on the Athlons. This means new motherboards, and new cases for most. So the upgrade path to a Pentium 4 is essentially a new computer.
But here's another issue with the heat output of the X86 architecture: Noise. Most Pentium IIIs and Athlons are generating, (due to the number of fans needed to keep those beasts cool), something like 55 to 60 decibels, (dB) of noise. This is similar to heavy traffic noise levels. Now multiply that times the number of computers in an area with cubicles. This is not minor, some of these boxes sound like DC-3s taking off. In contrast the Cube, or the iMac, or even a G4 Tower are much quieter, almost silent. Even the fan on the G4 Tower's power supply is very quiet compared to the three or so fans in a Pentium III box. A constant ~60dB noise level for eight hours a day, every day is not a good way to work, and with the Pentium 4, it's not going to get any better. (This would make an interesting ad campaign. "The Cube, because it won't make you deaf".
The upshot of this, is that for the first time, rigid focus on clock speed is burning Intel. Will the chip flop? Hardly, Intel is too pervasive for that. But it is finally making people say, "Why do I need this?" They are tired of spending money every six months for low-level speed gains that just don't show up in daily use. I type all my articles in BBEdit on a 400MHz G3 PowerBook. I've done a couple on a G4 at work. Other than a slightly faster speed when opening BBEdit, I'm not working any faster at 500MHz than I am at 400MHz. I just am not going to ever type fast enough to bog down a modern processor.
Does Motorola need to get the G4 running faster? Certainly, Mac users as a group hammer their machines harder than typical Wintel users. But I for one am more impressed with faster done correctly, and as part of an overall improvement, rather than a goal unto itself. There is much more to a computer than clock speed, and this truth has finally caught up with Intel. Hopefully, some of the naysayers are watching.
Netscape 6 Final
created 19 Nov. 2000
Netscape 6, Is It Really Worth The Effort?
Okay, so here it is, after a few years of waiting, the successor to Netscape 4. Finally out of beta, I've been able to work with it for a while now, and the impressions, unfortunately, are consistent with my earlier impressions of the various PR, (Public Release) versions.
The installation went smoothly enough, although it did take four or five attempts for the initial download. I'm not going to get upset about this, I'm willing to bet that every router that's ever heard of netscape.com is being hammered pretty heavily right now. The install creates about 480 items in the Netscape Folder, and it takes up about 29 MB of drive space. This is less space than Communicator 4.7.X, although about twice as many items, and more space and files than for Outlook Express 5 and Internet Explorer 5. One instantly annoying part of Netscape 6 is that thanks to a new plugin architecture, which is evidently incompatible with 4.7.X's plugins, Netscape ships with only Java and Shockwave plugins, no Quicktime, or any other plugins are evidently available.
Initial impressions are the same as the PR versions. The HTML rendering is faster than 4.7.X, but not noticeably faster than IE5, with the exception of long text pages, which has always been a sore spot with IE. The appearance of Netscape 6 can be changed via Netscape's themes mechanism, and the final release ships with 2 themes, the new theme associated with Netscape 6, and the older, 4.7.X-ish theme. I personally don't have a problem with the new appearance, and find it cleaner in some ways than the 4.7.X appearance.
One problem I do have is with the fact that the interface itself is slow and buggy. Popup text hints for button usage take longer than for IE, and the amount of artifacts that get left behind by either the popup text, the dropdown lists, etc. are much higher than is acceptable for a non-beta product. Netscape's insistence on using a common interface is part of the problem here, but a bigger problem is that it appears that in its quest to be platform neutral, Netscape decided that it would be better to completely duplicate all window, and scrolling routines that already exist in any OS. The MacOS Appearance Manager settings are ignored, and a severe speed penalty in scrolling long pages seems to be one of the results of this. Other interface bugs include the inability, at least on my PowerBook's external monitor, to widen web and email windows past the width of the PowerBook's LCD screen. When switching between windows within Netscape, the refresh of the windows can take up to 3 seconds, which is annoyingly slow. Scrolling is jumpy, much more so than in IE or 4.7.X. Another entry in the interface/OS incompatibility problem list is the utter ignoring of the Internet Control panel/Internet Config that Netscape does. Considering that 4.7.5 finally started to use the MacOS internet preferences settings, and that Netscape 6 ships with out any pre-defined helper applications, this distancing of the product from the interface is all the more annoying.
But the worst offenses are in the area of keyboard equivalents. Now, to mark a message as read, instead of the 4.7.X keyboard command of CMD-/, the command is the letter 'M'. Not CMD-M, (which is still 'New Message'), or CTRL-M, or even OPT-M. Just 'M'. To mark all messages in a folder as read, you use the letter 'A'. I'm amazed at this, as it is not too hard to see where you could accidently hit the letter 'A' in a window, and mark all messages as read without wanting to. Considering that other email clients allow you to use letters to quickly jump to other folders, the use of unmodified alphabet characters for program functions is mindboggling in the potential for causing all sorts of problems. This insistence on 'doing it all ourselves', on platform neutrality at all costs has caused far more problems than it will ever fix. It seems to have made the product much more complicated than it should be for any reason, and caused an even more serious issue in the area of RAM usage.
Netscape 6 doesn't just use RAM, it inhales it. I normally double the manufacturer's recommended RAM allocation for any application. So for Netscape 6, I set the minimum RAM to 20MB, and the preferred size to 40MB. Just sitting there, with only my home page open, Netscape was using 29.5MB of RAM, which tells me that the default preferred RAM settings are too low to be functional. By the end of 3 hours of use, including IMAP email, and my standard web browsing, Netscape 6 was using 47.3MB of a new allocated amount 60.7MB of RAM. So at this point, even my doubled RAM allocation was too low, and Netscape had vampired an additional 20MB of RAM from the system. Even with only one browser window, simply changing web sites, scrolling, and refreshing pages drove the RAM usage up an additional 1.7MB, and stayed there, even with the program doing nothing, for over an hour, no surfing, no emailing, nothing. This seems to indicate a pretty radical memory leak, as with nothing going on, Netscape should have returned RAM back to the system. As a comparison, for my normal usage, I have both Internet Explorer 5 and Microsoft Entourage set to use 16MB of RAM each, and that's the limits they stay within. Netscape starts out with 8MB more than both of those applications, and needs another 20+MB of RAM in addition to do the same amount of work. This is simply not acceptable behavior for an application that is in its fifth or sixth iteration, and especially not for an iteration that has been in development for over a year now.
When it comes to email, Netscape 6 isn't even able to keep up with its predecessors, much less its competitors. Netscape 4.7.X allowed me to download over 3000 IMAP email headers in under 5 minutes over a 33.6Kbps modem. Netscape 6, on a cable modem that was giving me T-1 level throughput took 50 minutes to download 1500 IMAP email headers. In both cases, the email server was the same Netscape/iPlanet IMAP server running on Solaris on a dual UltraSparc server. Netscape 6's email filtering capabilities are essentially unchanged over 4.7.X's, and when compared to the filtering capabilities of products such as Outlook Express, Eudora, Entourage, or even Emailer, quite pitiful. The lack of LDAP address book capability limits Netscape even further, by removing a valuable and useful way of condensing company and university - wide address books into one, easily administered and maintained listing. To be blunt, the lack of LDAP is forcing not only my company, but the company of almost every administrator I've talked to into starting the process of either removing Netscape from the list of supported software, or freezing Netscape at the 4.X.X level.
This is the first version of Netscape I find myself unable to recommend in any capacity, unless you are a web designer, and need to preview pages with Netscape's Gecko HTML engine. However, judging by the opinions of most web designers that I know, they are probably just going to redirect Netscape 6 users to pages that are compatible with Netscape 3. This is due to Netscape's overly rigid requirements that HTML conform to current W3C standards. Don't misunderstand me here, compliance with those standards should be the goal of every web designer. But there is a lot of old code out there that will never be revamped, for various fiscal and time reasons. Unfortunately, if your code used Netscape 4.X specific tags such as the layer tag, Netscape 6 won't work with those pages. Being compliant with the current CSS, DOM, XML and other standards is good, but to be incompatible with older versions borders on ridiculous. Considering the public lambasting that IE5 took over not being too accepting of older HTML, for Netscape to be even more restrictive with it's HTML engine is incomprehensible, especially considering their current market share.
I'm disappointed that AOL chose to release as final a product that is so obviously not a final release. It may have been a large helping of crow to release a PR4 version of Netscape 6, but it would have surely been less than the crow AOL is going to eat with the first service pack fix for Netscape 6. I'm also saddened at the way that AOL is ignoring, and even thumbing their nose at any of the non-home user market with this release. While the business and Higher Education markets may not have been AOL's traditional markets, they were Netscape's, especially higher education. But it looks like AOL has ceded these to Microsoft, Opera, and iCab. I don't see how they can afford to do this, unless they really mean for this to be the last commercial browser released under the Netscape name, and for Mozilla to take all of this function as their own. If so, I will mourn the passing of one of the companies that helped make the internet a tool for all of us.
Integrating OS X
created 15 Nov. 2000
Integrating OS X into existing network systems
In the previous articles in this series, we've looked at connecting the PB to specific types of servers, AppleShareIP, Windows, Unix. But there's another aspect of network connectivity, and that is integration. In other words, besides just connecting to specific machines, how well does OS X fit in with other network management schemes? The answer is, it depends.
If you are talking about a NetInfo network, which is OS X's native networking management scheme, the answer is, almost perfectly. This is what we expect of course. OS X ships with NetInfo built into the OS. Indeed, most of the essential parts of the OS are managed via NetInfo. If you are running a NetInfo network, then OS X will fit in perfectly, with very few integration issues.
The problem is, not many networks are based on NetInfo. This is not a technical failure on NetInfo's part. As I have been digging up information on NetInfo, and wrapping my head around it, I am very impressed by much of what it can do. As a directory service, it is easily as capable as LDAP, or Novell's NDS, and head and shoulders above Microsoft's Active Directory. It uses a heirarchal domain model, ala LDAP and NDS, and one NetInfo domain can contain as many computers, printers and users as your server configuration will allow. But again, not many places use NetInfo, so we have to look at how OS X fits into other vendors systems.
NIS, and NIS+ is the network management concept used primarily by Sun Microsystems. NIS, or Network Information Service allows for administrators to manage resources such as computers, printers, users, user rights, storage access, etc. from an NIS server. NIS runs on most Unix systems, and is widely used in the computing world. NIS+ is an enhancement to NIS that added encryption capabilities and security enhancements to NIS, and is usually only seen in Solaris networks, although it does retain backwards compatibility with NIS.
NetInfo in OS X can be configured to use NIS services, and ships with the basic components to set this up. I'm not going to go into the details here, as they can be quite extensive. An excellent 'howto' page can be found at http://www.bresink.de/osx/nis.html. This site not only covers the OS X public beta, but also MacOS X Server from 1.0 to 1.2, MacOS X DP4, and even Rhapsody DR2 for Intel, and there is some references to the Darwin OS as well. The NIS services in OS X currently allow for user/group management via NIS, and the site mentions how to set up the PB to automount any NIS home directories into the PB.
Having said that, there is almost nothing intuitive about setting up NIS in OS X, unless you have a solid background in NetInfo. Getting the necessary settings into NetInfo is a somewhat arcane and tedious process, and there is a very small, but necessary amount of config file editing required. As well, once you have set OS X up for NIS, if you boot it in a situation where you cannot connect to the NIS domain, then it will sit at the NIS part of the boot process, endlessly looking for the NIS domain. (It may time out eventually, I've only waited for a half-hour or so before rebooting.) This means that PowerBook owners, such as myself, get very good at EMACS and hostconfig files. Obviously, Apple needs to fix this process to a more intuitive way of connecting to NIS domains.
But once you get NIS working, it works fairly well, and doesn't seem to need a lot of care and feeding, which is the general idea.
The next network management system that OS X supports is LDAP, or Lightweight Directory Access Protocol. The support here is less extensive than NIS, seemingly limited to user login authentication. Part of this may be due to LDAP's relative lack of experience as a network management directory, so I expect this will improve. Most of the available information on using LDAP with NetInfo is in this TIL from Apple. Even though LDAP is a newcomer to the network management arena, many other directory and management services are based on, or compatible with LDAP to varying degrees, such as NIS, Novell, and Microsoft.
LDAP has the advantage of being a public RFC, and as such is 'owned' by no one company, and you can find LDAP servers that run on almost every OS available, including one that runs on the current MacOS, ClickMail Central Directory, from Gracion Software. If you are unfamiliar with LDAP, and would like to know more, Gracion's site is a good place to start, as it explains many of the basics of LDAP in a concise, understandable manner.
Third on our list of network management systems is Novell Directory Service, or NDS. This is not yet shipping, but was announced on November 7th. The actual product name is Native File Services for Macintosh, and will be a downloadable addon for NDS 5.X, and a native part of NDS 6.0. It promises to provide native support for MacOS clients on the server side, with no client software needed on the Macs. It will integrate Novell Modular Authentication Services with Apple's own authentication systems, and provide not only access to network storage, but user management and directory access as well. The product should be shipping in the first quarter of 2001, so you may be able to get a look at it at MacWorld Expo in San Francisco.
Again, this is only an announcement, not a shipping product, and as Mac administrators well know, especially with Novell's history of Mac support, much can change in 6 or so months, but it's a good announcement, and would give Novell an essentially uncontested foothold in the MacOS market. What that will translate to remains to be seen, but it's evidently quite tempting for Novell at least.
Our final entry is Active Directory from Microsoft. This is a quintessential Microsoft management product in that it really doesn't support much outside of Windows PCs beyond very basic file and print services. Luckily, it seems to support LDAP reasonably well, so you may be able to get away with having your OS X boxes treat the AD servers like LDAP servers. I have yet to really try this, but if anyone does, then please, let me know how it works.
I've probably left out a few other systems, but we've covered the 'big four' as far as MacOS X is concerned. It is good that systems other than NetInfo are supported natively, although the implementation procedures need a lot of work. The Novell announcement is good news for administrators using that system, or considering it, and if Microsoft's LDAP support is close to as complete as they indicate, then there is a way to at least partially integrate OS X into AD networks, although the reality of this remains to be seen. OS X is still a beta, so there is time for Apple to create proper interfaces for integrating with NIS and LDAP, and I would really like to see NetInfo made a lot more intuitive to use. I'd also like to see Apple release a LOT more documentation on NetInfo than it has. But the basics are there, so that's a good start.
OS X To Unix
created 30 Oct. 2000
Connecting OSX to Unix
Well, last time we talked about connecting the OS X PB to Windows machines, and the products available to test for that purpose. This time we are going to focus on connecting to Unix networks.
There is an interesting dichotomy here, as this is both some of the easiest, and most convoluted connections of the group.
First off, the standard Unix connection tools are all here, telnet, rsh, rlogin, ftp, nfs, lp, etc. Things like Telnet, rsh, rlogin are all currently command line only applications, although the Carbon version of MacTelnet is due quite soon now, and even in its current state, shows great promise, as it is scriptable, something the command line remote access tools are not.
This is of great benefit to those of us with time, effort and money invested in AppleScript, as porting those to various shell scripts would be non-trivial in both time and effort. For those of us who are used to things like shell scripts and PERL, the PB includes those capabilities as well, so that regardless of your scripting preferences, you have all the basic tools you need, although I imagine that AppleScript will give you better access to the GUI elements and the applications that aren't command line applications. Apple is being good about giving us low level access to AppleScript, so that regardless of your language choices, you should be able to integrate that language into AppleScript in some fashion.
FTP is there as well, again, no big shock, this is a Unix based OS. For those of you who prefer a GUI - based FTP client, (like me), there are products such as Transmit, from Panic. You can of course use web browsers for downloads, but I prefer the functionality from an FTP client. Although there are more Mac FTP clients available, as of yet, only Transmit has been Carbonized. As with things like MacTelnet, the primary advantages to a product like Transmit are that you don't need to start dealing with command lines, and you get AppleScript.
The next connectivity issue is NFS. At the moment, this is primarily one way, that is, the PB can easily mount other Unix NFS shares, but sharing PB drives is a bit trickier. This is primarily due to unresolved issues with NFS and HFS+. If you use UFS for the PB, you avoid the NFS issues, but you loose the ability to run the Classic environment, so it's a trade-off. As well, although I have found a reliable method for accessing other NFS drives, I haven't found a reliable method for creating NFS mounts in the PB, so I'm waiting for either Apple, or a third party to handle this.
In any event, the NFS procedure I use is relatively simple. You have to start NetInfo Manager, and unlock it. To unlock it, you must authenticate as root, with root's password. Considering that unlocking NetInfo unlocks the 'keys to the kingdom', this is a sensible precaution. Once in NetInfo, you will want to select the /mounts directory. This should be empty. You will want to create the following properties and values, one for each mount:
- property: value
- vstype: nfs
- dir: (local directory where the remote share attaches, i.e. /Network/public)
- name: (remote server and that server's share, as computer:/sharepath, i.e. server:/home/myhomedirectory)
- opts: bg
A sample NetInfo screen shot is shown below, (names changed to protect the innocent.)
One thing to make sure of is that you create the dir parameters manually. I personally create the destination/local directory before I create the mount entry. Once this is done, then you should be able to access the remote files from within the Finder window. I found that I sometimes had to reboot to see the mount, but this wasn't consistent. I presume this will not be required in the release. Another note is that the remote volume does not show up on the desktop in the same manner as AppleShareIP volumes. I would sincerely hope that Apple allows for this behavior to be selectable. That way, both Mac and Unix people can have the behavior they expect from remote volumes. Finally, because you statically create the destination directory, even if you are not on the network, the directory is still on your Mac, albeit empty. For those administrators with Unix experience, this is the norm, for the Mac administrators without this experience, this will be something new to watch out for. This works very well with Sun Solaris boxes. I have not had a chance yet to test it with Linux or SGI shares. It should work okay, although there does tend to be issues with the way Linux and SGI approach NFS. These aren't insurmountable, but beware of them.
The final connectivity protocol we'll look at is the X Window System. This is the basis for most Unix GUIs, and is also the primary method for running applications that physically exist on other servers in the Unix world. Before we start with X products for OSX, a brief overview of what X is should be looked at. (I would like to thank Sandy Nicholson for this explanation, posted as a comment to an earlier column I did.)
2. An `X server' is a program that implements the X protocol on a given computer, by actually rendering graphics and text for you to see, and by converting your mouse clicks and key presses into appropriate X protocol messages.
3. An `X client' is any program that communicates with an X server (using the X protocol), in order to interact with the user of the machine on which the X server is running. To the end user, it appears as though each X client is running on their machine, though in fact some or all of them could be running remotely.
4. An `X window manager' is a specialized X client, often (but not necessarily) running on the same machine as the X server. It provides basic window management functionality (things like raising and lowering windows, moving them around and iconizing them). To use X, you don't actually need to use a window manager, but it's pretty awkward if you don't!
Okay, so the X-Window app I have been playing with is Tenon Intersystems' XTools. This is a commercial X Window product that allows you to run X applications, such as GIMP, Netscape, etc. on your OS X Mac, or other computers to run X applications that reside on an OS X Mac. For example, there is no Carbon or Cocoa version of Netscape 4.7.X. So, without XTools, I am stuck with trying to use the Classic version, or booting into OS 9 to use Netscape, or trying to run the Carbonized version of Mozilla. But with XTools, I can log into one of our Unix servers, and run the Solaris version, shown below.
So with XTools, or the free port of XFree86, I can run any X application that exists on my network, from Netscape to MatLab, to IDL, and the only slowdown is if the network is running slow. This gives OS X users access to an exponentially higher range of applications that span the entire spectrum of application types, from vertical market high-end applications, to games. Admittedly, this capability existed for OS 9, with similar products such as Exodus, from PowerLan. But it's very important that this capability is available for OS X, as it is based on Unix. Even better than being just able to run remote X applications is the reverse of this. Other Unix computers or systems with X Window packages can run applications that reside on the OSX Mac, if they follow the X Window specifications. So that means that a multiprocessor OS X Mac could easily act as a compute server for a research firm, running such products as IDL and Mathematica. X Window capability simple extends OS X's reach to an incredibly large span, and that can only help not only Apple, but everyone who uses OS X.
So, finishing this installment, OS X has the essentials needed for good Unix connectivity. There's some blots on this, such as the awkwardness of setting up NFS, and I left out the WebDAV capability in Apache, (primarily because I haven't had a chance to really work with it personally), but the plumbing is there, so now Apple needs to get the user fixtures in place.
The next, and final part of my series on OSX connectivity will be on integrating the PB into non-NeXT/OSX Server/NetInfo networks.
OS X To Windows
created 23 Oct 2000
Getting the MacOS X Public Beta to speak Windows
So last time we took a look at how the MacOS X Public Beta Public Beta connects to a MacOS or AppleShare network, and decided that although there are some rough spots, in general, it does a good job.
This time we take a look at how well the Public Beta deals with Windows networks. (Note: I'm leaving off things such as FTP in this article, just as I did in the last one. For our purposes, I'm concentrating on what are considered the 'native' protocols of the target network that MacOS X is trying to connect to.) There are two main products that allow you to connect to Windows-based networks, Samba, an open-source server that implements the Server Message Block, (SMB) protocol. Samba is maintained by the Samba Group. The easiest way to get Samba for the Public Beta is to go to http://osx.macnn.com/features/installsamba.phtml, which not only has a link to the binaries for the Public Beta, but also a nice, concise set of instructions for installing Samba on the Public Beta.
Reading the install instructions brings up one of the annoying parts of the Public Beta, which is the reliance on the command-line. There are some marvelous opportunities here for shareware/freeware developers to take a lot of these products, and wrap them in a proper GUI installer application. On the other hand, the advantages of the Unix plumbing in MacOS X really shine here as well, considering that, for free, you now have a complete Windows server, and even with the command line, the installation is pretty simple. Luckily, thanks to the hard work done by the folks at the Samba group, there is a product called SWAT, which is a Web interface to Samba, and allows you to fully configure Samba from a browser, and avoid the command line completely.
Although there are a lot of options with Samba, the online help is very complete, and well - implemented. Each option on the web admin page(s) has a help button, and the entries explain your options well. This is not to say a home user could use Samba well, even at all. Like any cross-platform server, it requires a solid understanding of things like NT domains, domain security etc. But for an average network administrator, it shouldn't be a problem. (There have been rumors that Apple is considering shipping a version of Samba with the final release of MacOS X, along with an easy - to - use GUI. I personally hope that these rumors turn out to be true, as this would give Apple an OS that can, with a minimal amount of work, fit in to essentially any network, and be completely compatible, which would be not only a nice bragging point for Apple, esp. in the SciTech arena, but also earn them the gratitude of Mac administrators everywhere.)
As a server, Samba works well. You can specify any directory you wish to be shared to Windows users, (mostly due to the fact that to specify any shares, you have to log into the web admin as root, so you can do anything you like, almost.), (dis)allow guest logins, have Samba use an existing NT domain for authentication, etc. It's a very full featured server, and as easy to configure as any other server in that class.
Unfortunately, all Samba is a server. There is a client app, but it's command line only, and is more of an SMB-ized command-line FTP program. So Samba will allow you to share resources from the Public Beta across the network, but it can't act as a client.
To do that, you need the other product for the Public Beta, Sharity, from Objective Development. Sharity is a Common Internet File System, (CIFS) client. CIFS is the latest version of the SMB protocol. Although Sharity is not free, it is available with either per-server or per-client licensing, and the prices are reasonable, ($3695 allows an unlimited number of MacOS X Macs to connect to up to 20 WIndows/SMB servers.), and Sharity is a well - put together piece of software. Although the version I played with is a beta version, it works well. The install process is a nice GUI, although the requirement to be logged into the MacOS X Public Beta box as root is annoying. Allowing you to authenticate as root from within the installer would be nice.
The configuration is GUI - based as well, and once you have set it up, it can run in the background without needing attention. It provides access to all of your Windows PCs, Macs running DAVE, or Unix boxes running Samba, via a CIFS mount point in the Networks section at the root of your MacOS X hard disk. I was never able to get a remote drive to mount correctly, but these look like interactions between a beta OS and a beta version of the product. I expect that these will disappear with time. In any event, Sharity is easy to use and administer, and, for now, provides the only graphical SMB client for the Public Beta.
So, in conclusion, if you only need to act as a server to other SMB clients, Samba is the way to go. It's free, and easy to set up and administer. If you need to act as a client to SMB servers, then Sharity is the way to go. They both get high marks for providing capabilities to the Public Beta that allow it to easily coexist on a network with Windows PCs, or a Windows - controlled network, without requiring any work from the Windows end. All in all, they make MacOS X to Windows connectivity a simple and uncomplicated experience, and once Samba gets a proper GUI installer, the experience will be even better.
Connecting OS X
created 23 Oct. 2000
Connecting Mac OS X to the rest of the world
Well, after spending few more weeks with the OS X Public Beta, I've had a chance to see how it reacts to the rest of the world, namely, connecting to other Unix systems, MacOS systems, and Windows. Allowing for the beta status of the OS, and many of the products, it's been a mixed bag, result-wise, but in general, more good than bad.
One of the bigger downsides, (although this is due to many of these products being quick ports from other Unix products, or from earlier NeXT products, where the command line was not the verboten thing it is in the Mac world), is that you need the command line to install many of these products. While not inherently bad, most Mac users are not going to want to come close to this environment. I am however, reasonably confident that the vendors of these products realize this, and will create an OS X GUI install program that allows Mac users to avoid the command line, if they choose to do so. Admittedly, not many of these applications are the type of things a home user is going to install, but nonetheless, when in Rome, use a proper GUI.
So, since the Public Beta is an Apple OS, how does it connect to AppleShareIP servers? Quite nicely. The way you bring up the Network Browser is a bit different, (It's the "Connect To Server..." item in the Go menu, or cmd-K from the desktop.) This brings up the familiar Network Browser-style window, although it's named "Connect To Server". Currently, only servers that support either the AppleShareIP protocol, (more correctly, Apple File Protocol over Internet Protocol, or AFP over IP), or the HTTP protocol, and even if the server supports those protocols, it needs to be able to use the Network Services Locator, (NSL) protocol to advertise itself to the OS X Network Browser. The other restrictions are that the KeyChain is not usable from the Network Browser, and you cannot yet add remote drives to your "Favorites" list. However, once you connect to a remote AppleShareIP server, and log in, select the drive you wish to mount, it obediently pops up on your desktop, just like in OS 9. From there, you can use it just like you always have.
The only real downside to OS X Public Beta to AppleShare connections is that it can only connect to AppleShareIP servers, (this limitation is clearly spelled out in the various readmes for the Public Beta, so if you are running the Public Beta, and haven't yet done so, go read them, and the other installation notes.) So that means no straight AppleTalk, which keeps the Public Beta from connecting to Windows NT PCs running Services For Macintosh, (SFM), as NT's SFM is using straight AppleTalk. Windows 2000 servers are connectable, as that OS uses the AFP/IP protocol for its SFM. Similarly, for a Mac running the Public Beta to connect to other Macs via File Sharing, those systems must be using the File Sharing over TCP/IP capabilities included in OS 9.X, or, for older systems be running a product such as ShareWay IP from Open Door Networks, or some other product that allows a non-server Mac to use the AFP/IP protocol. In general, I'd give the ability of the Public Beta to connect to existing Mac networks a B+. It's limited by the lack of straight AppleTalk support, KeyChain support, and the inability to keep individual drive mounts in your Favorites.
As far as allowing other Macs to connect to the Public Beta, the results are about the same. Again, it's acting as an AFP/IP server, so most Macs should not have too many troubles connecting to a Public Beta Mac. The Public Beta Mac shows up in the Chooser or the Network Browser of the connecting Mac, just like any other Mac on the network. The only oddity is in what is accessible from the client Mac. If you are not logging in as the System Administrator, then all you can access is the Public folder in your user folder. As an example, if I log into my PowerBook when it's running OSX, and I use my userID, then the only folder I can access is the MacOSX/Users/jcwelch/Public folder. However, if I log in with "System Administrator" as my userid, and either the password for root, or my own password, since I am an admin for that OS X machine, then I can access any and all volumes that are connected and visible to that PowerBook. (Note: This information is spelled out in the Apple Tech Info Library, article # n106010.) While this may seem to be a bug, in an OS designed for multiple users, you do not want a user being able to just traverse the hard drives at will remotely. By locking down normal user access to a specific shared folder, you can help prevent accidental deletions of other users files. Now obviously, there will need to be more flexibility here, so that folders needed by a group can be accessed regardless of location, but I will keep a 'wait and see' attitude on this. In any case, I'll give Apple a C+ on this, as it works okay, but it is a bit too limited in scope to be as useful as it can be.
Finally, as of yet, there is no allowances for an OS X Public Beta Mac to connect to a server running Macintosh Manager, nor is NetBoot implemented in the Public Beta yet. Again, this is a beta, and since there is no server implementation of OS X, (OS X Server being a very different beast from OS X), the face that these features are missing is not surprising.
So Apple has done a decent job of allowing for Mac to Mac connections within the Public Beta. Although there are some rough spots, (AppleTalk, KeyChain), the basics are there, and the work well. Next time, I'll take a look at connecting to the wonderful world of Windows, followed by Unix connectivity, and finally, a look at managing the Public Beta on networks.
Netscape 6 pr3
created 4 Oct. 2000
Netscape 6.0 PR3: Some small improvements, one huge mistake
Well, I just took the time to install Preview Release 3 of Netscape version 6. So, for any of my comments, please bear in mind, it's a beta, and nothing is fixed in stone.
It installed correctly the first time, no crashes. It starts much faster than PR2 did, by about a minute on my 400MHz PowerBook G3 Series '99. The web page rendering is very fast, the text appearing almost instantly images following not long after. It did seem to have an odd problem with one table on my intranet, but that could be the HTML on that page too, so I'm not going to get excited over that. It handles pages from Xerox's Docushare document control product very well, better than Netscape 4.75. In some side by side comparisons, PR3 is sometimes faster than IE 5, sometimes not. In any case the speed difference was less than three seconds for me, so I'm not going to worry too much about that. There are some slowdowns, especially when resizing frames. The redraws are slow enough to watch the frame border redraw two or three times in the course of moving it about 2 inches. Java support is still spotty, with the functionality not as consistent has it needs to be.
The interface is a little cleaner, and feels less cluttered. The colors are easier on the eye, or at least my eye, and it is easier for me to find things in general. The pseudo -integration with Sherlock is nice, although it seems to me it would have been better just to do an Apple Events link to Sherlock, but when you are rigidly cross-platform, you loose good and bad both. Although not a new feature, it also gets rid of Netscape 4.7X's insistence on redrawing the page every time you resize the window. It's also nice to see that Netscape has copied some of IE's better features, such as its improved autocomplete and password manager. There is no KeyChain support, so both browsers still loose to iCab here. The window redraw takes a bit longer than I'd like, but for a beta, it's liveable. PR3 also appears to completely ignore my interface settings as far as scroll arrow settings, etc. I really, really dislike it when a product creates its own interface standard. I'm using it on a Mac, obey my Appearance Manager settings. In addition, many of the Netscape standard key combinations are gone, or changed. So in the address book window, cmd-I doesn't give me information on the selected address book, but rather tries to fire up the instant messaging function. Cute, but cmd-I is always 'Get Info'. Don't muck about with things like that.
There is also no Internet Config support, which, considering it finally showed up in version 4.75, means that once again, you have to maintain separate lists of file and protocol handlers. The AppleScript support is unchanged from 4.75, so it's still very lacking, especially when compared to other applications, such as Outlook Express, Eudora, or even Emailer.
The email client is somewhat improved from PR2 as well, I can finally get a good download on my IMAP mailbox headers in PR3. PR2 would just die at about 1000 headers. Considering I have some IMAP folders with over 4000 headers, that was a bad thing. Header download speed is somewhat slower than Netscape 4.75, but still quite fast, taking about 3-5 minutes for over 4200 headers on a 100Mb Ethernet connection. Reading messages is reasonably fast, although a the screen redraws are a bit jerky. I'm not happy that Netscape doesn't give me an option to not view HTML, or turn off external links in email messages. This is, in one form or another a feature of most other email clients, and is an important one if you are in a secure environment, where unauthorized web connections are prohibited. This ability needs to be added in, preferably before the next PR release. The email message filters, while allowing for many more filtering criteria than 4.75, still only allow for one action to be taken per rule. Compared to products like Outlook Express, Eudora, or Entourage, Netscape's filters are pretty weak.
The address book functionality is, however, broken. There is no capability to search local address books. For someone like me, who has hundreds of entries, and who uses their address book as a contact manager, I need to be able to find phone numbers, addresses, etc. A full-featured find capability in the address book is needed, not just email address autocomplete. But that's not the worst part.
There is no direct connect LDAP capability whatsoever. The only LDAP capability appears to be a one-time LDAP dump to a static LDIF file, but only if you had predefined LDAP servers in 4.75. This is, especially for IMAP or enterprise customers, an astoundingly critical thing to omit. LDAP is the addressbook standard used by too many companies and schools to count, and it's used by many of the public directories on the Internet. In addition, more and more companies are using LDAP as their main employee database, so if anything, it's more prevalent than it was when PR2 was released.
Almost every other email client on the Mac, and any other platform supports LDAP, and indeed, Netscape was one of the pioneers of using LDAP. They made, and Sun took over, one of the best LDAP servers on the market. Especially for mobile, or IMAP users, who may connect to their email from many different computers, LDAP is essential. Considering that every other directory service, including Novell and Microsoft both tout LDAP compatibility if not outright integration, Netscape's removal of LDAP from PR3 is a blunder, and borders on outright stupidity.
The LDIF file dump is unacceptable, as directories change content constantly, so the LDIF dump would have to be done every time you opened Communicator. If you are talking about a directory with 20,000 or so entries, this is going to make starting Communicator an all-morning affair over a modem.
I am also aware of Netscape's online address book features, but a) I don't want to have to join yet another portal to get a feature that had no business being yanked, and b) I don't feel comfortable with placing all my company's address information on an external server, and I am not in a terribly high-security configuration. For companies that are, the online option isn't viable, but LDAP via SSL is.
Between no search capability, and no LDAP capability, unless this is fixed, and quickly, Netscape has just given up the corporate email market, as any IS/IT manager that tries to put this out as the standard email client will at best, get their head handed to them. On a personal note, if this is not fixed, then I will, not may, but will be replacing Netscape as an email client, most likely by Eudora on PCs, OE/Entourage/Eudora/PowerMail on Macs, and I don't know what yet on Unix, although suggestions are welcome, and yes, we already use Pine and Elm.
In conclusion, with the exception of the address book mistake, PR3 is a nice improvement over PR2. Basic functionality is in place, and it's time to speed it up. The lack of LDAP capabilities though, is a stake through the heart if AOL/Netscape want anyone other than strictly home users to ever run Communicator 6. LDAP is just too critical to business and education to be able to function without it. I really hope this is fixed, otherwise, I will have no choice but to replace Netscape with some other email client. And if the only thing I use Netscape for is browsing, then why bother when I can use IE, Opera, iCab, or Omniweb?
Week with OS X
created 26 Sept. 2000
Living with OSX on my network, a week in the trenches, part 1.
Well, I've been living with OSX for just over a week now, and it's been a surprisingly mild ride. In fact, quite the pleasurable one. Just as some background info: I'm running the Public Beta on a G3 PowerBook '99, aka Lombard, with 192 MB of RAM, with an 18GB hard drive, with two partitions, the second one being a 3GB partition for OSX. I had not been able to run earlier developer previews on this setup for any useful length of time. Another important aspect of this is that I cannot, (for various reasons), run Classic on my setup, but I knew that before I installed the Public Beta, so no surprises there. The interesting aspect to this is that I have had to keep all of my applications and utilities 'native', so I am really getting a feel for OSX as more than a carrier for Classic applications.
First of all, as any Unix administrator will admit, Unix is not crash-proof. It's very resistant to crashes, but not immune. And I have on occasion been able to grind the Public Beta to an absolute halt, but it's been consistent enough that I can now submit a decent bug report on it. I've also had the Carbonized version of the Netscape M17 beta kill the whole OS. This is not that uncommon, I've watched Netscape kill Solaris servers as well. However, a reboot, and I'm back in business. I would have to say, running beta applications on a beta OS is definitely the way to have an interesting life.
At any rate, I find that there is very little I miss from the Classic world. The networking speed of the Public Beta is fast. In my own informal tests, I'd say by a factor of five to ten in some cases. Internet Explorer is faster, snappier, and access pages much faster than IE 5 in MacOS 9. I did try OmniWeb, and can see where it is technically a better browser in a lot of ways than IE, but IE works the way I like to, so I use that. Mozilla seems to work, but I can only keep it running for a matter of minutes, so I can't really say for sure if it's faster or not.
The Dock is turning out, for me at least, to be much more useful than I had thought. Even with ClassicMenu running, (the OSX version of the Apple Menu from Sig Software, at www.classicmenu.com), I don't really use it that often. I placed an alias to my applications folder on the dock, and between that, and the browser view in the Finder, it works really well. In addition, I have put around 15 applications on the Dock, so I can get to the things I use regularly with decent speed. I was never a great user of the control strip for a lot of things outside of Location Manager, and setting display resolution, so the lack of that doesn't bother me either. I do wish that I could more easily move it from one monitor to the other, but it's consistent in that it follows the menubar from what I can tell, so at least I know where it's going to be. I have found that the Dock can be very annoying if the applications don't deal with it well. Case in point is Internet Explorer, which will extend it's Favorites list down into the Dock area, making it hard to get to choices at the bottom. I would also like to be able to ctrl-click the trash, and have that give me a context menu, as at the moment, it simply opens the trash up for me. But that has the feel of a beta-bug, not a permanent issue, so I'm not too worried about it.
One of the very nice things about the dock has to do with the fact that it is not static. I know we've all seen the demos with "Mission Impossible 2" playing in the dock, but that's more of a parlor trick. What is useful is the way you can have the CPU usage meter running in the dock, and still easily see how hard something is beating your system. Or the fact that the OSX mail client shows you from the dock icon that you have unread messages in your inbox. Things like these show a lot of potential for the dock if developers take advantage of it. By allowing live displays in the Dock, it also gives it a lot of potential to make up for some of what the Control Strip gave us. I do have to admit to not really liking the new clock. It works, and it's pretty, but it's in the way all the time. However, VersionTracker has a listing for a third party menu bar clock, so again, if Apple doesn't give it to me, someone else will.
This is one of the more interesting areas of OSX, what *isn't* included with it, and I find the choices interesting. So my thoughts on it follows this line. A lot of what we take for granted in OS9 actually started life as shareware. Things like SuperClock, WindowShade, being able to use Location Manager and the Control Strip on non-PowerBook Macs, most of these were bought, or licensed by Apple. But in X, they are all gone. Now, (and this doesn't count Location Manager, I'm more than a little sure that it is on the way), by doing this, Apple does two things. First of all, it creates huge opportunity for interface shareware developers, much like existed in the System 7 days. Secondly, it gives Apple a chance to re-evaluate a lot of the OS utilities, and see which ones are important to users, how many users they are important to, and why. This way, Apple can make better decisions on what to keep from the Classic OS. It's easy to assume that Apple has just killed all of this stuff off, but if you look at it, this is the first time in years, maybe ever, that Apple has had a chance to see, in the 'real' world, exactly what their users want from the MacOS. The Public Beta gives them that chance, and it will be much more useful than user surveys ever are.
The Desktop and the Finder are other areas of concern for Mac users and rightly so, as in the end, these two things, more than anyone else make the Mac what it is. From my experiences, I don't think that Apple has gotten rid of either, they've just altered them a bit. Where the Finder and Desktop were once thought of as one and the same, now they are more separate to the user. From what I can tell, there are not a lot of differences that are all that radical.
For starters, the Desktop is still functional, with the only differences being the fact that internal hard drives don't automatically show up on the desktop, and the Trash is in the Dock. I've got all kinds of folders and applications living on my desktop, happy as can be. I was able to move things like Disk Copy to the desktop, again, just like in Classic. Note: Move, not alias or copy. The actual Desktop folder exists in a sub folder of my User folder, but this is no different than when using Multiple Users, or Macintosh Manager under OS9. Your personal files and preferences are kept separate from the master set. This is good, as that way, it is harder to do real damage to your system. I also think Apple has done a masterful job on simplifying the directory structure *especially* compared to DP4. While it still needs a few tweaks, like maybe moving the root Library directory under the root System folder, which would then give you a directory structure very close to an OS9 Mac running Multiple Users. Aliases seem to be a bit more spotty, mostly working the way we are used to, but in some cases, breaking if you move the original, most notably in the login items tab in the Login control panel. Again, I think this is more due to "It's a Beta" than "Apple's dumping Aliases". Another interesting change is the absence of the 'Put Away' command, (cmd-Y) to dismount network drives, among other things. Instead, you use the 'Eject' command, (cmd-E) to accomplish this. I'm not sure if that's good or bad, but for me, it's probably closer to bad. Again, this strikes me as a "It's a Beta" detail.
The Finder hasn't changed that much either. If you use cmd-B, or Hide Toolbar from the View menu, and stay in list or icon view, it still looks very similar to current Finder windows, with some added buttons. I have not found, in a week of almost constant use, any case where I hit the wrong button to close the window instead of minimizing it. The window controls are spaced well apart, and you have to click on the button to activate it, not just near it. This includes rollovers. You can in fact activate the rollover effect, yet not have the active area in of the cursor in the clickable area of the button. So you are either on target, or nothing happens. This is acceptable, as the buttons are big enough to make targeting easy, yet not so big that you can easily hit them by mistake.
I also have to admit to really enjoying the browser view. Especially for someone like me, who does have very deep folder hierarchies, it's nice to be able to scroll back to the parent folder or hard drive without having to close/open windows. Once you get used to it, it's quite a bit faster for navigating folders and finding things. One thing I do *NOT* like is that you can only move windows via the title bar. This can get quite awkward, and makes things harder than they need to be. I'm also not thrilled with the menubar acting as a ceiling, but only on the main monitor. If you are not going to let us slide windows up past the top of the screen or menubar on one monitor, then eliminate that behavior for all monitors. On the other hand, since you can only move windows by the title bar anyway, you aren't moving them too far up. The one really curious window behavior involves what happens if it gets hidden behind the Dock. There's a nagging inconsistency there. If the application in question is the Finder or Internet Explorer, you have to hide the Dock to get to the window, or just give up, close the window, and re-open it. If it's the email application, then the title bar pops back up above the Dock as soon as you release it. TextEdit leaves it alone, until you select the window from the Window Menu, at which point it pops it above the Dock. I like the Email application's method for new users, and TextEdit's behavior for experienced users. In any case, 'losing' a window behind the Dock is not an acceptable mode, and I hope that however this is dealt with, it's dealt with at a system, not application level, at least for the basic behavior.
Those of you who hate the brushed metal look in Sherlock will be happy, as that is now gone. QuickTime still has the metal look, with all it's good, (easily draggable), and bad, (hard to tell it's in the background) features, although the older favorites drawer is replaced by a button that says TV, which is less intuitive than the old version, as I wouldn't expect my favorites to be in a tab in the TV button's window. The stereo controls are gone, and the volume slider is an actual slider now, not that pseudo-wheel it was.
In any case, there is a lot to like about OSX, and a lot more than just Aqua, although that's what I've covered here today. Next up, a look at the more geeky parts of OSX that will make an administrators heart beat a little faster.
created 30 Aug. 2000
The Mac OS X Public Beta
So, with the announcement that the public beta of OSX is available on September 13th, Mac network administrators are going to be thrown into the same swamp that Windows and other platform administrators have had to deal with for a while now...how to handle users with a public beta of an OS.
The most conservative reaction is to ban it completely. While safe, I think this would be a mistake. OSX is going to be a part of your life, whether public beta or golden release. The beta is a perfect chance to not only do network level tests, and compatibility testing yourself, but to also get firsthand experience with users issues that will crop up.
I am going to go the route of finding a smallish number of Mac users, with the knowledge and need for OSX. The reason for this is simple. No matter how long I test something, my tests are going to be biased by my needs and uses of the system. I don't use my PowerBook the same way one of our VPs uses theirs. I won't do the same things they will. They will find different bugs, or issues than I would.
So how does this help?
Well, for one, it gives you far more opportunity to see how OSX is going to change things in your environment. It will also let you know what kind of user training will be required to make the transition to the new OS as painless as possible. If you manage to include a power user or two, you will also get the joy, or pain, of seeing how various programs and system modifications work, or do not work. You'll also have the best kind of test data for any sort of infrastructure changes that OSX may require...first hand.
You'll also find out exactly what you have to do to sell the upgrade to the people in charge at your company.
Don't underestimate the effect that a good sales strategy will have here. I was able to sell the upgrade to OS 8.5 and later 9.0 based more on our being able to easily view Chinese web sites correctly without reconfiguring the browser than any other feature. Why? Because we do a lot of business with Hong Kong, and other Asian countries. Finding a feature that makes your business run easier is always a big hit for any software, especially an OS.
But how do you go about keeping people from just installing a beta en masse?
Well, first of all, don't try to hide its existence. You won't be able to anyway, and you'll just look foolish. Instead, send an email to your Mac users, telling them about the beta, and that you'd like to set up a small group to evaluate it for your company. Have a clear list that has feedback requirements, and large, nasty warnings that a beta OS, even a stable one, can do bad things to your programs and data. Make sure they understand that bad means 'gone forever' in the worst case.
That should weed out the more casual users. Once you have gotten enough feedback, then inform them that since this is a beta, again, they need to be willing to commit to regular meetings, and other feedback on bugs or errors they have noticed. Make sure they understand that this will take a few hours a week from other things, as they will be spending a lot more time dealing with the OS than they are used to.
This should weed out a few more folks, and help you get the group to a manageable size. Now, you have your small, elite, group of people ready to do a dangerous thing. Play that up. These folks are not normally used to doing beta tests of the OS, so make them feel like they are doing a dangerous thing that is also very cool. Set up a custom email address for the group with a cool name, (think along the lines of the X-Men if you can't come up with something else). I'm not saying go buy t-shirts and buttons, although if you want to, by all means, go ahead.
What I am saying is make this new OS be something so cool that everyone wants a piece of it. Make it the news of the IT department. As time goes by, and bugs are fixed, add more people to the group, with different levels of expertise and experience.
In the end, you will gain far more than just the headaches of sheparding a beta program. You'll have live, firsthand knowledge of what you need to do as an administrator to get your company ready for OSX. You'll have months of experience dealing with the networking and communications changes that OSX brings. You'll also have a group of OSX 'power users', who will, in their own way, have as much knowledge about the OS as you do. So you'll have an extra layer of user support, without the budget. You'll have months to fix any in-house software that OSX breaks. You'll have avoided the agony of random users installing OSX, and then screaming at you for letting them do that. You'll know what works, and what doesn't, and you'll know this because you'll have seen it firsthand.
And with a little luck, you'll look like the visionary that you already knew you were, and your users will see you, and themselves the same way.
And won't that be handy when it comes time to upgrade your Macs?
created 9 Aug. 2000
Netscape PR2...not even close
Well, I've just finished playing with both the M18 release of Mozilla, the open source pre-release version of Netscape Communicator, and PR2 of Netscape version 6. In the case of PR2, attempting to play with it would be the better choice, as I never actually got it to run. On the other hand, M18 installed fine, started up, and acted like a somewhat functional beta. Unfortunately, I still cannot add new LDAP directory entries for email address lookups, and since my company uses LDAP for our corporate address books, I really can't do any email work with M18.
But as I was sitting there, staring at what has to be the most horridly non-mac interface of any application I've dealt with in years, I suddenly realized what was making me so mad about Netscape. It wasn't that the beta didn't work right, although in my testing experience, a beta is feature complete, yet buggy. If the features aren't all present, and basically functional, then it's an alpha, and a public preview release should at least start up without causing Macsbug screens. But that wasn't what was making me angry, something else was.
The way they've treated their Mac users over the last few years.
As a network administrator, I've spent more time dealing with new versions of Netscape across three platforms over the last year than Windows patches by far. Now, thanks to yet another bug in Communicator, I have to tell my Netscape users on three platforms to disable Java, because Netscape managed to make it into a whopping security hole. So now, my Netscape users have to deal with a large loss of functionality until Netscape releases the patch, and we can get it installed.
And yet, in the Mac community, Netscape has this exalted place as the leader of the fight against the Microsoft Monster.
Why? Why do we support a company simply because they exist?
Oh certainly, they had a good product at one point. But what has Netscape done for the Mac in the last year? Their Java implementation on the Mac is a joke. Everyone else on the Mac is able to use Java that runs with the 1.1.8 JDK, Netscape is still back at 1.0.X. It's so bad that if you use the document control features with Netscape's web server, you can't browse your hard drive to find the files you want to upload. You have to enter the path. Not only that, but after 4 releases since version 4.7, and many more since version 4.5, Communicator *still* doesn't support Apple's MRJ java implementation.
But that's not all.
Netscape ignores Internet Config/Internet Control Panel settings, so even though I spent many hours creating a Internet Preferences file that is perfectly tuned for our users, for Netscape I have to manually tell it things like how to treat Word files, not to use Sparkle for MPEG movies, etc. It still can't handle multiple POP accounts unless you create multiple user configurations, one per POP account. It has essentially no XML support, and feature-wise, it can't even match the Windows version much less anyone else's browser. The AppleScript support for the Mac version of Communicator 4.7.X is horrid, and I didn't see a point in looking at the PR2 version. Their menus still don't comply with the Platinum interface, which has been the standard for around three years now. They still don't support Navigation Services, which has been out for the last two years or so. If I'm reading email in Netscape, and click on a link, there is no easy way to tell Netscape to always automatically use a different web or FTP application. The list goes on.
Here's a company that had an absolute lock on the Mac browser market, and now the Mac version of their shipping client is the worst one they ship. And when my Mac users complain, my answer has been, until now, "Well, Netscape 6 will fix this."
No more. There's a company that is shipping the best XML browser available, it supports Internet standards better than any browser that isn't in beta, it's smaller than Communicator, needs less memory to run, integrates better with the MacOS, and crashes less. This company also is shipping a better email client that has some of the best AppleScript support of any email client, and they are about to release a full-featured email client/PIM as part of another product that is just fantastic. Who is this company?
Yes, I know they are the evil ones, Bill is the devil, I've heard all the rants. But when it comes to their Mac products, the rants are hollow. I did some checking on my hard drive, and right now, the combined size of Internet Explorer 5, Outlook Express 5, and AOL Instant Messenger, (the three products that essentially give you all the features of Communicator) is less than the size of Communicator 4.7.X . I've also realized, from talking to the Microsoft developers, that the Mac Office, OE, and IE development teams are as big a group of hardcore Mac heads as you will find anywhere. They love the Mac platform, and are on a mission to write the best Mac applications in whatever market they are writing for, from email to word processing. And it shows.
Internet Explorer has the best XML support of any commercial browser, it's also fast enough that the differences between it and Netscape are minor, it uses Apple's MRJ for Java, which while not current with Sun's, is better than Netscape's by far. It uses Internet Config settings, has allowed me to auto-fill online forms since version 4.5, and is more stable for me and my users than Netscape. It also maintains my browsing history even after I close my current browser window. It tracks my online passwords for me, and allows me to view and edit the ones I have it tracking. It may display HTML marginally slower than Communicator, but it's other features more than make up for that time by the end of my day. In short, it's a better Mac application.
Outlook Express has excellent Applescript support, phenomonally powerful filters, handles multiple POP and IMAP accounts with ease, supports LDAP, and while not as fast as Netscape for certain IMAP functions, has more features that my users and I need, and uses less RAM than Netscape. Outlook Express is simply a better Mac application than Communicator.
Their upcoming Entourage product, which I have been testing, is honestly a joy to use, and it beats Netscape in too many ways to list here. It, like Communicator 6 is a beta product. Unlike Communicator 6, it isn't over a year late, it is feature complete, it conforms to MacOS interface rules, (yes, I know about skins, but I find it annoying that I need a third party product to make a Mac application look like a Mac application. Also, I have to deal with many more people than just myself.) and it has a PIM feature set that is one of the best I have ever used. It supports Internet messaging, news and calendaring standards, (it's amusing to note, the only way Entourage, can connect to a Microsoft Exchange Server is via Internet protocols such as POP, IMAP, or iCal.) It also handles Netscape's vCards better than Netscape does, gives me almost unlimited ways to view my email, and the AppleScript support is, not surprisingly, excellent. This is unlike Netscape, whose AppleScript support for email functions is so bad as to be better off being removed completely. Entourage also has Palm support for its calendar and contact list. Netscape has yet to be able to get any Palm support into any Mac version of Communicator. But the Windows version of Communicator has it. Once again, Microsoft has made Entourage a better Mac application than Netscape has done with Communicator.
The point to all of this is, Netscape's free ride, at least in my small domain, is over, done, ended. No longer will I make excuses for a currently bad product, hoping that the next version will work better. I certainly don't do it for Microsoft. They want to be my recommended product, they now have to earn it like everyone else does.
As an example, until recently, Outlook Express couldn't sort IMAP email into folders that weren't local folders. I helped beta test that product, but I couldn't use it without that feature, and was quite up front in telling the OE team why. They fixed that, and I started using it.
If Netscape Communicator 6 turns into an excellent Mac product in all the ways that are required for a Mac product to be excellent, and is better than the other products available, I would have no problem in using it, or recommending to others that they use it. But right now, I can't do that.
Netscape cannot succeed simply because they aren't Microsoft. Frankly, if that's the best reason they have for being, they don't deserve to succeed. I'm not going to use a product because of what it isn't, or who the company that makes it is not. The product either helps me and my users do what we need to do better than its competition, or we won't use it, no matter who makes it.
I have no company loyalty, I have no product loyalty. I use OE and IE, because for the way I work, they are the best products out there. If iCab or Opera release a browser that is better for me than IE, I'll stop using IE. Simple as that. If Netscape 6 turns out to accomplish those goals, then they will have earned their place as my web and email applications of choice.
Until something better comes along.
X for X
created 25 July 2000
Well, as a network administrator at Macworld Expo, there are times when I can feel like the proverbial fish lacking water. but there are always products that catch my eye, and some that even make me feel like someone out there is listening to us. This year, if I had to pick the one announcement that received almost no press, and yet is of critical importance to OSX, it would have to be Tenon Intersystems' announcement of an X Windows package for OSX.
Even though it's not available now, (then again, neither is OSX), this was an announcement of major importance to OSX.
Being based on Unix, there is a natural synchronicity between OSX and other flavors of Unix, such as Solaris, Linux, AIX, and Irix. But until this announcement, OSX was isolated from its Unix brethren due to the lack, (some say shocking) of a commercial quality X Windows package. (Yes, John Carmack from Id has done a good job of creating a Darwin - based X project for the Open Source community, but Darwin is not OSX, only a part of it.)
But why X Windows? Why is this so important?
In simple terms, X Windows is one of the things that make Unix, well, Unix. X allows Unix users to easily share graphical applications and other resources with other X Windows users on the network, regardless of platform.
As an example, at my company, we use iPlanet's email server. If I need to perform some administrative task on that server, I can use an X Windows package on my PowerBook to access the Solaris box running the server, and run the server administration program natively on the server, but with all the display and mouse information displayed on my Mac. This means I don't ever need to worry about having a Mac version of that program, as long as it runs under X , I can use it just as well as if I was sitting at that machine.
In other words, X allows the remote access and execution of graphical applications across a network by any computer, regardless of OS or hardware, as long as that remote computer has a compliant X Windows application. For those of you using Citrix's Metaframe product with Windows Terminal Server, they are quite similar. Citrix has done some serious refinements to the X protocol, trimming bandwidth, allowing for non-TCP/IP networks, and making security an inherent part of the system, but at its heart, Citrix is basically X Windows for NT/Windows 2000.
By having an X package available for OSX, Tenon ensures that OSX will not be left on the sidelines of the Unix world, but will be able to play on an equal basis with all the other Unix variants. By further allowing OSX to be an X Windows server as well as a client, Tenon is ensuring that any Unix user will be able to make use of the power of Apple's OS and hardware, not just other OSX users. So this way, if a company had a number of multiprocessor G4 boxes, by installing Tenon's package, and BSD-X applications on those boxes, someone using Linux or even Windows would be able to run those X applications, and leverage the power of Apple's hardware.
So far, the ability of Tenon's product to remotely serve native OSX or Carbon applications, (i.e. non-native X WIndows applications) is not known, although I would be surprised if the first release did this. This is not to say it would be impossible, but there are some technical issues with getting Aqua to accurately display on platforms that don't have the Quartz system as part of the OS, and translating Aqua to X is not a minor issue. Going the other way, it looks as though Tenon is able to make X applications being run on an OSX box conform to the Aqua behaviors, i.e. window controls, the Dock, etc.
Tenon is also including X development libraries, to make it easier for OSX developers to create their own applications that can be run via X Windows.
A full X implementation for OSX is an important step for this OS. It is a primary, and critical way to really show the world, especially in those areas where X is of crucial importance, such as upper education, and science/technology computing, that Apple is really coming out with an OS that is a real Unix - based OS, and that it will play nicely with other Unix platforms, while losing none of what makes the Mac so special.
OS X Security Concerns
created 25 July 2000
OS X Security Concerns
Last column, we took a quick look at some of the advantages that OSX gives the network administrator, particularly in the security area. This time, we are going to deal with the dark side of security, namely the new, fun ways that OSX can potentially hurt you if you aren't aware of security, and security issues.
The first danger has much to do with OSX's increased feature set, and how a Unix box can be manipulated on a network. Although Mac users have been networking heavily since 1985, Unix takes network operations to another level.
For one, in the world of Unix, the only difference between a networked hard drive and a local hard drive is the name. Functionally, you use applications on a mounted network drive the same way as you would use applications on a local drive. In some cases, the directory that you run most of your applications from may not even be local, and in larger Unix installations, your home directory is on the network as well. The local hard drives are used for swap space and the operating system.
So far this is not too terribly different than the way Mac users do things, especially with things like NetBoot, Macintosh Manager, etc. The next part of the network equation is very different, and is where the Unix layer of OSX has a real ability to severely hurt a network.
It's the Remote Procedure Call, (RPC)
RPC is a way for Unix, and other operating systems to 'farm out' jobs to other computers on a network, so that large jobs can be handled by multiple machines at once. RPC was started by Sun Microsystems, and is now a standard way for computers to programmatically communicate with each other.
Essentially, there are two parts to an RPC program. The local part is the part you start, and contains the code that does what needs to be done locally, as well as the locations of the remote machines that are going to assist in running the program. The local RPC application passes data to the remote programs, and waits for the returned data. (NOTE: This is a drastic oversimplification of what really goes on with RPC.) The advantage of this is that you can have a relatively small RPC local stub program passing information to much larger remote programs on tens, or even hundreds of machines, and let them work on the data for you. Very efficient, and a nice way to make use of spare CPU cycles.
Especially for crackers.
If a hacker gets root access, (root being the 'superuser' or owner of a machine in Unix-speak), then they can set up RPC programs that can do, well, anything they want them to, from sniffing passwords, to copying data, to being used as launch pads for other activities. RPC programs aren't scripts, or applets, they are compiled code, and can have the capabilities that any other compiled application can have.
So how do you prevent this from happening to you?
First of all, don't turn anything on that doesn't need to be on. If you have an OSX Mac that doesn't have a specific need to use RPC, don't turn it on. The same goes for FTP, Web services, File Sharing, etc. If there is no door, the lock can't get picked. Yes, this will mean you aren't exercising the absolute full capabilities of your network. This is due to one simple principle:
Security and inconvenience are directly proportional to each other.
The most secure computer in the world is one that's turned off. But it's also rather useless. Now, in a lot of cases, you will need to have certain services, such as RPC, or FTP available for use, so the next level is how to make sure that the only people using those services are the ones who are supposed to.
The answer: Password policy
First of all, root password should *only* be given to those with an absolute clear need for it. 'Need to know' should be the only reason here, not position, not friendship, not anything else. Secondly, all passwords, not just root should be changed regularly. I recommend a minimum of every thirty days, but you may want to change critical ones, like root more often. In some heavily classified facilities, it is not unheard of for certain passwords to change daily. Other times to change root is when anyone who had root leaves the company, or transfers to a position where root is no longer needed, or when a remote site is added or dropped on or off of the network.
Third, enforce good passwords. This means a minimum of eight characters, with at least one number and one non-alphanumeric character, no names, no common words. Something like 'Hyrg8*_Z' is a decent enough one. Make sure that when passwords are changed, they can't be 'changed' to the exact same thing they currently are, and in some cases, keeping track of the last year's worth of changes is not a bad idea.
Finally, get the message across that writing down, or giving out passwords is A BAD THING. If you read about crackers like Kevin Mitnick, you realize that he did a lot of his best cracking by calling up an employee of a company and saying "This is the IS department, we're running a check of the system, and need to verify your password. Could you tell me what that is so that I can make sure it's correct?" No long, sweaty hours over a CRT, just five minutes, and a believable story, and he had an access to a network. Janitorial staffs have been also been a great way to gain access. A cracker will hire on with a company that cleans for a company they want to crack, and a little astute observation of sticky notes on monitors, and boom! Instant access.
There's still more to talk about on this subject, such as command - line issues, and shell scripts, etc. But this is a good start. I highly recommend that any Mac administrator familiarize themselves with Unix security issues now, before you are doing it at 3am while dealing with a break-in. A lot of security measures will not win you points with your users, and they are very inconvenient. But it beats having a hundred G4s become the local cracker supercomputer cluster.
OS X Networking
created 15 June 2000
Networking in the Public Beta
With the public beta of OSX fast approaching, there are more than a few network administrators asking, "What will OSX do for me ?" Well, the answer is, quite a lot.
At the OS level, OSX fixes a number of annoyances that have been a part of the MacOS for a long time. The first one is the limitation on the number of active network interfaces. As it currently stands, you can only have one interface per protocol active. This means that if you have two ethernet cards, TCP/IP can only use one of them, the same for AppleTalk. Now, you could have AppleTalk on one card, and TCP/IP on the other, but still, you couldn't have both cards running TCP/IP and AppleTalk. The only way around this is to use a third party product, such as IPNetRouter, or SoftRouter, or to use AppleShareIP, (which only lets you get around this with AppleTalk, not TCP/IP.) This ability to use multiple network interfaces simultaneously is called multilink multihoming, and as I said, the lack of this ability has been a severe limitation of the MacOS for as long as it has had networking.
(Technically, this is not a limitation of the MacOS networking subsystem, aka Open Transport. Open Transport does allow you to have multiple active interfaces, otherwise things like SoftRouter and IPNetRouter wouldn't be able to work. More accurately, it is the AppleTalk and TCP/IP control panels that don't allow you to do this.)
OSX fixes this. With OSX, the user interface for the networking subsystem will allow you select multiple network interfaces and give them their own TCP/IP addresses, subnet masks, etc., and they will all work. Better still, you will be able to set up OSX to forward IP packets between interfaces, allowing it to act as a very simple router. So, for administrators wanting to set up the server version of OSX, you'll be able to set up, for example, a Gigabit Ethernet or ATM card, and set it to only communicate on a server subnet, where you would want clean, high-speed connections. You could then set up another Gigabit card, or a 100Mb Ethernet card so that Classic MacOS clients, as well as OSX clients could talk to the server OSX machine. This has been common practice with Unix, Windows, and other servers for years, and now the MacOS gets this as well. So, with OSX, you can have as many network interfaces as you have slots to stuff them in.
Another benefit that OSX brings is in security. The BSD/Darwin layer comes with the standard Unix security capabilities. For the network administrator, this is a huge benefit as the BSD underpinings give the admin better security capabilities than the current MacOS.
As secure as the current MacOS is, it's an accidental kind of security. Lack of a command line makes it by default, a very secure platform. But accidental security is not the same as deliberate security, and here is where OSX is far more capable than the current MacOS.
OSX, due to the BSD layer, has far more granular security capabilities than the Classic MacOS. You can apply separate permissions for the owner of a file or folder, the group that owner belongs to, and the general public. You can set not just read/write privileges, but execute privileges as well, so even if someone can see a file or application, they can't run it. You can apply different permissions for the directory that file is in, so, in a highly secure facility, the person who creates the file wouldn't be able to access it once they were done with it. So mobile workers can take laptops home, and not have to hide things from small children, as the child won't be able to touch it without the worker being logged in. While third party add-ons to the current MacOS give you this ability as well, with OSX, it's a part of the OS.
A further security advantage is that the primary user doesn't have to be the owner of that machine. Although first introduced with things like At Ease, MacOS 9's multiple users, and other third party products, OSX again, makes it a normal way to work, not an abnormal way. So in a corporate/educational setting, the owner of a given OSX Mac is going to be 'root', and everyone else logs in with various capabilities depending on the need. This is a wonderful thing when the person who has been working on a major product quits abruptly, and no one has their password. With OSX, not a problem, just have the administrator log in as 'root', and change the owner of the files to the person and/or that needs them.
A final security advantage is logging. Right now, even as secure as the current MacOS is, if you have physical access to a Mac, even Multiple Users takes about 5 minutes to bypass, and then the entire machine is yours. Worse yet, if the cracker in question is reasonably careful, they could copy every bit on that hard drive, and unless they left something out of place, no one would ever know. However, in the Unix world, there is an ability to log, not only major system events, but in a high-security configuration, you can log every action taken by every user, including 'root'. This means that you can easily track anyone's actions on not only an individual machine, but on the network as well. While this may sound disturbing from a personal freedom point of view, if you are the one in charge of making sure that your company's data and hard work stay that way, it's a serious advantage.
Obviously there are a lot more security features and capabilities in OSX than I went over here. There are also more security issues that need to be dealt with in OSX that I'll go over in my next column. But hopefully, the administrators out there who have maybe been a little nervous about OSX and it's Unix link can start to breathe easier, and feel better about what OSX will do for them instead of to them.
created 6 June 2000
Pondering a Microsoft Breakup
With the newest wrinkle in the Microsoft case, and writing this on the 56th anniversary of D-Day, I sat for a few moments and wondered a Microsoft breakup would mean to the Mac network administrator.
What would be the direct and long-term possible impacts from a two-paned window named Microsoft?
Short - term, not much. The Macintosh Business Unit is a big moneymaker for Microsoft, and one of the few divisions they can point to as an example of how they aren't a Windows-only company. In addition, the MBU gives them experience in one area that they may need a lot of if the breakup survives appeal: Writing applications that aren't a part of the operating system.
Think about this from Microsoft's point of view. For years, pretty much every Microsoft Windows application is not so much a program that runs on Windows as an extension to Windows. The Office programmers have been able to write for APIs that no one outside of Microsoft gets to see, and if they need to maybe have the Windows API altered for Office, well, no problem, make an internal suggestion, and see what happens. Even if it didn't work that way, the Office coders had access to the filesystem and OS at almost hardware levels. No other Windows application maker has that level of access, that easily.
And it's hurt Microsoft in a lot of ways. Because Office works as part of, instead of on top of Windows, it's been easy to get really good speed out of it. But the Office for Windows programmers have also gotten lazy with this. The best example is Access. There is no way that Microsoft is incapable of porting this application to the MacOS. The explanation that the Mac market won't support an application like Access is just as inane, as proven by FileMaker's deal with the Department of The Interior. So what's the deal then? Why isn't there an Access for MacOS, and along with it, a current version of Project, (which uses modified Access databases for its file format) for the MacOS?
Access, in its current form is so tied to Windows, that to do a quick port would require porting a huge chunk of Windows to the MacOS. Access just runs at too low a level to be a cross platform application. This means that if the Office folks can't get that juicy low-level Windows access without giving those same APIs out to the rest of their developers, and at the same time that the Office coders get them, they have two choices: Freeze Access where it is, and create a new, different low-end database, or, do the rewrite, get it above the OS, so that you don't have to give away the APIs for the low-level hidden Windows stuff. In either case, if you unlock Access from Windows, getting it onto the Mac is much easier.
Long - term, I think you would see most of Microsoft's applications needing the same type of rewrite. And this is where the Mac community could see some huge gains. Because guess who the current experts in getting Microsoft applications to work at a normal application level are?
That's right, the Macintosh Business Unit.
So now, things are looking a little better all of a sudden for the Mac, from the perspective of more Microsoft apps. Because they already know what issues are involved in running beasts like Word, and Excel when you don't have intimate access to the OS.
And from the administration view, there's some nice potential there as well.
Face it, for a company like Microsoft, the Linux market is a swamp. They may do okay, they may get corporate malaria from it. There's no way to ensure that the Linux you are coding Word for has anything to do with what it gets installed on. Filesystems, windowing environments, hardware, none of these things can be assumed with Linux. This is why you see so many commercial Linux products limited to a select few distributions on specific hardware, or like Corel, you run your own distribution for your apps to run on. No matter how you look at it, for Microsoft, it's not a pretty sight.
But OSX? Ah, there's a horse of a different color indeed, and it's green my friends. Here you have a Unix - based OS, with consistency that only a corporate admin could love. You know what your base hardware is going to be, the GUI is a thing to bet on, no worrying about the kernel version du jour, and it's based on a lot of open-source work!
All the benefits of Unix, and none of the headaches of Linux.
So now, the network management folks at Microsoft need a place to expand into, because WIndows is no longer locked tight for them....hmmm...What is the next logical target? A platform with horsepower, and a good user base, one that appreciates efforts towards ease of use and integration, one that Microsoft has experience with, yet isn't a threat to Windows?
What's that Trigger? M-A-C-O-S-X you say?
Again, these are nothing but opinions and predictions, and anyone can do no better or worse with a bowl of chicken livers. But the capabilities are there, the abilities are there, and the Mac has long been a fun little lab for Microsoft. And, if I had to decide on an additional platform for SMS, SQL*Server, IIS, Exchange, etc, because I needed to create a new revenue stream for those products, MacOS X would be looking pretty sweet. Using stuff you already have is always more effective than reinventing the wheel.
In any case, the computer industry hasn't been this much fun in a long time, and I think that Apple, and MacOS X have a good chance to reap some handy benefits from a Microsoft breakup.
created 28 May 2000
Network compatible applications wanted
One of the most frustrating things as an administrator is to get a call from a user because an application, extension, or some other piece of software isn't working correctly or as advertised. What doubles this frustration is to discover that the malfunction is caused by the software not dealing well with networks.
In this day and age, I find it inexcusable for any program, especially one designed for the workplace, written in the last year to not be fully network friendly. By that I mean applications and software that work on Macs that are running other pieces of software, and performing network functions. Yet time after time, version after version, I see software that just doesn't work well on a network. Some of the problems with PowerPoint and AppleShareIP are an example. As L. Carroll once wrote, "The time has come, the Walrus said..."
It must be assumed that any Mac is multitasking, and I think that we can avoid getting bogged down in the relative quality of how it does this. If you are writing any application, assume you are sharing CPU and other resources with email programs, web browsers, instant messaging software, etc. (Even if you write one of these, don't assume the other company's stuff gets tossed. I have at least two to three versions of web browsers, and email programs around for testing purposes) That means you have to go through extra hoops during coding and testing.
It means that if you need the user to open a file, that you have to use Navigation Services from the beginning, because you cannot assume that the file will be on a local hard drive. If your application doesn't use Navigation Services, it's time for that update. It means that if you are going to create a dialog, not only must it not stop the CPU until the dialog is dismissed, but the user has to be able to move it out of the way, as it may be blocking the information that the user needs to accurately do what you are trying to get them to do. It also means that you have to create dialogs that can be ignored until the user comes back to that application, as your application may not be the most important thing they need to do.
It means no hard-coding font numbers, no assumptions about what resources a particular Mac may have when the application is launched, because in the case of a laptop, Location Manager can completely alter these things while your application is being run. Laptops bring another issue to mind, and that of power management. This means that you have to play nice when the laptop is put to sleep, or when a battery notification is sent out. So if you are blanking out the menubar, you need to let the user know somehow that they are about to run out of battery. You need to code with an eye towards the CD drive not always spinning, or even not even being a part of the computer all the time. It means setting up your installations to be remote - install aware, for folks using netOctopus or FileWave, or the Apple Network Administrator Toolkit. If you write installers, it means that you make it easier for remote installations to be set up.
It means that you don't make assumptions on the locations of files, or that the user has the rights to alter certain files. Multiple Users is a heads up for what will be happening in OS X. No longer can you assume that a single user means a single Mac. The person using your application may need to get to it from many Macs. You need to take this into account.
It means that you don't lock out resources or memory that you don't need, and that you get religious about checking for memory leaks. It means that you don't code for any fixed CPU time other than what you happen to get at that moment. It means that you make proper use of the capabilities of the Thread Manager, or the MultiProcessing libraries, using appropriate gestalt calls to determine what these are. It means that you don't use undocumented calls that may disappear, or use features that are going to go away in the near future. It means that you have a full scripting implementation, so users can use your application in ways you never dreamed of, which has the byproduct of making more people want to use your application.
It means that when the OS tells your application to go into the background, that you not only do so quickly, but also relinquish CPU time. No fair eating 80% of the CPU when you're running in the background. It also means putting realistic RAM requirements in your ads, and in the Get Info box. No dividing real world by three to get normal and by six to get minimum numbers.
It means a lot of work for developers and testers, and that's a real hard thing to justify sometimes, but here's the benefits of this work. It means that users like to use your application, because it just works. It means that regardless of the resources available, as long as your minimums are able to be met, your application will always work as advertised. It means that network admins like me don't groan and curse your name at the mention of your product. It also means that people doing reviews of products write the kinds of reviews you *want* to put on a bulletin board. In other words it means you get to have the kind of application everyone wants to use, because it's cool, and it just works.
I'm not going to pretend these things are easy, but they are correct. We live in a distributed, multitasking world, yet I still see applications written with the assumptions that we are all still using the System 6 Finder, and that multitasking and networks are only for UberGeeks. But again, if you do all these things, or at least make a better attempt to do these things, I can promise you one more thing. The kind of reward that comes from having a great application, and the respect, and sales that come along with that.
Think about it....
created 25 May 2000
The 2000 WWDC
Well, after spending a week at the Apple World-Wide Developer Conference 2000, I think there is a lot to be happy about for network administrators. WIthout going into specifics, (because I have this obligation not to break NDAs, and personal trusts), I think that administrators have much to be pleased about, not only for OSX, but for OS 9.X, and Apple in general.
First of all, the difference between Apple's view on I.S. between last year and this year is amazing. Last year, if you mentioned supporting the Mac as an I.S. professional, the shields went up, and you got the "Apple is not moving into the enterprise market" speech, and that was that, end of conversation.
This year, it seems that Apple understands that I.S. is taking over computer support in the educational market, and that artists using Macs work for enterprise companies. They seem to understand that helping I.S. support Macs does not equate to Apple having a direct enterprise presence.
So as I was talking to various Apple people, they seemed genuinely interested in helping I.S. support the Mac and the MacOS. Maybe it's because they understand that MacOS X is going to be a much bigger product, in terms of things like rendering farms, server farms, etc.
Maybe they finally see that I.S. types can be an ally instead of an enemy. It really doesn't matter.
Or as one Apple person said, "K-12 is as big as any Fortune 500 company."
What matters is that at the documentation sessions, when I.S. folks were asking for better non-developer/non-user support and administration information, we got the answers that we didn't get last year. What matters is that during the sessions that dealt with the server aspects of OS X, when administrators were asking questions and requesting features, the Apple folks were asking us questions back about our questions.
If you're going to blow someone off, you don't ask for clarification. You say "thank you", and quickly move on to the next session.
I was pleased to see Apple understanding that if we are going to deploy OS X in the same space as AppleShareIP, that we will take longer to do that. Servers take longer to deploy than desktops, server budget cycles take longer to go through than desktop budget cycles, server testing takes longer than desktop testing, and Apple appears to understand this.
The answers I heard, and the conversations I had gave me a good feeling about Apple's attitude towards the people who support the computers that developers, educators, and artists create on.
This is not to say that I am entranced by Apple, and blindly going where they point. Like any company, they can change their song if they feel the need to. So I, like any good admin, will be watching how the walk matches the talk. But this is the first time in a while that the talk has been both good to hear, and realistic in tone and content.
It's a start, and that's better than we got last year.
On the OS 9 front, while Apple has been very clear that OS X is the future, and that the classic MacOS has a limited life span, I got a good feel that they aren't going to just leave the users of the current MacOS hanging. They are going to deliver needed improvements to the current MacOS, which makes sense, because from a business point of view, until they start selling OS X, it doesn't exist.
Apple also understands that there will be, in addition to the time frame leading up to the commercial release of OS X, a time when people will buy what they are comfortable with as a fall back from the new OS. Again, if you are looking for the classic OS to have major new versions and features, I personallywould not make that bet. The MacOS is a grand thing, but its needed to be fixed for a long time. OS X is that fix, and I welcome it. On the other hand, Apple seems willing to do those things that need to be done in the current OS.
Another thing for classic MacOS diehards to remember is that Apple supports products for a very long time after they have ceased to be a product. They supported the Apple II for many years after it ceased production, and considering the size of the current Mac installed base, I can't see them not supporting that base for a similar period.
Again, the important thing that I got from Apple is that while they want all Mac users on OS X as soon as possible, they understand that ASAP does not equal three weeks after release, especially in the educational market. The realism in this attitude is again, a welcome change, (especially if you remember things like Rhapsody and Copland.)
On the OSX front, the feeling I got was that while there was things that folks don't like about Aqua, most of us see them as not critical to the success of the OS. Considering that at least one developer has already released an Apple Menu for OS X, I think that most issues with Aqua will be handled, either by Apple, or the third party population.
Remember, MacHack is coming, and that is a very fertile source for improvements to the MacOS. And from what I heard around the conference, there are some very neat hacks already being started, so stay tuned for those.
On the non-Aqua front, the reaction was more generally positive. Apple is using OS X as a chance to fix some long-standing annoyances with the current OS, and they were happily taking ideas on just how this should work.
Security is of major importance to Apple, both in the classic OS, and especially OS X. The last thing that Apple wants or needs is a Melissa/ILOVEYOU debacle, and they seem to be perfectly willing to trade convenience for security. Apple is absolutely aware that a Unix base can open up all kinds of holes that don't exist in the current OS, and they are diligently working on keeping the script kiddies as frustrated with OS X as they are with the current MacOS.
In general, I think the upcoming months to the public beta of OS X, and the final release are going to be some of the most interesting in the history of the Mac, and I am looking forward to it. I would also recommend keeping a close eye on what comes out of MacHack, as I think that this year is going to be one of the most interesting in a long time for that conference as well.
So start planning, start thinking about how you are going to test the public beta, and what it will do for you.
Interesting things are afoot, and we as admins are going to be the beneficiaries of many of them. Only time will tell if that's good or bad.
Dealing with Virii
With the introduction of the "ILOVEYOU" virus, once again, email virii, and methods of dealing with them are at the front of every network administrator's thoughts.
Admittedly, as an administrator with far more Unix and Mac boxes than Windows PCs, I'm not in the same state of utter panic as many of my associates are. But even if I was in a position of having no Windows PCs, I would still make sure that my protection procedures were current.
Now there are a lot of ways to deal with virii, from the blind panic method of banning all attachments, (more than one pundit is saying this), to the simpler "Just say no to Outlook" method.
The first one is just nonsensical. Attachments increase the usefulness of email by a hundredfold. The ability to easily get the same data to large numbers of people who need it on the cheap is not going to go away, nor should it. Yes, virus writers, spammers, and even everyday folks sometimes do bad, or silly things with attachments. But ban them? You may as well get rid of email in that case, for without attachments, email is not much more useful than a phone with a good voice mail system.
Other methods that fall more in the middle of extremes are things like user education, setting up a virus scanner on your email server, ensuring that all files are scanned when opened or saved, etc.
The user education one is the most critical. Antivirus programs are only as good as their last set of definitions. If the virus is new and fast-moving, such as ILOVEYOU, or Melissa, then there is going to be a delay in getting the newer antivirus definitions out. Obviously, the virus can spread unchecked during this delay. If your users are educated, and motivated to use that knowledge, then the chances of opening a strange attachment is much less.
One of the big problems with the ILOVEYOU virus was that because it used the Outlook address books, the email was coming from a legitimate source, and once people saw that, they assumed that the attachment was legitimate too.
This is where education is needed. Users need to know that a certain amount of discretion is needed in dealing with attachments, regardless of source. I think that, outside of Bill Gates, or Warren Buffet, there are not too many people who could expect to receive a legitimate email from Dow Jones with "ILOVEYOU" as the subject. In almost every case of really bad infections, this is what was happening. The sender was legitimate, so the users opened the email, and boom. Infections. In some cases, the same person opened multiple copies of the same email from different sources.
Again, no antivirus program can substitute for education, and the will to use that knowledge.
Another set of solutions is to ban Outlook, the Windows Scripting Host, Exchange, Windows itself, etc. Although at first glance these seem silly, I wonder if some of them may not have value.
Feelings about Outlook aside, it has been the best vehicle for spreading virii over the last year or so, and none of Microsoft's updates seem to be fixing this. Before I get the emails on how useful Outlook is, believe me, I understand this. But security procedures, and virus prevention is a part of this, require you to eliminate holes, and as it stands, Outlook, Exchange, and the Windows OS act as huge security holes all too often.
The fact is, there are a lot of ways to get Outlook's functionality without the risks. For one, consider using a Unix - based IMAP email server such as Netscape/Sun's, or Stalker's, instead of Exchange. (I know that AppleShareIP has IMAP features, but it has some hard limits that make it unsuitable for all but fairly low-end implementations.) IMAP gives you easy access to your email, regardless of location, computer, or operating system. IMAP is supported by almost every email client available, which gives your users more options.
Consider a separate calendar server, such as Meeting Maker, or CS&T's Calendar server. These give you advanced scheduling features beyond what Outlook and Exchange support, and run on non-Windows OS's, which can eliminate yet another entry point for Visual Basic virii.
A good news server can give you collaboration and discussion capabilities, and if you need real-time features, there are a number of standards-based video conferencing servers from companies such as White Pine.
The advantage to considering multiple products is that you can tailor your solution to your needs. As well, Exchange has a history of not supporting anything other than Windows terribly well, whereas these products have full featured clients for almost all OS's and platforms, including Palm.
The disadvantage is that these are multiple products, and you have to manage them as such. You don't get one client that deals with all of them from one spot, (although Netscape/iPlanet comes close). Your education and training costs go up, because you have to learn how to manage these different products correctly.
That has always been a large part of the draw for Microsoft Exchange, the fact that you can get 90% of what you need with one product, on a relatively easy to manage OS.
So you have to make the choice:
Is it better to use Exchange and Outlook, and understand that you will have to be extremely proactive about email security and virus prevention and protection, but gain the simplicity of only needing one product?
Or, is it better to have multiple servers, possibly on multiple platforms, that allow you to avoid Outlook/Exchange and it's associated risks, but will force you to deal with the problems that integrating multiple products entails?
Unfortunately, that's the choice that all network administrators face, and there is still no easy answer.
created 23 April 2000
No matter how fast your network is, as an admin, you will always get the call for more speed. If you have switched 10Mbps lines to the desktop, you'll get the calls for 100. If you put 100Mbps to the desktop, you need Gigabit. I can guarantee you, no matter what you do, the network will never be fast enough for some folks.
Making things even harder is the never-ending array of new technologies that will make you network so fast, you won't even need hard drives in your Macs. Gigabit Ethernet, ATM, FireWire networking, Fibre Channel, high-speed switching, vLANS, the list is almost endless.
However, just blindly throwing money at a single solution may give you more speed, but it may also ignore the problems you are really having. Each of these technologies has a place where it fits better than others, and each of them has problems related to it's design and / or relative maturity.
First of all, on the desktop, you are going to be limited in what you can use. These days, the newer Macs all come with 100Mbps Ethernet, so that's a pretty good place to start. Most of your standard Ethernet equipment will handle switched 100Mbps without a lot of extra cost. Although you can use 100Mbps hubs and save some money, the shared bandwidth of a hub will give you less of a speed increase than you get with the dedicated bandwidth of a switch. Also, switches give you more configuration and management options for things like vLANS, and segmenting.
The next question is what about servers? This gets tricky, due to some limitations in the MacOS's networking architecture. The biggest problem is that the Mac cannot inherently have more than one active network interface per protocol. There is an exception to this in AppleShareIP, but that is strictly limited to AppleTalk, and AppleTalk's future is somewhat limited. Although OSX will lift this, for now, if you want more than one interface without third-party add-ons in the current MacOS, you can't do it.
This does not mean that you shouldn't consider higher-speed interfaces for MacOS servers. For things like print servers, RIP servers and the like, a Gigabit Ethernet card is still a good choice. One reason is that with a Gigabit card, the server can handle ten 100Mbps clients at full bandwidth. With some clever uses of switching, you can keep that Gigabit interface working at full speed, giving you maximum use of the available bandwidth, which in a heavy use environment can save you quite a bit of time and money.
Another area where higher-speed interfaces can help is with file servers. Technologies such as Fibre Channel allow you to set up disk arrays with access speeds that rival most SCSI implementations, and without the baggage that SCSI still carries, such as termination, LU numbering, etc.
In combination with a Gigabit card, you can get greater efficiency for all users of the server by eliminating bottlenecks on a few select Macs, and save money over reconfiguring an entire network. (I have seen too many servers with insanely fast disk arrays that are then attached to the network with 10 or 100Mbps connections into an almost-full hub, and everyone scratching their heads over why things aren't faster. )
Another advantage of Fibre Channel is that since it was first designed as a networking protocol, it can help you set up a Storage Area Network, or SAN. The advantage to a SAN is that the drives are not 'assigned' to a specific computer host, but exist as their own entity on your network. You can then have multiple servers accessing the same drive array, without one of them being dedicated as a file server. SANs are also OS independent, so if you have Windows NT/2000 servers, or Sun Solaris servers, they can easily access drives on a SAN as well.
FireWire is another interface that is coming into its own as a networking implementation. Recent announcements from companies like VST, MicroNet, unibrain, and others are showing that in addition to just being a way to get things like video into a Mac, FireWire can allow you to set up high - speed networks, or SANs with relative ease. Although FireWire is limited in the number of devices on a segment compared to Ethernet or Fibre Channel, the fact that all Macs come with it is a compelling reason to consider it, especially for server - to server communication. FireWire is also host and OS independent, so devices on a FireWire network can operate independently of any other devices, and do not need a host server.
Backup is another area that bears careful analysis for network speed. In this, the infrastructure of the network is more important than the interface speed on the backup server. This is mainly due to the relative slowness of the backup media and the backup process. Due to the stop / start nature of the backup process, and client load, even a fast tape drive will have trouble sustaining speeds in the 100Mbps range consistently. So for more efficient backup servers, you are better off ensuring that all your client Macs have clean, switched, 100Mbps connections. This will give you better overall results than slow connections on the clients, and a Gigabit card in the server.
Although I have mentioned only the current MacOS in conjunction with these products, there are Gigabit Ethernet solutions available from TeamASA, and Fibre Channel solutions from Micronet and Hammer that will run under MacOS X Server as well. Considering features of OS X Server such as NetBoot and QuickTime Streaming Server, getting as much speed from the hardware as possible only makes sense.
In the end, planning your high-speed implementation is as important as the implementation used. By carefully considering which technologies are best suited to the tasks at hand, you can greatly improve the speed of your network, without breaking your budget.
What is the 'best' computer?
created 19 April 2000
As a network administrator I am often asked, "What's the best computer?" Unfortunately, my answer tends to be a long series of questions starting with, "What do you want to do?" This question is a side effect of the computer industry, and for the network admin, the start of what is often a long series of headaches. People, (often having titles like "CEO"), want the BEST computer. What I have found however, is that there isn't one. Unlike a single task tool, such as a shovel, computers are designed to do, well, almost anything you can think of. With that kind of scope, it is impossible to pick one CPU, one operating system, one application and say "This is the BEST". But still the question persists.
What is really being asked here is, "What should we standardize on?" If you are running a network that makes use of almost any number of Macs, the follow up to this is "I think we should get rid of all the Macs because..." There is then a list of various reasons, some well thought out, some encouraged by certain other press outlets. In any case, the person has decided that somehow, having Macs on the network is a "bad thing". They have also decided that the only way to avoid the "bad thing" is to completely move to an 'industry standard computing platform'. Meaning Windows in 99.999% of these cases.
The problem for an admin, who has a network full of Macs that is running smoothly, and users who are getting their job done, is how to point out that standardization has much more to do with the work you are doing and less to do with the hardware you are doing it on.
One of the first things to do is find out why there is a push for standardization. Often times, you may find out about problems that users are having, but hadn't reported. In any event, sit down with the people behind the standardization push, talk to them. You can't counter arguments until you know what they are.
In many cases, the reason can be data exchange. Considering the misconceptions about what Macs can or cannot do that are endemic in my profession, do not be surprised if the same misconceptions are held by folks who aren't technically oriented. Make sure to point out that it is far easier to standardize on a document format for a given type of information transfer, than to completely rebuild a network. One of the best I have found is Adobe's PDF. Because it is content neutral, it can be an excellent final format for any kind of data, from word processing files to presentations. Other standards that are easier to implement are things like Word 8, or even HTML for word processing documents, Excel for spreadsheets, etc. These are not only areas that the Mac can meet or beat Windows in with ease, but it also concentrates the standards process on the output of work, not the process of work. In the scientific arena, the Mac versions of products such as Mathematica, and IDL are just as capable as their Windows counterparts, and with the speed boost these products get from the Altivec units in the G4, quite often a good deal more capable. (At the 1999 Apple WWDC, the Research Systems rep demoing IDL on a G4 said it was the fastest single-cpu version of that product in the company.)
If the reasons given are based on security, point out that there are viable, current, standards-based security solutions for the Mac, in such areas as VPNs, and SecureID systems. Be able to show that the Mac plays with internet standards such as IPSec as well as any other platform. Also, point out that in areas such as safety against cracking attempts, the MacOS is consdered to be one of the most secure platforms available. Point out specific real - world examples, such as the U.S. Army's MacOS - based web server being the only one that hasn't been successfully hacked in their recent round of troubles.
If one of the points to go to an all Windows network is because Macs are the cause of too much network overhead due to AppleTalk, show them that AppleTalk is no longer the necessity it once was. Macs are very capable of functioning in a 99% pure TCP/IP environment, without losing capabilities. You can bypass AppleTalk for printing, and use TCP/IP printing via LPR in all OS versions since 8.1 . In MacOS 9.0, the Network Browser not only does AppleTalk, but can function as an FTP client, and an LDAP client. Products such as MacNFS and DAVE, from Thursby Systems allow the Mac to connect to almost any other computer system in a TCP/IP environment. WIth MacOS 9, even personal filesharing is TCP/IP - based, and has less overhead than AppleTalk did. Again, the Mac has a definite architectural advantage here, as getting a Windows PC to deal with not only its native SMB networking, but things like NFS or other protocols is a more complex process than for a Mac. From the manageability standpoint, with the addition of SNMP in OS 8.5, and products such as Netopia's netOctopus, you can easily show that Macs are capable of being run in a coherent, centralized manner.
If there is still a push for 'standardizing' on Windows, don't be afraid to point out the costs of 'standardization'. Point out that forcing users to switch platforms is going to cost a lot of money. Not just for the initial hardware purchases, but for things like servers, network equipment, IS staff training and support, application replacement, user training and support. I have found that a lot of the folks who push for a 'Mac dump' are imagining replacing them with $400 computers, and when the real numbers are shown to them, are often quite willing to rethink the idea. Having to hire two or three more full-time IS people just to support an all-windows network is another cost that will never go away, and again, probably wasn't considered in the initial decision. Bring along a catalog showing the training costs involved in bringing your staff up to speed so that they can properly run an all-windows network.
Standardization, when used correctly, can be a time and money saver. As a Mac administrator, you have the obligation to be up to speed on the areas where the Mac is able to comply with industry standards, and where it is not. This is no different than any other platform. Make sure that someone from the IS group is a part of any standards body at your company, so that technical issues with changing or updating standards are adequately explained. Sometimes it can be a real bear to have to play the advocacy game, but if you consider the alternative, it's a small burden indeed.