La scelta tra il "NIS tradizionale" o il codice NIS nella libreria NYS è la scelta tra pigrizia e maturità contro flessibilità e spirito d'avventura.
Il codice del "NIS tradizione" è nella libreria C standard, è in giro da parecchio e qualche volta soffre della sua età e leggera inflessibilità.
Il codice NIS nella libreria NYS richiede la ricompilazione delle libreria libc per includere al suo interno il codice NYS (oppure si può prendere una versione precompilata di libc da qualcuno che l'ha già fatto).
Un'altra differenza è che il codice NIS tradizionale ha un po' di supporto per i Netgroup ("gruppi di rete") NIS, che il codice NYS non ha. D'altra parte il codice NYS permette la gestione delle Shadow Password in modo trasparente. Il codice del "NIS tradizionale" non supporta le Password Shadow su NIS.
Si dimentichi tutto questo se si ha la nuova libreria C 2.x della GNU (detta anche libc6). Ha un reale supporto per NSS (name switch service), che la rende davvero flessibile e contiene il supporto per le seguenti mappe NIS/NIS+: aliases, ethers, group, hosts, netgroups, networks, protocols, publickey, passwd, rpc, services e shadow. La libreria C della GNU non ha problemi con le shadow password assieme al NIS.
La scelta tra NIS e NIS+ è facile: usare NIS se non si deve usare NIS+ o si hanno stringenti necessità di sicurezza. NIS+ è _molto_ più problematico da amministrare (è abbastanza facile da gestire dal lato client, ma il lato server è orribile). Un altro problema è che il supporto per NIS+ sotto Linux è ancora in sviluppo: si deve usare l'ultimissima glibc 2.1. Esiste un port del supporto NIS+ di glibc per libc5 come rimpiazzo temporaneo.