La respuesta breve es que en los viejos tiempos (50, 60 y principios de los 70) no había diferencia entre los dos, pero a mediados de los 60 como desarrolladores de sistemas operativos decidimos que era una mala idea y comenzamos a superponer mejor el sistema para separar funcionalidad Hoy, no importa qué sistema operativo use, la imagen se ve más o menos así:
El núcleo tiene algunas responsabilidades básicas:
- ¿Cuál es el lenguaje más utilizado en el aprendizaje automático?
- ¿El aprendizaje por refuerzo se usa popularmente en la optimización de ejecución comercial?
- ¿Cómo se almacena la información en binario?
- ¿Están los problemas de descifrado involucrados en los algoritmos de criptografía asimétrica actuales NP-Complete?
- ¿Cómo se puede aplicar Machine Learning para descifrar la secuencia de comandos de idiomas desconocidos?
- Interfaz con el hardware y proporcionar nombres y modelos uniformes para diferentes servicios que el sistema operativo proporciona a los programas en ejecución
- proporcionando protección / seguridad entre diferentes acciones que ocurren en el sistema
- cargar / descargar programas de memoria e iniciarlos / detenerlos según corresponda
El núcleo hace esto con un pequeño número de interfaces bien definidas, que llamamos “llamadas al sistema” que tienen resultados bien especificados para acciones específicas. Si el programa presenta algo o algún conjunto de información al núcleo, el núcleo devolverá algo más a cambio de ese programa (o un error).
El shell, o sistema de comando, por otro lado, es principalmente un programa para interactuar con el humano, aunque a veces también se puede programar en un sentido de secuencia de comandos para que se puedan realizar acciones más complejas. Su trabajo es traducir de ideas de nivel superior a acciones que la computadora puede tomar a instancias de los humanos. Utiliza las interfaces del sistema operativo con los servicios que proporciona el núcleo para realizar esas operaciones para el ser humano. Como resultado, el término “shell” proviene de la idea / observación de que, como usuario, “ves: la computadora como si estuvieras encerrada en un shell” ( es decir, en una habitación cerrada) y las únicas cosas sobre la computadora que lo que puedes observar son las cosas que el caparazón te permite ver. Todo lo demás sobre la computadora está oculto para usted, el usuario.
Como dije, en épocas anteriores, el sistema de comando se atornillaba en el núcleo y normalmente no era un programa separado. Así fue como se desarrollaron sistemas como TSS / 360, OS / 360, RT / 11, TOPS, etc. y originalmente VMS. Al hacer que el sistema de comandos, también conocido como el shell, fuera un programa separado del núcleo en sí, como se hizo con Multics y UNIX, significaba que se podían crear diferentes experiencias de interfaz de usuario a partir de las mismas partes fundamentales. A fines de la década de 1970, la mayoría de los sistemas operativos separaron el intérprete de comandos / shell y el kernel en el modelo que muestro arriba.
Considere Mac OSx y Linux, por ejemplo. Si bien ambos se basan en tecnologías “UNIX” y todos admiten algún tipo de shell de UNIX como interfaz de línea de comandos, la experiencia de inicio de sesión básica varía enormemente dependiendo de la ‘distribución, cómo está configurada, qué interfaz gráfica de usuario o qué shell está configurado como un shell de inicio de sesión. La “sensación” de los sistemas puede ser muy diferente. De hecho, Linux y UNIX a menudo están ‘integrados’ en dispositivos como los sistemas de navegación en automóviles o su ‘TiVo’, y es poco probable que vea un ‘aviso de shell’ en esos dispositivos.
Tenga en cuenta que Windows no es diferente en funcionalidad y puede hacer lo mismo, aunque el reemplazo de su interfaz se realiza con menos frecuencia. El punto clave es que el núcleo y la interfaz de usuario se han separado en las capas y, como resultado, se pueden insertar diferentes interfaces de usuario cuando tiene sentido.