As you can read in my “About” page, I’ve been involved with computing for a long time. Although the industry has seen tremendous progress during that time, every once in a while, something comes along that makes me think it is still 1980.
In the early days of personal computing (about 25 ago), when IBM PCs and Apple IIs started appearing on corporate desktops but before “LANs” became commonplace, the term “sneakernet” was used to refer to communicating information by physically walking it over. You’d write out your WordPerfect file to a 5-1/4″ “floppy” (which actually was “floppy”) then stroll over to your intended recipient. Pretty simple.
Later, even this simple scenario was complicated by the advent of 720Kb, 1.4Mb and 2.8Mb 3.5″ floppies (no longer “floppy”) and differences between IBM and Apple formats. The Mac used a weird variable speed technique that the PC could not read.
Even when networks started showing up in office settings, sneakernet remained popular. Early networks required that file exchange be accomplished by writing the data to a “file server” and then having the recipient read it from the agreed location. Connecting to a file server required magic NetWare or LANMAN command-line incantations.
“Windows for Workgroups” and, later, Windows 95 made PC networking much easier. Meanwhile Apple had a very easy to use network based in AppleTalk, yet another example of Apple’s willingness/bias towards doing things their own way.
It did not take long for the industry to consolidate on standards. AppleTalk, like “token ring” and other competing protocols gave way to Ethernet. Netbios and IPX gave way to TCP/IP. For a while, file sharing was not too hard. Users could easily “share” folders or store things in their automatically shared Public folders and use these file file exchange. It was okay to wear dress shoes to work and leave the sneakers at home.
The arrival and broad adoption of the Internet introduced new challenges that reversed this trend. The Internet made possible the effective use of WANs (wide-area networks) and the connection of companies and company branches that were not normally connected in a private network. Sharing files through sneakernet, now, became impossible because sneakers would not get you from New York to Japan or Australia (at least, not without getting them wet). On the other hand, sharing files through simple operating system mechanisms also became (almost) impossible, mostly, due to security concerns.
Within their LANs, companies often have liberal policies regarding what type of network traffic is allowed to occur. File sharing protocols work within these corporations because the necessary TCP/IP ports are available and communication to/from these ports is permitted. Corporations typically separate their internal LANs from the external Internet by using firewalls. Firewalls are typically appliances (or dedicated computers running networking software) that control what type of information is allow to flow between the internal LAN and the external Ethernet. The TCP/IP ports required for file sharing are usually blocked by firewalls. No IT director wants random strangers on the Internet to be able to access computers in their corporate LANs and to read shared files.
The net result (no pun intended) is that sharing files across the Internet has gotten complicated again. Some companies will set up special FTP servers outside their firewalls. Others might use Internet “collaboration” web sites to facilitate file sharing. More often than not, I see people simply e-mailing files to each other. Crude but simple. The electronic equivalent of sneakernet.
Another thing that makes file sharing complicated even within a LAN is the use of different operating systems. Once again, Apple is involved here but, this time, it’s got plenty of company. Mac OS X is based on the FreeBSD operating system – a UNIX variant. Mac OS X has the same challenges that Linux and all flavors of UNIX (AIX, Solaris, HPUX) have. In order for these systems to “talk” to Microsoft systems, they have to do one of two things: they have to “look like” a Windows client to get data from a Windows server or they have to look like a Windows server so that Windows clients can get data from them. (FTP is, again, an option in LANs but a relatively painful one).
The Samba open source software can help with both of these. Samba, for example, provides the smbclient utility that allows UNIX systems to get data from Windows servers using an FTP-like interface (but without requiring the Windows servers to run any FTP software). Samba also provides the smbd service (daemon) that allows a UNIX computer to look like a Windows server so that it can be accessed by Windows clients.
Setting up a Samba server can be a difficult task, especially if you want it to be integrated with Microsoft Active Directory and to supports its user authentication features. There’s a great 700+ page book that describes how to do it. Nevertheless, there’s no better way to do this. If you’re willing to forego AD security, setting up Samba is a lot easier.
Beyond Samba, there’s also the “smb file system” smbfs and some commercial products to allow Linux and Mac OS X to act like a Windows client. Additionally, Apple and Linux vendors have begun to build such functionality into their standard graphical “shells”.
Perhaps, in another 25 years, we’ll have it all worked out.