MoMA, la mamá de los monos...

MoMA o Mono Migration Analyzer, es una herramienta que ayuda a identificar diferentes problemas que se tengan al portar las aplicaciones del Framework .NET al Framework de Mono. Aunque MoMA pueda ayudar a enseñar problemas potenciales, existen muchos factores completos que no pueden ser previstos mediante el uso de una sola herramienta. Pero la utilidad de MoMA es innegable. Si tienes una aplicación hecha en .NET que no pase ninguna prueba de MoMA... entonces ya tienes una idea del trabajo que tendrás que hacer para migrar esa aplicación al Mono Framework.

Recordemos que la verdadera prueba resulta al correr tu aplicación sin problemas en Mono.

Pero para que se acostumbren a codificar bien, y tengan una idea de como usar MoMA, aquí esta una pequeña guia, ¡espero que les sea de utilidad!

nota aclaratoria: las capturas de pantallas ajustadas a menor tamaño no son tan importantes o interesantes como las de tamaño "grande", esto es claro, bajo el criterio del autor. Como siempre, pueden dar click a cualquier imagen para verla en tamaño real.

Guía ejemplo de uso de MoMA:

1.0 Descargando MoMA

Puedes descargar MoMA de http://www.mono-project.com/Moma , luego ve a la seccion de descargas "Download" y allí encontraras el vinculo de descarga.

"Captura de pantalla del sitio web de MoMA con el URL marcado (muy marcado) para descargarlo"

Recuerden que MoMA necesita el framwork .NET 2.0 ó Mono 1.2+, como solo estoy usando GNU\Linux, usare Mono para correr MoMA.

1.1 Ejecutando MoMA

Después de descargar el archivo .Zip de MoMA, extraemos su contenido y podremos ver lo siguiente:

"Captura de pantalla del contenido del archivo .Zip descargado"

Ahi estan los archivos que necesitamos, muchos diran: ah!, son simples ejecutables de windows. Pues noooo, estos archivos "exe" estan compilados en un lenguaje intermedio (como el bytecode de Java) llamado MSIL (MicroSoft Intermedium Languaje). Y las extensiones "exe" y "dll" pues solo son extensiones re utilizadas.
Vamos a usar Mono para correr/interpretar/compilar (como le quieran decir) el archivo "MoMA.exe".
Abrimos una consola (en mi caso usare Konsole) y nos vamos a la carpeta donde se encuentra "MoMA.exe", ahi ejecutamos el comando:

mono MoMA.exe

Aquí hay una captura por si se pierden:

"Captura de la consola, usando mono para ejecutar MoMA.exe"

Y si todo sale bien, pues podremos ver la ventana de MoMA en nuestra pantalla:

"Captura de MoMA en GNU\Linux, usando KDE como Desktop Manager"

1.2 Usando MoMA

Para usar MoMA solo necesitamos ejecutables hechos con el Framework .NET y dar unos cuantos clicks.
Yo usare de ejemplo la librería de un amigo para comprobar si puede ser ejecutado o no con Mono. Ustedes pueden usar cualquier otro compilado (el que ustedes quieran) que corra en el Framework .NET 1.0 y 2.0, y que evidentemente no sea una librería especifica a la plataforma o parte de .NET (como System.dll). Esta es la librería CustomDataSource(CDS) Ver.1.0 de Roberto Linares, que puede ser encontrada aquí.

"Captura de pantalla, descarga de Bin.rar de CDS, foro ingenieria UES-FMOcc"

En el paso 2 (de 4) de MoMA, podemos agregar uno o varios ejecutables hechos con el Framework .NET, asi que despues de descargar los binarios de CDS, y extraerlos en mi escritorio, agregare el archivo "CrypterClassLib.dll" dando click en el boton con signo "+" y luego eligiendo el/los archivo a agregar, asi:

"Captura de pantalla, agregando archivos para analizar con MoMA"

"Captura de pantalla, ¿Listo para analizar?"

Ya con la lista de archivos que seran analizados, pues solo basta dar click en "Next"; para que MoMA analize el ejecutable y podamos ver un resumen de compatibilidad del archivo con mono. Al final obtendremos un resultado como este:

"Captura de Pantalla, ¡Te salvaste Roberto!"

En este paso (3 de 4) podemos ver que en el análisis general, el .dll analizado paso las pruebas con exito.
Asi que en teoria, el archivo "CrypterClassLib.dll" puede ejecutarse sin problemas con el Mono Framwork.
Vaya Roberto... te salvaste del bochorno publico jaja ;)

Pero... ¿Que sucede cuando TODO sale mal?

"Captura de Pantalla, ¡OH NO!"

Bien, si sucede algo tragico como lo muestra la captura anterior, o peor... pues MoMA genera un util reporte (paso 4 de 4) que muestra de manera general, que se puede hacer para combatir esta incompatibilidad.

"Captura reporte de ejemplo"

Con este reporte en mano y teniendo en cuenta ciertos tips de migracion/codificacion seremos capaces de migrar una aplicacion casi (especulativamente) sin problemas de un S.O. a otro.

1.3 Consideraciones finales

No olviden enviar el reporte (sea bueno o malo) de compatibilidad que genera MoMA (MoMA lo envia automáticamente):

"Captura de pantalla, envío de reporte a Mono Project"

Esto ayuda para que los desarrolladores de Mono coloquen especial énfasis en los problemas mas comunes de compatibilidad encontrados, es tan fácil como dar un click al botón "Submit Report".

Una guía mas completa y extensa para corregir problemas de interoperabilidad puede ser hallada aquí.

Hasta Luego!

mono .net microsoft linux gnu software desarrollo moma

MoMA, la mamá de los monos...

MoMA o Mono Migration Analyzer, es una herramienta que ayuda a identificar diferentes problemas que se tengan al portar las aplicaciones del Framework .NET al Framework de Mono. Aunque MoMA pueda ayudar a enseñar problemas potenciales, existen muchos factores completos que no pueden ser previstos mediante el uso de una sola herramienta. Pero la utilidad de MoMA es innegable. Si tienes una aplicación hecha en .NET que no pase ninguna prueba de MoMA... entonces ya tienes una idea del trabajo que tendrás que hacer para migrar esa aplicación al Mono Framework.

Recordemos que la verdadera prueba resulta al correr tu aplicación sin problemas en Mono.

Pero para que se acostumbren a codificar bien, y tengan una idea de como usar MoMA, aquí esta una pequeña guia, ¡espero que les sea de utilidad!

nota aclaratoria: las capturas de pantallas ajustadas a menor tamaño no son tan importantes o interesantes como las de tamaño "grande", esto es claro, bajo el criterio del autor. Como siempre, pueden dar click a cualquier imagen para verla en tamaño real.

Guía ejemplo de uso de MoMA:

1.0 Descargando MoMA

Puedes descargar MoMA de http://www.mono-project.com/Moma , luego ve a la seccion de descargas "Download" y allí encontraras el vinculo de descarga.

"Captura de pantalla del sitio web de MoMA con el URL marcado (muy marcado) para descargarlo"

Recuerden que MoMA necesita el framwork .NET 2.0 ó Mono 1.2+, como solo estoy usando GNU\Linux, usare Mono para correr MoMA.

1.1 Ejecutando MoMA

Después de descargar el archivo .Zip de MoMA, extraemos su contenido y podremos ver lo siguiente:

"Captura de pantalla del contenido del archivo .Zip descargado"

Ahi estan los archivos que necesitamos, muchos diran: ah!, son simples ejecutables de windows. Pues noooo, estos archivos "exe" estan compilados en un lenguaje intermedio (como el bytecode de Java) llamado MSIL (MicroSoft Intermedium Languaje). Y las extensiones "exe" y "dll" pues solo son extensiones re utilizadas.
Vamos a usar Mono para correr/interpretar/compilar (como le quieran decir) el archivo "MoMA.exe".
Abrimos una consola (en mi caso usare Konsole) y nos vamos a la carpeta donde se encuentra "MoMA.exe", ahi ejecutamos el comando:

mono MoMA.exe

Aquí hay una captura por si se pierden:

"Captura de la consola, usando mono para ejecutar MoMA.exe"

Y si todo sale bien, pues podremos ver la ventana de MoMA en nuestra pantalla:

"Captura de MoMA en GNU\Linux, usando KDE como Desktop Manager"

1.2 Usando MoMA

Para usar MoMA solo necesitamos ejecutables hechos con el Framework .NET y dar unos cuantos clicks.
Yo usare de ejemplo la librería de un amigo para comprobar si puede ser ejecutado o no con Mono. Ustedes pueden usar cualquier otro compilado (el que ustedes quieran) que corra en el Framework .NET 1.0 y 2.0, y que evidentemente no sea una librería especifica a la plataforma o parte de .NET (como System.dll). Esta es la librería CustomDataSource(CDS) Ver.1.0 de Roberto Linares, que puede ser encontrada aquí.

"Captura de pantalla, descarga de Bin.rar de CDS, foro ingenieria UES-FMOcc"

En el paso 2 (de 4) de MoMA, podemos agregar uno o varios ejecutables hechos con el Framework .NET, asi que despues de descargar los binarios de CDS, y extraerlos en mi escritorio, agregare el archivo "CrypterClassLib.dll" dando click en el boton con signo "+" y luego eligiendo el/los archivo a agregar, asi:

"Captura de pantalla, agregando archivos para analizar con MoMA"

"Captura de pantalla, ¿Listo para analizar?"

Ya con la lista de archivos que seran analizados, pues solo basta dar click en "Next"; para que MoMA analize el ejecutable y podamos ver un resumen de compatibilidad del archivo con mono. Al final obtendremos un resultado como este:

"Captura de Pantalla, ¡Te salvaste Roberto!"

En este paso (3 de 4) podemos ver que en el análisis general, el .dll analizado paso las pruebas con exito.
Asi que en teoria, el archivo "CrypterClassLib.dll" puede ejecutarse sin problemas con el Mono Framwork.
Vaya Roberto... te salvaste del bochorno publico jaja ;)

Pero... ¿Que sucede cuando TODO sale mal?

"Captura de Pantalla, ¡OH NO!"

Bien, si sucede algo tragico como lo muestra la captura anterior, o peor... pues MoMA genera un util reporte (paso 4 de 4) que muestra de manera general, que se puede hacer para combatir esta incompatibilidad.

"Captura reporte de ejemplo"

Con este reporte en mano y teniendo en cuenta ciertos tips de migracion/codificacion seremos capaces de migrar una aplicacion casi (especulativamente) sin problemas de un S.O. a otro.

1.3 Consideraciones finales

No olviden enviar el reporte (sea bueno o malo) de compatibilidad que genera MoMA (MoMA lo envia automáticamente):

"Captura de pantalla, envío de reporte a Mono Project"

Esto ayuda para que los desarrolladores de Mono coloquen especial énfasis en los problemas mas comunes de compatibilidad encontrados, es tan fácil como dar un click al botón "Submit Report".

Una guía mas completa y extensa para corregir problemas de interoperabilidad puede ser hallada aquí.

Hasta Luego!

mono .net microsoft linux gnu software desarrollo moma

Guía de Construcción de un Kernel Personalizado.

tipo: guía/tutorial.

1.0 Construyendo un Kernel Personalizado, a la manera tradicional (o como un Vikingo Leñador).

Esta parte especifica describe el proceso de creación de un Kernel personalizado (o que se volverá así a medida que veas que es un proceso para nada complicado). Abarca desde la descarga de un Kernel (donde encontrarlo), usar un parche en nuestro Kernel, el software necesario para compilar el Kernel, la Configuración y la creación de un "initram" (no se preocupen, ya llegaremos a eso). Todos los pasos se realizan suponiendo que el lector tiene Debian Etch instalado como sistema operativo y GRUB como bootloader (gestor de arranque) instalado. Al final de esta guía/tutorial, se espera que termines con un Kernel (por lo menos ligeramente) personalizado...

"La belleza del Kernel de Linux, esta en su personalización"

1. 1 Instalando los paquetes requeridos para la compilación del Kernel.

Primero actualizamos la lista de paquetes instalables en el sistema:

apt-get update

Luego instalamos los paquetes

• kernel-package
• libncurses5-dev
• fakeroot
• wget
• bzip2
• build-essential

...con el siguiente comando:

apt-get install kernel-package libncurses5-dev fakeroot wget bzip2 build-essential

1.2 Descargando el código fuente del Kernel

"10 años de Kernel.org"

En el sitio http://kernel.org se publica el codigo del kernel mas reciente, versiones anteriores del mismo y también parches respectivos. Al momento de hacer esta guía, el Kernel esta en su version estable 2.6.22.1 (este es el Kernel que sera usado). Pero antes de descargarlo vamonos al directorio "/usr/src":

cd /usr/src

y ahora:

wget http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.22.1.tar.bz2

O lo puedes descargar con Firefox o Kget o d4x... cualquiera que sea tu gestor de descargas, lo importante es que el archivo este en "/usr/src", para no perdernos. Ahora vamos a desempaquetar el Kernel y realizar un "acceso directo" (no me tiren tomates) o "symlink" al directorio creado por el proceso de desempaquetado del Kernel:

tar xvf linux-2.6.22.1.tar.bz2
ln -s linux-2.66.22.1 linux
cd linux

Ahora estamos en "/usr/src/linux", compruebalo con el comando "pwd".

1.3 Aplicando un parche al código del Kernel

Más tarde pongo como parchar un Kernel, como estamos usando la versión 2.66.22.1 estable, no hay necesidad (aun de parcharlo), cuando salga el primer parche, pongo el proceso.

1.4 Configurando el Kernel

Este es el proceso que mas interacción exige del usuario en la compilación del Kernel. Y quizás la mas temida también. Este proceso consiste en decirle al proceso de compilación, que módulos crear y que no, que hardware soportara o no nuestro Kernel, que características especiales tendrá, etc. Es decir, aquí es donde lo personalizamos, lo afinamos, e integramos con el hardware de nuestra PC.
Este proceso genera un archivo llamado ".config", nótese que es un dotfile o archivo oculto.

Como consejo, es buena costumbre usar la configuración del Kernel que tienes funcionando en este momento, para tener una solida base para la personalizacion de mismo.
Este paso es opcional; para usar la configuración de tu Kernel actual (y funcional), basta con copiarlo a la carpeta /usr/src/linux con el nombre .config:

cp /boot/config-`uname -r` ./.config

uname es un programa de consola que imprime la información del sistema, uname con el argumento "-r" imprime la versión del Kernel actual.
El comando anterior, suponiendo que tienes un Kernel 2.6.18-4-686, seria interpretado de la siguiente forma:

cp /boot/config-2.6.18-4-686 /usr/src/linux/.config

Ahora podemos comenzar con la configuración personalizada con:

make menuconfig

make se encargara construir el programa menuconfig y mostrarlo, menuconfig lista de opciones (módulos, características, etc) disponibles para el Kernel y los guardada en ".config" (lo lee y lo sobre escribe con las personalizaciones hechas). Existen otras opciones para modificar el archivo ".config" (con un editor de texto por ejemplo ja ja) por ejemplo con:

• xconfig, que usa un front end con Qt
  
• gconfig, que usa un front end con GTK
  

Pero menuconfig es la manera de hacerlo este trabajo como un vikingo leñador, y no requiere mayor cosa que los libncurses5, asi que ¡adelante!

"Captura de pantalla de menuconfig"

Ahora vamos a seleccionar la opción: Load an Alternate Configuration File.

"Captura de pantalla, selección de la opción Load an Alter Configuration File"

Y nos aseguramos de que este el nombre del archivo ".config":

"Captura de pantalla, nombre del archivo de configuración"

Cuando salgas, si has cambiado alguna configuración y no has salvado el ".config", te aparecerá un "cuadro de dialogo" para salvar el archivo. Hay que aclarar, que el proceso de compilación del Kernel espera que exista un archivo con el nombre ".config", si este no existe, entonces no podremos continuar.

En resumen...

Tiene que existir un archivo llamado ".config" en la carpeta del código fuente del Kernel ¡¡¿ok?!?

1.5 Construyendo e Instalando el nuevo Kernel

Los siguientes comandos son para construir el Kernel (recuerda que make es el que hacer la magia):

make all
make modules_install
make install

Ahora seamos pacientes, este proceso puede tomar desde algunos minutos, hasta un par de horas. Esto depende de la configuración que hiciste (si habilitaste todas las opciones como un perfecto demente) y la velocidad de tu procesador.
Si deseas saber que otras opciones puedes usar para el make, puedes hacer

make help

en "/usr/src/linux", la carpeta del código del Kernel, claro.

1.6 Proceso posterior a la instalación

El nuevo Kernel ahora esta instalado en tu sistema, pero necesita un "ramdisk", si no lo tiene, lo mas probable es que ¡el sistema no arranque!

"Oh no!... Kernel Panic"

Además necesitamos actualizar el GRUB para que muestre el nuevo Kernel.
Bien, lo primero es hacer el "ramdisk", asumiendo que tenemos el Kernel :

depmod 2.6.22.1

Este comando realiza un mapa de las dependencias de los módulos que usa tu Kernel, basándonos en este mapa podemos crear un ramdisk que tenga todos los modulosa necesarios que usa nuestro Kernel.
Para mas información de depmod ... RFTM.

Suponiendo que no tienes instalado mkinitramfs, evidentemente habrá que instalarlo...

apt-get install initramfs-tools

Y ahora que tenemos instalado mkinitramfs, hagamos nuestro ramdisk con:

mkinitramfs -o /boot/initrd.img-2.6.22.1 2.6.22.1

Esto genera el ramdisk con respecto a los módulos específicos compilados para nuestro Kernel.
Ahora actualizaremos GRUB con:

update-grub

Esto detectara el nuevo Kernel y ramdisk creado y actualizara el archivo "/boot/grub/menu.lst" por nosotros.

1.7 Últimos pasos...

Reiniciar el sistema:

shutdown -r now

En el menú del grub, selecciona tu nuevo Kernel. Si todo sale bien, ya esta funcionando tu PC con tu nuevo Kernel, ¡felicidades! Podes verificar si "realmente" estas usando tu nuevo Kernel con:

uname -r

Si tu sistema no arranca, entonces puedes re iniciar la computadora, y seleccionar el Kernel antiguo (y funcional) que tenias, para modificar los cambios.

1.8 Comentarios Finales

Si bien la etapa de configuración/compilación/re-inicar/arrancar etc... parece que no puede ser más corta, existe una interesante, educativa y "mejor" de probar el Kernel recién compilado sin re-iniciar la PC.
Esta es la forma del Vikingo Inteligente (por decirle de alguna forma) que examinaremos y explicaremos en algunos días.

1.9 Agradecimientos

Gracias a Falko Timme por su guía de compilación de Kernel, su guía fue usada como base para la realización de este documento, y gracias a ti por leer esta guía. Se esperan sugerencias y cualquier comentario es bienvenido.

Saludos y hasta la próxima!

Kernel Linux make compilar compilacion config modules modulos 2.6 gnu debian etch tutorial guia 2.6.22.1 2.6.x

Guía de Construcción de un Kernel Personalizado.

tipo: guía/tutorial.

1.0 Construyendo un Kernel Personalizado, a la manera tradicional (o como un Vikingo Leñador).

Esta parte especifica describe el proceso de creación de un Kernel personalizado (o que se volverá así a medida que veas que es un proceso para nada complicado). Abarca desde la descarga de un Kernel (donde encontrarlo), usar un parche en nuestro Kernel, el software necesario para compilar el Kernel, la Configuración y la creación de un "initram" (no se preocupen, ya llegaremos a eso). Todos los pasos se realizan suponiendo que el lector tiene Debian Etch instalado como sistema operativo y GRUB como bootloader (gestor de arranque) instalado. Al final de esta guía/tutorial, se espera que termines con un Kernel (por lo menos ligeramente) personalizado...

"La belleza del Kernel de Linux, esta en su personalización"

1. 1 Instalando los paquetes requeridos para la compilación del Kernel.

Primero actualizamos la lista de paquetes instalables en el sistema:

apt-get update

Luego instalamos los paquetes

• kernel-package
• libncurses5-dev
• fakeroot
• wget
• bzip2
• build-essential

...con el siguiente comando:

apt-get install kernel-package libncurses5-dev fakeroot wget bzip2 build-essential

1.2 Descargando el código fuente del Kernel

"10 años de Kernel.org"

En el sitio http://kernel.org se publica el codigo del kernel mas reciente, versiones anteriores del mismo y también parches respectivos. Al momento de hacer esta guía, el Kernel esta en su version estable 2.6.22.1 (este es el Kernel que sera usado). Pero antes de descargarlo vamonos al directorio "/usr/src":

cd /usr/src

y ahora:

wget http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.22.1.tar.bz2

O lo puedes descargar con Firefox o Kget o d4x... cualquiera que sea tu gestor de descargas, lo importante es que el archivo este en "/usr/src", para no perdernos. Ahora vamos a desempaquetar el Kernel y realizar un "acceso directo" (no me tiren tomates) o "symlink" al directorio creado por el proceso de desempaquetado del Kernel:

tar xvf linux-2.6.22.1.tar.bz2
ln -s linux-2.66.22.1 linux
cd linux

Ahora estamos en "/usr/src/linux", compruebalo con el comando "pwd".

1.3 Aplicando un parche al código del Kernel

Más tarde pongo como parchar un Kernel, como estamos usando la versión 2.66.22.1 estable, no hay necesidad (aun de parcharlo), cuando salga el primer parche, pongo el proceso.

1.4 Configurando el Kernel

Este es el proceso que mas interacción exige del usuario en la compilación del Kernel. Y quizás la mas temida también. Este proceso consiste en decirle al proceso de compilación, que módulos crear y que no, que hardware soportara o no nuestro Kernel, que características especiales tendrá, etc. Es decir, aquí es donde lo personalizamos, lo afinamos, e integramos con el hardware de nuestra PC.
Este proceso genera un archivo llamado ".config", nótese que es un dotfile o archivo oculto.

Como consejo, es buena costumbre usar la configuración del Kernel que tienes funcionando en este momento, para tener una solida base para la personalizacion de mismo.
Este paso es opcional; para usar la configuración de tu Kernel actual (y funcional), basta con copiarlo a la carpeta /usr/src/linux con el nombre .config:

cp /boot/config-`uname -r` ./.config

uname es un programa de consola que imprime la información del sistema, uname con el argumento "-r" imprime la versión del Kernel actual.
El comando anterior, suponiendo que tienes un Kernel 2.6.18-4-686, seria interpretado de la siguiente forma:

cp /boot/config-2.6.18-4-686 /usr/src/linux/.config

Ahora podemos comenzar con la configuración personalizada con:

make menuconfig

make se encargara construir el programa menuconfig y mostrarlo, menuconfig lista de opciones (módulos, características, etc) disponibles para el Kernel y los guardada en ".config" (lo lee y lo sobre escribe con las personalizaciones hechas). Existen otras opciones para modificar el archivo ".config" (con un editor de texto por ejemplo ja ja) por ejemplo con:

• xconfig, que usa un front end con Qt
  
• gconfig, que usa un front end con GTK
  

Pero menuconfig es la manera de hacerlo este trabajo como un vikingo leñador, y no requiere mayor cosa que los libncurses5, asi que ¡adelante!

"Captura de pantalla de menuconfig"

Ahora vamos a seleccionar la opción: Load an Alternate Configuration File.

"Captura de pantalla, selección de la opción Load an Alter Configuration File"

Y nos aseguramos de que este el nombre del archivo ".config":

"Captura de pantalla, nombre del archivo de configuración"

Cuando salgas, si has cambiado alguna configuración y no has salvado el ".config", te aparecerá un "cuadro de dialogo" para salvar el archivo. Hay que aclarar, que el proceso de compilación del Kernel espera que exista un archivo con el nombre ".config", si este no existe, entonces no podremos continuar.

En resumen...

Tiene que existir un archivo llamado ".config" en la carpeta del código fuente del Kernel ¡¡¿ok?!?

1.5 Construyendo e Instalando el nuevo Kernel

Los siguientes comandos son para construir el Kernel (recuerda que make es el que hacer la magia):

make all
make modules_install
make install

Ahora seamos pacientes, este proceso puede tomar desde algunos minutos, hasta un par de horas. Esto depende de la configuración que hiciste (si habilitaste todas las opciones como un perfecto demente) y la velocidad de tu procesador.
Si deseas saber que otras opciones puedes usar para el make, puedes hacer

make help

en "/usr/src/linux", la carpeta del código del Kernel, claro.

1.6 Proceso posterior a la instalación

El nuevo Kernel ahora esta instalado en tu sistema, pero necesita un "ramdisk", si no lo tiene, lo mas probable es que ¡el sistema no arranque!

"Oh no!... Kernel Panic"

Además necesitamos actualizar el GRUB para que muestre el nuevo Kernel.
Bien, lo primero es hacer el "ramdisk", asumiendo que tenemos el Kernel :

depmod 2.6.22.1

Este comando realiza un mapa de las dependencias de los módulos que usa tu Kernel, basándonos en este mapa podemos crear un ramdisk que tenga todos los modulosa necesarios que usa nuestro Kernel.
Para mas información de depmod ... RFTM.

Suponiendo que no tienes instalado mkinitramfs, evidentemente habrá que instalarlo...

apt-get install initramfs-tools

Y ahora que tenemos instalado mkinitramfs, hagamos nuestro ramdisk con:

mkinitramfs -o /boot/initrd.img-2.6.22.1 2.6.22.1

Esto genera el ramdisk con respecto a los módulos específicos compilados para nuestro Kernel.
Ahora actualizaremos GRUB con:

update-grub

Esto detectara el nuevo Kernel y ramdisk creado y actualizara el archivo "/boot/grub/menu.lst" por nosotros.

1.7 Últimos pasos...

Reiniciar el sistema:

shutdown -r now

En el menú del grub, selecciona tu nuevo Kernel. Si todo sale bien, ya esta funcionando tu PC con tu nuevo Kernel, ¡felicidades! Podes verificar si "realmente" estas usando tu nuevo Kernel con:

uname -r

Si tu sistema no arranca, entonces puedes re iniciar la computadora, y seleccionar el Kernel antiguo (y funcional) que tenias, para modificar los cambios.

1.8 Comentarios Finales

Si bien la etapa de configuración/compilación/re-inicar/arrancar etc... parece que no puede ser más corta, existe una interesante, educativa y "mejor" de probar el Kernel recién compilado sin re-iniciar la PC.
Esta es la forma del Vikingo Inteligente (por decirle de alguna forma) que examinaremos y explicaremos en algunos días.

1.9 Agradecimientos

Gracias a Falko Timme por su guía de compilación de Kernel, su guía fue usada como base para la realización de este documento, y gracias a ti por leer esta guía. Se esperan sugerencias y cualquier comentario es bienvenido.

Saludos y hasta la próxima!

Kernel Linux make compilar compilacion config modules modulos 2.6 gnu debian etch tutorial guia 2.6.22.1 2.6.x

Kernel, Almendras, Ventanas y Circulos Viciosos...

En el oscuro y ofuscado mundo de los Sistemas Operativos, un Kernel (también conocido en español como núcleo) es el componente central que se responsabiliza en manejar los recursos del sistema (manejo de memoria por ejemplo) y la comunicación entre el Hardware (parte física de una computadora) y el Software (programas).

Como componente básico de cualquier sistema operativo, un Kernel provee el nivel mas bajo en la capa de abstracción antes de llegar al Hardware... algo mas "abajo" del sistema operativo... son unos y ceros... o cambios voltaje.

La tarea del Kernel es ejecutar procesos (Software, aplicaciones, programas, como le quieran decir) y facilitarles a los mismos la tarea de interacción con el Hardware, mediante la comunicación entre procesos y llamadas al sistema (system calls).

Existen una gran variedad de Kernels: Micro Kernel y Mono Kernel y además esta el ExoKernel, el Kernel Híbrido y el Nano Kernel...

"Macro (Mono), Micro y Exo Kernel... el concepto"

...el diseño y creación de estos obedece usualmente a la implementación de los "anillos de protección". Estos anillos obedecen a un mecanismo que busca proteger datos y funcionalidad: de fallos y de comportamiento malicioso.

Los dos tipos de Kernel más usados son: Micro Kernel y Mono Kernel... y entre ellos existen un sin fin de implementaciones. Esto es como decir que solo existen Negros y Blancos... mentira, hay morenos, mulatos, cheles, chilucos, etc... Lo mismo es con las diversas implementaciones que existen entre el Micro Kernel y el Mono Kernel.

La forma mas fácil de imaginar un Kernel es como una almendra...

"Kernel en ingles, es el centro comestible de una almendra"

Hay que mencionar, que Microsoft decidió omitir esta regla de "anillos de protección" desde Windows 3.x hasta Windows 98. ¿Por qué?... bueno, la comunicación entre los anillos de protección requiere MUCHOS ciclos de procesamiento. Y con Windows siendo un sistema operativo elementalmente visual, Microsoft no tenia mas remedio que ELIMINAR los anillos de protección para mejorar el rendimiento general del sistema. Claro, esto llevo a problemas terribles muy bien conocidos en todos los Windows de la serie 3.x y 9x, como la famosa BSOD (Pantalla Azul).

"Así se vería el Kernel de Windows 98 después de una BSOD"

Ahora la serie de sistemas Windows XP/Vista eliminan (enormemente) este problema implementando en su Kernel los una vez desplazados anillos de protección... que se asemejan mucho con las capas de una cebolla... pero basta de hablar de comida.

El tema del Kernel no sera muy tratado por los usuarios de Windows... pero crean cuando les digo que es un tema muy interesante y elegido como tema de conversación (bueno, ni tanto) por muchos usuarios de GNU\Linux... y no es solo interesante, sino también controversial y ¡extenso!.

Lo "bonito" del Kernel de Linux, es que como es Open Source, todo mundo sabe como funciona y esto permite algunas características muy interesantes a la hora del famoso proceso de "compilación del Kernel".

Compilar el Kernel en un sistema, no se trata de una tarea exclusiva para "geeks", basta con leer un poco y entender la dinámica. Lo que si aburre, es el TIEMPO que tarda en compilarse, y sumado a esto, tener que re-iniciar la maquina para probar el nuevo kernel, y sino funciona, hacer el proceso de nuevo.

Pues para este circulo vicioso, existe un método que simplifica MUCHO las cosas, y además, sirve de ejemplo perfecto de la flexibilidad que presenta el Software Libre.
Este método consiste en la utilización de una maquina virtual para probar nuestro Kernel, y definitivamente NO consiste en copiar el kernel a la maquina virtual y arrancarla o peor aun, compilar el kernel en una maquina virtual, NO NO NO!
Es mucho mejor que eso (y menos tedioso), consiste en arrancar la imagen de un disco duro virtual con un Kernel (el que hemos compilado) EXTERNO a esta maquina virtual.

"Logo de QEmu"

Esta fantástica característica parte de QEMU (QEmu es un emulador de computadoras virtuales), se llama "Direct Linux Boot":

"Captura de pantalla de Qemu Laucher con Direct Linux Boot habilitado"

Direct Linux Boot, permite ahorrar tiempo de una manera increíble, al evitar estar re-iniciando la maquina constantemente y evitando el infame "Kernel Panic".

"Captura de pantalla de Direct Linux Boot con Kernel EXTERNO 2.6.21rac
Click para hacerlo más grande"

En el transcurso de la semana escribo un tutorial sobre como compilar y probar un Kernel usando QEMU.

Hasta Luego!

Kernel, Almendras, Ventanas y Circulos Viciosos...

En el oscuro y ofuscado mundo de los Sistemas Operativos, un Kernel (también conocido en español como núcleo) es el componente central que se responsabiliza en manejar los recursos del sistema (manejo de memoria por ejemplo) y la comunicación entre el Hardware (parte física de una computadora) y el Software (programas).

Como componente básico de cualquier sistema operativo, un Kernel provee el nivel mas bajo en la capa de abstracción antes de llegar al Hardware... algo mas "abajo" del sistema operativo... son unos y ceros... o cambios voltaje.

La tarea del Kernel es ejecutar procesos (Software, aplicaciones, programas, como le quieran decir) y facilitarles a los mismos la tarea de interacción con el Hardware, mediante la comunicación entre procesos y llamadas al sistema (system calls).

Existen una gran variedad de Kernels: Micro Kernel y Mono Kernel y además esta el ExoKernel, el Kernel Híbrido y el Nano Kernel...

"Macro (Mono), Micro y Exo Kernel... el concepto"

...el diseño y creación de estos obedece usualmente a la implementación de los "anillos de protección". Estos anillos obedecen a un mecanismo que busca proteger datos y funcionalidad: de fallos y de comportamiento malicioso.

Los dos tipos de Kernel más usados son: Micro Kernel y Mono Kernel... y entre ellos existen un sin fin de implementaciones. Esto es como decir que solo existen Negros y Blancos... mentira, hay morenos, mulatos, cheles, chilucos, etc... Lo mismo es con las diversas implementaciones que existen entre el Micro Kernel y el Mono Kernel.

La forma mas fácil de imaginar un Kernel es como una almendra...

"Kernel en ingles, es el centro comestible de una almendra"

Hay que mencionar, que Microsoft decidió omitir esta regla de "anillos de protección" desde Windows 3.x hasta Windows 98. ¿Por qué?... bueno, la comunicación entre los anillos de protección requiere MUCHOS ciclos de procesamiento. Y con Windows siendo un sistema operativo elementalmente visual, Microsoft no tenia mas remedio que ELIMINAR los anillos de protección para mejorar el rendimiento general del sistema. Claro, esto llevo a problemas terribles muy bien conocidos en todos los Windows de la serie 3.x y 9x, como la famosa BSOD (Pantalla Azul).

"Así se vería el Kernel de Windows 98 después de una BSOD"

Ahora la serie de sistemas Windows XP/Vista eliminan (enormemente) este problema implementando en su Kernel los una vez desplazados anillos de protección... que se asemejan mucho con las capas de una cebolla... pero basta de hablar de comida.

El tema del Kernel no sera muy tratado por los usuarios de Windows... pero crean cuando les digo que es un tema muy interesante y elegido como tema de conversación (bueno, ni tanto) por muchos usuarios de GNU\Linux... y no es solo interesante, sino también controversial y ¡extenso!.

Lo "bonito" del Kernel de Linux, es que como es Open Source, todo mundo sabe como funciona y esto permite algunas características muy interesantes a la hora del famoso proceso de "compilación del Kernel".

Compilar el Kernel en un sistema, no se trata de una tarea exclusiva para "geeks", basta con leer un poco y entender la dinámica. Lo que si aburre, es el TIEMPO que tarda en compilarse, y sumado a esto, tener que re-iniciar la maquina para probar el nuevo kernel, y sino funciona, hacer el proceso de nuevo.

Pues para este circulo vicioso, existe un método que simplifica MUCHO las cosas, y además, sirve de ejemplo perfecto de la flexibilidad que presenta el Software Libre.
Este método consiste en la utilización de una maquina virtual para probar nuestro Kernel, y definitivamente NO consiste en copiar el kernel a la maquina virtual y arrancarla o peor aun, compilar el kernel en una maquina virtual, NO NO NO!
Es mucho mejor que eso (y menos tedioso), consiste en arrancar la imagen de un disco duro virtual con un Kernel (el que hemos compilado) EXTERNO a esta maquina virtual.

"Logo de QEmu"

Esta fantástica característica parte de QEMU (QEmu es un emulador de computadoras virtuales), se llama "Direct Linux Boot":

"Captura de pantalla de Qemu Laucher con Direct Linux Boot habilitado"

Direct Linux Boot, permite ahorrar tiempo de una manera increíble, al evitar estar re-iniciando la maquina constantemente y evitando el infame "Kernel Panic".

"Captura de pantalla de Direct Linux Boot con Kernel EXTERNO 2.6.21rac
Click para hacerlo más grande"

En el transcurso de la semana escribo un tutorial sobre como compilar y probar un Kernel usando QEMU.

Hasta Luego!

La Tecnologia y Yo.

Después de una "acalorada" discusión con un internauta de este blog, ciego defensor del software propietario y frustrado usuario de gnu\linux, pero con interesantes (y cenagosos) puntos de vista; obtuve una serie de interesantes interrogantes sobre las ideas base con las que comencé a escribir en este blog.

Nacidas de ese trastornado y terriblemente trillado conflicto de:

"Windows es mejor, Linux es mejor, Windows es mejor, Linux es mejor..."

y de todo esto recordé, que es la tecnología es la que me apasiona y que alimenta los engranajes del mundo y de mi imanación.
La tecnología con ímpetu increíble trasciende fronteras, política, raza, religión y atraviesa como una lanza todos los puntos de vista.

La tecnología es como la energía eléctrica, y alimenta cualquier aparato que se pueda conectar a ella.

Pero al tratar de mantener su pista y avance acelerado. Me he llenado del tinte político que tanto desprecio, y casi inevitablemente he tomado "partido" por la ideología tecnológica/social con la que mas me identifico (Software Libre).
Al punto de criticar, algunas veces hasta sin sentido, el uso de los Sistemas Propietarios existentes.

Pues bien es tiempo de abstraer mi mente de fronteras ideológicas o dogmas impuestos, y de esos pequeños detalles engorrosos que solo son muestra o de una profunda ignorancia o un manifiesto de algún interés egoísta.
Ahora hablare de los detalles que me interesan, pero lo haré sin prejuicios, sin tintes y con todos los puntos sobre la mesa, pero inevitablemente ... hablare de lo que me gusta.

Así que, para comenzar con esta re-invención blogística... esperen el próximo articulo. ;)

Hasta luego.

La Tecnologia y Yo.

Después de una "acalorada" discusión con un internauta de este blog, ciego defensor del software propietario y frustrado usuario de gnu\linux, pero con interesantes (y cenagosos) puntos de vista; obtuve una serie de interesantes interrogantes sobre las ideas base con las que comencé a escribir en este blog.

Nacidas de ese trastornado y terriblemente trillado conflicto de:

"Windows es mejor, Linux es mejor, Windows es mejor, Linux es mejor..."

y de todo esto recordé, que es la tecnología es la que me apasiona y que alimenta los engranajes del mundo y de mi imanación.
La tecnología con ímpetu increíble trasciende fronteras, política, raza, religión y atraviesa como una lanza todos los puntos de vista.

La tecnología es como la energía eléctrica, y alimenta cualquier aparato que se pueda conectar a ella.

Pero al tratar de mantener su pista y avance acelerado. Me he llenado del tinte político que tanto desprecio, y casi inevitablemente he tomado "partido" por la ideología tecnológica/social con la que mas me identifico (Software Libre).
Al punto de criticar, algunas veces hasta sin sentido, el uso de los Sistemas Propietarios existentes.

Pues bien es tiempo de abstraer mi mente de fronteras ideológicas o dogmas impuestos, y de esos pequeños detalles engorrosos que solo son muestra o de una profunda ignorancia o un manifiesto de algún interés egoísta.
Ahora hablare de los detalles que me interesan, pero lo haré sin prejuicios, sin tintes y con todos los puntos sobre la mesa, pero inevitablemente ... hablare de lo que me gusta.

Así que, para comenzar con esta re-invención blogística... esperen el próximo articulo. ;)

Hasta luego.