Ir al contenido principal

Actualización de Kernel sin reinicio

Si exite algo molesto en el sistema operativo de Bill es que al instalar actualizaciones necesitas reiniciar la máquina y ni qué decir cuando quieres apagar la máquina y este sistema operativo te lleva la contraria y te pone un mensaje de "No apague ni desconecte Windows ...."

También es verdad que algunas actualizaciones de linux que incluyen modificaciones al kernel requieren reinicio de la máquina lo que igualmente no deja de ser molesto; claro que se tiene la pequeña diferencia que puedes evitar eso, seguir trabajo y esperar al apagado de la máquina y con eso tendrías.

Afortunadamente parece que los que usamos Linux ya no tenemos que pasar por esto del reinicio con las actualizaciones del kernel y esto gracias en un principio a SUSE y RED HAT quienes unieron esfuerzos en desarrollar la tecnología para poder parchar el kernel en caliente.  Esta tecnología ya es utilizada con alguna anterioridad por ksplice adoptado y comprado por el amigo Oracle quien lo convirtió (como es su filosofía) en propietario; ksplice es usado en el sistema operativo Oracle Linux Server.

El esfuerzo de SUSE y RED HAT está por ahora implementado para las arquitecturas x86, PowerPC, s390.

Esta maravilla será puesta en marcha con la versión kernel Linux 3.20.

Fuentes:
http://www.theregister.co.uk/2015/02/11/linux_to_get_live_patching_in_320/
http://www.phoronix.com/scan.php?page=search&q=Linux+3.20

Comentarios

Entradas populares de este blog

Lenguajes de programación más conocidos en la historia de la computación

Los primeros lenguajes de programación eran difíciles de construir ya que éstos debían ser "desarrollados" a un nivel que la máquina entendiera directamente, es decir, la programación de computadoras de esta época dependía mucho de la máquina para la que se estaba trabajando y detectar un error o fallo en la programación no solo era complejo sino que demandaba mucho tiempo y esfuerzo. En 1946 Grace Murray Hopper, científica en sistemas y oficial de la marina estadounidense creo el FLOW-MATIC, considerado el primer lenguaje de programación útil para resolver problemas de usuarios comerciales.  Su desarrollo fue enfocado a la UNIVAC 1.  Este lenguaje de programación fue visto como de "alto nivel", fácil de usar por los científicos de la época.  FLOW-MATIC requería de un traductor (compilador) para ser interpretado por la máquina.   Con este lenguaje de programación se establece el concepto de programación basado en palabras del lenguaje natural y se da inicio al d...

Las 10 Aplicaciones Más Descargadas en Google Play Store y Apple App Store en 2024

  En el mundo digital actual, las aplicaciones móviles juegan un papel crucial en nuestras vidas diarias. Con millones de aplicaciones disponibles, solo unas pocas logran destacar y acumular millones de descargas. En este artículo, exploramos las aplicaciones más descargadas en Google Play Store y Apple App Store hasta la primera mitad de 2024. 1. Instagram Instagram sigue siendo una de las aplicaciones más populares a nivel mundial. Con 696 millones de descargas en Google Play Store, esta plataforma de redes sociales permite a los usuarios compartir fotos y videos, interactuar con amigos y seguir a celebridades. 2. TikTok TikTok, la aplicación de videos cortos, ha revolucionado la forma en que consumimos contenido. Con 654 millones de descargas en Google Play Store, se mantiene como una de las favoritas entre los usuarios jóvenes y creativos. 3. Facebook Facebook, la red social pionera, continúa siendo relevante con 553 millones de descargas . La plataforma ofrece una variedad d...

SQL Error [53200]: ERROR: out of shared memory

  ¡Hola, amigos del blog! Hoy vamos a hablar sobre un tema que puede causar más de un dolor de cabeza a los que trabajamos con PostgreSQL: el temido error SQL Error [53200]: ERROR: out of shared memory. Pero no te preocupes, porque aquí te explico por qué sucede y cómo solucionarlo de manera sencilla y divertida. Imagina que estás en una fiesta y hay demasiada gente queriendo usar el mismo baño. Al final, alguien se quedará esperando fuera, ¿verdad? Algo similar pasa con PostgreSQL cuando se queda sin memoria compartida para gestionar los bloqueos de los objetos. Este error suele aparecer cuando hay demasiados objetos bloqueados en una sola transacción o cuando el parámetro max_locks_per_transaction está configurado demasiado bajo. ¿Por qué ocurre este error? Las principales causas son: Muchas transacciones concurrentes : Cuando hay demasiadas transacciones al mismo tiempo, todas compitiendo por recursos. Operaciones complejas : Transacciones que bloquean muchos objetos a la vez, ...