La distribución más popular, Ubuntu, a través de su empresa matriz, no podía dejar de comentar el lanzamiento del que puede convertirse en breve en su mayor: rival/aliado. La nota que a continuación os dejo, apareció hace un par de días en el blog oficial de Canonical y como no he tenido tiempo de traducirla hasta hoy, no la he publicado. Sigue siendo plenamente actual pese a eso.

La nota traducida (espero que no demasiado mal, acepto y agradezco correcciones) a continuación:

Felicitamos a Google en el lanzamiento del código de Google Chrome OS.

Cuando Chrome se anunció en Junio, Canonical lo vio como un desarrollo positivo, que traía más opciones al consumidor. Consideramos que el desarrollo de software libre es una forma de cooperación a la vez que una forma de competencia. Google ha dejado claro que están dispuestos a desarrollar Chrome como un sistema operativo abierta y hemos tenido el placer de acoger a un buen número de desarrolladores de la compañía en la cumbre de desarrolladores de Ubuntu que tuvo lugar en Dallaslos últimos días, donde hemos apreciar la transparencia del desarrollo.

En aras de la transparencia, comentaros que Canonical está contribuyendo al proyecto de Google a través de un contrato firmado por ambas partes. En nuestras charlas, Sundar Pichai y Linus Upson dejaron claro que ellos quieren, siempre que sea posible, desarrollar sobre los componentes y los instrumentos existentes de la comunidad de código abierto para evitar la reinvención. Esta idea central debe beneficiar a variedad de proyectos existentes y por lo tanto le damos la bienvenida.

Su autor, Chema Martín, hace un repaso a las cinco distribuciones o distros más populares de Linux: Ubuntu, Mandriva, OpenSuSE, Mint y Fedora.

Aunque es un artículo dirigido para principiantes, os recomiendo encarecidamente su lectura.

Enlace: Distros Linux: guía básica.

• Descargar una imagen para VMWare lista para ejecutar
• Compilarlo (Google recomienda Ubuntu)

Construir lighttpd desde cero es un poco más complicado, ya que depende de otras bibliotecas. Como mínimo, necesita la versión de desarrollo (la versión que incluye los archivos de cabecera) de expresiones regulares compatibles con la biblioteca de Perl (PCRE) y la herramienta de compresión zlib. Después de haber instalado estas bibliotecas, la compilación de lighttpd es sencilla:

$ # Lighttpd requires libpcre3-dev and zlib1g-dev
$ wget http://www.lighttpd.net/download/lighttpd-1.4.24.tar.gz
$ tar xzf lighttpd-1.4.22.tar.gz
$ cd lighttpd-1.4.22
$ ./configure && make && sudo make install

Una vez compilado, hemos de crear nuestro archivo de configuración. La configuración más minimalista posible establece la raíz del documento (document root), el puerto del servidor (server port), algunos tipos MIME (Multipurpose Internet Mail Extension), el usuario por defecto (default user) y un grupo para el demonio (daemon):

server.document-root = “/var/www/lighttpd/miDirectorioHost”
server.groupname = “www”
server.port = 80
server.username = “www”

mimetype.assign = (
“.html” => “text/html”,
“.txt” => “text/plain”,
“.jpg” => “image/jpeg”,
“.png” => “image/png”
)

static-file.exclude-extensions = ( “.fcgi”, “.php”, “.rb”, “~”, “.inc” )
index-file.names = ( “index.html” )

Considerando que hemos guardado nuestro archivo de texto como /opt/etc/lighttpd.conf, para lanzar lighttpd bastará con invocarlo y pasarle dicho archivo de configuración:

lighttpd -D -f /opt/etc/lighttpd.conf.

Al igual que Apache, lighttpd puede servir servidores vituales (virtual hosts). Y en solo tres líneas y usando un condicional:

$HTTP["host"] == “www2.linuxhispano-ejemplo.net” {
server.document-root = “/var/www/lighttpd/miDirectorioHostVirtual
}

De esta manera, si accedemos www2.linuxhispano-ejemplo.net, usaremos la alternativa planteada.

Lighttpd es especialmente hábil en el manejo de un gran número de peticiones en paralelo. Y al igual que Apache, podemos usarlo conjuntamente con Ruby on Rails (RoR), PHP, etc.

Artículos relacionados.
Artículo original en  IBM Developer Works.

El estado en el chat de Gmail (puntos verdes, naranjas y rojos) nos indican los amigos que están conectados y en que estado, el problema reside en que en ocasiones nos podemos encontrar a nuestros amigos en verde cuando realmente no están delante, simplemente tienen el chat abierto en su terminal Android y no lo están usando.

Ahora, con el nuevo experimento de Gmail Labs, podremos ver (si lo activamos) un icono con forma de robot junto a las personas que lo están utilizando desde un Android. En la imagen se observa cómo Shirley está en línea con Android, Nicolle R. es usuario de Gmail que no está online, y Chris I. está ausente, pero también en Android.

Este tipo de mejoras hacen que podamos decidir si la conversación que vamos a mantener con estas personas sea de una forma u otra dependiendo de que sistema esté utilizando, evidentemente tardará más en respondernos desde un terminal móvil, por ejemplo.

Cuando estos contactos vuelvan a conectarse por el método tradicional desde el ordenador, volverán a tener su estado de la misma manera. Pruébalo, creo que merece la pena.

Vía The Official Gmail Blog.

¿Algo que añadir?

Muy en línea con un tema de actualidad a día de hoy, como podéis ver en la Tira, vamos a hablar de ese mismo comando, sudo y sus variantes para entorno gráfico: gksudo y kdesudo.

¿Qué es sudo en realidad?

Es un programa que permite ejecutar programas con los privilegios de seguridad de otro usuario. Normalmente como el root, o superusuario. De hecho sus siglas vienen de superuser do aunque hay otras versiones que dicen que es en realidad substite user do.

Es necesario para multitud de aplicaciones y es más que conocido para todo aquel que trabaje con la terminal.

¿Y gksudo y kdesudo?

Imaginad que estáis usando el navegador de ficheros de Gnome, Nautilus, y necesitáis borrar un directorio, para cuyo borrado es necesario ser superusuario. La primera opción es utilizar sudo en la terminal pero desde luego puede resultaros mucho más cómodo ejecutar (en Ubuntu Alt + F2) gksudo nautilus y de esta manera hacer lo mismo que haríamos con sudo pero en el entorno gráfico. Los usuarios de KDE tienen su aplicación homóloga: kdesudo.

Un ejemplo típico de gksudo es cada vez que abrís Synaptic desde el menú de Sistema en Ubuntu. Aunque vosotros no lo veáis, el elemento del menú incluye gksudo en su llamada.

Para terminar un ejemplo de sudo que nunca deberéis utilizar

Por si no conoces todavía el mundo del podcasting, te recomiendo dos cosas:

• Leerte esta entrada de la Wikipedia
• Y suscribirte a nuestro podcast

Volviendo a lo que íbamos, os comento que a través de esta noticia aparecida en Ubuntips me entero que los LoCosHispanos, las comunidades locales de Ubuntu,  ha creado un podcast de publicación periódica y en habla hispana, con una duración que variará de los 45 minutos a 1 hora.

El enlace a la descarga del primer capítulo lo tenéis aquí.

• Notas del lanzamiento en español
• Guía de instalación en español
• Resumen guía de instalación e inicio rápido
• Descarga

Me complace anunciaros que Linux Hispano ya dispone de versión accesible desde vuestro terminal móvil, para ello bastará que accedáis como hasta ahora a http://www.linuxhispano.net y seremos nosotros los que detectaremos si el navegador usado corresponde con el de un terminal móvil, para ello se hace uso del User Agent. Para ver el User Agent de tu navegador haz clic aquí.

Las capturas corresponden a la versión renderizada para Android 2.0. Si tenéis alguna duda, sugerencia o problema no dudéis en comentarlo.

Cómo revertir un commit errado en Subversion por Checho.

Pista: Se trata de un navegador.

Para el que no lo entienda: microsoft patenta sudo

Las entradas de un blog no serían lo mismo si no tuvieran fotografías. En ciertos temas, no es que sean recomendables, sino necesarias. ¿Os imagináis un blog de viajes o de coches sin imágenes? Esta necesidad está cubierta por una serie de soluciones, cada una con sus pros y sus contras que cada blogger sopesa, valora y finalmente elige.

Existen básicamente cuatro alternativas:

• Utilizar tu propio equipo como servidor.
• Enlazarlas desde otro sitio web, el llamado, y nada recomendable, hotlinking o inline linking (hay una entrada en la Wikipedia muy interesante sobre el mismo, pero está en inglés).
• Utilizar un servicio externo: Imageshack o Flickr son buenos ejemplos de ello.
• O utilizar tu propia cuenta en un  servidor externo, donde tengas alojada la web.

¿Ventajas, inconvenientes y limitaciones de las dos últimas?

La primera y la cuarta están relacionadas en buena parte, pero considero que alojar y administrar un servidor propio (con las líneas que hay en España) con un número de visitas relativamente elevado en un ADSL/similar casero, no es demasiado factible (seguro que más de uno lo hace y no tiene problemas. Si pudiera comentar cómo hace para balancear la carga y rentabilizar al máximo de la administración del servidor lo agradecería).

La segunda directamente no la tratamos por considerarla perjudicial para toda la comunidad, en nuestra versión anterior hacíamos uso de ella en ocasiones y os puedo asegurar que te arrepientes, no sólo por chupar ancho de banda a un tercero, sino porque te quedas sin servicio en ocasiones.

Bueno vamos a lo que íbamos.

Servicios externos

La opción de utilizar un servicio externo como puede ser Flickr o Imageshack. Las ventajas son principalmente:

• Ahorro de espacio en disco en el servidor.
• Ahorro de ancho de banda de transferencia en el servidor.
• Posibilidad de utilizar herramientas del servicios que nos sean de utilidad.

Sin embargo, hay otros inconvenientes a valorar:

• Dependencia de un tercero (estos dos servicios son bastante sólidos, pero siempre pueden estar caídos en algún momento, aunque posiblemente se caigan menos que tu propio servidor).
• Necesidad de subir las imágenes al servicio (este en el fondo también pasa también en el otro caso).
• Posibilidad de tener que realizar un pago, si llegamos a un determinado límite.

El segundo punto es fácilmente resoluble con el uso de aplicaciones como:

• ImageShack.us Uploader, del que hoy mismo hablan en Ubuntips.
• JUploadr para Flickr

En el mismo sitio que tienes alojado el sitio

Más o menos podríamos decir que los pros y contras son justos lo contrarios, pero no es del todo así. Veamos, primero los pros.

• Posibilidad de subir directamente las imágenes por FTP o en nuestro propio equipo copiando y pengando directamente.
• Las imágenes y la web, estarán caídas (o no) al mismo tiempo. No habrá imágenes que no aparezcan porque falle algo externo.
• Hay algunos CMS, como WordPress que implementan funcionalidades para subir y tratar las imágenes.
• Subir las imágenes es gratuito (los límites son los de nuestra cuenta o equipo).

Las desventajas empiezan por ahí:

• En nuestro propio equipo, el límite lo marca nuestra línea y nuestro disco duro, pero en una cuenta externa, el límite viene muchas veces marcado por lo que pagamos.
• Subir las imágenes por FTP/SFTP puede llegar a ser bastante más fastidioso que hacerlo por alguna de las aplicaciones que antes comentábamos.

Más que probablemente podáis comentar mucho más sobre el tema de vuestra experiencia personal sobre un problema que nos afecta a todos los que de una manera u otra, editamos contenido en un sitio web.