César Yáñez Fernández La Persistencia Ortogonal es un concepto relativamente nuevo en el campo de Sistemas Operativos; este concepto opera en que no se necesita "guardar" ni "cargar" objetos o archivos, el Sistema Operativo es el encargado de guardar el contenido de la memoria física en disco cuando éste se apaga. La primera implementación real se dió en EROS (Extremely Reliable Operating System). En EROS, se guardan los cambios a un log inmediatamente, y toma un 'snapshot' periódicamente. ¿Qué pasa si se pierde la energía electrica o el Sistema Operativo cuelga? El Sistema Operativo también debe de ser capaz de recuperarse y recuperar los datos más frescos antes del percance. Es el término que se aplica a una propiedad del sistema en donde los objetos persisten hasta que ya no son necesitados, aún antes, aunque falle el sistema, y aún después, donde podrían gastar (eventualmente) los recursos limitados del sistema. Pongamos de ejemplo un uso básico de la computadora. Un usuario que usa por primera vez un equipo de cómputo, se la pasa toda la noche capturando datos en su base de datos sobre libros de una biblioteca. Después, apaga la computadora y se va a dormir. Al siguiente día, el usuario enciende la computadora de nuevo, y los datos desaparecieron. El usuario no sabía que tenía explicitamente que "guardar" los datos antes de salir de la aplicación. La persistencia de datos significa que los datos deberían seguir alli; la persistencia ortogonal de datos significa que el usuario no tiene que preocuparse por ello. Pongamos otro ejemplo, digamos que tenemos una calculadora científica que nunca perdía los datos durante una operación normal; pero podría perder todos los programas que hicimos cuando la batería se acababa o si hacemos operaciones muy raras (como programar en ensamblador con ésta), sin respaldar nuestros datos en una cinta o disco. Entonces la memoria de la calculadora es persistente ortogonalmente, pero no de manera satisfactoria. Persistencia ortogonal es un concepto natural, porque es exactamente lo que la gente necesita cuando manipula objetos, lo que cuenta para las personas serias no es divertirse con la computadora, sino el trabajo que acumulan durante el tiempo de uso. Las personas no entrenadas, esperan que los datos sean persistentes ortogonalmente; y el progreso en sistemas de cómputo no ha tenido cuidado en esto. Supongamos que tenemos dos tipos de papeles, aquel que persiste y el otro que se autodestruirá después de que ya no esté encima del escritorio; prefieres usar el papel que persiste para datos que tienen valor, aunque no vayas a escribir algo que vaya a durar, prefieres el papel que persiste, porque lo que escribiste en éste tal vez tenga más valor que el que tenía inicialmente, y no quieres gaster tus recursos intelectuales haciendolo de nuevo, inclusive al hacer una copia: tu tiempo es más valioso que el papel. Lo mismo puede pasar eventualmente con computadoras: solo haciendo aplicaciones optimizadas los usuarios usarán más memoria persistente ortogonalmente. No hay un sistema operativo tradicional basando en el estándar de la industria que soporte persistencia ortogonal. Para algunos puede ser ridiculo, propenso a errores, completamente inseguro, y los usuarios, quienes constantemente se preocupan sobre guardar sus datos, son sujetos a fallas horribles por algun error o apagado accidental obstaculizando la acción de guardar los datos. Una razón por la cual la persistencia ortogonal no ha sido aceptada es porque se ha dicho que es muy dificil o cara de implementar. Pero no es así, como algunos sistemas como Eumel o EROS lo mostraron. La tradición de tener sistemas no persistentes se ha ido desarrollando al paso del tiempo, y requiere de usuarios/programadores que explicitamente guarden y restauren el estado de los objetos que usan de un medio persistente de bajo nivel. Actualmente, como la discrepancia de la velocidad entre los componentes de memoria y unidades de cómputo crece cada día más, se vuelve cada día más ovbio que la DRAM es realmente otro cache entre el CPU y el almacenaje persistente, así como la SRAM y los registros de CPU antes de ésta. No hay razón por la que los usuarios normales tengan que explicitamente llenen y vacíen este cache, cuando todas esas cosas pueden hacerse de manera automatica por la misma computadora. El hecho de que el vaciado sea hecho por el software del sistema o el hardware del sistema es irrelevante para el usuario, que considera que a éstos dos componentes como un todo cuando los usa. Si ponemos una computadora por usuario, dejando que continuamente la encienda y apague, con la misma sesión corriendo, la persistencia puede ser alcanzada teoricamente, pero al primer error o falla de energía, todo se habrá perdido, donde la política tradicional es que se permitan errores sin que nada suceda tan grave, y proponer que se reinicie, que es una técnica usual. El problema con persistencia ortogonal es entonces la respuesta y el rendimiento. Para tener persistencia ortogonal, podría hacerse más fácil si solo las computadoras o discos fueran equipados con una memoria de respaldo, o TRAM (Transactional RAM) como se ha propuesto. Las fallas de energía pueden ser manejadas sin sacrificar la velocidad que es requerida para que los cambios sean guardados en disco antes de continuar. Lamentablemente el hardware no está disponible. Te queda la opción de usar un UPS que es caro, para todo tu sistema, (más caro que usar TRAM), ó permitir que la latencia del sistema vacíe buffers al disco. El usuario entonces puede controlar la latencia, de manera dependiente al problema, dependiento de las capacidades disponibles del sistema. También se podrían insertar puntos de sincronización explícitos, para esperar los datos que sean guardados en los medios persistentes (como fsync en UNIX). Si el hardware no está equipado con TRAM, existe la necesidad de mantenerse informado sobre los datos siendo guardados en disco antes de publicar que la transacción ha terminado. Éste no es una desventaja particular de persistencia ortogonal comparado con otras formas de persistencia explicita, ya que todos los sistemas operativos modernos tienen el mismo problema de garantizar el guardado de datos en bases de datos persistentes de manera explicita, y requiere de un llamado a un procedimiento especial para asegurarse que los buffers han sido vaciados al disco durante la sincronización o el apagado. Un problema de desentendimiento acerca de la Persistencia Ortogonal es que si nos deshacemos de los sistemas de archivos, también podemos deshacernos de las jerarquías de árbol de directorios. Éstas jerarquías de árbol son una manera simple y natural de organizar nuestra información, pero no es la única forma. Aún con persistencia ortogonal, habrían muchos "diccionarios" donde se reunen objetos de una manera legible para el humano con nombres que se pueden teclear. Éstos objetos no serían archivos, sino hilos de bytes cotiguos, serán solo un dato estructurado que el sistema de cómputo puede manipular. También, no todo tiene que estar en jerarquías de árbol o construído junto con una herramienta diferente de lo usual. Otro desentendimiento en persistencia ortogonal es de que se remuevan los botones de "guardar" de los editores de documentos. Eso no es completamente correcto. Con persistencia ortogonal, normalmente no habría necesidad de guardar datos, pero existe la necesidad de manejar datos. Aún con persistena ortogonal, los usuarios querrán algúna manera explicita de guardar datos para distinguir entre los documentos bien elaborados por versiones, como en CVS. Inclusive el editor de documentos más simple debe de tener la manera de distinguir entre "estable", "desarrollo" y "respaldo" del mismo documento. La persistencia ortogonal no cambiará acerca del manejo de proyectos con sus complejidades intrinsecas; lo que hará es proveer consistencia a travez de implementaciones más simples y mejor hechas, con un sistema completo de manejo de errores y control. Mejora de productividad en la programación con semánticas más simples Mecanismos de protección de chequeo de tipos de datos operan en todo el entorno. Integridad referencial está automáticamente soportado. Los procedimientos y módulos pueden ser representados por valores de primera clase que residen en un medio persistente. Los mecanismos de persistencia verifican la corrección de tipo en dicho enlace. Unununium es un Sistema Operativo, con el fin de crear un mejor entorno computacional, maximizando la interconexión entre componentes. Unununium está en primeras fases de desarrollo. Aunque se ha completado un sistema básico, Unununium no está listo para su uso como Sistema Operativo de propósito general. Unununium fue creado con el consentimiento de que no hay un Sistema Operativo disponible actualmente que tenga la elegancia en el diseño requerida para tomar al máximo el potencial en el cómputo. Hoy existen muchos sistemas operativos, y muchos de éstos son software libre. Sin embargo, son algo similares en forma. En todos los sistemas operativos populares, el entorno general es el mismo: un sistema de archivos global y simple y un número de aplicaciones para manipular archivos. Las aplicaciones son entidades distintas, con una interconexión definida por el usuario, o que se comunican por tuberías. Si el sistema tiene una Interfaz Gráfica de Usuario, emula un escritorio. Al principio parece que no hay nada malo con este modelo, porque ha sido aceptado por definición en el cómputo. Esto puede cambiarse. Para hacer el cómputo más natural y eficiente, se tiene pensado implementar los siguientes conceptos: ¿Por qué no puedo usar mi editor de texto favorito para editar los campos de entrada de texto de un sitio web? La noción de que una aplicación es una "caja", y que esta aplicación puede usar "bibliotecas" pero no otras "aplicaciones" es absurdo. Un editor de texto no debe ser una aplicación apartada de otras, sino un componente que puede ser usado para editar cualquier texto. El entorno no debería ser un grupo de aplicaciones plano, sino una jerarquía de componentes que pueden ser interconectados en cualquier configuración. Los datos pueden tener acceso de manera universal. Los sistemas actuales tienen un sistema de archivos, y éste no puede hacer todos los datos disponibles para su uso. Por ejemplo, ¿por qué los archivos de internet por HTTP son vistos en diferente forma que archivos de un disco local? Todos los datos pueden estar disponibles por una interfaz común para que se puedan manipular de manera independiente a la fuente de los datos. Hoy hay sólo dos métodos populares de interacción con el usuario: la línea de comandos y la intefaz gráfica. Las interfaces de línea de comando son frecuentemente favorables para el usuario experimentado, sólo porque las interfaces gráficas son pobremente diseñadas. También son limitadas en sus capacidades de entrada y salida. Las interfaces gráficas son una variación pequeña del sistema desarrollado en Xerox tiempo atras, que fue diseñado para emular objetos tangibles como papel y escritorios. Como cualquiera sabe, existe un paradigma; ¿por qué las computadoras lo emulan? A través de un poco de experiencia, se ha aprendido que entre más elegante el software es, es más elegante el lenguaje detrás de éste. Se ha escogido Python como el lenguaje para el desarrollo. Usando un lenguaje de alto nivel, detalles como el manejo de memoria son delegados al lenguaje, permitiendo a los desarrolladores enfocarse en crear un programa elegante. En la implementación del lenguaje actual, la ejecución de Python no es tan rápida como en la mayoría de los lenguajes tradicionalmente usados en el desarrollo de sistemas operativos. Sin embargo, este es un problema de implementación, no del mismo lenguaje. La decisión de usar Python fue hecha después de considerar la creación de un nuevo lenguaje. Desarrollar una implementación de Python más rápida también es un objetivo de Unununium. Unununium no sólo está en la búsqueda de un Python más rápido. Futuras implementaciones del intérprete estándar son planeadas para que incluyan una optimización más agresiva. Psyco es un programa prometedor que compila el bytecode de Python en código nativo. Pyrex convierte Python a C. Python define un API que puede ser usada como interfaz para lenguajes de menor nivel como C o ensamblador. Unununium era en un principio escrito por completo en ensamblador, y se decidió por adoptar Python por la experiencia adquirida en el desarrollo. El buen diseño de Python y la necesidad de una implementación más rápida de un componente, es lo que permite que usemos la API del lenguaje. Unununium es software libre. Esto significa que puede ser libremente distribuíble y modificado, más no libre de costo. Creemos que la colaboración abierta y el intercambio de ideas es el camino para un mejor futuro. Todo mundo tiene diferentes opiniones en cómo el software debería ser libre. Existe una plétora de licencias como la GPL, o algunas modificaciones de la licencia BSD. Unununium es agnóstico. Si el software es libre, ¿por qué debería tener licencia? Algunos ven la idea como tonta. Unununium Database Filesystem (UDBFS) Extended Filesystem (Ext3) Manejador de memoria con volcado de estado Manejador de procesos con monitoreo de estado asincrono