Linux en tu USB

Sin duda uno de los grandes inventos de los últimos tiempos (a nivel de usuario de informática) es el de los famosos pen drives. ¿Quién no posee uno? ¿Quién no lo lleva casi siempre consigo?. Son ciertamente bastante útiles. En este post voy a citar algunas distribuciones Linux que caben en uno de estos fantásticos aparatitos:

Damn Small Linux:
Damn Small Linux tiene un tamaño de 50 MB. A pesar de su reducido tamaño tiene un desktop bastante funcional y de uso muy fácil. Entre sus caracterí­sticas se pueden citar las siguientes:desktop casi completo que incluye XMMS (MP3 y MPEG), cliente FTP, Dillo web browser, Sylpheed email, un procesador de palabras (Ted-GTK), cuatro editores (SciTe, nVi, Zile [emacs clone], y Nano [Pico clone]), edición de gráficos y visualización (Xpaint y xzgv), Xpdf, emelFM (gestor de ficheros), Naim (AIM, ICQ, IRC), VNCviwer, Rdesktop, servidor y cliente SSH/SCP , cliente DHCP, PPP, PPPoE (ADSL), un servidor web, calculadora, soporte de impresora genérico y GhostScript, NFS, juegos, aplicaciones de monitorización del sistema, soporte pcmcia, algo de soporte para wireless, etc.

Más información en http://www.damnsmalllinux.org

Feather Linux:
Feather Linux tiene un tamaño de 64Mb. Está basado en Knoppix , e intenta incluir software que la mayoría de la gente utiliza diariamente. Características:Kernel 2.4.26, Ted, ABS, Dillo, XMMS y plugins, wavplay, mpg321, ogg123 , Sylpheed, axyFTP, emelFM, cdrecord, mkisofs, rdesktop, tcpdump, parted, partimage, aircrack, madwifi, dnsmasq, foremost, antiword, e2undel, iftop, bbpager, utelnetd, minicom, index, gpart, socat, traceroute, SciTE, prozilla, Midnight Commander, Samba, elmo, tmsnc, apsfilter, mplayer, mount.app, chntpw, zile, tinycc, nano, Xpaint, Xzgv, Xpdf, naim, hdparm, usbview, index, recoverdm, mtr, cdparanoia, betaftpd, Mutella, Chipmunk Basic, gqcam, e3, lua, ettercap, wavemon, iptables, recover, amap, hping2, cabextract, splitvt, pciutils, LinNeighborhood, nmap y nmapfe, portmap y nfs-common, aumix, CTorrent, VNCviewer, sqlite, cliente SSH y SCP, cliente DHCP, xtdesktop, soporte para PPP y PPPoE support, un lector RSS , stress, cpuburn, servidor web Monkey , Xcalc, Fluxbox, evilwm, etc.

Más información en http://featherlinux.berlios.de

Flonix:
Flonix USB Edition 1.0 es un sistema operativo nuevo que corre desde unidades USB 2.0. Es perfecto para aplicaciones de ofimática, multimedia, PC’s sin disco, demos, etc

Más información en http://www.flonix.com

Flash Puppy:
La diferencia con otras distribuciones es que se carga completamente en RAM. Incluye cantidad de software, entre el que se incluye Firefox.

Más información en http://www.goosee.com/puppy/flash-puppy.htm

Personalizar la barra de scroll

Problemas en BdW

Octubre para BdW ha sido un mes de cambios. Primero estreno de la nueva dirección www.bitacoradewebmaster.com.
Después nuevo hosting. Y ahora…estreno de nuevo servidor. Algunas de sus características:

• PowerEdge 1850 Xeon 2.8Ghz/1MB, 800FSB

• PROMO - FREE 2ND PROC - 2.8DP
• PCIX RiserCard - with ROMB support
• 4GB Single Rank DDR2 Memory (4×1GB)
• Additional Xeon 2.8GHz/1MB 800Mhz FSB processor
• 73GB SCSI Ultra320 (10,000rpm) 1in 80 pin Hard Drive
• PERC 4di Embedded RAID Option
• C03 MR1, RAID 1, Using Motherboard Raid (2 Hard Drives)

Sentimos mucho las incidencias de los últimos días, pero son problemas ajenos a BdW, y esperamos que pronto sean subsanados todos los problemas técnicos y se pueda acceder a los contenidos con toda normalidad.

Editor w.bloggar

¿En realidad es bueno seguir los estándares del W3C?

La respuesta evidentemente es afirmativa, pero antes de adentrarnos en la especificación de los distintos beneficios que nos aporta seguir los estándares en el desarrollo web, definamos el término estándar, según la RAE tenemos que:

adj. Que sirve como tipo, modelo, norma, patrón o referencia.

Habiendo definido el término, apliquémoslo al mundo del desarrollo web, los estándares del W3C deben seguirse como un patrón, dicho consorcio se encarga de establecer las normas a seguir por los desarrolladores con el fin de generar un bien común, evitando en lo posible que ciertas compañias impongan algunas etiquetas o métodos no convencionales que solo servirán en un navegador o Agente de Usuario, lo anterior ha sucedido con compañias como Netscape o Microsoft, principalmente cuando se estableció entre ambas compañias la "guerra" por liderar el mercado de los navegadores, impusieron ciertas etiquetas no estándares que en vez de generarle un bien a la WWW lo complicó aún más. ¿Se imaginan desarrollar un documento XHTML para cada Agente de Usuario existente en el mercado?, se generarían excesivos gastos en la producción y la pérdida de tiempo no se podría cuantificar, la idea de seguir los estándares es que un solo documento pueda ser visualizado en todos los Agentes de Usuario existentes.

Al seguir los lineamientos de los estándares lograremos:

• Separar el contenido o estructura del documento XHTML de la presentación o diseño del mismo.
• Reducción en la cantidad de código XHTML.
• Facilidad en el cambio del diseño del documento, ofreciendo una mayor flexibilidad.
• Mejoramos la semántica de nuestros documentos y por ende brindamos una mayor accesibilidad al mismo.
• Basta un solo documento para todos los agentes de usuario existentes.

Debemos recordar que el "antiguo" lenguaje HTML fue concebido como un lenguaje de marcas para la presentación de documentos científicos, en otras palabras, nació como una abstracción del lenguaje que se llevaba en las imprentas, en donde los editores colocaban "marcas" en los documentos, por ejemplo, el título de la página, los posibles subtítulos, los párrafos, etc. Para colocarlo en términos simples, los editores de las imprentas no pensaban en un título de color rojo, un párrafo indentado, definitivamente no era ese su estilo de marcas. Para el diseño o presentación de los documentos XHTML recurriremos a las fabulosas hojas de estilos en cascada o CSS, en las cuales a tráves de unas reglas nos permitirá controlar tanto el posicionamiento de los elementos en nuestros documentos así como también nos permite controlar la presentación de los mismos.

Un tema en el que se debe hacer hincapíe es en el mal uso de las tablas, al emplearlas para maquetar los documentos, es uno de los errores más cómunes en los desarrolladores que aún siguen la vieja escuela. La presentación de los documentos a través del empleo de las tablas para la maquetación se ha venido convirtiendo en un abuso real de este principio tan importante. Hace ya algunos años atrás, diseñadores web sintieron la necesidad de usar tablas para crear complejas presentaciones. Este hack de usar tablas y pequeñas imágenes transparentes para la creación de presentaciones hacían estas páginas interesantes en el aspecto visual, pero todo esto iba en contra de la accesibilidad y usabilidad, este legado aún se mantiene en gran parte del desarrollo web. Hasta hoy día, el lema, si funciona, es bueno domina el diseño web. Realmente se debe dejar atrás esta actitud, y mantener en mente la importancia de los principios accesibilidad y usabilidad, haciendo uso apropiado de los recursos estándar para el desarrollo web.

Las tablas en HTML no existen para propósitos de presentación, pero si para representar datos de manera tabular. Algunos ejemplos incluyen listas de productos, cursos disponibles en la escuela, colegio o la universidad, y los calendarios. En este tipo de información será en la que es realmente útil el uso de las tablas.

A continuación se dará una breve explicación de los beneficios obtenidos al seguir los lineamientos del W3C.

Reducción en la cantidad de código necesario

Doug Bowman nos demuestra en su presentación The beauty and business of CSS, especificamente en la sección Wired News: file size reductions como se logró reducir el tamaño de los archivos, en el caso de la portada de Wired News la reducción fue de un 54%, esto genera un ahorro en el ancho de banda, en la medida de lograr lo anterior se obtienen ciertos beneficios, entre ellos podemos mencionar el incremento en la capacidad y eficiencia de respuesta del servidor, carga más rápida de las páginas, entre otras. En el caso expuesto de ESPN las estadísticas llaman aún más la atención, el ahorro estipulado por página se considera alrededor de los 50 KB, ESPN tiene aproximadamente unas 40 millones de visitas por día, por lo tanto se prevee que el ahorro diario en ancho de banda se acerca a los 2 Terabytes por día, en un mes serían 61 Terabytes, en un año serían aproximadamente 730 Terabytes o equivalententemente unos 784.000.000.000 KB. Si esto ya le parece demasiado prepárese para lo mejor, el caso de estudio hecho a Microsoft realizado por el mismo Doug Bowman.

Un solo documento para todos los Navegadores o Agentes de Usuario

En el caso de estudio mencionado previamente se puede notar que Microsoft mantiene 2 versiones en sus documentos, una versión para IE5.5 e IE6.0 para Windows y la otra versión con menos detalles para los demás navegadores, esto genera un costo de producción y pérdida de tiempo, la solución es apegarse a los estándares.

Separar el contenido o estructura del documento del diseño o presentación del mismo

Simplemente basta con visualizar el proyecto comenzado por Dave Shea llamado CSS Zen Garden, en él se puede observar que se emplea un solo documento bien estructurado en XHTML y se pueden aplicar al mismo documento distintos estilos controlados vía CSS. Además, cabe mencionar que si controlamos nuestros documentos a través de hojas de estilos en cascada externas estas sólo necesitarán cargarse la primera vez que son invocadas, posteriomente no será necesaria su carga ya que quedan almacenadas en el cache del navegador, esto realmente es una ventaja.

Este artículo es una breve introducción sobre los beneficios que nos aporta el seguir los estándares en el desarrollo web, el objetivo de este documento es difundir su uso.

Antes de finalizar quisiera recomendarles el hecho de válidar nuestros documentos, para ello les recomiendo:

• Servicio de Validación del W3C.
• Servicio de Validación del WDG (Mi preferido).

Referencias:

• World Wide Web Consortium
• Real Academia Española
• Zen and the Art of Web Improvement por Dave Shea.
• Designing with CSS: Past, Present, and Future por Dave Shea.
• The beauty and business of CSS por Doug Bowman.
• Pushing Your Limits (and other secrets of designing with CSS) por Doug Bowman
• CSS Zen Garden

Hurd

Todo el mundo ha oído hablar de GNU, pero … ¿conocéis Hurd?.

La FSF (Free SoftwareFoundation) y su proyecto GNU siguen trabajando en su proyecto de
acabar un sistema operativo completo. Cabe recordar que el proyecto GNU tení­a como principal objetivo conseguir un clon UNIX de software libre, y las utilidades GNU sólo son el software de sistema necesario. A partir de 1991, cuando Linus consigue conjuntar su kernel con algunas
utilidades GNU, se dio un primer paso que ha acabado en los sistemas GNU/Linux actuales. Pero el proyecto GNU sigue trabajando en su idea de terminar el sistema completo. En este momento disponen ya de un núcleo en el que pueden correr sus utilidades GNU. A este núcleo se le denomina Hurd; y a un sistema construido con él se le conoce como GNU/Hurd.

No lo he probado, aunque me muero de ganas de hacerlo. Si os lo bajais y probais, por favor, hacerlo saber y comentad que os parece.

Más información:

http://www.gnu.org/software/hurd/hurd.html

Acceso remoto a nuestro equipo

He encontrado un artículo de Raul Serrano que nos explica como acceder de forma remota a nuestro equipo desde cualquier máquina conectada a Internet siempre y cuando tengamos Windows XP. El acceso se realiza desde Internet Explorer (navegador de Windows), por lo que no hay que instalar ningún software adicional en el cliente, como podrí­a ser el Cliente de Terminal Server de Microsoft. Podemos entrar pinchando aquí­.

Minuta del Webmaster Mejorada

1. TC es el coeficiente corrector de Tipo de Cliente (Nuevo=0.9, Habitual=1 ó Preferente=0.95).
2. DP es el coeficiente corrector de la Duración del Proyecto (Corta=1, Media=0.95 ó Larga=0.9).
3. DiP es el coeficiente corrector de la Dificultad del Proyecto (Baja=0.9, Media=0.95, Alta=1).

Aquí te puedes descargar la hoja de cálculo que ha desarrollado BdW, que facilita la obtención del presupuesto, con tan sólo introducir los datos del proyecto. Junto con la versión 1.1, te descargarás la 1.2 con la que ha contribuido nuestro amigo Alejandro Archila Celis añadiéndole algunas mejoras.

Firefox 1.0 RC1 liberada

Para los que padezcan versionitis: se ha liberado la primera versión candidata del Mozilla Firefox 1.0 (hasta ahora tení­amos la Preview Release version). Esá¡ disponible para su descarga ví­a FTP. Realmente, no es una actualización muy necesaria, ya que las versiones candidatas suelen servir para corregir fallos con respecto a las versiones definitivas. De hecho, desde Mozilla piden su uso para reportar fallos a mejorar en la versión definitiva. En el caso del Firefox, quedan un par de semanas para la primera versión oficial (prevista para el 9 de noviembre, aunque se retrasará unos dí­as). Lo que sí­ os puedo adelantar es que en esta RC1 se han corregido 250 bugs sobre la anterior.

Y una curiosidad para los que gusten de este navegador: Firefox NO es un zorro; es un panda rojo.

Los servlets y Apache

Aunque se trate de un tema un tanto trillado ya, me he animado a realizar este post. ¿ Cómo podemos ejecutar servlets haciendo uso de Apache ?. Bueno, voy a centrarme en linux (que es lo que conozco un poco) aunque para Windows tampoco tiene demasiados cambios creo.

Necesitamos:

1 - Debemos tener instalado JDK en nuestro servidor. Pues nada nos vamos a la web de Sun, descargamos la última versión, instalamos y configuramos.

2 - Tomcat. Es un contenedor de servlets, que puede funcionar también como servidor web (no será nuestro caso) y que forma parte del proyecto Jakarta de Apache. Nos podemos descargar las fuentes de http://jakarta.apache.org/site/sourceindex.cgi o bien el binario http://jakarta.apache.org/site/binindex.cgi. El binario va bien.
Instalamos y configuramos. CATALINA_HOME será una variable de entorno que contendrá el camino de instalación de Tomcat. Por supuesto comprobar que Tomcat está arriba mediante http://localhost:8080 (por defecto)

3 - Aquí viene lo interesante de esto: el conector jk. Existen dos versiones jk 1.2 y jk2. Yo he probado la primera. El funcionamiento es el siguiente: Apache recibe una petición para ejecutar un servlet o jsp bien mediante http o https; Apache pasa esta petición a Tomcat que lo ejecuta y devuelve el resultado a Apache y a su vez al usuario final. ¿ Qué relaciona Apache y Tomcat ? Pues el conector jk.

Bueno vamos a ponerlo en marcha:

- como requisitos previos debemos tener instalados autoconf, automake y libtool.

- descargamos las fuentes de http://jakarta.apache.org/site/sourceindex.cgi
- descomprimimos fichero donde estimemos oportuno
- cambiamos al directorio_creado/jk/native
- ejecutamos:
./buildconf.sh
./configure –with-apxs=path_a_apxs
make

- Copiamos desde /jk/native/apache_versionx el fichero mod_jk.so generado al directorio de modulos de Apache

- editamos $CATALINA_HOME/conf/workers.properties con el contenido:
worker.list=ajp13 # define la lista de workers
worker.ajp13.port=8009 # define el puerto en el que escucha
worker.ajp13.host=localhost # el nombre del host
worker.ajp13.type=ajp13 # el protocolo que utiliza (hay dos ajp12 y ajp13), evidentemente el último más reciente

En el ejemplo anterior el worker se llama igual que el protocolo.
Un worker es una instancia de Tomcat que está en espera de ejecutar un servlet. Podemos definir varios pero con uno bastará para un entorno de trabajo medio.
- Editar el fichero de configuración de Apache y añadimos las siguientes directivas en las zonas adecuadas:
LoadModule jk_module modules/mod_jk.so
AddModule mod_jk.c
JkWorkersFile $CATALINA_HOME/conf/workers.properties
JkLogFile /log/mod_jk.log
JkLogLevel warn # o cualquier otro nivel de log (debug, info, …)

- Sobre el virtual host que queramos o en la definición general del servidor añadiremos directivas JkMount que redireccionan las peticiones de ejecución de servlets a tomcat. La sintaxis es: JkMount URL worker. Por ejemplo: JkMount /*.jsp ajp13 , redirecciona todas las peticiones de ejecución de jsp’s a Tomcat mediante el worker ajp13 cuya definición se realizó en el fichero $CATALINA_HOME/workers.properties anteriormente.

- Si no utilizamos el puerto 8080 para nuestro servidor web ya no tendremos que hacer nada más. Si no tendríamos que tocar el fichero $CATALINA_HOME/serverl.xml y cambiar el puerto a otro. Por defecto Tomcat utiliza el 8080.

Pues hasta aquí llego, ya solo queda que hagamos pruebas de petición de ejecución de jsp’s a nuestro sufrido servidor Apache.

Más información:

de partida para Tomcat, http://jakarta.apache.org/tomcat/index.html

para los conectores,
http://jakarta.apache.org/tomcat/connectors-doc/jk2/index.html
http://johnturner.com/howto/apache-tomcat-howto.html
http://www.onjava.com/pub/a/onjava/2002/11/20/tomcat.html
http://www.osmosislatina.com/apache/java.htm