¿Qué hace que un sistema operativo sea "similar a Unix"?

Con frecuencia me encuentro con el término "como unix" en muchos sitios web.

No hay un estándar; es justo en la forma en que se comporta.

Pero si tuviera que desarrollar un núcleo desde cero, ¿qué lo haría considerado "unix-like"?

Básicamente, ¿cuáles son las cosas que hacen que el código escrito sea como Unix?

No hay un estándar; es justo en la forma en que se comporta.

Creo que la mayoría de los sistemas operativos "similares a Unix" hacen un esfuerzo muy serio para adherirse al estándar POSIX , supervisado por Open Group, que también controla la Especificación UNIX única que define un "UNIX verdadero". El primero es el núcleo del segundo.

Entonces, de hecho, hay un estándar que define los aspectos prácticos de los sistemas operativos tipo UNIX . Eche un vistazo a la lista de sistemas operativos "totalmente" y "en su mayoría" compatibles al final del artículo de Wikipedia en POSIX.

Hay algunas razones obvias en que Linux en particular podría no ser considerado totalmente compatible o certificable por la Especificación Single Unix (SUS), pero esto no se debe a que un sistema Linux dado sea necesariamente incompatible con él. El artículo de wikipedia resume las especificaciones de esta manera:

SUSv3 totaliza unas 3700 páginas, que se dividen temáticamente en cuatro partes principales:

Definiciones básicas (XBD) : una lista de definiciones y convenciones utilizadas en las especificaciones y una lista de archivos de encabezado C que deben proporcionar los sistemas compatibles. Se proporcionan 84 archivos de encabezado en total.

Shell y utilidades (XCU) : una lista de utilidades y una descripción del shell, sh. Se especifican 160 utilidades en total.

Interfaces del sistema (XSH) : contiene la especificación de varias funciones que se implementan como llamadas al sistema o funciones de biblioteca. Se especifican 1123 interfaces del sistema en total.

Justificación (XRAT) : la explicación detrás del estándar.

La línea de comandos de usuario estándar y la interfaz de secuencias de comandos es el shell POSIX, una extensión de Bourne Shell basada en una versión anterior de Korn Shell.

Otros programas, servicios y utilidades a nivel de usuario incluyen awk, echo, ed, vi y cientos de otros. Los servicios requeridos a nivel de programa incluyen servicios básicos de E / S (archivo, terminal y red).

Un conjunto de pruebas acompaña al estándar. Se llama PCTS o POSIX Certification Test Suite.

Además, SUS incluye la especificación CURSES (XCURSES), que especifica 372 funciones y 3 archivos de encabezado. Con todo, SUSv3 especifica 1742 interfaces.

Obviamente, esto se refiere específicamente a muchos componentes del país de usuario (como el shell) que simplemente no forman parte del núcleo de Linux. Entonces no hay forma de que linux.org et. Alabama. puede tener el núcleo solo certificado; en este sentido, no es un sistema operativo en absoluto. Podrían, por supuesto, tratar de certificar algún sistema en particular usando el núcleo, pero esto no tendría sentido a la luz del esquema de distribución general: el núcleo y las personas que lo mantienen son independientes de las personas que mantienen el núcleo de usuario (GNU) que son independientes de las personas que mantienen distribuciones de SO ensambladas reales (Debian, Fedora, etc.).

Supongo que Debian o Fedora podrían participar en el proceso de certificación (por ejemplo, RedHat Enterprise podría convertirse en un "unix certificado"), pero esto plantea la pregunta de que es realmente deseable. Supongo que la razón principal de los sistemas SUS es ejecutar software (a escala comercial, no para el consumidor) escrito para tal, que simplemente no es el nicho de Linux: las personas que lo hagan pagarán miles de dólares por licencia para el sistema operativo, incluidos los lotes de soporte, etc., porque también están pagando decenas o cientos de miles de dólares por licencia por cualquier software adicional que quieran ejecutar en el sistema. Linux y los demás valores atípicos, por otro lado, han perseguido objetivos de diseño más allá del simple cumplimiento con fines comerciales, y hay varios ejemplos de esto, por ejemplo (desdehttp://en.wikipedia.org/wiki/STREAMS ):

STREAMS se requería para cumplir con las versiones 1 (UNIX 95) y 2 (UNIX 98) de la Especificación UNIX única, pero como resultado de la negativa de los desarrolladores de BSD y Linux a proporcionar STREAMS, [cita requerida] se marcó como opcional para POSIX cumplimiento por el Grupo Austin en la versión 3 (UNIX 03).

Un alojamiento interesante que destaca el punto que SUS y The Open Group! = Linux,! = BSD, etc.

Para ampliar la primera respuesta sobre POSIX, para comprender lo que significa "unix-like", bueno, primero se debe tratar de comprender qué es exactamente UNIX. Mirando la documentación de Open Group , que posee la marca registrada Unix, encontrará detalles sobre la evolución de la especificación Single UNIX : aquí está UNIX03 :

El estándar de producto UNIX 03 es la marca para los sistemas que se ajustan a la versión 3 de la especificación UNIX única. Es una versión significativamente mejorada del estándar de producto UNIX 98. Las mejoras obligatorias incluyen la alineación con el lenguaje de programación ISO / IEC 9989: 1999 C, IEEE Std 1003.1-2001 e ISO / IEC 9945: 2002. Este estándar del producto incluye los siguientes estándares obligatorios del producto: llamadas y bibliotecas internacionalizadas del sistema V3 extendido, comandos y utilidades V4, lenguaje C V2 e interfaces de terminal internacionalizadas.

UNIX98 :

El estándar de producto UNIX 98 es una versión significativamente mejorada del estándar de producto UNIX 95. Las mejoras obligatorias incluyen (1) Interfaces de subprocesos, (2) Extensión de soporte multibyte (MSE), (3) Soporte de archivos grandes, (4) Enlace dinámico, (5) cambios para eliminar dependencias o restricciones de longitud de datos de hardware, y (6 ) Cambios del año 2000. Además, se incluyen las siguientes mejoras opcionales: instalaciones de administración de software y un conjunto de API para soporte en tiempo real. Este estándar del producto incluye los siguientes estándares obligatorios del producto: llamadas y bibliotecas internacionalizadas del sistema V2 extendido, comandos y utilidades V3, lenguaje C, servicio de transporte (XTI) V2, sockets V2 e interfaces de terminal internacionalizadas. Además, también puede cumplir con el Estándar de producto de administración de software.

UNIX95 (mi énfasis):

Esta Norma de producto define una plataforma consolidada para el soporte de una amplia gama de aplicaciones desarrolladas originalmente para una de la clase de sistemas operativos que se derivaron del código y / o interfaces del sistema operativo UNIX desarrollados originalmente por AT&T , además de las instalaciones proporcionadas por el estándar de producto base. Tiene un alcance más amplio que Base. Este estándar de producto incluye los siguientes estándares de producto: llamadas de sistema internacionalizadas y bibliotecas extendidas, comandos y utilidades V2, lenguaje C, servicio de transporte (XTI), sockets e interfaces de terminal internacionalizadas.

Las versiones de servidor del estándar agregan Internet Server e IPv6 en algunos casos.

Entonces, por supuesto, vemos la referencia a AT&T Bell Laboratories y el lenguaje C es el núcleo de lo que es UNIX: el lenguaje C, las herramientas de base modulares y el shell y cómo se diseñaron e implementaron el núcleo, el sistema de archivos y otros componentes clave del sistema operativo .

Ahí es donde el libro El diseño del sistema operativo UNIX de Maurice J. Bach se convierte en una lectura invaluable porque es un asunto histórico en este momento. Es de destacar, por supuesto, cómo se relaciona esto con otros inventos como el lenguaje C de hecho. C fue desarrollado por AT&T Bell para implementar Unix con un lenguaje que podría ser tan rápido como el ensamblado pero portátil en diferentes hardware, y mucho POSIX es una extensión del estándar C.

En lo que respecta al núcleo en sí, a menudo encontrará un diagrama conceptual como este para ilustrar de qué se trataba tradicionalmente un núcleo UNIX:

Aquí hay algunos extractos del clásico libro del Sr. Bach (1986) que discuten los fundamentos del núcleo del sistema V de UNIX:

Sin embargo, [los subsistemas y programas de aplicación] utilizan todos los servicios de nivel inferior proporcionados en última instancia por el núcleo, y hacen uso de esos servicios a través del conjunto de llamadas del sistema. Hay alrededor de 64 llamadas al sistema en el Sistema V, de las cuales menos de 32 se usan con frecuencia. Tienen opciones simples que los hacen fáciles de usar, pero proporcionan al usuario mucha potencia. El conjunto de llamadas al sistema y los algoritmos internos que los implementan forman el cuerpo del núcleo [...]

[...] sus dos componentes principales son el subsistema de archivos y el subsistema de procesos.

Los archivos se organizan en sistemas de archivos, que se tratan como dispositivos lógicos; Un dispositivo físico como un disco puede contener varios dispositivos lógicos (sistemas de archivos). Cada sistema de archivos tiene un superbloque que describe la estructura y el contenido del sistema de archivos, y cada archivo en un sistema de archivos se describe mediante un inodo que proporciona los atributos del archivo. Las llamadas al sistema que manipulan archivos lo hacen a través de inodes. [y el grupo de búferes]

[...] Hay dos versiones del inodo: la copia del disco que almacena la información del inodo cuando el archivo no está en uso y la copia in-core que registra información sobre los archivos activos.

La ejecución de procesos de usuario en sistemas UNIX se divide en dos niveles: usuario y kernel. Cuando un proceso ejecuta una llamada al sistema, el modo de ejecución del proceso cambia de modo usuario a modo de núcleo : se ejecuta el sistema operativo y los intentos para atender la solicitud de usuario [...]

[...] la filosofía del sistema UNIX es proporcionar primitivas del sistema operativo que permitan a los usuarios escribir pequeños programas modulares que pueden usarse como bloques de construcción para construir programas más complejos. Uno de tales primitiva visible para bombardear a los usuarios es la capacidad de redirigir I / O .

[...] Además de atender las llamadas del sistema, el kernel realiza la contabilidad general para la comunidad de usuarios, controla la programación de procesos, gestiona el almacenamiento y la protección de los procesos en la memoria principal, interrumpe las interrupciones, gestiona archivos y dispositivos y se encarga de los errores del sistema condiciones

Si está interesado en las diferentes implementaciones de kernels en sistemas operativos tipo Unix, también puede echar un vistazo a la implementación de FreeBSD (4.4BSD) o al kernel Mach o ver esta comparación de sus características.

Cuanto más sepa sobre el diseño de UNIX, más comprenderá lo que sucedió en el siguiente diagrama sobre la ascendencia de UNIX y su historia . Bach habla principalmente del Sistema V en su libro, pero también habla de BSD:

Hay más en esto de lo que parece a simple vista . Por ejemplo, Mac OSX tiene certificación UNIX03, pero ¿lo ve conectado a alguno de los UNIX puros (en su mayoría en rojo)?

Arriba puede ver cómo BSD, GNU, Microsoft y diversas personas contribuyeron a este universo. Aunque GNU y, en última instancia, Linux no tienen un linaje directo con UNIX, puede ver que GNU es un esfuerzo para rediseñar en el mundo de código abierto las herramientas y el software de UNIX comercial que se había cerrado. Por lo tanto, mirar el software mantenido por GNU da una idea, por ejemplo, de las aplicaciones y bibliotecas prototipo iniciales.

Las guerras de licencias jugaron un papel en la evolución (y el estancamiento a veces) de UNIX. Puede ver de inmediato que UNIX está alineado según el tipo de licencia: cerrado frente a BSD ( BSD permite que el código sea de código cerrado ... vea OSX) y GPL que permite que Linux y GNU se complementen en el mundo copyleft. Aquí está el mapa clásico del núcleo de Linux desarrollado inicialmente por Linus Torvalds, que también revela lo que un núcleo "puede" ser en un sistema operativo tipo Unix:

Esto sugiere la idea de que un tipo de diseño " kernel " no es lo que hace que el estándar UNIX o lo que define un sistema operativo tipo UNIX. Esto se evidencia por el hecho de que muchos sistemas operativos tipo UNIX pueden tener un núcleo monolítico o un microkernel: el monolítico era el tipo de diseño clásico para UNIX. De hecho, incluso dentro de UNIX puro, HPUX tiene un núcleo monolítico, mientras que AIX usa un microkernel. Este debate sobre el diseño trata sobre el rendimiento y no está relacionado con la ascendencia o identidad de Unix. Por otro lado, existe un enfoque conceptual tradicional para proporcionar servicios al software, tratar con sistemas de archivos, etc., bajo sistemas operativos UNIX / tipo UNIX.

Creo que tales consideraciones agregarán contexto a la parte del sistema operativo de su pregunta.