Le choix entre NIS et NIS+ est facile à faire : utilisez NIS tant que vous n'avez pas besoin d'utiliser NIS+ ou si vous avez des besoins de sécurité importants. NIS+ est bien plus problématique à administrer (c'est plutôt facile à manipuler du côté du client, mais en ce qui concerne le côté serveur, c'est une horreur). Un autre problème est que le support de NIS+ pour Linux est encore en cours de développement : vous devrez avoir la toute dernière version de glibc ou attendre la sortie de glibc 2.1. Il existe un portage du NIS+ glibc pour libc5, qui consiste à installer une libc de remplacement.
Le choix entre "NIS traditionnel" ou le code NIS dans la bibliothèque NYS est un choix entre paresse et maturité d'un côté, flexibilité et amour de l'aventure de l'autre.
Le code "NIS traditionnel" se trouve dans la bibliothèque C standard, existe depuis fort longtemps, et souffre parfois de son age et de son léger manque de souplesse.
Le code NIS de la bibliothèque NYS vous oblige à recompiler la bibliothèque libc pour y inclure le code NYS (à moins que vous ne trouviez une version de libc précompilée chez quelqu'un qui l'a déjà fait).
Une autre différence est que le code "NIS traditionnel" gère en partie les groupes de réseaux NIS (Netgroups), alors que le code NYS ne le fait pas. D'un autre côté, le code NYS vous permet d'utiliser les mots de passe Shadow d'une manière transparente. Le code "NIS traditionnel" ne permet pas d'utiliser les mots de passe Shadow sur NIS.
Vous pouvez cependant oublier tout ça si vous utilisez la nouvelle bibliothèque GNU C 2.x (alias libc6). Elle comporte un vrai support de NSS (Name Switch Service), ce qui la rend vraiment souple, et elle est capable de gérer les "maps" NIS/NIS+ suivantes : aliases, ethers, group, hosts, netgroups, networks, protocols, publickey, passwd, rpc, services et shadow. La bibliothèque GNU C ne pose aucun problème avec les mots de passe Shadow sur NIS.