MacUnix

Why use the MacUnix version of KDX Server instead of the normal Mac version?

The core of MacOS X is based on Unix (BSD flavor). The normal Mac GUI (Graphical User Interface) version of KDX Server uses the Mac interface/API for networking (obviously, since it is a Mac program), which MacOS X then translates to the Unix interface/API for networking (which is the real networking interface in MacOS X). Whereas the Mac Unix version of KDX talks directly to the Unix interface/API and so is more efficient (an unnecessary layer is removed).

For a server program, the Unix APIs are likely to have greater reliability and performance overall than the Mac APIs (API = Application Programming Interface). So if you are running a busy/hardcore server, you might consider switching to the MacUnix version.

Please note that the Mac Unix version is for advanced users only. Unix is not user friendly. If this is your first time using KDX Server, we recommend that you stick to the normal GUI version for now.

The MacUnix version has been extended with some non-Unix Mac-Specific code. This allows it to access some Mac features that are not available in the Unix interfaces. However it is still almost entirely a Unix program. The MacUnix version requires MacOS 10.2 or better.

Differences Between MacUnix and Mac GUI Versions

• User Interface -- The MacUnix version does not display a graphical user interface (GUI). It is a command-line interface (CLI) program. This means it must be run using the Terminal program which is found in Utilities in Applications. However because it is named ended with ".command", you can simply double-click it and it will open in the Terminal program.
  
  
• Aliases -- The MacUnix version does not support Mac aliases -- they appear as unrecognized files. However it does support unix symlinks which are the equivalent of aliases, so use symlinks instead. If you use the MacUnix server to create an alias, it actually creates a symlink.
  
  
• Shutdown Computer -- MacOS X does not allow a unix program to use the "shutdown" shell command (used for both power-off and restart) unless the program is running as the root user. For more information, enter "man shutdown" into the Terminal.
  
  
• Mac Type/Creator Codes -- The MacUnix version does not recognize Mac type/creator codes. This means that the type of the file (for example, which icon is displayed for it) is determined by the extension at the end of the file name (".txt" etc). Mac type/creator codes are lost when transferring files. This is not a big problem because Apple has declared these obsolete, although there might be some compatibility issues with old programs.
  
  
• Mac Resource Forks -- The MacUnix version does not recognize Mac resource forks. Resource forks are lost when transferring files, and not included in file size information. This is not a big problem because Apple has declared resource forks to be obsolete. However, you may experience problems transferring some uncompressed Mac applications/programs, or documents produced by old programs. You can still transfer resource forks if you first compress the application/program/file before transferring it, using a compression program that supports resource forks such as Stuffit.
  
  
• File Color/Label -- The MacUnix version does not support Mac file colors/labels because it generates file listings using the Unix API, which does not support this feature.
  
  
• Child Counts -- The MacUnix version does not show the number of items in each folder in listings because it generates file listings using the Unix API, which does not support this feature.
  
  
• Volume Icons -- Both versions have difficulty identifying the correct icon to display for volumes, due to deficiencies in the Mac API. The MacUnix version is slightly worse at identifying the correct icon.
  
  
• Process Monitor -- The MacUnix Process Monitor generates the process listing using the Unix API, which gives different information to the Mac API, and shows more processes, and is generally superior albeit less friendly.
  
  
• Exit/Terminate/Restart Process -- In the MacUnix version, "Terminate Process" (which is intended to force the program to be impolitely terminated immediately) sends the unix SIGKILL signal and it works perfectly. "Exit Process" (which is intended to give the process a chance to save data etc before exiting) sends the unix SIGTERM signal, which is correct for unix programs but non-unix programs might respond as if Terminate not Exit had been used (possible loss of data). Restarting the process is not supported.
  
  
• Dock -- MacOS X does not show an icon in the Dock (that row of icons which is usually located at the bottom of the screen) for unix programs. The Terminal program appears instead, except if you have configured the unix program to startup automatically before login when the computer is started (in which case MacOS would show nothing).
  
  
• Auto Startup -- In theory at least, the MacUnix version can be started prior to login, when the computer starts, whereas MacOS X does not support this for GUI programs. In practise, it is difficult to configure MacOS X to do this. See the Auto Startup FAQ for more info.
  
  

Similarities Between MacUnix and Mac GUI Versions

• Trash -- The "Empty Trash" command in MacUnix empties the real Mac Trash (not ~/.Trash) thanks to special mac-specific code. And likewise for moving a file to the trash (deleting).
  
  
• Unicode -- Both support unicode including in file names.
  
  
• Comments -- Both support Mac file/folder comments.
  
  
• Launch Program -- The "Launch Program" command in MacUnix launches the file using the MacOS "open" shell command, which has the same effect as if you had double-clicked it in the Finder. For more information, enter "man open" into the Terminal. To launch unix CLI programs, name them ending with ".command", which makes them open in the Terminal program.
  
  
• View/Control Display -- Both support View/Control Display.
  
  

Security

You may wish to further increase the security of the MacUnix version by creating a new MacOS user account on the computer, and running KDX Server as this user, and then set your file/folder access permissions on the computer to limit what this user can access, thus giving you the dual protection of what KDX provides and what the OS provides.