El estándar ODF y el "estándar" OOXML
octubre 31, 2007Tecnología WiFi con Linux
marzo 12, 2007
En Linux toda tarjeta de red inalámbrica puede tener teóricamente hasta 7 modos de operación:
Ad-hoc: El equipo actúa como parte de una red ad-hoc.
Managed: El equipo actúa como cliente de una red de infraestructura.
Master: El equipo actúa como un Access Point.
Repetear: El equipo solo reenvía los paquetes recibidos de otros nodos inalámbricos.
Secondary: El equipo actúa como un backup de un Master o Repetear.
Monitor: El equipo solo recibe paquetes en modo de monitoreo.
Auto: Configuración automática empezando por Ad-hoc y siguiendo en Managed.
Los drivers no necesariamente soportan todos los modos de trabajo, pero al menos deben dar soporte a los modos Ad-hoc y Managed, siendo el modo Master una opción interesante, sin embargo también está limitado al tipo de tarjeta inalámbrica que usemos. En particular la tarjeta inalámbrica que viene en las notebooks con procesador Intel Centrino no permiten este modo.
Para el desarrollo del presente artículo usaremos la tarjeta inalámbrica PCI D-Link modelo DWL-G520 el cual se basa en el chip de la empresa Atheros, así como la distribución Fedora 6.0, sin embargo básicamente haremos uso de comandos del sistema así que podemos tomarlo de referencia para otras distribuciones. El driver no es proporcionado por Fedora ni por la compañía D-Link pero existe un driver creado por el proyecto Madwifi que puede ser descargado de la página http://madwifi.org/
El driver madwifi es muy interesante, permite crear varias extensiones virtuales asociadas a la tarjeta inalámbrica y soporta los modos de trabajo Ad-hoc, Manager y Master, siendo éste último el que nos va a permitir crear un Access Point, una característica que no encuentro disponible en Windows y que una vez mas comprueba el poder de flexibilidad del software libre.
Ad-hoc: El equipo actúa como parte de una red ad-hoc.
Managed: El equipo actúa como cliente de una red de infraestructura.
Master: El equipo actúa como un Access Point.
Repetear: El equipo solo reenvía los paquetes recibidos de otros nodos inalámbricos.
Secondary: El equipo actúa como un backup de un Master o Repetear.
Monitor: El equipo solo recibe paquetes en modo de monitoreo.
Auto: Configuración automática empezando por Ad-hoc y siguiendo en Managed.
Los drivers no necesariamente soportan todos los modos de trabajo, pero al menos deben dar soporte a los modos Ad-hoc y Managed, siendo el modo Master una opción interesante, sin embargo también está limitado al tipo de tarjeta inalámbrica que usemos. En particular la tarjeta inalámbrica que viene en las notebooks con procesador Intel Centrino no permiten este modo.
Para el desarrollo del presente artículo usaremos la tarjeta inalámbrica PCI D-Link modelo DWL-G520 el cual se basa en el chip de la empresa Atheros, así como la distribución Fedora 6.0, sin embargo básicamente haremos uso de comandos del sistema así que podemos tomarlo de referencia para otras distribuciones. El driver no es proporcionado por Fedora ni por la compañía D-Link pero existe un driver creado por el proyecto Madwifi que puede ser descargado de la página http://madwifi.org/
El driver madwifi es muy interesante, permite crear varias extensiones virtuales asociadas a la tarjeta inalámbrica y soporta los modos de trabajo Ad-hoc, Manager y Master, siendo éste último el que nos va a permitir crear un Access Point, una característica que no encuentro disponible en Windows y que una vez mas comprueba el poder de flexibilidad del software libre.
Clusters y Grid Computacionales
abril 03, 2006
El problema de interconectar computadoras para ejecutar cálculos en paralelo es antiguo pero recién ahora está tomando mayor importancia a nivel corporativo donde el esquema cliente servidor requiere servidores cada vez más potentes, básicamente en el tema de servicios web y minería de datos. A nivel de investigación se requiere gran capacidad de cómputo para aplicaciones que van desde simulaciones del medio ambiente, biomedicina, física de partículas, estadísticas, criptografía, etc. La potencia de las computadoras es cada vez mayor, pero al mismo tiempo siguen apareciendo retos computacionales más grandes, lo que viene a continuación es una pequeña introducción con enlaces de referencia.
Bonding: multiplicando la velocidad del Ethernet
marzo 28, 2006
En ésta oportunidad les contaré acerca de la técnica llamada Bonding. En ambientes LAN donde se necesita un servidor que deba soportar transferencias de grandes volumenes de datos (por ejemplo un servidor de archivos desde donde se descargan instaladores o donde todos hacen backups diarios o servidores de video streaming) muchas veces nos queda corta la velocidad de la tarjeta de red, asi conectemos nuestro servidor a un switch.
Compresión HTTP
marzo 05, 2006
Quería comentarles acerca de la técnica de compresión HTTP. Para los no entendidos el http es el protocolo que usan los navegadores y los servidores web para conversar entre ellos. A través de éste protocolo el servidor envía las páginas webs, imágenes, archivos, etc, que le solicita el cliente, tal y como están almacenados en el servidor.
No hay problema con las imágenes pues normalmente están en formato comprimido como jpf o gif, sin considerar el cuidado que debe tener el diseñador para usar imágenes de poco peso. Sin embargo gran parte de la información que se envía son los documentos html que al fin y al cabo son texto, sin contar documentos u otros archivos sin comprimir. Si dicha información estuviera comprimida la velocidad de descarga de las páginas sería mucho mayor, sobre toda en aquellas donde se muestra mucho contenido html como en formularios o tablas. Aquí es donde entra la técnica de HTTP Comprimido, el servidor envía toda la información al cliente comprimida y el cliente la descomprime, por supuesto ésta forma de trabajo debe ser soportado por servidor y cliente, en éste último caso es donde hasta hace un par de años habían muchos problemas porque los navegadores no lo soportaban adecuadamente o decían que lo soportaban cuando en realidad no lo hacía, pero en la actualidad la gente dispone de navegadores con todo el soporte adecuado y ya no es una excusa para no usarlo.
No hay problema con las imágenes pues normalmente están en formato comprimido como jpf o gif, sin considerar el cuidado que debe tener el diseñador para usar imágenes de poco peso. Sin embargo gran parte de la información que se envía son los documentos html que al fin y al cabo son texto, sin contar documentos u otros archivos sin comprimir. Si dicha información estuviera comprimida la velocidad de descarga de las páginas sería mucho mayor, sobre toda en aquellas donde se muestra mucho contenido html como en formularios o tablas. Aquí es donde entra la técnica de HTTP Comprimido, el servidor envía toda la información al cliente comprimida y el cliente la descomprime, por supuesto ésta forma de trabajo debe ser soportado por servidor y cliente, en éste último caso es donde hasta hace un par de años habían muchos problemas porque los navegadores no lo soportaban adecuadamente o decían que lo soportaban cuando en realidad no lo hacía, pero en la actualidad la gente dispone de navegadores con todo el soporte adecuado y ya no es una excusa para no usarlo.
