Torvalds anunció ayer la disponibilidad de la nueva versión del kernel, la 3.4, después de dos meses del lanzamiento de la última versión. Esta nueva versión tiene varias mejoras, sobretodo enfocadas a las nuevas NVIDIAs y a los procesadores de 64 bits. Aquí van las nuevas características:

• Módulo de seguridad Yama, el cual mejora la interacción entre procesos, memoria y procesador.
• Varias mejoras en nuestro querido Btrfs: herramientas de recuperación y reparación de datos, bloques de metadatos mayores de 4KB, mejoras en el control de errores, mejoras de rendimiento…
• Soporta anticipado para las nuevas NVIDIA GeForce.
• Soporte para los gráficos Intel Medfield, RadeonHD 7 y Trinity.
• Mejoras de rendimiento en procesadores de 64 bits con la nueva ABI X32.
• Ruta de arranque mapeable.
• Soporte para un dispositivo externo de lectura como fuente de origen para un volumen LVM.
• Rendimiento: mejor visualización del ensamblado, profiles de ramas, filtrado de los usuarios y subprocesos e informe de GTK2 en la GUI.
• Correcciones para la gestión de la memoria y de redes.
• Mejoras de virtualización KVM y Xen.
• Mejoras en EXT4, FUSE, NFS, XFS, HFSplus, CIFS y GFS2 (sistemas de archivos).
• Nuevos drivers agregados.
• Nuevos dispositivos compatibles.
• Y mucho más…

Ver lista completa | Kernelnewbies
Fuentes | Softpedia, The H-Open y LKML.org (anuncio de Torvalds)

He leído por varios sitios y por algún que otro blog el problema que están sufriendo algunos usuarios de portátiles con Ubuntu 12.04, en el cual el brillo de la pantalla del portátil disminuye continuamente sin control. Parece estar pasando en portátiles Dell, pero si tienes este problema, puedes probar esta solución, no vas a romper nada…

Lo primero es averiguar cual es el brillo máximo soportado por tu pantalla, para ello ejecuta:

$ sudo cat /sys/class/backlight/acpi_video0/max_brightness

Te devolverá un valor, el cual es el máximo (por ejemplo, 4). Una vez realizado esto, editaremos el archivo /etc/rc.local, en el cual podemos establecer tareas para que se ejecuten a la vez que el sistema operativo:

$ sudo gedit /etc/rc.local

Al final del archivo, encontramos:

exit 0

Pues justo antes de esa línea, pegamos lo siguiente (sustituyendo el 4 por el valor máximo de brillo soportado por tu pantalla):

echo 4 > /sys/class/backlight/acpi_video0/brightness

Quedando así las dos últimas líneas de archivo /etc/rc.local (sustituyendo también el 4):

echo 4 > /sys/class/backlight/acpi_video0/brightness
exit 0

Ahora guardamos, cerramos el archivo y reiniciamos el portátil. Esta línea que hemos añadido fuerza el brillo que tendremos en todo momento. Si al intentar averiguar cual es el brillo máximo soportado por tu pantalla te ha devuelto que ese archivo no existe, prueba aumentando progresivamente (empieza por el 1, después el 2, y así hasta que no aumente más o hasta que lo desees).

Esta solución no permite modificar el brillo como habitualmente lo hacías, pero te permite manejar tu portátil cómodamente mientras se encuentra una solución más adecuada.

Fuente | Ubuntizando

El sabio no se sienta para lamentarse, sino que se pone alegremente a su tarea de reparar el daño hecho.

William Shakespeare

Entro un día al blog, vaya, error en la línea no se cual del archivo no se cuantos, edito el error, resubo el archivo, recargo la página, vuelve a aparecer el error, pero en otra línea de otro archivo, lo corrijo de nuevo, y asi sucesivamente, con absolutamente todos los archivos PHP de la web, que os puedo asegurar que son bastantes.

El caso es que el problema sucedía en todas las webs del servidor (mi web personal y otros proyectos), por lo que supuse que no sería un error de WordPress, ya que el resto funcionaban bajo otro gestor de contenidos o mediante código propio, el cual en mi ordenador funcionaba perfectamente. Llegué a la conclusión tras varias reinstalaciones de WordPress y de los otros gestores de contenidos de que el problema provenía del servidor. Estudié el problema y di con la clave, pero al arreglarlo, se restauraba el problema.

Decidí entonces contactar con el servicio técnico de nuestro servidor (Dreamhost), que siempre ha sido bastante eficaz, excepto en este caso: me dijeron que habían hackeado el servidor y que eliminase y reinstalase absolutamente todo, y resetease contraseñas (SSH, FTP, WordPress..), una vez realizado, todo funcionaba, pero al día siguiente, el problema volvió a aparecer.

¿La solución alternativa? Resetear TODO el servidor, incluidas las bases de datos, contraseñas, archivos de configuración, Apache, PHP, etc. Con la pérdida absoluta de datos.. tan solo pude salvar algunos datos de otros proyectos que nada tienen que ver con Ubunteate.

Y aquí estamos, empezando de nuevo, que remedio. Sentimos todas las molestias que haya podido causar este altercado que, en parte, es culpa nuestra.