jueves, 18 de noviembre de 2010

Android Limitaría el Desarrollo de Linux en el Mercado de Teléfonos Inteligentes

Android Limitaría el Desarrollo de Linux en el Mercado de Teléfonos Inteligentes

Dejando de lado la formalidad que me rodea en estos días y migrando hacia un tono más informal, me disculpo por no haber tenido la paciencia de redactar un artículo en lo que va de este de año. A veces suelo divagar en cosas intrascendentes y al final no concretar nada. Sin embargo acá les va un artículo algo tardío sobre como afecta Android al desarrollo de Linux para teléfonos inteligentes. Disfrútenlo.

Estos días estoy barajando la opción de cambiar de teléfono móvil, tengo el viejo Nokia 6300 (todo un clásico y machazo) y estoy pensando cambiarlo por un Sony-Ericsson Xperia X10(1) (me lo compraría si tuviera el dinero y si no fuera tan grande). Revisando las especificaciones (porque como deben de saber, antes de comprar un móvil es preciso revisar exhaustivamente las especificaciones) descubrí que este teléfono móvil tenía al producto de Google Android como sistema operativo. De pronto recordé algunas cosas de Android que menciono a continuación.

Ya ha pasado poco más de dos año(2) desde que vimos el primer teléfono inteligente con Android y podemos decir que le ha ido bien en el mercado puesto que en la actualidad ocupa el segundo lugar(3) del ranking de plataformas móviles después de Symbian OS de Nokia y antes que iOS de Apple.

Android es un sistema operativo derivado de Linux. Linux pertenece a la comunidad GNU y cualquier persona o individuo (o gigante de Internet) puede modificar el código a su gusto y comercializar el resultado. Esto es exactamente lo que ha hecho Google, ha tomado el kernel de Linux, lo ha modificado y lo ha comercializado, adicionalmente los sistemas de licencia GNU establecen que los cambios que se realicen en el código GNU deben de ser publicados de modo que Linux con el apoyo de la comunidad sea compatible con este derivado como es el caso de Android.

Google ha cumplido con todo lo estipulado en las licencias GNU. La prueba de ello la puedo dar yo personalmente cuando a principios de este año revisaba el kernel de Linux y me encontré que en el directorio Stagin de la sección de Drivers había una carpeta Android.

Cuando encontré la carpeta Android en el directorio Stagein(4) de la zona de Drivers me pareció una estupenda idea hacer Linux compatible con Android. Más o menos alucine (porque no hay una palabra mejor dicha) que por un lado Google certificaba los móviles compatibles con Andoid y que siendo Android compatible con Linux dentro de pocos meces sería posible instalar Linux en gran cantidad de teléfonos inteligentes. Este hecho demostraría que Google (a diferencia de otras corporaciones como IBM) no sólo usa a la comunidad GNU para sus intereses sino que también retribuye y aporta desarrollo a la comunidad.

Si bien a todos los que amamos la filosofía Google nos gustaría que lo anterior sea cierto. La realidad nuevamente nos hace equivocarnos porque la verdad es que el código que ha publicado Google sobre los drivers de Android no resultan ser compatibles con Linux y en la actualidad ya el código Android ya ha sido eliminado del Kernel(5).

Desde el punto de vista de Google, está totalmente clara la idea(6). Si su código fuera compatible con Linux entonces tendría un competidor más (y ya tiene suficiente con Aplee y Microsoft). Sin embargo tener a Linux como competir traería un problema adicional ya que Linux atacaría directamente al modelo de mercado de Android a diferencia de Apple y Microsoft que manejan otro modelo de mercado.

Yo la tengo claro, si Linux fuera compatible con Android los fabricantes optarían por instalar Linux y no tener que depender tanto a Google (tampoco es bueno depender tanto de una compañía ya sea Google o Microsoft). En este sentido Google ha sabido jugar al futbol y la comunidad GNU otra vez ha perdido una batalla.

Google la tiene claro, Linux no atacaría el modelo de mercado de Google por el contrarío es Google quien ha atacado en modelo de mercado de la comunidad GNU. Analicemos. Android es gratuito por lo que los fabricantes no tienen que pagar ni regalías ni patentes, esto es exactamente lo que es Linux. Ahora el problema es que los fabricantes van a perder interes en soportar Linux ya que van a estar enfocados en soportar Android.

Pero cual es el problema que los fabricantes soporten Android y no Linux, bueno el problema está en que Android se ha publicado bajo otro sistema de licencia la cual permite que los desarrolladores no tengan la obligación de publicar el código.

No es la primera vez que Google utiliza a la comunidad GNU para desarrollar tecnología los que tenemos memoria debemos de recordar que Google fue unos de los mayores auspiciadores del proyecto Mozilla (Firefox) y que luego se retiró para lanzar su navegador Chrome (el cual yo uso porque es muy bueno). Sin embargo Chrome no aportó ningún conocimiento a Mozilla. Google también la tiene claro, en estos tiempo el conocimiento vale más que el dinero.

Finalmente no seamos reaccionarios, resentidos o negativos y a estas alturas del artículo cambiemos nuestro punto de vista hacia un horizonte más positivo. La pregunta del millón es sí tendría la comunidad Linux el poder de convocatorio de Google para que los fabricantes instalen Linux en sus equipos móviles. Si crees que la respuesta es ‘no’, estás en lo cierto. Google está generando su propio mercado que cosiste en regalar lo que no le cuesta (o le cuesta poco) como es Android e instalar sus aplicaciones y comenzar a cobrar por publicidad. Si ver publicidad es el precio de emplear su plataforma y productos entonces creo que haría un buen negocio teniendo Android instalado en mi próximo Xperia X10.

(1) http://www.sonyericsson.com/cws/products/2.371/xperiax10

(2) http://en.wikipedia.org/wiki/Android_%28operating_system%29

(3) http://www.eweek.com/c/a/Mobile-and-Wireless/Android-Will-Rise-to-No-2-Smartphone-Ranking-by-2013-Says-Study-742057/

(4) http://www.kroah.com/log/linux/android-kernel-problems.html?seemore=y

(5) http://www.fayerwayer.com/2010/02/eliminan-codigo-de-android-en-linux/

(6) http://linuxhaters.blogspot.com/2010/02/they-took-our-codes.html

viernes, 12 de noviembre de 2010

GIS Aplicado a las Telecomunicaciones

GIS Aplicado a las Telecomunicaciones



Después del éxito del seminario de Proyectos de Banda Ancha ofrecido por la semana de la ingeniería electrónica y a pedido del público, sólo por única vez estaré dictando el curso de ArcGis en el colegio de ingenieros. Estan todos cordialmente invitados. No se lo pierdan.

domingo, 31 de octubre de 2010

Becas CCNA CTT


Como no podía ser de otra manera CTT organizará una maratón para otorgar becas CCNA a los ganadores. Dentro de la cultura CTT es la mejor forma de promover e impulsar las certificaciones internacionales que hoy por son la base para la competitividad laboral.

Este viernes 5 de noviembre estaremos brindando una charla informativa con toda la información que se necesita para participar en la maratón de becas.

jueves, 30 de septiembre de 2010

Gestión de Proyectos en Infraestructura de Telecomunicaciones de Banda Ancha

Gestión de Proyectos en Infraestructura de Telecomunicaciones de Banda Ancha


En el marco de la semana de la Ingeniería Electrónica, quiero expresar mi saludo a todos los colegas y amigos Ingenieros Electrónicos del Perú, con especial mención a los Colegios de Trujillo y Lima.

Si bien el capítulo de Ingenieros Electrónicos de Trujillo a organizado un estupendo seminario (del cual he recibido los mejores comentarios). En Lima también estamos organizando un evento de similar magnitud que va estar a la altura de las expectativas. Se trata de un Seminario Profesional en el Colegio de Ingeniero de Lima, auspiciado por el Capítulo de Ingeniería Electrónica.

Las personas con las que compartiremos este seminario es Carlos Sotelo (mi jefe y jefe del área de formulación de Proyectos de Fitel) y Juan Carlos Ames (Analista en economía de Proyectos de Inversión) ambos amigos y compañeros de trabajo expertos en su campo. Será un honor compartir el seminario con este equipo.

En este seminario nos haremos presentes revisando las herramientas de Software para la planificación de Proyectos Redes de Banda Ancha de Gran Escala. Están todos cordialmente invitados. Desde ya puedo comentarles va ha estar muy bueno.

lunes, 20 de septiembre de 2010

Charla Informativa CCNA con CTTPerú



Lo más importante del devenir del tiempo, es la experiencia. La experiencia que uno acumula es fundamental para afrontar nuevas circunstancias y problemas. Sin embargo la experiencia para que sea significativa no necesariamente tiene que ser vivencial, también puede ser transferible. Se ha demostrado que un aprendizaje significativo se logra de la experiencia que nos transfieren personas como nuestros padres, maestros y amigos.

En este sentido, en el mundo globalizado en el que vivimos hoy en día, como bien dice un el spot de un banco “el tiempo vale más que el dinero” y es que el tiempo ganado en minimizar la curva de aprendizaje es invaluable.

En cuanto a la curva de aprendizaje, está se puede optimizar con los recursos y metodología adecuada. En este punto, CTTPerú tiene el KNOW HOW de la pedagogía en el campo tecnológico, capacitándote para que puedas certificarte en el menor tiempo en marcas lideres como Cisco o Google.

Para terminar (antes de que esto sea demasiado largo ;) les recomiendo e invito a la charla informativa que CTT brindará en día jueves 23 de septiembre, hora 6:30pm, en su local ubicado en Rivera Navarrete 501, piso 17, Edificio Capital. San Isidro, el teléfono para mayor información es 6154949.

miércoles, 30 de junio de 2010

Almorzar viendo el Mundial

Estamos con esta fiebre del mundial, totalmente comprensible porque el que no la disfruta hoy tendrá que esperar cuatro años para volver a disfrutarla.

Estaba en Trujillo, había decidido ir a almorzar al centro comercial Mall Aventura, sabía que había una pantalla gigante ahí. Cuando me trajeron mi almuerzo le solicite al mozo (amablemente claro está) me que trajera mayoneza, me dijo que en seguida.

Después de esperar lo suficiente me acerque al puesto de comida rápida y le comente al cajero que había pedido mayonesa y no me la habían alcanzado, me dijo que en seguida me la llevarían y que tomara asiento.

De manera respetuosa le comente al responsable que no había necesidad de que me la llevaran y que yo la podía llevar personalmente. Me solicitó que esperara un momento. Después de otra espera me volvió a solicitar que tomara asiento porque la iban a preparar y eso demoraría. Entre todos los ‘tome asiento’ y los ‘tenga paciencia’ llevaba más de media hora y ya terminaba el partido.

Educadamente le reprendí al responsable que hubiera sido suficiente conque el mozo que dijera que no había mayonesa. Que el cajero me dijera que no había mayonesa o que incluso él me dijera que no había mayonesa. Le reproché que el servicio al cliente era pésimo. Mientras me alejaba escuchaba fanfarronear al encargado cosas como que yo no era el único cliente, que el sabía manejar su negocio, que quien era yo y que la mayonesa me la llevarían el mismo. Por su puesto la mayonesa nunca llegó, igual, si hubiera llegado yo ya había terminado de almorzar antes de acerca al puesto de comida.

sábado, 13 de marzo de 2010

Instalación de la interfaz virtual TUN/TAP en Fedora 12 para QEMU

Instalación de la interfaz virtual TUN/TAP en Fedora 12 para QEMU

Introducción

El blog estaba abandonado, más aún no había ninguna entrada sobre linux, en este sentido he sacrificado una tarde de verano para dejar este tutorial que espero que les sirva y le saquen provecho.

Las interfaces virtuales sirven para distintos propócitos, en mi caso necesito simular la plataforma ARM Integrator con una interfaz de red, que cuente con toda las características de una interfaz real. Si bien el simulador, QEMU, proporciona una interfaz virtual, está solo es accesible desde el simulador hacia afuera sin embargo no es posible acceder desde la pc hacia el simulador, en mi caso estoy simulando algunos servicios en la plataforma ARM Integrator y necesito una interfaz virtual con todas las características de una interfaz de red normal.

Despues de buscar en google la información necesaria (generalmente de foros y blogs de linux) logré la configuración correcta, estos pasos que voy a mostrar funcionan en Fedora 12, supongo que para otras versiones de Fedora (en su mayoría recientes) se seguirá un proceso similar. Para otras distribuciones los pasos varían un poco por lo que es mejor buscar el procedimiento para esa distribución específica.

Instalación

Buno, manos a la obra, en primer lugar necesitamos instalar los paquetes necesarios, en este caso necesitamos instalar bridge-utils que porporciona la funcionalidad de bridge (o switch cómo generalmente lo conocemos en Perú), adicionalmente necesitamos instalar tun que es el driver con el que se maneja las interfaces virtuales y finalmente necesitamos una herramienta llamanta tun-ctl la cual nos permite crear interfaces TAP empleando el driver TUN, resumiendo los paquetes son los siguientes

  1. bridge-utils: driver que proporciona funcionalidad de bridge

  2. tun: driver para manejar interfaces virtuales

  3. tun-ctl: herramienta para crear interfaces virtuales TAP

La instalación de estos paquetes lo hacemos empleando yum del modo siguiente

$sudo yun install bridge-utils tun-ctl

Como ven, no es necesario instalar tun ya que es parte del kernel lo que debemos hacer es intalarlo como módulo y verificar si el módulo se instalo correctamente esto lo hacemos así:

$sudo modprobe tun

Para verificar la instalación del driver podemos revisar la vitácora del sistema con este comando

$sudo tail /var/log/messages

entre las últimas lineas de deve de encontrar algo similar a lo siguiente

Mar 13 19:52:31 dpinspiron kernel: tun: Universal TUN/TAP device driver, 1.6

Mar 13 19:52:31 dpinspiron kernel: tun: (C) 1999-2004 Max Krasnyansky

adicionalmente podemos verificar si se ha registrado el dispositivo tun con el siguiente comando

$ ls -l /dev/net

debe mostrar la siguiente linea

crw-rw-rw-. 1 root root 10, 200 2010-03-13 09:08 tun

Si todo está de acuerdo a lo que muestro entonces podremos ir al siguiente paso que es la configuración

Configuración

En primer lugar vamos ha crear el archivo de configuración de la interfaz bridge, esta interfaz va a ser como nuestro switch al que luego le agregaremos las interfaces de red que deseemos, sin embargo esta interfaz bridge también puede tener una dirección ip asignada de manera estática o mediante dhcp, bueno sin más preambulo creamos el fichero ifcfg-br0

$sudo vi /etc/sysconfig/network-scripts/ifcfg-br0

con el siguiente contenido

# Interface bridge0

DEVICE=br0

ONBOOT=yes

BOOTPROTO=static

TYPE=Bridge

IPADDR=192.168.0.254

NETMASK=255.255.255.0

NM_CONTROLLED=no

PEERDNS=yes

la opción NM_CONTROLLED=no hace que el programa NetworkManager no administre de manera automática esta interfaz. A continuación debemos de editar la configuración de las interfaces ethernet que deseamos que formen parte del bridge, en mi caso sólo dispongo de la interfaz eth0, puesto que no es posible agragar interfaces wireless (al menos así dice la teoría y yo le creo). Bueno, entonces editamos la configuración de la interfaz de red eth0 de la siguiente manera

$ sudo vi /etc/sysconfig/network-scripts/ifcfg-eth0

y lo modificamos (o lo creamos en el caso que no exista) de la siguiente manera

# Interfaz Ethernet Eth0

DEVICE=eth0

HWADDR=00:1C:23:95:B6:A3

ONBOOT=yes

BOOTPROTO=static

IPADDR=192.168.0.1

NETMASK=255.255.255.0

TYPE=Ethernet

NM_CONTROLLED=no

BRIDGE=br0

En mi caso le he asignado una dirección estática debido a que salgo a internet por la red inalámbrica, sin embargo en el trabajo tendré con cambiarla por dhcp. Como se deben de haber percatado la opción BRIDGE=br0 hace que la interfaz eth0 forme parte del bridge (o como ya dije del switch por decirlo en de la manera coloquial). Bueno ahora sólo nos queda crear el archivo de configuración de nuestra interfaz virtual tap0 para esto creamos el fichero ifcfg-tap0

sudo vi /etc/sysconfig/network-scripts/ifcfg-tap0

el contenido de este fichero deberá ser el siguiente

# Interfaz Virtual TUN/TAP Tap0

DEVICE=tap0

ONBOOT=no

BOOTPROTO=static

TYPE=Tap

NM_CONTROLLED=no

BRIDGE=br0

En mi caso no es necesario asignarle una dirección ip puesto que será qemu el encargado de configurar la interfaz.

Inicialización

Si tenemos suerte entonces podemos reiniciar los servicios de red de la siguiente manera

$ sudo service network restart

El resultado debe ser el sigueinte

Shutting down interface br0: [ OK ]

Shutting down interface eth0: [ OK ]

Shutting down loopback interface: [ OK ]

Bringing up loopback interface: [ OK ]

Bringing up interface eth0: [ OK ]

Bringing up interface br0: [ OK ]

Y para terminar iniciamos la interfaz tap0

$ sudo ifup eth0

Verificación

Para verificar que todo haya salido de acuerdo a lo planeado ejecutamos el siguiente comando

$ ifconfig

la salida debe ser la sigueinte

br0 Link encap:Ethernet HWaddr 00:1C:23:95:B6:A3

inet addr:192.168.0.254 Bcast:192.168.0.255 Mask:255.255.255.0

inet6 addr: fe80::21c:23ff:fe95:b6a3/64 Scope:Link

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:0 errors:0 dropped:0 overruns:0 frame:0

TX packets:34 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:0

RX bytes:0 (0.0 b) TX bytes:5373 (5.2 KiB)


eth0 Link encap:Ethernet HWaddr 00:1C:23:95:B6:A3

UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1

RX packets:0 errors:0 dropped:0 overruns:0 frame:0

TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

Interrupt:21


lo Link encap:Local Loopback

inet addr:127.0.0.1 Mask:255.0.0.0

inet6 addr: ::1/128 Scope:Host

UP LOOPBACK RUNNING MTU:16436 Metric:1

RX packets:88 errors:0 dropped:0 overruns:0 frame:0

TX packets:88 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:0

RX bytes:5280 (5.1 KiB) TX bytes:5280 (5.1 KiB)


tap0 Link encap:Ethernet HWaddr AA:BA:D3:D9:89:F2

UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1

RX packets:0 errors:0 dropped:0 overruns:0 frame:0

TX packets:0 errors:0 dropped:6 overruns:0 carrier:0

collisions:0 txqueuelen:500

RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)


wlan0 Link encap:Ethernet HWaddr 00:1C:26:98:60:67

inet addr:192.168.1.34 Bcast:192.168.1.255 Mask:255.255.255.0

inet6 addr: fe80::21c:26ff:fe98:6067/64 Scope:Link

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:150927 errors:0 dropped:0 overruns:0 frame:0

TX packets:101489 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:203655276 (194.2 MiB) TX bytes:10828922 (10.3 MiB)

Debemos de tener como mínimo nuestra interfaz br0, eth0 y tap0. Puden darse cuanta que en mi caso mi interfaz eth0 no tiene la dirección ip, sospecho que esto se debe a que no está con el cable de red sin embargo le podemos asignar una dirección ip manualmente con el comando

$ sudo ifconfig eth0 192.168.0.1

Adicionalmente podemos ususar la herramienta brctl

$ brctl show

bridge name bridge id STP enabled interfaces

br0 8000.001c2395b6a3 no eth0

tap0

pan0 8000.000000000000 no

Como se puede observar las interfaces eth0 y tap0 forman parte del br0

Finalización

Con está interfaz virtual podemos proporcionar full conectividad a nuestras máquinas virtuales que corremos con virtual box o qemu, en mi caso estoy empleando qemu para simular la plataforma ARM Integrator por lo que inicio el simulador de la sigueinte manera

sudo qemu-system-arm -kernel images/zImage -initrd images/initrd.gz -append "console=ttyAMA0 root=/dev/ram0 rw ramdisk_size=90000" -nographic -net nic -net tap,ifname=tap0,script=no

Eso ha sido todo, cualquier información no duden en preguntar. Saludos y hasta la próxima.