Fabrice Bellard es un programador independiente francés quien consiguió hacer funcionar el kernel de Linux dentro de un navegador web gracias al uso de JavaScript.

Para lograrlo, lo que hizo Bellard fue crear una especie de emulador compatible tanto con Firefox 4 como con Chrome 11, que es capaz de ejecutar el Kernel de Linux en su versión 2.6.20.

Bellard señaló que creó esto “porque es divertido. Los nuevos motores de JavaScript son lo suficientemente rápidos para hacer cosas complicadas”.

Según el programador francés, su emulador corre dos veces más lento con el motor JavaScript V8 de Chrome, comparado con el motor Jaeger Monkey de Firefox. Su desarrollo ya fue probado por Brendan Eich, programador de Mozilla y creador de JavaScript, y Bellard cree que se puede usar como un sistema de prueba (un benchmark) para los motores de JavaScript.

Visto en | FayerWayer

En noviembre del año pasado un parche de 233 líneas del desarrollador Mike Galbrait demostró que podría  acelerar notablemente la experiencia del escritorio en Linux, reduciendo la latencia hasta en 60 veces. En esta versión de Linux, el parche cambia la forma en que el planificador asigna tiempo de CPU a cada proceso para que el sistema pueda agrupar todos los procesos con el mismo identificador de sesión.

Por otro lado, los cambios en el sistema virtual de archivos (VFS) no solo hacen que las cargas de trabajo multi-hilo sean escalables, sino que también hace que algunas cargas con procesos únicos sean mucho más rápidos. En esencia, el dcache VFS (directorio de caché) y los mecanismo de búsqueda de ruta se han revisado a fin de ser más escalables.

La memoria permitida para procesar aumentará de tamaño de 4KB a 2 MB gracias a las “Transparent Huge Pages”, que reducen el número de asignaciones de memoria y aprovechan el mayor rendimiento del hardware. Según Tim Burke, vicepresidente de Ingeniería Linux de Red Hat, el impacto de la inclusión de las THP en Linux 2.6.38 es que ofrecen un mejor desempeño en las cargas de trabajo que requiere una gran cantidad de memoria, tales como servidores de JVM y base de datos.

Adiciones importantes a Linux 2.6.38:

• Compresión LZO y snapshots de sólo lectura en Btrfs: Btrfs añade soporte para el algoritmo de compresión LZO, como alternativa a zlib. También se añade soporte para marcar un snapshot como sólo lectura y la característica “force mounting” (forzar montaje) que hará que el código base sea más tolerante a fallos.
• Transparent huge pages - Esta alternativa al API basado en el sistema de archivos aprovecha de las ventajas de rendimiento de los procesadores modernos con mayor cache. El código de Transparent huge pages ahora se utiliza por defecto cuando sea aplicable, pero puede ser configurado para ser utilizado siempre o sólo cuando se solicite. El aumento será especialmente notable con el incremento en cargas de trabajo intensivas de datos, como bases de datos o sesiones KVM, que con frecuencia accesan a direcciones virtuales.
• Protocolo de malla B.A.T.M.A.N. – Better Approach To Mobile Ad-hoc Networking es un protocolo de ruteo proactivo para Redes Mesh Ad-hoc Inalámbricas [PDF], incluyendo las redes ad-hoc móviles (en inglés MANETs). El protocolo mantiene proactivamente información sobre la existencia de todos los nodos en la malla, que son accesibles a través de enlaces de comunicación de uno o múltiples saltos. La estrategia de B.A.T.M.A.N. es determinar para cada destino en la malla un vecino de un salto, el cual puede ser utilizado como mejor gateway para comunicarse con el nodo de destino. En estas redes, cada nodo de enrutamiento participa en los datos de reenvío para otros nodos de forma dinámica y se dice que es útil para situaciones de emergencia como desastres naturales.
• Soporte para AMD Fusion – Esta versión incluye el soporte para los nuevos APUs Fusión basados en una o más instancias del núcleo “Bobcat”.
• Límites de memoria sucia – Esta función controla los límites de Dirty Pages (Buffer de páginas que contienen modificaciones que no se han escrito en el disco) de cada controlador de memoria cgroups.

Linux 2.6.38  también ofrece una variedad habitual variedad de ajustes, adiciones y correcciones de errores, incluyendo mejoras en el núcleo, el planificador (scheduler), gestión de memoria, manejo de bloques, sistemas de archivos, creación de redes, criptografía, virtualización, seguridad y trazado.

Visto en | FayerWayer

Esta versión cuenta con:

• Mejoras de escalabilidad y rendimiento en los sistemas de archivos Ext4 y XFS
• Posibilidad de compilar el kernel sin el BKL (Big Kernel Lock), bloqueo más molesto del núcleo que no tenía impacto en el rendimiento
• Dispositivo de bloques basado en el sistema de archivos distribuido Ceph.
• Soporte de limitación I/O, esto hace posible que con cgroup se limite la lectura/escritura de un grupo de procesos.

Además agrega varias mejoras en Btrfs, pruebas estáticas más eficientes, soporte a los módulos de prueba perf y listados de variables locales y globales accesibles, hibernación de imágenes utilizando la compresión LZO, PPP a través de IPv4 y varias microoptimizaciones de redes, sin mencionar los nuevos controladores para dispositivos.

Visto en | FayerWayer

El kernel de Linux cumplió la mayoría de edad hace poco tiempo y ya es uno de los sistemas operativos con mayor proyección, especialmente en el terreno de servidores. Éstas son algunas de las cosas que le han ocurrido en sus 18 años de vida.

1. Linux Torvalds desarrolló el kernel de Linux mientras estudiaba en la Universidad de Helsinki en 1991.

2. El año pasado, el 75% del código creado para Linux fue desarrollado por programadores que trabajan en empresas privadas.

3. En diciembre de 2009 IBM anunció un nuevo sistema Mainframe diseñado para trabajar con Linux.

4. El Gigante Azul eligió Linux para el que espera ser el supercomputador más potente del mundo, Sequoia, que verá la luz en 2011.

5. Los sistemas basados en Linux se encuentran en 446 de los 500 supercomputadores más potentes del mundo.

6. El 95% de los servidores que se utilizan en los estudios de Hollywood para las películas de animación están gobernados por Linux.

7. El primer largometraje de éxito producido en servidores Linux fue Titanic en 1997.

8. James Cameron también eligió servidores con Linux para producir la película Avatar.

9. Los servidores de Google corren bajo Linux.

10. Google ha contribuido en el 1,1% del código del actual kernel de Linux

11. Linux se está extendiendo rápidamente en el mercado de smartphones y otros dispositivos electrónicos dentro del mercado de consumo.

12. Sistemas operativos como Palm WebOS, Google Android, Nokia Maemo o Samsung Bada están desarrollados en base al kernel de Linux.

13. TiVo utiliza una versión personalizada de Linux para sus dispositivos.

14. En 2009, las diferentes variantes de Linux consiguieron una cuota de mercado en servidores del 33,8% frente al 7,3% de los sistemas de Microsoft.

15. Mientras tanto, en el área de ordenadores (sobremesa y portátil) Linux tan sólo cuenta con un 1,02% de cuota de mercado.

16. Torvalds creó Linux para el proyecto GNU bajo licencia GPL.

17. Torvalds no hubiera creado nunca su propio sistema operativo si la GNU ya tuviera un kernel en ese momento.

18. El proyecto GNU carecía por entonces de controladores o kernel.

19. Bajo la licencia GPL, cualquier desarrollador o empresa que distribuya el kernel de Linux debe proporcionar también el código fuente dentro del propio paquete.

20. En palabras de Torvalds: “Desarrollar Linux bajo licencia GPL ha sido definitivamente lo mejor que he hecho en mi vida”.

21. Torvalds no consiguió en primera instancia registrar el nombre de Linux.

22. En 1994, un tal William Della Croce Jr. registró la marca Linux en los Estados Unidos y comenzó a pedir royalties a las distintas distribuciones Linux.

23. Torvalds y sus abogados ganaron esta batalla en 1997 para recuperar el registro de la marca Linux.

24. Actualmente existen más de 300 distribuciones Linux activas.

25. Linux ganó mucha popularidad más allá de los tradicionales programadores gracias a la distribución Slackware, que era más fácil de utilizar para los no iniciados en la programación.

26. La distribución Debian fue una de las primeras que realmente estaba orientada como Comunidad de desarrolladores en Linux.

27. El código base de Debian se mantiene en otras distribuciones populares como Ubuntu, Knoppix y Xandros.

28. El código fuente de la versión Debian 4.0 contiene 283 millones de líneas de código.

29. Se estima que en un entorno de desarrollo comercial el código fuente de Linux costaría en torno a los 7.300 millones de dólares.

30. La primera distribución comercial de Linux fue Yggdrasil, lanzada en 1992 en formato Live-CD (no es necesaria la instalación del sistema, sino que se ejecuta directamente desde un CD).

31. Red Hat fue una de las primeras distribuciones comerciales de Linux en calar hondo en la empresa.

32. Ubuntu fue la primera “distro” en ser ofrecida por un fabricante OEM (Dell) preinstalada en los ordenadores.

33. En el apartado de Netbooks, la distribución elegida fue Xandros a través de los populares Asus EeePC.

34. El nombre del servidor web basado en Linux, Apache, no estaba basada en la tribu india del popular Geronimo, sino que era la contracción de “a patchy server”, en referencia a un sistema creado en base a muchas piezas de código aportadas por la comunidad Linux.

35. En 2002, The Register publicó que Microsoft había gastado 421 millones de dólares para combatir a Linux.

36. En 2003, SCO (Santa Cruz Operation), uno de los máximos valedores de UNIX, acusó a IBM de haber transferido código desde UNIX a Linux y solicitó que lo eliminara de estas distribuciones.

37. El estado Indio de Kerala desarrolló una Ley que obligaba a todas sus escuelas y universidades a ejecutar Linux en sus ordenadores.

38. Algo parecido ocurrió en Brasil, donde se primaba el uso de Linux en el PC por encima de otros sistemas operativos comerciales.

39. En 2009, este país sudamericano desplegó la mayor infraestructura de thin-clients con Linux hasta la fecha, con más de 350.000 equipos.

40. La analista IDC contempla que en 2012 las ventas de soporte para Linux superen los 1.000 millones de dólares.

Visto en | http://ubuntu.foroactivo.com.es/40-cosas-curiosas-sobre-linux-n501.htm

Hoy temprano me levante con la curiosidad, de compilar un propio kernel para mi micro (AMD Athlon(tm) 64 X2 Dual Core Processor 4200+) para optimizarlo, pero me tope con esta aclaracion, y si no tiene ganas de leer esto (aunque se lo recomiendo) en resumen diria que si compilaramos nuestro propio kernel este no aumentara si eficiencia de manera significativa…, yo por lo pronto no hice nada pero tengo a mano los modulos que debo instalar para mi micro…

$ sudo aptitude install linux-image-k7 linux-restricted-modules-k7

Asi que si alguien lo prueba que me avise que tal le fue…

_____________________________________________________________________________

Hay una especie de “regla no escrita” en el mundo linuxero que dice que toda persona “debe” compilar su propio kernel, como parte de su proceso de aprendizaje o de incremento de su “estatus geek”. Nada más lejos de la realidad: El kernel, al igual que el resto del software del sistema, no deberia necesitar compilarse – como cualquier software diseñado decentemente. Lo que mucha gente no sabe es que Linux 2.6 es lo suficientemente avanzado como para que un kernel precompilado funcione perfectamente sin retoques en la mayoría de sistemas

• Razón 1: Hay un mito sobre el kernel: La gente piensa que optimizando el kernel, el sistema irá más rápido, y que si no lo haces irá lentísimo y estarás desaprovechando tu equipo.

  Vamos a ignorarlo y hacer un análisis serio. Pregunta: ¿Cuanto tiempo de CPU gasta un sistema normal ejecutando codigo en espacio de usuario y cuanto gasta ejecutando código del kernel?. sar (maravilloso programa que no debería faltar en vuestros sistemas) puede decirlo:
  

  20:05:01          CPU     %user     %nice   %system   %iowait     %idle20:05:01          all      6,23      0,00      0,50      0,25     93,03

  
  Como se puede ver en este caso, de todo el tiempo de CPU transcurrido en mi sistema en un uso típico de escritorio (email, firefox, escribir artículos malos) solo un 0.50% del tiempo de CPU ha sido utilizado por el kernel, y un 6.23% por programas de espacio de usuario (un servidor dará diferentes números, de hecho un servidor web dará porcentajes diferentes a un pc haciendo de router). Es decir, 12.46 veces más. De todos los ciclos de CPU durante el que se ejecuta “software real” (todo lo que no es tiempo “idle”) el 92.57% se ejecutan en espacio de usuario, y un 7.42% en el kernel.

  Lo que quiere decir esto es que en un uso normal el sistema se pasa la mayor parte del tiempo ejecutando software en espacio de usuario, y que por lo tanto optimizar el kernel no mejorar el rendimiento del sistema de manera notable, por la simple razón de que la mayor parte del tiempo no es su código el que se está ejecutando. En las distros precompiladas tiene especialmente poco sentido: ¿Para qué optimizar para el procesador de turno el 7.42% del tiempo de ejecución si el software que se ejecuta el 92.57 del tiempo está “optimizado” para i586 o i386?.

  Esto tampoco quiere decir que la optimización no influya en absoluto: Hay ciertas funciones (como las funciones que mueven porciones de memoria de un sitio a otro) que se utilizan mucho y algunas tienen incluso optimizaciones específicas en ensamblador. Lo que quiero decir es que esperar que el optimizar el kernel vaya a acelerar notablemente un sistema típico es lo mismo que esperar que un grano de arena sea distinguible en un desierto.

• Razón 2: Las diferencias entre procesadores puede que no justifican la optimización. Eso tampoco quiere decir que no existan esas diferencias o que no vayan a influir: Simplemente, las diferencias no son tan grandes como para justificar la optimización. Las distribuciones suelen tener un kernel i586 por defecto (excepto ubuntu y debian) y muchas kernels precompilados adicionales disponibles (para k7, para athlon64, para p4) en los repositorios. En serio, no necesitas recompilar el kernel solo porque en el kernel no añadieron una opción al gcc que tu “sabes” que en “teoria” optimiza mucho el ejecutable para tu máquina. Como ejemplo extremo está Ubuntú: Su kernel por defecto está optimizado con instrucciones de i386 (pero optimizadas para un pentium 4, esto es otro tema), y apuesto a que mucha gente ni siquiera se ha dado cuenta. Además hay que tener en cuenta una pecularidad de la plataforma x86: Todos sus procesadores se parecen “enormemente” entre si. De hecho, es la base de su éxito: Si x86 está donde está es en gran parte por no cambiar demasiado y preservar la compatibilidad lo máximo posible. En general, cuando las empresas dedicadas a CPUs preparan una nueva versión de CPU intentan copiar al máximo y dentro de las posibilidades de la nueva arquitectura el comportamiento de los procesadores anteriores, por la simple razón de que los compiladores tardan años en optimizarse para una arquitectura determinada. Eso puede suponer que al salir el producto a la calle el rendimiento sea pobre y que el producto fracase comercialmente. ¿A alguien le suena Itanium?

  Una de las principales diferencias entre los x86 (además de las diferencias fundamentales como netburst vs opteron etc) son las extensiones “multimedia”: MMX, SSE, 3dnow. Estas son especialmente irrelevantes para el kernel: Existe una regla en el kernel que prohibe utilizar código en punto flotante en el kernel excepto en unos pocos lugares controlados (usarlo demasiado obligaría a guardar los contenidos del coprocesador matemático entre cambios de contexto y eso enlentecería mucho el kernel). Se utilizan en algunos puntos, pero se evitan como si tuvieran la peste

  Lo que quiero decir aquí es que esto es como los benchmarks de Intel vs AMD: “En x benchmark AMD gana a intel un 5%”. Si, el AMD es más rápido, pero esa “ventaja” supone que en vez de tardar un minuto el amd lo hace en 59 segundos, que es prácticamente lo mismo. Es muy probable que no notes las optimizaciones que estes haciendo al compilar a mano el kernel. Son demasiado pequeñas. Las principales diferencias vienen casi siempre de mano los algoritmos: No hay optimización de procesador en el mundo que vaya a hacer que el kernel descarte correctamente tal o cual dato en el cache de disco o el orden correcto en el elevator del kernel, por ejemplo, y te aseguro que esa decisión va a influir muchísimo más en el rendimiento de tu máquina que cualquier optimización a nivel de procesador

• Razón 3: Seguridad: Si descargas y compilas tu propio kernel, el día que haya un fallo de seguridad en el kernel tendrás que: 1) Enterarte. Algo que no es fácil, porque los fallos de seguridad del kernel casi nunca se reportan en barrapunto o slashdot o osnews (y si piensas que si, significa que no te has enterado de muchos fallos de seguridad o incluso de que alguien ha hackeado tu servidor gracias a uno de esos bugs y tiene instalado un rootkit en él ahora mismo, y no tengo por qué estar siendo paranoico) 2) reconfigurar 3) recompilar

  Sin embargo, si instalas un kernel precompilado, lo instalarás a partir de los paquetes de tu distro, y los sistemas de actualización de tu distro te lo actualizarán automáticamente en cuanto haya nueva actualización de seguridad. Es una opción bastante más inteligente…

• Razón 4: Tener muchas cosas (opciones) compiladas en el kernel no daña necesariamente el rendimiento: Alguna gente se cree que tener todos los sistemas de archivos en el kernel, o la emulación de coprocesador matemático va a hacer las cosas mas lentas. ¿Por qué? No se trata mas que de un gran IF: Si algo no se usa, no tiene porque afectar al resto. El código de un dispositivo que no se tiene jamás se ejecutará. Y por supuesto la mayoría de kernels precompilados no hacen esas cosas – se modularizan las cosas exageradamente, hasta el punto que algunas distros nisiquiera compilan el sistema de archivos del sistema de archivos root / en el kernel, compilan todos como módulo y cargan el necesario en el initrd
• Razón 5: Tener muchos módulos es útil: La gente suele compilar su kernel porque quiere “compilar solo el soporta para su hardware y quitar el resto”. Esto está relacionado con el punto anterior. La pregunta es: ¿Por qué? Los módulos no utilizan nada más que espacio en el disco al menos que no se carguen. Probablemente tengas un /usr/X11R6/lib/modules/drivers/vmware_drv.o en tu sistema. ¿Recompilas las X solo para desactivar ese driver? ¿Recompilas para desactivar las librerias de accesibilidad de gnome solo porque no las necesitas? Tener 100 o los módulos que sean ahí no hace daño. Tampoco es ninguna guarrada: Es lo correcto. El objetivo del kernel es que tu hardware funcione, y el soportar más hardware del que tienes significa que podrás cambiar de hardware sin recompilar el kernel: Y esto es importante para todos, porque con USB y firewire es imposible determinar en tiempo de compilación que dispositivos vas a acabar conectando a tu equipo. La flexibilidad es una característica del software, y es buena.

  Una vez sufrí un problema relacionado con esto: No tengo un lápiz USB, asi que no tenía compilado el soporte. Pero resulta que un amigo vino con un disco duro externo USB, y como no tenia ganas de hacerle soportar la espera de compilar un kernel, tuve que iniciar en Windows. Windows paraba la transferencia a la mitad y el driver dejaba de funcionar asi que finalmente tuve que hacer esperar a mi amigo. Moraleja: Un sistema moderno tiene USB y firewire y por lo tanto no tiene una configuración de hardware estática

  Udev es quien se encarga de hacer gran parte del trabajo de configurar el hardware del sistema y cargar los modulos de tu hardware y no cargar los que no son. Si yo por ejemplo enchufo mi webcam Creative Go Plus, el kernel notifica a udev de que se ha insertado un dispositivo en el bus usb, udev mira que es mirando identificando el hardware y carga los dos ó 3 módulos de soporte básico de USB, el módulo de la camara, el módulo del chip de la camara, y el módulo de V4l. Automaticamente. Pero si no la enchufo, no las carga, y puedo hacer que udev descargue los módulos cuando desenchufo la cámara – no hay “bloatware” en ningún lado. Las máquinas se inventaron para hacer cosas por nosotros. Utilizalas para ello y utiliza un kernel precompilado y udev. Muchisima gente de la que compila su kernel a mano no activa el soporte de hotplug (necesario para udev), porque piensa “que no lo necesita”. Lo cual nos lleva al siguiente punto

• Razón 6: Configurar el kernel no es fácil y los mantenedores del paquete precompilado saben que necesitas mucho mejor que tú, aunque no lo creas: El número de opciones disponibles en la fase de configuración del kernel se multiplica en cada versión, y a día de hoy es prácticamente imposible saber configurar correctamente todas las opciones. Mi config tiene 1034 opciones diferentes entre las activadas y desactivadas. ¿Sabes configurar correctamente esas 1034 opciones? Puedes pensar que sabes, pero siendo realistas no hay nadie en el mundo que sepa configurar por si mismo un kernel por completo. Yo llevo años compilando decenas y decenas de kernels por afición al desarrollo del kernel, y aun hay muchas opciones que no se que hacen, ni si debería activarlas o no. Ni tan siquiera los hackers del kernel lo saben, ni Linus Torvalds, te lo aseguro (bueno, quizás Alan Cox…) Los que mantienen una arquitectura no se enteran de que cosas están haciendo los del soporte USB, y viceversa. Por si fuera poco, muchas opciones no están documentadas (o están mal documentadas, que es peor), algunas son peligrosas y otras no puedes saber si activarlas o desactivarlas porque simplemente te da lo mismo (como pasa con cualquier proyecto software que tenga este tamaño: nadie puede conocer 200 MB de código C, además en linux se tiene la “manía” de hacer todo extremadamente configurable hasta el punto que dudo mucho que exista un kernel más configurable) Y la configuración por defecto que trae el kernel de kernel.org está muy lejos de tener los valores por defecto ideales. Moraleja: Deja que los mantenedores de tu distribución se ocupen de la compleja tarea de configurar el kernel. Ellos tienen los recursos (varias personas, sistemas de seguimiento de bugs por si se equivocan en algo, etc) para hacerlo, tú no.

¿Y esto para que lo escribo? Para intentar evitar que la gente se pase la vida compilando kernels por “tradición”. Eso no quiere decir que esté prohibido compilarles: Compilar kernels es una actividad divertida y entretenida para un geek, siempre que tenga una razón para ello (por ejemplo, que le da la gana). Lo absurdo es hacer lo que hace la gente: Compilar por que si, sin tan siquiera tener ganas, como si fuera una “obligación” a su estatus de “geek”.

Saludos…

Fuente

Si queréis poder dedicar un minuto a jugar un poco con el exploit para comprobar por uno mismo si afecta a nuestra distribución. Para ello basta descargar el código fuente del exploit (y aquí otra variante), compilarlo y ejecutarlo como usuario normal. A continuacion las acciones:

zarpele@makid:~$ uname -r
2.6.22-3-686

zarpele@makid:~/Desktop$ gcc exploit.c -o exploit
zarpele@makid:~/Desktop$ whoami
zarpele
zarpele@makid:~/Desktop$ ./exploit
———————————–
Linux vmsplice Local Root Exploit
By qaaz
———————————–
[+] mmap: 0×0 .. 0×1000
[+] page: 0×0
[+] page: 0×20
[+] mmap: 0×4000 .. 0×5000
[+] page: 0×4000
[+] page: 0×4020
[+] mmap: 0×1000 .. 0×2000
[+] page: 0×1000
[+] mmap: 0xb7dd2000 .. 0xb7e04000
[+] root
root@makid:~/Desktop#

Casi tan pasmosa como la efectividad del exploit es la sencillez del parche que lo soluciona.
Ya hay nueva versión del kernel (2.6.24.2) con el bug resuelto.
Esto es importante ya que dispones de un ciber con este kernel cualquier usuario podria acceder como root y hacer lo que quiera!!!.

DistroWatch hace un resumen de la rapidez con que las principales distribuciones GNU/Linux respondieron publicando sus correcciones al problema. Todas las 10 primeras distribuciones reaccionaron en menos de 48 horas:

Distribution	Date/Time	Delay	Reference
Debian GNU/Linux	2008-02-11 13:58	+0 hours	DSA 1494-1
Fedora	2008-02-11 22:39	+8 hours	FEDORA-2008-1423
Slackware Linux	2008-02-12 02:00	+12 hours	SSA:2008-042-01
Mandriva Linux	2008-02-12 07:06	+19 hours	MDVSA-2008:043
Frugalware Linux	2008-02-12 11:17	+21 hours	FSA-369
openSUSE	2008-02-12 12:43	+23 hours	SUSE-SA:2008:007
rPath Linux	2008-02-12 16:28	+26 hours	rPSA-2008-0052-1
Red Hat Enterprise Linux	2008-02-12 16:54	+27 hours	RHSA-2008:0129-01
Ubuntu	2008-02-12 17:23	+27 hours	USN-577-1
CentOS	2008-02-13 03:27	+37 hours	CESA-2008:0129

Saludos…

Fuente: DistroWatch, BraiaNet