💾 Archived View for texto-plano.xyz › peron › articulos › fundamentos_unix.gmi captured on 2023-06-16 at 16:55:09. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-01-29)
-=-=-=-=-=-=-
Unix no es el único sistema operativo de uso común, pero probablemente sea el más importante, o al menos la clase más común de sistemas utilizados para la informática de infraestructura.
Este documento proporciona una descripción general de los sistemas Unix dirigida a aquell@s que cuentan con poca experiencia en sistemas similares a Unix tales como GNU/Linux, BSD u otros derivados relacionados. Si cuentas con más conocimientos de Linux u otros sistemas similares a Unix, en este documento se aborda parte de la historia, lógica y convenciones comunes que podrían no resultar obvias para l@s usuari@s contemporáne@s pero que, sin embargo, permitan dar forma a sus experiencias con esta tecnología.
Los programadores de los Laboratorios Bell (es decir, la telefónica AT&T) desarrollaron Unix a partir de 1969 como un sistema de investigación y desarrollo de tiempo de cómputo compartido. Eventualmente, la flexibilidad y la portabilidad que caracterizaron al nuevo sistema operativo fue impulsando su adopción tanto en situaciones académicas como industriales en los EE.UU., y para la década de los años 80 existían allí toda una serie de sistemas Unix de patente comercial basados en código fuente derivado de las versiones de Unix de AT&T.
Al momento de surgir Unix, la actividad económica en la informática se derivaba de la aplicación más que de los productos. [1] Esto condujo a dos fenómenos:
-La comunidad de usuari@s de Unix apreciaba y valoraba la apertura y la capacidad de examinar y modificar todos los aspectos del sistema. No había usuarios "no técnicos" de Unix; los sistemas eran - al menos en los primeros días - mucho más simples y, a menudo, se proporcionaba el código fuente. Eventualmente, cuando las empresas comenzaron a vender Unix, la apertura en torno a las licencias y la disponibilidad fue decreciendo. Sin embargo, las decisiones fundamentales de diseño continuaron impregnando el ethos de Unix y sus usuarios (ver "Filosofía").
-El sistema en sí es y fue flexible, de propósito general y extremadamente extensible.
Más tarde, entre finales de los 80 y principios de los 90, fueron desarrollándose variantes de software libre de Unix, dando rienda suelta a sistemas cuya particularidad era que cualquiera pudisese usarlos y modificarlos de forma irrestricta. Hoy en día, estos sistemas Unix de software libre predominan en el cómputo contemporáneo a nivel de sistemas. Los sistemas similares a Unix actuales constan de los siguientes sistemas y componentes principales:
El proyecto GNU representa un conjunto completo de utilidades de "de usuario" (es decir, no relacionadas con el núcleo de sistema). En muchos aspectos, los componentes de cualquier sistema similar a Unix no embebido con el que cual l@s usuari@s interactúan realmente son las herramientas de usuario de GNU, por lo que la experiencia de usar "similares a Unix" generalmente se refiere a los componentes GNU.
Linux es un núcleo de sistema operativo ("kernel") que proporciona a un sistema operativo similar a Unix características de administración de memoria, abstracción del sistema de archivos, servicios básicos de comunicación en red y otros servicios esenciales. Desarrollado a principios de los 90, siguiendo [3] el modelo de desarrollo de software libre, Linux tiene una comunidad vibrante de desarrolladores y un amplio soporte para una diversa selección de plataformas de hardware. Como resultado, actualmente Linux es el principal kernel de sistema similar a Unix en uso.
Derivado de los sistemas BSD originales de los años 80 (que en última instancia se derivan del código de AT&T), BSD combina los núcleos de sistema y herramental de usuari@ en una sola entidad conceptual. Los ejemplos actuales incluyen FreeBSD, OpenBSD, DragonFlyBSD y Darwin (el núcleo en el que Appl€ basa sus sistemas OS X).
Las razones exactas por las que Unix continúa prevaleciendo luego de 4 décadas tras su creación son múltiples y resultan difíciles de aislar. Sin embargo, los siguientes fenómenos son causas principales:
La calidad del kernel de Linux (y del herramental de usuari@ de GNU) y su amplio soporte para diferentes plataformas y configuraciones de hardware lo convierten en la opción tecnológica obvia para la mayoría de las aplicaciones informáticas. [2] El hecho de que el sistema operativo sea gratuito y también libremente modificable le agrega un gran valor.
Cuando l@s programador@s tienen preferencia por un sistema específico, tenderán a desarrollar más software innovador para tal sistema. L@s programador@s originales de UNIX eran ingenieros y compilaron Unix para su propio uso. Debido a que Unix expone su poder a l@s usuari@s, l@s programador@s a menudo gravitan hacia esta plataforma.
Probablemente en lugar de afirmar que el soporte de redes en sistemas similares a Unix es muy potente y flexible, resulte más justo decir que las redes contemporáneas (es decir, TCP/IP y todos los protocolos con los que estamos familiarizados) son - en sí - similares a Unix. Las personas que diseñaron y desarrollaron los protocolos de red que usamos hoy en día contaban con gran experiencia en Unix y probablemente dieron uso de sistemas Unix. Si bien todos los sistemas tienen soporte para redes, el sistema de redes es particularmente flexible y fácil de usar, lo que ha fomentado la adopción de Unix para cargas de trabajo de infraestructura.
Unix siempre ha funcionado y los sistemas Unix contemporáneos tienen esta propiedad. Los sistemas Unix cuentan con una sólida separación inter-procesos, lo que mantiene aislado a la mayoría del software de usuario entre sí. La separación evita interacciones más propensas a causar bloqueos. Como resultado estos sistemas pueden funcionar fácilmente durante meses o años sin necesidad de reiniciarlos y con un mantenimiento mínimo.
Si bien estas características no son necesariamente exclusivas de Unix, y son en gran medida consecuencia del acervo de la plataforma. Estos aspectos, sin embargo, han tenido un gran impacto en la adopción y la prevalencia continua de los sistemas similares a Unix.
Dada la diversidad actual de sistemas similares a Unix, la siguiente lista abarca un resumen de varias características tecnológicas específicas y abstracciones que definen el paradigma Unix:
El sistema de archivaje está en el centro de todos los sistemas Unix, y los ficheros proporcionan una metáfora de abstracción para otros tipos de objetos, incluida la comunicación entre procesos, los servicios del núcleo, las conexiones de red y los dispositivos de hardware. Mediante el uso de una única metáfora - en gran medida efectiva - para englobar tantos conceptos y aspectos diferentes del sistema, Unix es capaz de ofrecer gran cantidad de funcionalidades en un conjunto de herramientas comparativamente pequeño. Debido a que la metáfora y las herramientas son tan omnipresentes (¡y simples!), es sencillo para l@s usuari@s, programador@s y administrador@s aprender cómo realizar nuevas tareas más rápidamente.
Los sistemas de archivaje no están exentos de inconvenientes y limitaciones, en particular para los sistemas de datos de alto rendimiento y algunos controles de acceso más complejos. Por demás, la metáfora no se encuentra prevalente al completo (por ejemplo, los dispositivos de red en el sistema de archivaje de Linux carecen de nodos de dispositivos, y muchos procesos cuentan únicamente con interfaces e interacciones mínimas).
Finalmente, los sistemas Unix disponen de un solo "árbol de sistema de archivaje" y las herramientas como "mount" son las encargadas de proporcionar interfaces para integrar y vincular los distintos dispositivos de medios de almacenamiento como orígen de datos a través de una organización puramente lógica. Por demás, los sistemas como "FUSE" hacen posible (e incluso simple) ver e interactuar con objetos ajenos al sistema de archivaje, utilizando herramientas del sistema de archivaje en sí.
En Unix, los procesos tienen una entrada estándar y una salida estándar que l@s usuari@s usan para la interacción básica, y a través de guiones. Debido a que toda la entrada/salida se encuentran definidas en un mismo modo, el texto plano (sin formato), es posible dirigir la salida de un proceso a la entrada de otro, o escribir la salida de un proceso en un fichero. Como todos los procesos son similares en este sentido, la automatización de operaciones comunes o la escritura de funciones novedosas basadas en herramental existentes es trivial y común. Estas características muy simples dan lugar a una serie de aspectos de la "Filosofía Unix" y dan forma al diseño y funcionamiento de una gran cantidad de software Unix.
Muchos elementos de software de Unix - incluidos los sistemas que inicialmente no parecían propensos a convenir arquitecturas cliente-servidor - emplean este patrón de diseño básico como método para separar las interfaces de la implementación interna en todos los niveles. Además, los sistemas cliente-servidor crean cierta medida de paralelismo y asincronía, lo que puede conducir a un rendimiento aún mayor (especialmente en hardware contemporáneo).
Si bien muchos núcleos de Unix utilizan una arquitectura monolítica internamente con el fin de brindar una mayor confiabilidad y rendimiento, el impulso de mover la funcionalidad fuera del núcleo de sistema y hacia el herramental de usuari@ sigue siendo un tema persistente en el desarrollo de tales sistemas.
L@s programador@as y usuari@s de Unix - en su mayor parte - siempre han estado dispuestos a ceder, como lo indican las preocupaciones pragmáticas. Los ficheros y los sistemas de archivaje proporcionan una abstracción útil en varias situaciones, pero existen casos en los que no tiene sentido representar una interfaz usando ficheros, en cuyo caso el sistema no usará esta metáfora. Del mismo modo, si bien prevalecen en muchas situaciones las arquitecturas cliente-servidor y los paquetes altamente regimentados, existe una notable n cantidad de procesos y diseños monolíticos que tienen más sentido de usar, y todas estas soluciones hayan su lugar dentro del ecosistema más grande de Unix.
[1] es decir, la forma de ganar dinero con las computadoras era - y podría decirse que todavía es - usarlas para "hacer cosas" y optimizar los procesos existentes, en lugar de vender recursos o licencias de uso de software.
[2] Si bien existen otros sistemas operativos y núcleos de muy alta calidad, todos los demás sistemas de propósito general de uso común (es decir, BSD, Darwin, Windows y los sistemas basados en UNIX System V como AIX, HP-UX y Solaris) existen por razones comerciales (es decir, licencias) o porque son anteriores a Linux. Si bien muchos de estos sistemas operativos no son gratuitos ni de código abierto, la mayoría de los sistemas de propósito general restantes son derivados de Unix.
[3] En muchos sentidos, el proyecto del kernel de Linux definió la forma en que la mayoría de los proyectos de software libre desarrollan software.
El diseño de Unix y la historia de su uso han dado lugar a una colección de principios y enfoques para escribir software y administrar tecnologías, los cuales - en conjunto - se conoce como "la Filosofía Unix".
El elemento ideal del software Unix es una herramienta de software simple, con una interfaz simple que hace una cosa (como escribir datos en un fichero desde una fuente de red, descargar correo electrónico, cambiar el nombre de un fichero, filtrar el contenido de un árbol del sistema de archivos, buscar un patrón de texto en un flujo de datos de entrada o un fichero, o transformar el contenido de un fichero. El paradigma de Unix está definido por estándares: los formatos y paradigmas de entrada y salida estandarizados, el enfoque en el sistema de archivaje y un sistema universal de secuencias de comandos interprocesos (es decir, caños y el intérprete de comandos), que respaldan un ecosistema y una plataforma - en gran medida - armoniosos.
Richard Gabriel acuñó esta idea para representar la idea de que las implementaciones e interfaces simples eran preferibles a las implementaciones e interfaces más complejas, incluso si las soluciones con mayor complejidad tenían más "corrección" o mayor funcionalidad. La simplicidad hace que los sistemas y el código sean más fáciles de usar, ampliar, modificar y mantener. Los sistemas simples, aunque suelen ser un poco más difíciles de diseñar, también son más fáciles de implementar.
Hay críticos del enfoque Unix de los sistemas y la tecnología, tanto dentro como fuera del mundo Unix. Hay una gran cantidad de software de Unix que no se adhiere a ningún tipo de "objetivo de diseño de Unix", y si busca lo suficiente, puede encontrar muchos ejemplos de software que sacrifica la simplicidad por funcionalidad adicional o corrección. También hay una gran cantidad de software de Unix que intenta hacer muchas cosas en lugar de centrarse en una función, o que evita pragmáticamente el sistema de archivos.
Los sistemas de administración de bases de datos son un gran ejemplo de software que intenta hacer muchas cosas a expensas de la simplicidad y, al mismo tiempo, evita el sistema de archivos y el texto sin formato para mejorar el rendimiento y la conveniencia. Las bases de datos utilizan representaciones binarias en disco y, a menudo, se utilizan para el almacenamiento de datos, la agregación de datos, la persistencia de aplicaciones, el almacenamiento en caché y el almacenamiento de datos de configuración.
Hay muchos otros ejemplos de software que rompen con las convenciones de Unix: Emacs es un gran ejemplo de una pieza de software para un propósito (editar texto) que proporciona todo, desde funciones de secuencias de comandos hasta navegación web y servicios de correo electrónico. fetchmail proporciona funciones de clasificación y filtrado de correo electrónico además de la recuperación básica de correo.
Más allá del hecho de que los sistemas y el software de Unix se adhieren mal a la filosofía de Unix, también es cierto que, si bien las herramientas simples son individualmente más fáciles de entender y usar que las herramientas complejas, los grandes ecosistemas de herramientas simples son en sí mismos complejos en su conjunto. Estos sistemas a menudo tienen grandes problemas de dependencia y pueden sufrir fallas y problemas de rendimiento difíciles de aislar.
En efecto, según la interpretación de los sistemas contemporáneos, la “Filosofía Unix”, en la medida en que existe, puede circunscribirse a las siguientes ideas:
Unix ha seguido cambiando para reflejar los requisitos, el hardware y los patrones de uso contemporáneos. Si bien las herramientas de Linux y GNU predominan en el espacio similar a Unix, sigue existiendo una gran diversidad entre los sistemas operativos y las "distribuciones". Esta sección proporciona una serie de heurísticas para evaluar las diferencias entre estos sistemas.
Los sistemas de gestión de paquetes son las herramientas que permiten que los sistemas instalen, rastreen, actualicen y creen software que funcione con otros sistemas. El enfoque de un sistema operativo y el uso del software de administración de paquetes explica en gran medida las diferencias entre los sistemas. Existen dos enfoques básicos:
-El enfoque del sistema base.
Algunos sistemas tienen un sistema "base" que no está gestionado por el sistema de administración de paquetes, que incluye ciertas utilidades principales, las bibliotecas necesarias, el kernel del sistema operativo y las propias herramientas de administración de paquetes. Luego, todo el resto del software reside en el sistema.
Este enfoque es utilizado típicamente por (algunas) distribuciones comerciales de Unix y sistemas Unix derivados de BSD. Por lo general, estos sistemas mantienen sus propios núcleos de sistema operativo exclusivos y, al mantener un conjunto "básico" de utilidades, es posible que l@s usuari@s hagan suposiciones sobre las dependencias que estarán disponibles en un sistema de un tipo y una versión determinados. Al mismo tiempo, estos sistemas tienden a ser más difíciles de actualizar.
-El enfoque de “empaquetar todo”.
Otros sistemas gestionan todo en un sistema como un paquete a través del sistema de gestión de paquetes; desde la propia herramienta de gestión de paquetes hasta el núcleo, pasando por todas las utilidades de usuari@.
Muchos sistemas Linux adoptan este enfoque (por ejemplo, Arch Linux, Debian/Ubuntu, Fedora/Red Hat, Slackware, SuSE, etc.) y hace que la actualización de bibliotecas y otras actualizaciones de sistemas grandes con requisitos de dependencia más complejos se vuelvan más sencillas y confiables. Al mismo tiempo, a vecesproducen problemas difíciles de arranque relacionados con la instalación inicial, y han existido problemas de manejo de dependencias que han agregado mucha complejidad , pero los sistemas modernos son bastante útiles en este sentido.
Es posible crear e incluso mantener sistemas Unix sin sistemas de administración de paquetes, aunque esto solo es frecuente en ambientes embebdiso, e incluso si se emplea un sistema operativo que proporciona herramientas de administración de paquetes, no es necesario usarlas.
Pero deberías.
Sin la administración de paquetes, no se tiene registro de qué proceso, paquete o sistema depende de cierta versión dada de un fichero de sistema. La eliminación de software se vuelve prácticamente imposible, porque no puede asegurarse que la eliminación de un programa o fichero no rompa otro componente. Del mismo modo, actualizar debido a un "proceso sucio": no solo debería resolver los problemas de dependencia manualmente, sino que los ficheros antiguos permanecerían en el sistema, sin poder eliminarlos para siempre.
La mayoría de las veces, cuando la gente habla de los sistemas de gestión de paquetes y del "uso de paquetes", se refiere a los paquetes proporcionados por los desarrolladores del sistema operativo o de la distribución. Los mantenedores de estos paquetes realizan una gran cantidad de trabajo de integración y prueba que hace que el software instalado desde estos paquetes resulte más confiable y simple de usar en el contexto de un sistema genérico.
Los paquetes proporcionados por los mantenedores de distribución y los proveedores suelen estar retrasados con respecto a la última versión de software disponible por algún período de tiempo. Los proyectos de distribución tienen sus propios ciclos de lanzamiento estables y deben intentar mantener selecciones de paquetes estables durante este tiempo. Además, las pruebas, la integración y el empaquetado consumen una cierta cantidad de tiempo.
La cantidad de retraso varía según la distribución y depende de las políticas y objetivos del distribuidor. Si necesita paquetes más actualizados, puede crearlos usted mismo o intentar encontrar software en un repositorio de "backports" como Debian backports, Fedora/Red Hat's "EPEL" o "Extra Packages for Enterprise Linux".
Sin embargo, todos los sistemas de administración de paquetes hacen posible, si no fácil, crear y administrar sus propios paquetes personalizados utilizando las herramientas de administración de paquetes del sistema. Hacer esto. En particular, si necesita instalar el mismo software en varios sistemas, con algún tipo de seguimiento de dependencia o si espera realizar un seguimiento o actualizar el software en cualquier momento. Lo cual debe dar cuenta de todo uso no experimental.
Las comunidades de desarrolladores de los lenguajes de programación Perl, Python, Ruby, R y TeX también proporcionan interfaces similares a paquetes para descargar e instalar software en forma de CPAN, PyPI (es decir, "The Cheese Shop"), RubyGems, CRAN y CTAN respectivamente. Por lo general, estos repositorios no tienen control de calidad adicional o trabajo de integración y los desarrolladores "upstream" son responsables de cargar los paquetes.
Si bien las herramientas de administración de paquetes específicas del idioma agregan facilidad de administración, en la mayoría de los casos, todavía tiene sentido usar las herramientas de administración de paquetes del sistema operativo para instalar este tipo de software. Hay excepciones, como el sistema Virtualenv de Python, o Quicklisp, que proporcionan sandboxing por proyecto e instalación de paquetes sin nivel de sistema. [4] Úselo bajo su propio riesgo.
[4] El principal problema de esta clase de paquetes es que normalmente funcionan mejor cuando instala paquetes en el entorno de su sistema (que requiere privilegios de root e instala software en lugares que no puede rastrear fácilmente). Debido a que la eliminación de paquetes es difícil, el El resultado son entornos que son difíciles de rastrear y un mayor riesgo de paquetes obsoletos y agujeros de seguridad en su capa de aplicación.
Las características definitorias del Unix contemporáneo se centran en el predominio de Linux y Unix en las aplicaciones web y la "computación en la nube", y en el interés y la atención (relacionados) con los lenguajes y entornos de programación que han surgido de la comunidad de usuarios de Unix: Python, Perl, Ruby y, en menor medida, Java. [5] Este ecosistema existe, en parte, debido a la aparición de la "pila" Unix de software libre que incluye GNU y Linux, así como proyectos de software relacionados como Apache httpd que impulsaron la adopción temprana.
Aunque los sistemas propietarios de Unix como AIX, HP-UX y, en diversos grados, Solaris permanecen, son muy específicos y la mayoría de los administradores los encontrarán solo esporádicamente. Desde la perspectiva de la mayoría de los usuarios, todos los sistemas Unix son generalmente similares. Si bien las operaciones de bajo nivel de los sistemas Unix son importantes e interesantes, la mayor parte de la "administración" o incluso el desarrollo de un sistema similar a Unix tiene menos que ver con las funciones de nivel inferior y más con estar familiarizado con el ecosistema.
[5] Si bien el diseño original de Java iba a ser multiplataforma (y lo es), en realidad es bastante seguro decir que la mayoría del código Java se ejecuta en sistemas Unix y Linux. Si bien existen aplicaciones para Java fuera del ecosistema de Unix, su éxito se debe en gran medida a lo bien que se ejecuta Java en Linux y Unix.
Los sistemas tipo Unix son poderosos. Extremadamente poderoso. Su flexibilidad puede ser tentadora, pero no salte ante cada nueva tentación o herramienta que aprenda. En muchos casos, las soluciones más rudimentarias, construidas con herramientas familiares, son preferibles a usar un nuevo paquete o ampliar la funcionalidad de una herramienta para una solución más allá del ámbito de lo que es razonable, solo porque es posible.
Además, si bien la simplicidad y el minimalismo forman el núcleo de la "filosofía Unix", al comenzar, puede sentir que siempre debe evitar las soluciones complejas y preferir siempre las soluciones simples. Cuestiona esto: hay problemas complejos en la administración de sistemas ya veces las únicas soluciones son complejas. Si bien los principios y la historia de Unix pueden ayudar a inspirar soluciones a los problemas de los sistemas Unix, el dogmatismo rara vez conduce a soluciones ideales.
Los mejores administradores pueden, eventualmente, determinar la diferencia entre los problemas que requieren soluciones complejas y los que no, pero este instinto puede tardar años en desarrollarse adecuadamente. Mientras tanto: cuestione los requisitos, investigue a fondo todas las soluciones propuestas, pruebe sus propias ideas y esté abierto a aprender de sus colegas y de la literatura.
Dado que la mayoría de los sistemas similares a Unix son generalmente similares, puede sentirse tentado a asegurarse de que sus paquetes, scripts y sistemas de compilación admitan múltiples distribuciones o sistemas. Incluso entre las distribuciones de sistemas operativos basados en Linux, existe una gran diversidad. Si bien, a menudo no existe una barrera técnica fuerte para esta compatibilidad en muchas plataformas y versiones diferentes, a menos que deba tener esta interoperabilidad, evite esta empresa.
Los requisitos adicionales de compatibilidad no solo complican el desarrollo, sino que las soluciones resultantes son más difíciles de mantener y, en la mayoría de los casos, los entornos de producción reales son en gran medida consistentes. Esto no quiere decir que deba evitar la interoperabilidad, y existen prácticas básicas que puede utilizar para garantizar la interoperabilidad. pero limitar la diversidad de su entorno es una buena manera de reducir prácticamente la carga de trabajo.
En general, usar herramientas estándar (es decir, bash o pure sh sobre zsh) que sabe que estarán disponibles es un buen primer paso. Además, estar familiarizado en general con diferentes tipos de sistemas y sus singularidades ayuda a desarrollar soluciones y software que no caen en trampas no interoperables.