The two biggest changes, however, in the new release are the inclusion of the GNOME 2 desktop environment and the addition of built-in support for wireless LANs. Of these two, GNOME 2 is the most problematic in an OS-upgrade scenario. For openBench Labs, each system upgrade that we made from SuSE 8.0 to SuSE 8.1 required a two-step approach.

The reason for this is rooted in the SuSE YaST installation program. It views all of the GNOME 2 packages as new software rather than as upgrades to GNOME, which is technically correct. As a result, a SuSE 8.0 system that has GNOME as a desktop option will not have that option after upgrading to version 8.1 of SuSE. Nonetheless, all of the appropriate GNOME 2 modules can be easily added via YaST following the initial shock of booting into KDE.

To insure maximum interoperability with other wireless LAN interface cards and APs, it’s best to look for devices bearing the Wi-Fi mark. This indicates that the equipment has successfully passed the interoperability tests devised by the wireless industry group. We chose the Proxim ORiNOCO AP 1000 for our access point. The AP-1000 utilizes two PC Card slots to enable transmission on two different channels for load balancing. Currently there are two ORiNOCO PC cards available with either the typical 64-bit Wired Equivalent Privacy (WEP) algorithm from RSA Data Security or a more robust 128-bit RSA encryption algorithm. We used 64-bit WEP cards in both our AP and our HP Omnibook client.

For anyone trying to integrate Linux and Windows 2000 into a corporate file-sharing scheme, it is either necessary to make Linux dance to the tune of Windows using SMB, or put Windows 2000 in step with an open industry standard protocol. This boils down to putting Samba on Linux or NFS on Windows 2000.

For environments with casual integration needs, Samba lets Linux clients cut in without missing a beat. It’s when you introduce a few more operating systems, say Solaris, HP-UX, or maybe even OpenVMS; you require a more exacting distributed security system; or you start to build an enterprise IT architecture on top of a SAN, that the Windows Samba solo starts sounding a bit discordant.

Just consider the minefield of file security. Linux file systems apply ownership and security from a completely different perspective from Windows 2000. Under Linux, only individual users own files. Under Windows NT/2000, individuals and the groups to which they belong may own files. For NTFS, Windows 2000 begins applying security from a global perspective—Everyone— and then begins to look membership in subset groups. Linux, on the other hand, starts with the user’s UID, then turns to the group to which the user belongs via the GID, and then finally looks to world permissions.

What’s more, the IP address of an NFS client along with the UID and GID of the user are the controlling factors when gaining access to an NFS server. Once these credentials have been established, the NFS server is able to control read, write, and execute privileges during file access. That makes it especially important in a large heterogeneous network to able to easily manage the user account information—UIDs and GIDs.

To enable NFS file sharing on the Windows 2000 server, we installed DiskShare from Shaffer Solutions, which adds NSFv3 support on Windows 2000 Server. NSFv3 is provided for in the 2.4.x Linux kernel and is the first major revision of NFS since it became a commercial product. While NSFv3 incorporates many performance improvements over version 2, such as extending the maximum transfer buffer of 64KB from 8KB for NSFv2, it does not change the NFS security model.

DiskShare provides a number of security mechanisms to rationalize the Unix security scheme with the NT security scheme. At the least granular level, there are global share permissions for resource—disk volume—access: none, read-only, read-write, and root. At the file level, read, write, and execute permissions are based on user and group IDs. As a result, DiskShare has robust facilities to map any given user ID to any Windows NT user and any given group ID to and Windows NT group. UIDs and GIDs can be entered manually or imported from a Network Information Service (NIS) master server.

Once DiskShare is up, running, and properly configured by a network or systems administrator, it creates an NFS daemon process on the Windows server, dubbed the PCNSFD service, which enables users to share any disk, partition, or folder as an NFS volume just as they would share a volume via SMB. The volume that we chose to share was physically resident on our MegaRAM 2000 ram disk, which is fully capable of saturating our 1Gbit SAN. We chose such functional overkill in order to insure that the wireless networking tests were not adversely affected by ancillary bottlenecks.

To test performance we began by creating a performance baseline for wireless file transfers using Samba. Our tests consisted of simple simple file transfers of a 100MB file initiated by dragging and dropping the file using the GNOME 2 Metacity desktop manager. We monitored the laptop system's performance using a KDE application, ksystemguard. GNOME 2 is perfectly capable of running applications with GUIs designed for KDE and GNOME.

We used Linux Network Neighborhood  as our client Samba application. This application provides a very comfortable interface for corporate Windows users. Interestingly, the latest version of this Samba client has eliminated the option to scan the network using a specific range of IP addresses. This change in the client application was transparent when using the Omnibook's 3Com embedded  LAN controller; however, problems arose when we tried to find systems with our wireless connection.

Scanning our workgroup using SMB using a wireless connection, however, never returned any of the available Windows computers or Samba servers. Only by explicitly adding a server via its IP address could we mount a shared volume offered by that server. Because of this wireless scanning issue, we recreated all of our tests with a Fast Ethernet connection.

 All of the results scaled according to Hoyle. In tests where we measured throughput in the range of 400KB with a wireless connection, throughput jumped to 4MB per second. Whatever its cause, the SMB scanning problem over a wireless connection did not materially affect performance once a connection was established.

When copying data from the Windows server to the laptop via Samba, throughput peaked at around 450MB per second and averaged about 375KB per second. At the same time, a steady 10% user process load was imposed on the CPU.

When copying our test file to the server, via Samba, throughput was a bit more consistent. This time it peaked again around 450MB per second, but was able to average around 425MB per second. Once again, CPU overhead had a distinct user process component of about 10%.

Shifting to using NFS on the client and using the PCNFSD daemon that was created on the Windows server with DiskShare, we measured a very distinct improvement in performance. We started by doing a file copy to the laptop from the same volume on the server used in our Samba test. This time, however,  the volume was mounted via NFS. Throughput jumped by 70% to 635MB per second.

At the same time, the CPU load was characterized by only a small amount of initial user process activity and a corresponding increase in the system load activity. The net result was a file transfer that completed in almost half the time.

Copying a file to the server using NFS did not produce any statistically different results from copying from the server. Throughput averaged about 650MB per second, which translates into about a 45% improvement in throughput performance over Samba. Once again, CPU overhead was a function of system process load rather than user processes. In terms of the time necessary to make the file transfer, NFS was about 30% quicker.

As noted earlier, when we repeated these tests over a wired Fast Ethernet LAN the relative results were unchanged. Using a medium that was an order of magnitude faster simply raised all of the performance numbers accordingly.

The first inescapable result is that using NFS v3 provides a significant throughput advantage sharing files. The second is that despite all the hand-wringing over the folding of Eazel earlier this year, Linux is very much alive and well on the desktop.