Saber cuando se desconectó la energía en el notebook

Hola nuevamente! Les traigo un nuevo script.
Resulta que yo uso notebook, y lo tengo con la batería puesta. Resulta que ultimamente se ha cortado la luz varias veces, y yo no me he dado cuenta ya que como uso la batería puesta, no hay nada que me avise cuando se encuentra "off-line" u "on-line". Para ello he diseñado un pequeño script, que manda un mensaje en caso que se haya desconectado el cable (o se cortó la luz).
Como dependencias sólo necesita 'acpitool' y 'zenity'.
Copien el script a un archivo con extensión sh, ojalá sin espacios, luego denle permisos de ejecución (chmod 777 archivo.sh), y pónganlo que se ejecute en el inicio; para ello yo usé el menú de "aplicaciones al inicio" de gnome, pero pueden ponerlo en el .bashrc de su home, o en inittab, o de cualquier forma que se ejecute al inicio.
Dejo el sccript, y en pastebin también:
Obviamente el script es para linux.

#!/bin/bash
bandera=true
while [ true ]; do
 
 salida=$(acpitool |grep off-line)
 if [  -n "$salida" ]  &&   $bandera  ;
 then
  bandera=false
  #echo "está off line"
  zenity --info --text="La batería está off line"
  
 elif [ ! -n "$salida" ];
 then
 
  bandera=true
  #echo "está on line"
 fi
 sleep 30s
done

Breve y sencilla explicación del bug de OpenSSL "HeartBleed"

El bug recientemente parchado de openssl, llamado "heartbleed", ha estado muy en boca de todo el mundo recientemente. Bueno, al menos del mundo informático, e incluso ha ido más allá.
OpenSSL es la implementación de protoclos de seguridad SSL/TLS más famosa y usada. Los mencionados protocolos son los que se usan para encriptar información en internet. Y se usan en, por ejemplo, https (el candadito en la url), ftps, ssh, etc.
La idea de usar esta encriptación, es por ejemplo en https (lo más usado por los usuarios entre los mencionados anteriormente), que nadie pueda leer la información entre tú y la página web. De esta manera puedes pasar una contraseña a la página web y estar seguro que nadie podrá leerla y saber cuál es haciendo un análisis de tráfico web (o sea por ejemplo alguien espiando tu internet, como puede incluso ser gente de los proveedores de internet o la policía que analice tu tráfico).
Para compartir tráfico encriptado entre usuario y servidor, hay que iniciar una sesión TLS entre ambos, tras lo cual se comparten de manera segura la clave que usarán para cifrar y descifrar los mensajes. Ahora, el problema en SSLv2 y anteriores, es que si pasaba cierto tiempo desde que se inició la sesión tls y no habían paquetes entre las partes, la sesión TLS se cerraba, teniendo que inicarla nuevamente, creando las claves y todo eso, lo cual era tiempo y gasto computacional. Eso se mejoró con la versión 3 de SSL, que implementa un sistema llamado "heartbeat" (latido del corazón, como para avisar que aún sigues vivo), con el cual podías mantener abierta una sesión TLS más tiempo.
Para ello, el cliente manda un mensaje de tipo "TLS1_HB_REQUEST", con dos campos: El payload (el mensaje), y el tamaño del payload. Luego el servidor le manda otro mensaje de vuelta llamado "TLS1_HB_RESPONSE" que copia el payload y lo manda de vuelta, para 'configurar' la respuesta. Los campos del mensaje response del servidor incluyen el mismo payload y el mismo largo.
El truco viene en que OpenSSL no comprueba que el payload tenga el mismo largo que el que se mandó en el campo "largo". Esto hace que OpenSSL "crea ciégamente" que el payload tiene ese largo (sin comprobarlo), y envía de vuelta lo que debiera ser el payload. Pero el truco consiste en mandar un payload de 1 byte, y un campo "largo" diciendo que nuestro payload mide 64KB, es decir varios miles de veces más. Lo que hará OpenSSL será empezar copiando desde el payload, hasta 64KB más adelante de lo que haya en la memoria ram (el payload reside en la ram, entonces copia desde el comienzo del payload hasta 64kilo bytes más adelante, haya lo que haya), copiando así trozos de memoria ram pertenecientes a OpenSSL que no eran parte del payload, sino de trozos de código y datos del mismo OpenSSL.
El problema es que OpenSSL contiene contraseñas, las claves de cifrado, y muchas otras cosas sensibles; de manera que mandando continuamente mensajes truqueados, obtendremos cada vez 64kb de memoria de trozos aleatorios del programa, pudiendo obtener potencialmente gigas y gigas de trozos, que incluyen contraseñas, claves, etc.
Dejo un mono explicativo:

Este fallo se reportó varios años antes, pero no ha sido sino hasta el reciente 7 de abril 2014 que se ha publicado el parche para que no siga ocurriendo. Hasta que las páginas no actualicen su versión de OpenSSL seguirá ocurriendo el problema, y los servidores serán potenciales víctimas de ataques. Eso sí, esto sólo roba las contraseñas que están en la memoria RAM, es decir sólo los ingresos recientes, o activos, así que la recomendación sería no ingresar hasta que sea reportado el que actualizaron el software y repararon el problema.

Fuentes:
Blog de Chema alonso, un experto en seguridad http://www.elladodelmal.com/2014/04/heartbleed-y-el-caos-de-seguridad-en.html
Video explicativo en inglés del fallo, con monitos http://parkerati.com/my-quick-video-post/