En informática , la actualización dinámica de software ( DSU , por sus siglas en inglés) es un campo de investigación que se centra en la actualización de programas mientras se ejecutan. Actualmente, la DSU no se utiliza ampliamente en la industria. Sin embargo, los investigadores han desarrollado una gran variedad de sistemas y técnicas para su implementación. Estos sistemas suelen probarse en programas reales.
Los sistemas operativos y lenguajes de programación actuales no suelen diseñarse teniendo en cuenta la actualización dinámica de software (DSU, por sus siglas en inglés). Por ello, las implementaciones de DSU suelen utilizar herramientas existentes o compiladores especializados . Estos compiladores conservan la semántica del programa original, pero instrumentan el código fuente o el código objeto para generar un programa que se pueda actualizar dinámicamente. Los investigadores comparan las variantes de programas compatibles con DSU con el programa original para evaluar la seguridad y el rendimiento.
Introducción
Cualquier programa en ejecución puede considerarse una tupla., dóndees el estado actual del programa yes el código del programa actual. Los sistemas de actualización dinámica de software transforman un programa en ejecución.a una nueva versiónPara ello, el estado debe transformarse en la representación.espera. Esto requiere una función de transformación de estado . Por lo tanto, DSU transforma un programa.aUna actualización se considera válida si y solo si el programa en ejecuciónse puede reducir a una tupla de puntosque es alcanzable desde el punto de partida de la nueva versión del programa,. [ 1 ]
La ubicación en un programa donde ocurre una actualización dinámica se denomina punto de actualización . Las implementaciones de DSU existentes varían considerablemente en su tratamiento de los puntos de actualización. En algunos sistemas, como UpStare y PoLUS , una actualización puede ocurrir en cualquier momento durante la ejecución. El compilador de Ginseng intentará inferir ubicaciones adecuadas para los puntos de actualización, pero también puede utilizar puntos de actualización especificados por el programador. Kitsune y Ekiden requieren que los desarrolladores especifiquen y nombren manualmente todos los puntos de actualización.
Los sistemas de actualización difieren en los tipos de cambios de programa que admiten. Por ejemplo, Ksplice solo admite cambios de código en funciones y no admite cambios en la representación del estado. Esto se debe a que Ksplice se centra principalmente en cambios de seguridad, en lugar de actualizaciones generales. En cambio, Ekiden puede actualizar un programa a cualquier otro programa ejecutable, incluso uno escrito en un lenguaje de programación diferente. Los diseñadores de sistemas pueden obtener valiosas garantías de rendimiento o seguridad limitando el alcance de las actualizaciones. Por ejemplo, cualquier comprobación de seguridad de actualización limita el alcance de las actualizaciones a aquellas que superan dicha comprobación. El mecanismo utilizado para transformar el código y el estado influye en los tipos de actualizaciones que admite un sistema.
Los sistemas DSU, como herramientas, también pueden evaluarse según su facilidad de uso y claridad para los desarrolladores. Muchos sistemas DSU, como Ginseng , requieren que los programas superen diversos análisis estáticos. Si bien estos análisis demuestran propiedades de los programas valiosas para DSU, son, por naturaleza, sofisticados y difíciles de comprender. Los sistemas DSU que no utilizan análisis estático podrían requerir el uso de un compilador especializado. Algunos sistemas DSU no requieren ni análisis estático ni compiladores especializados.
Los programas que se actualizan mediante un sistema DSU se denominan programas objetivo . Las publicaciones académicas sobre sistemas DSU suelen incluir varios programas objetivo como estudios de caso. vsftpd , OpenSSH , PostgreSQL , Tor , Apache , GNU Zebra , memcached y Redis son ejemplos de programas objetivo para la actualización dinámica en diversos sistemas. Dado que pocos programas se diseñan teniendo en cuenta la actualización dinámica, adaptar los programas existentes es una valiosa manera de evaluar un sistema DSU para su uso práctico.
Campos relacionados
El ámbito de problemas que aborda la actualización dinámica puede considerarse como la intersección de varios otros. Algunos ejemplos son los puntos de control , la vinculación dinámica y la persistencia . Por ejemplo, una base de datos que debe ser compatible con versiones anteriores de su formato de archivo en disco debe realizar el mismo tipo de transformación de estado que se espera de un sistema de actualización dinámica. Del mismo modo, un programa con arquitectura de complementos debe poder cargar y ejecutar código nuevo en tiempo de ejecución.
Técnicas similares también se emplean a veces con el propósito de eliminar dinámicamente el código muerto para eliminar el código condicionalmente muerto o inaccesible durante la carga o la ejecución, y recombinar el código restante para minimizar su huella de memoria o mejorar la velocidad. [ 2 ] [ 3 ]
Historia
El precursor más antiguo de la actualización dinámica de software son los sistemas redundantes . En un entorno redundante, existen sistemas de reserva listos para tomar el control de los cálculos activos en caso de fallo del sistema principal. Estos sistemas constan de una máquina principal y una de reserva en caliente . La de reserva en caliente se actualiza periódicamente con un punto de control del sistema principal. En caso de fallo, la de reserva en caliente toma el control y la máquina principal se convierte en la nueva de reserva en caliente. Este patrón se puede generalizar a las actualizaciones. En caso de actualización, la de reserva en caliente se activa, el sistema principal se actualiza y, a continuación, el sistema actualizado retoma el control.
El primer sistema de actualización dinámica de software verdadero es DYMOS ( Dynamic Modification System ). [ 4 ] Presentado en 1983 en la tesis doctoral de Insup Lee, DYMOS era un sistema totalmente integrado que tenía acceso a una interfaz de usuario interactiva, un compilador y un entorno de ejecución para una variante de Modula , y el código fuente. Esto permitía a DYMOS verificar los tipos de las actualizaciones con respecto al programa existente.
Implementación
Los sistemas DSU deben cargar el código nuevo en un programa en ejecución y transformar el estado existente a un formato que el nuevo código pueda comprender. Dado que muchos casos de uso de DSU son críticos en cuanto al tiempo (por ejemplo, implementar una corrección de seguridad en un sistema vulnerable en producción), los sistemas DSU deben garantizar una disponibilidad de actualizaciones adecuada . Algunos sistemas DSU también intentan asegurar que las actualizaciones sean seguras antes de aplicarlas.
No existe una solución canónica única para ninguno de estos problemas. Por lo general, un sistema DSU que funciona bien en un área problemática lo hace a costa de perjudicar otras. Por ejemplo, las pruebas empíricas de actualizaciones dinámicas indican que aumentar el número de puntos de actualización resulta en un mayor número de actualizaciones inseguras. [ 5 ]
Transformación de código
La mayoría de los sistemas DSU utilizan subrutinas como unidad de código para las actualizaciones; sin embargo, los sistemas DSU más recientes implementan actualizaciones de programa completo. [ 6 ] [ 7 ]
Si el programa de destino está implementado en un lenguaje de máquina virtual , esta puede usar la infraestructura existente para cargar código nuevo, ya que las máquinas virtuales modernas admiten la carga en tiempo de ejecución para otros casos de uso además de DSU (principalmente depuración ). La JVM HotSpot admite la carga de código en tiempo de ejecución, y los sistemas DSU que utilizan Java (lenguaje de programación) pueden aprovechar esta función.
En lenguajes nativos como C o C++ , los sistemas DSU pueden usar compiladores especializados que insertan indirección en el programa. Al actualizar, esta indirección se actualiza para apuntar a la versión más reciente. Si un sistema DSU no usa un compilador para insertar estas indirecciones estáticamente, las inserta en tiempo de ejecución mediante reescritura binaria . La reescritura binaria es el proceso de escribir código de bajo nivel en la imagen de memoria de un programa nativo en ejecución para redirigir funciones. Si bien esto no requiere un análisis estático del programa, depende en gran medida de la plataforma.
Ekiden y Kitsune cargan nuevo código de programa iniciando un programa completamente nuevo, ya sea mediante fork-exec o carga dinámica . El estado del programa existente se transfiere entonces al nuevo espacio de programa. [ 6 ] [ 7 ]
Transformación del estado
Durante una actualización, el estado del programa debe transformarse de la representación original a la de la nueva versión. Esto se conoce como transformación de estado . Una función que transforma un objeto de estado o un grupo de objetos se denomina función transformadora o transformador de estado .
Los sistemas DSU pueden intentar sintetizar las funciones de los transformadores o requerir que el desarrollador las proporcione manualmente. Algunos sistemas combinan ambos enfoques, infiriendo algunos elementos de los transformadores y requiriendo la intervención del desarrollador en otros.
Estas funciones de transformación pueden aplicarse al estado del programa de forma diferida, accediendo a cada parte del estado de la versión anterior, o de forma inmediata, transformando todo el estado en el momento de la actualización. La transformación diferida garantiza que la actualización se complete en tiempo constante, pero también genera una sobrecarga de estado estable en el acceso a los objetos. La transformación inmediata genera un mayor coste en el momento de la actualización, ya que requiere que el sistema se detenga mientras se ejecutan todos los transformadores. Sin embargo, la transformación inmediata permite a los compiladores optimizar completamente el acceso al estado, evitando la sobrecarga de estado estable asociada a la transformación diferida.
Actualizar seguridad
La mayoría de los sistemas DSU intentan demostrar ciertas propiedades de seguridad para las actualizaciones. La variante más común de comprobación de seguridad es la seguridad de tipos, donde una actualización se considera segura si no da como resultado que ningún código nuevo opere sobre una representación de estado anterior, o viceversa.
La seguridad de tipos se suele comprobar demostrando una de dos propiedades: seguridad de actividad o seguridad sin dependencias . Un programa se considera seguro en cuanto a actividad si no existe ninguna función actualizada en la pila de llamadas en el momento de la actualización. Esto demuestra la seguridad, ya que el control nunca puede volver a código antiguo que acceda a nuevas representaciones de los datos.
La ausencia de cons es otra forma de demostrar la seguridad de tipos, donde una sección de código se considera segura si no accede al estado de un tipo dado de una manera que requiera conocimiento de la representación del tipo. Se puede decir que este código no accede al estado de forma concreta , aunque puede acceder al estado de forma abstracta . Es posible demostrar o refutar la ausencia de cons para todos los tipos en cualquier sección de código, y el sistema DSU Ginseng utiliza esto para demostrar la seguridad de tipos. [ 8 ] [ 9 ] Si se demuestra que una función es libre de cons , se puede actualizar incluso si está activa en la pila, ya que no causará un error de tipo al acceder al estado utilizando la representación antigua.
El análisis empírico de la seguridad de la actividad y la ausencia de restricciones realizado por Hayden et al. muestra que ambas técnicas permiten la mayoría de las actualizaciones correctas y rechazan la mayoría de las erróneas. Sin embargo, la selección manual de los puntos de actualización no produce errores y permite una disponibilidad frecuente de actualizaciones. [ 5 ]
Sistemas existentes
DYMOS
DYMOS destaca por ser el primer sistema DSU propuesto. DYMOS consiste en un entorno totalmente integrado para programas escritos en una variante de Modula , lo que le otorga acceso a un intérprete de comandos, código fuente, compilador y entorno de ejecución, similar a un REPL . En DYMOS, las actualizaciones se inician mediante la ejecución de un comando por parte del usuario en el entorno interactivo. Este comando incluye directivas que especifican cuándo puede ocurrir una actualización, denominadas condiciones de actualización . La información disponible para DYMOS le permite garantizar la seguridad de tipos de las actualizaciones con respecto al programa objetivo en ejecución. [ 4 ]
Ksplice, kpatch y kGraft
Ksplice es un sistema DSU que se dirige únicamente al kernel de Linux , lo que lo convierte en uno de los sistemas DSU especializados que admiten un kernel de sistema operativo como programa objetivo. Ksplice utiliza diferencias a nivel de código fuente para determinar los cambios entre las versiones actuales y actualizadas del kernel de Linux, y luego utiliza la reescritura binaria para insertar los cambios en el kernel en ejecución. [ 10 ] Ksplice fue mantenido por una empresa comercial fundada por sus autores originales, Ksplice Inc., que fue adquirida por Oracle Corporation en julio de 2011. [ 11 ] Ksplice se utiliza comercialmente y exclusivamente en la distribución Oracle Linux . [ 12 ]
SUSE desarrolló kGraft como una alternativa de código abierto para la aplicación de parches en vivo al kernel, y Red Hat hizo lo mismo con kpatch . Ambos permiten aplicar cambios a nivel de función a un kernel de Linux en ejecución, basándose en los mecanismos de aplicación de parches en vivo establecidos por ftrace . La principal diferencia entre kGraft y kpatch radica en cómo garantizan la consistencia en tiempo de ejecución de las secciones de código actualizadas mientras se aplican los parches en caliente . kGraft y kpatch se presentaron para su inclusión en la rama principal del kernel de Linux en abril de 2014 y mayo de 2014, respectivamente, [ 13 ] [ 14 ] y los fundamentos minimalistas para la aplicación de parches en vivo se integraron en la rama principal del kernel de Linux en la versión 4.0, publicada el 12 de abril de 2015. [ 15 ]
Desde abril de 2015, se está trabajando en la adaptación de kpatch y kGraft al núcleo común de parcheo en vivo proporcionado por el kernel principal de Linux. Sin embargo, la implementación de los mecanismos de consistencia a nivel de función, necesarios para transiciones seguras entre las versiones originales y parcheadas de las funciones, se ha retrasado debido a que las pilas de llamadas proporcionadas por el kernel de Linux pueden ser poco fiables en situaciones que involucran código ensamblador sin marcos de pila adecuados ; como resultado, el trabajo de adaptación sigue en curso a fecha de septiembre de 2015. En un intento por mejorar la fiabilidad de las pilas de llamadas del kernel, también se ha desarrollado una utilidad especializada de espacio de usuario stacktool para la comprobación de integridad, cuyo propósito es verificar los archivos objeto de tiempo de compilación del kernel y garantizar que la pila de llamadas se mantenga siempre; además, abre la posibilidad de lograr pilas de llamadas más fiables como parte de los mensajes de error del kernel . [ 16 ] [ 17 ]
Ginseng
Ginseng es un sistema DSU de propósito general. Es el único sistema DSU que utiliza la técnica de seguridad sin restricciones , lo que le permite actualizar funciones que están activas en la pila siempre que no realicen accesos concretos a los tipos actualizados.
Ginseng se implementa como un compilador de código fuente a código fuente escrito utilizando el marco de trabajo del lenguaje intermedio C en OCaml . Este compilador inserta indirección en todas las llamadas a funciones y accesos a tipos, lo que permite a Ginseng transformar el estado de forma diferida a costa de imponer una sobrecarga de tiempo constante durante toda la ejecución del programa. [ 9 ] El compilador de Ginseng demuestra las propiedades de ausencia de cons del programa inicial completo y de los parches dinámicos.
Las versiones posteriores de Ginseng también admiten la noción de seguridad transaccional. Esto permite a los desarrolladores anotar una secuencia de llamadas a funciones como una unidad lógica, evitando que las actualizaciones violen la semántica del programa de maneras que no sean detectables ni por la seguridad de actividad ni por la seguridad de ausencia de cons . Por ejemplo, en dos versiones de OpenSSH examinadas por los autores de Ginseng, se movió código importante de verificación de usuario entre dos funciones llamadas en secuencia. Si se ejecutaba la primera versión de la primera función, se producía una actualización y se ejecutaba la nueva versión de la segunda función, entonces la verificación nunca se realizaría. Marcar esta sección como una transacción garantiza que una actualización no impedirá que se realice la verificación. [ 18 ]
Mirada hacia arriba
UpStare es un sistema DSU que utiliza un mecanismo de actualización único: la reconstrucción de la pila . Para actualizar un programa con UpStare, el desarrollador especifica una correspondencia entre cualquier marco de pila posible. UpStare puede utilizar esta correspondencia para actualizar el programa inmediatamente en cualquier punto, con cualquier número de subprocesos y con cualquier función activa en la pila. [ 19 ]
POLUS
PoLUS es un sistema DSU de reescritura binaria para C. Es capaz de actualizar programas no modificados en cualquier punto de su ejecución. Para actualizar funciones, reescribe el preludio de una función objetivo para redirigir a una nueva función, encadenando estas redirecciones a través de múltiples versiones. Esto evita la sobrecarga de estado constante en funciones que no se han actualizado. [ 20 ]
Katana
Katana es un sistema de investigación que proporciona actualizaciones dinámicas limitadas (similares a Ksplice y sus derivados) para binarios ELF en modo usuario . El modelo de parcheo de Katana opera a nivel de objetos ELF y, por lo tanto, puede ser independiente del lenguaje siempre que el objetivo de compilación sea ELF.
Kitsune y Ekiden
Ekiden y Kitsune son dos variantes de un único sistema DSU que implementa el estilo de transferencia de estado de DSU para programas escritos en C. En lugar de actualizar funciones dentro de un solo programa, Ekiden y Kitsune realizan actualizaciones en programas completos, transfiriendo el estado necesario entre las dos ejecuciones. Mientras que Ekiden logra esto iniciando un nuevo programa mediante el patrón UNIX fork-exec , serializando el estado del programa de destino y transfiriéndolo, Kitsune utiliza el enlace dinámico para realizar la transferencia de estado "in situ". Kitsune deriva del código fuente de Ekiden y puede considerarse una versión posterior de este.
Ekiden y Kitsune también destacan por estar implementados principalmente como bibliotecas de nivel de aplicación, en lugar de entornos de ejecución o compiladores especializados. Por lo tanto, para usar Ekiden o Kitsune, el desarrollador de la aplicación debe marcar manualmente el estado que se transferirá y seleccionar manualmente los puntos del programa donde se puede realizar una actualización. Para facilitar este proceso, Kitsune incluye un compilador especializado que implementa un lenguaje específico de dominio para escribir transformadores de estado. [ 6 ] [ 7 ]
Erlang
Erlang admite la actualización dinámica de software, aunque comúnmente se la conoce como " carga de código en caliente ". Erlang no exige garantías de seguridad en las actualizaciones, pero la cultura de Erlang sugiere que los desarrolladores escriban código con un estilo defensivo que gestione adecuadamente los errores de tipo generados durante la actualización.
Pymoult
Pymoult es una plataforma de prototipado para actualizaciones dinámicas escrita en Python. Reúne diversas técnicas de otros sistemas, permitiendo su combinación y configuración. El objetivo de esta plataforma es que los desarrolladores puedan elegir las técnicas de actualización que consideren más adecuadas a sus necesidades. Por ejemplo, se puede combinar la actualización diferida del estado, como en Ginseng, con la modificación completa del código de la aplicación, como en Kitsune o Ekiden. [ 21 ] [ 22 ]
Microsoft Visual C++
Microsoft está utilizando tecnología de parcheo interna para Microsoft Visual C++ que permite parchear funciones individuales de C++ manteniendo la corrección funcional de los parches. Actualmente, se sabe que la aplicación compatible es SQL Server en Azure SQL Database. [ 23 ]
Véase también
Referencias
- ↑ Gupta, Deepak; Jalote, Pankaj; Barua, Gautam (1996). "Un marco formal para el cambio de versión de software en línea" (PDF) . IEEE Transactions on Software Engineering . 22 (2): 120– 131. doi : 10.1109/32.485222 . Archivado del original (PDF) el 7 de abril de 2014.
- ↑ Paul, Matthias R.; Frinke, Axel C. (13 de octubre de 1997) [publicado por primera vez en 1991], FreeKEYB - Controlador mejorado de teclado y consola para DOS (Manual del usuario) ( ed. v6.5) (NB. El sucesor de K3PLUS, FreeKEYB, es un controlador totalmente reconfigurable con muchas características especiales de carga dinámica. Implementa una forma única de técnicas de eliminación y reubicación de código muerto dinámicas y granulares a nivel de byte en el tiempo de carga , así como código automodificable y reconfigurabilidad en tiempo de ejecución para minimizar su huella de memoria cerca de la forma canónica dependiendo del hardware, el sistema operativo, otro entorno y la configuración del controlador, así como el conjunto de características y la configuración regional seleccionados (alrededor de sesenta interruptores de configuración con cientos de opciones para un número casi ilimitado de combinaciones posibles). El proceso de compilación utiliza un ensamblador de macros , así como un marco de herramientas de pre y postprocesamiento automático que analizan los binarios temporales para generar metadatos de dependencia y transformación de código que se incrustan en el archivo ejecutable resultante junto con el código binario y un cargador autodesechable, relajado y reubicable para (re)combinar, (sobre)cargar, modificar, actualizar o descargar dinámicamente la imagen de tiempo de ejecución (código y datos) del controlador según se solicite. La complejidad está oculta en un único archivo autocontenido para que para un usuario El manejo es el mismo que para un controlador (semi)monolítico normal/ programa de terminación y permanencia residente .
- ↑ Paul, Matthias R.; Frinke, Axel C. (16 de enero de 2006), FreeKEYB - Controlador avanzado internacional de teclado y consola DOS (Manual de usuario) ( edición preliminar v7)
- 1 2 Lee, Insup (1983). Dymos: un sistema de modificación dinámica (tesis doctoral en Ciencias de la Computación). Universidad de Wisconsin-Madison. Archivado del original el 16 de septiembre de 2003.
- 1 2 Hayden, Chris; Smith, Edward K.; Hardisty, Eric; Hicks, Michael; Foster, Jeffery (2011). "Evaluación de la seguridad de las actualizaciones dinámicas de software mediante pruebas sistemáticas" (PDF) . IEEE Transactions on Software Engineering (99). IEEE.
- 1 2 3 Hayden, Chris; Smith, Edward K.; Hicks, Michael; Foster, Jeffery (2011). "Transferencia de estado para actualizaciones de tiempo de ejecución claras y eficientes" (PDF) . Data Engineering Workshops (ICDEW), 2011 IEEE 27th International Conference on . IEEE: 179–184 .
- 1 2 3 Hayden, Chris; Smith, Edward K.; Denchev, Michail; Hicks, Michael; Foster, Jeffery (2011). "Kitsune: Actualización de software dinámica, eficiente y de propósito general para C" (PDF) .
{{cite journal}}: Para citar una revista se requiere|journal=( ayuda ) - ↑ Stoyle, Gareth; Hicks, Michael; Bierman, Gavin; Sewall, Peter; Neamtiu, Iulian (2005). "Mutatis mutandis: Actualización de software dinámica segura y predecible" (PDF) . Actas de la Conferencia ACM sobre Principios de Lenguajes de Programación .
- 1 2 Neamtiu, Iulian; Hicks, Michael; Stoyle, Gareth; Oriol, Manuel (2006). "Actualización dinámica práctica de software para C" (PDF) . ACM SIGPLAN Notices . 41 (6): 72– 83. CiteSeerX 10.1.1.625.4663 . doi : 10.1145/1133255.1133991 .
- ↑ Arnold, Jeff; Kaashoek, M. Frans (2009). "Ksplice: actualizaciones automáticas del kernel sin reinicio". Actas de la 4.ª Conferencia Europea ACM sobre Sistemas Informáticos (PDF) . págs. 187–198 . doi : 10.1145/1519065.1519085 . hdl : 1721.1/51698 . ISBN 9781605584829. S2CID 7720018 .
- ↑ "Oracle y Ksplice" . Consultado el 21 de julio de 2011 .
- ↑ "Primeros pasos con Oracle Ksplice" . oracle.com . Consultado el 2 de agosto de 2014 .
- ↑ Poimboeuf, Josh (2014-05-01). "kpatch: parcheo dinámico del kernel" . LWN.net . Recuperado el 23 de julio de 2014 .
- ↑ Corbet, Jonathan (30 de abril de 2014). "El envío inicial de kGraft" . LWN.net . Recuperado el 7 de noviembre de 2014 .
- ↑ "Núcleo de Linux 4.0, Sección 1.2. Aplicación de parches en vivo" . kernelnewbies.org . 26 de abril de 2015. Consultado el 14 de mayo de 2015 .
- ↑ Corbet, Jonathan (30-09-2015). "Validación de pila en tiempo de compilación" . LWN.net . Consultado el 02-10-2015 .
- ↑ Poimboeuf, Josh (24-09-2015). "Documentación del kernel de Linux: Documentation/stack-validation.txt (del parche v13)" . LWN.net . Recuperado el 02-10-2015 .
- ↑ Neamtiu, Iulian; Hicks, Michael; Foster, Jeffrey; Pratikakis, Polyvios (2008). "Efectos contextuales para la actualización dinámica de software con coherencia de versiones y la programación concurrente segura". Actas de la Conferencia {ACM} sobre Principios de Lenguajes de Programación (POPL) : 37–58 .
- ↑ Makris, Kristis; Bazzi, Rida A. (2009). "Actualizaciones de software dinámicas multihilo inmediatas mediante reconstrucción de pila" (PDF) . Actas de la Conferencia Técnica Anual USENIX de 2009 .
- ↑ Chen, Haibo; Yu, Jie; Chen, Rong; Zang, Binyu; Yew, Pen-Chung (2007). "POLUS: Un potente sistema de actualización en vivo" (PDF) . 29.ª Conferencia Internacional sobre Ingeniería de Software : 271–281 . Archivado del original (PDF) el 26 de abril de 2012. Consultado el 18 de diciembre de 2011 .
- ↑ Sébastien Martinez; Fabien Dagnat; Jérémy Buisson (2013). "Prototipado de técnicas DSU usando Python" . Actas del 5.º Taller sobre Temas Candentes en Actualizaciones de Software (HotSWUp'13) .
- ↑ Martínez, Sébastien (06-03-2013). "Pymoult" . Bitbucket . Recuperado el 27-11-2014 .
- ↑ "Actualización en caliente del motor de SQL Server en Azure SQL Database" . TECHCOMMUNITY.MICROSOFT.COM . 11 de septiembre de 2019. Consultado el 15 de septiembre de 2019 .
Enlaces externos
- Página principal de Ksplice
- Código fuente de Ksplice
- Página del proyecto Ginseng y código fuente / Documento UpStare / Documento PoLUS
- Página principal de Erlang
- Página principal de Katana
- Entrada de blog sobre la aplicación de parches a Visual C++
- Administración del sistema