L'origine d'Unix remonte à un projet commun entre General Electric, le Massachussettes Institute of Technology et les Bell Labs d'AT&T entre 1965 et 1968 : Multics. L'objectif de Multics était de montrer que les nouveaux concepts alors théoriques d'un système générique, multi-utilisateurs et à partage de temps étaient réalisables. Par contre, le projet était devenu trop ambitieux, et les objectifs de General Electric, qui étaient principalement d'ordre fonctionnel et opérationnel, dans un cadre d'amélioration de sa production, se heurtaient aux objectifs beaucoup plus expérimentaux et académiques du MIT. AT&T décida en 1969 de se retirer du projet.
Pour un certain nombre de personnes chez AT&T, qui avaient expérimenté avec des versions prototype incomplètes le retour à un ancien système d'exploitation était difficile à accepter et incompatible avec leurs réels besoins d'un environnement de programmation flexible.
Ken Thompson? décida de récupérer un ordinateur PDP-7 inutilisée, et se mit à développer un environnement simplifié intégrant une grande partie des notions présentes dans Multics : la notion de processus comme principale entité d'exécution, un accès transparent aux périphériques, un système de fichier arborescent, une interface interactive, etc. Il baptisa le système Unics (qui deviendra rapidement Unix) pour mettre en exergue sa simplicité par rapport au système plus complexe Multics.
Ses concepteurs (dont Dennis Richie?) définissent un certain nombre de règles pratiques pour concevoir et faire évoluer Unix :

1. Chaque outil du système fait une seule chose, mais le fait bien. Les nouveaux besoins doivent se concevoir comme de nouveaux outils (programmes) plutôt comme des évolutions/extension d'outils existants.
2. Chaque programme doit prévoir que ses données peuvent venir de n'importe quel autre programme, et que ses sorties peuvent êtres destinés à d'autres programmes. Les données d'entrée/sortie doivent, par conséquent, être le plus simple possible et ne pas être soumis à des contraintes de mise en forme complexe.
3. Les logiciels et les parties du système doivent être conçus pour être testés rapidement.
4. Concentrer les efforts sur le développement de petits outils réutilisables (éventuellement jetables) fonctionnant les uns avec les autres pour créer un programme.

Vers 1970, Unix tourne sur un PDP-11 (24Ko de RAM ; dont 12Ko utilisés par le noyau d'Unix) et commence à être utilisé par d'autres que ses seuls concepteurs. Le passage au nouveau PDP-11, met d'ailleurs en exergue l'inefficacité en terme de portabilité de l'écriture en assembleur. Les concepteurs se tournent alors vers un langage, appelé B, malgré ses pauvres capacités et performances. Progressivement, les besoins nécessitant d'empiler de plus en plus de bibliothèques de fonctionnalités autour du langage, Dennis Richie? et Brian Kernighan? finirent par développer en parallèle un nouveau langage plus en adéquation avec leurs besoins, et beaucoup plus performant, le langage C. Lorsque le C fut suffisamment mûr, le noyau d'Unix fut réécrit dans ce langage, vers 1973 (il comporte alors approximativement 11000 lignes de code, dont 10000 en C).
À partir de 1973, AT&T commence à utiliser Unix dans ses produits et diffuse les programmes sources sous licence à partir de 1975. L’environnement sh (pour « shell ») est développé par Steve Bourne? en 1974. Pendant l'année universitaire 1976-1977, Ken Thompson? passe une année comme enseignant à l'Université de Berkeley en Californie et y impulse ce qui deviendra une des branches majeures d'Unix, indépendante de celle d'AT&T : BSD (Berkeley Software Distribution). C'est d'ailleurs à Berkeley que sera développé en 1978 le csh (pour « C-shell ») par Bill Joy?. Ce développement parallèle d'un « autre » Unix est emblématique de ce qui va se produire tout au long des années 1970 et 1980 : comme la licence de distribution n’était pas chère, qu’elle donnait accès au code source et autorisait une grande liberté dans l'utilisation du produit, chaque constructeur majeur de l'époque a développé son propre Unix (Solaris, HP-UX, AIX, Ultrix, ...), plus ou moins compatible avec les autres. D'où la nécessité d'avoir une norme : Posix, qui a vu le jour en 1988.
Linux (dont la première version date de 1991) n'est pas une version d'Unix ! D'ailleurs, certains prétendent que Linux n'est pas tant un jeu de mot avec le prénom de son concepteur initial, Linus Torvalds?, mais plutôt l'acronyme pour « Linux is not Unix ». Linux est le produit d'une rétroconception d'un système d'exploitation à partir de Posix. Posix étant une norme payante mais ouverte, Linus Torvalds? a eu l'idée de s'affranchir de la licence Unix qui était obligatoire pour avoir accès aux codes source d'Unix, en développant, à partir des seules spécifications fonctionnelles, un nouveau système. De fait, Linux est parfaitement compatible avec les différents Unix au niveau des interfaces principales de programmation et d'utilisation.

La majorité des systèmes d'exploitation (exception faite des systèmes spécifiques ou embarqués) intègrent aussi une interface graphique. Certains ne permettent pas d'autre interaction qu'à travers un système de fenêtrage.
Les interfaces graphiques sont majoritairement conçus autour du paradigme WIMP? (Windows, Icons, Menus, Pointing device). Les métaphores, l'iconographie et les différentes dispositions, ainsi que les enchaînements des actions font l'objet de champs d'études bien au-delà de cet ouvrage. Ils constituent néanmoins souvent des éléments de différenciation notables entre les différents systèmes.

Même si tous ces systèmes d'interface graphique servent le même objectif, ils diffèrent grandement sur plusieurs points en termes d'architecture et d'implémentation.

Un corollaire des interfaces graphiques est l'association d'actions à des données. Les interfaces graphiques nous ont habituées à activer des applications en cliquant sur des documents. La notion de fichier exécutable, contenant des instructions binaires qu'un processus doit exécuter existe toujours, elle n'est plus toujours invoqué directement, mais souvent à travers des documents.
Pour cela le système associe un « type » à chaque document afin de mettre en place un mécanisme d'association entre des types de documents et les actions qu'ils déclenchent.
Dans le monde Windows, c'est le nom de fichier qui sert d'indicateur. Selon son extension, un type est supposé et les actions correspondantes sont déclenchées. Dans les environnements Unix, la notion d'extension n'existe pas, et le « . » est un caractère quelconque du nom du fichier (sauf si c'est le premier caractère du nom, auquel cas le fichier est considéré comme « caché »). En revanche, beaucoup de systèmes de fichiers, comme ext2, par exemple, intègrent dans les attributs des fichiers un nombre magique ou magic number. Chaque fichier se voit attribué un type, et la commande file permet de connaître le type de contenu, et donc de déclencher le traitement associé.