El ecosistema PHP ha estado bastante convulso en los últimos tiempos con la publicación de PHP 5.3, que supone la inclusión de varias novedades y un pequeño punto de ruptura. Pero éste es el pistoletazo de salida para una revolución cuyos primeros visos de cambio aparecen con la creación del primer, y hasta el momento único, estándar de facto de la comunidad PHP.

Pero sin duda, el gran empujón lo supone la segunda versión del framework Symfony. Partiendo desde cero con un diseño arriesgado y diametralmente opuesto al previo ha sabido reinventarse completamente. Incorporación de los últimos patrones, integración de componentes existentes y porte/adaptación de grandes soluciones ya inventadas, aunque fueran en el seno otras comunidades, son los pilares de este framework.

En artículos sobre PHP empiezan a surgir términos como inyección de dependencias/inversión de control, assets, event dispatcher, pruebas, behavior driven development… cosas lejanas o completamente inimaginables en la comunidad PHP cuando escribí el artículo previo. Y no sólo es esta evolución sino la pequeña constelación de proyectos que han surgido alrededor es realmente sorprendente y un impulso notable. Proyectos como Assetic, Behat, Monolog, Twig… portan las mejores ideas y soluciones de otras comunidades.

Grandes conocidos ya se han subido al tren: PhpBB fue el primero que decidió desarrollar PhpBB4 sobre el sistema y la comunidad de Drupal está integrando componentes de Symfony 2 en Drupal8. Aunque aún falta camino para llegar al utópico mundo en el que es posible rehusar el código de todas los grandes proyectos para montar tu sistema a medida, se han dado los primeros pasos en esa dirección.

Por ello, en lugar de un artículo desdiciendo lo que publiqué hace ya casi tres años, he decidido iniciar el 2012 con una nueva serie: Desarrollo de aplicaciones en PHP. La idea es cubrir las mejores prácticas, los puntos no documentados o trucos variados mientras desarrollo un par de aplicaciones sobre el Symfony 2.

The concert hall at the Sydney Opera House holds 2,700 people. This blog was viewed about 43.000 times in 2011. If it were a concert at Sydney Opera House, it would take about 16 sold-out performances for that many people to see it.

Jamás habría pensado en intentar llenar el auditorio de Sydney y mucho menos 16 veces

Para completar este informe, voy a dar un par de pinceladas extra. Mi año se puede resumir en pocas palabras: intenso, agotador y cambio.

Profesional: Magerit2 alcanza el nº1 de España

El evento con mayúsculas fue la actualización del supercomputador Magerit que se convirtió en el más potente de España al alcanzar el puesto 136 en la lista de junio de 2011 del TOP500. Pero además alcanzó el puesto 18 en la lista Green500.

La actualización se realizó en tan solo dos meses (el vídeo sólo cubre unos 10 días de recepción de material y montaje físico, no se muestra la instalación y configuración del software) pero supuso una ingente cantidad de trabajo antes (planificación), durante (montaje, instalación y configuración) y después (adaptación de sistemas). Aún colean bastantes flecos de sistemas que precisan adaptación ya que el nuevo sistema cambia prácticamente todo: sólo se mantiene el concepto.

Personal: Mudanza en la cabeza

En lo relativo más a lo personal, es el año de los cambios de mentalidad: he modificado muchos de mis gustos, ideas preconcebidas y rutinas.

He cambiado mis herramientas de Maxthon a Chrome, Zend Framework por Symfony, de emacs a vim o Eclipse por Netbeans, por poner algunos ejemplos.

He pasado de no entender el concepto iPad a poseer y exprimir uno de ellos de forma intensiva.

He subido a la “nube” aunque con reticencias.

He rediseñado mi escritorio (tanto el físico y el virtual) reduciéndolo a lo imprescindible.

He logrado mantener el zero-inbox.

He cambiado mis fuentes de información de TV y periódicos a redes sociales (mayoritariamente Twitter) y feeds.

He pasado de ver la TV a leer mientras escucho la radio.

Y, sin duda lo más difícil, me he deshecho de un montón de cosas viejas (sobre todos, apuntes, libros y cachivaches varios) que nunca utilizaré.

Por serendipia, mientras curioseaba entre las opciones de un iOS5, he acabado en un menú de las opciones de localización (Localización > Servicios del sistema). Entre las opciones aparece “Icono en la barra de estado”, que permite mostrar un icono (un triangulito) en la parte superior derecha al lado del porcentaje de batería, como desactivado. Y, como no puedo quedarme quieto, lo he activado.

Opciones de Localización > Servicios del sistema con sus valores por omisión en iOS5.

Automáticamente ha aparecido el icono, como si alguna aplicación estuviera usando el servicio de localización en ese momento. Era un poco desconcertante: ninguna de las aplicaciones abiertas debía estar usándolo. Pero, además, sólo debería aparecer si la aplicación en primer plano lo usa, aunque puede que eso hubiera cambiado.

Empecé a cerrar las aplicaciones abiertas, y el icono seguía indicando que algo estaba usando la localización, hasta que no quedó nada abierto: la localización seguía activa. Abrí las opciones de localización para aplicaciones y ninguna aplicación tenía el icono violeta indicando un uso en el momento, pero el icono general seguía insistentemente al lado del de la batería.

Finalmente, descubrí el causante: al retornar a la pantalla en la que había desencadenado esta situación, descubrí que el servicio de zona horaria tenía el icono violeta, indicativo de que estaba utilizando la localización. Tras inhibir el acceso a la localización el icono general desaparece instantáneamente comportándose como en la versión anterior.

Parece que este comportamiento se debe al ajuste automático de fecha y hora (posiblemente, algún tipo de NTP) y, de hecho, si se desactiva dicho ajuste, pasando al modo manual, también desaparece el icono de localización activa. Una posible explicación es que iOS5 está determinando la ubicación del dispositivo para conocer la zona horaria en la que se encuentra y ajustar adecuadamente el reloj. Esta detección automática podría ser de interés en algún caso, pero no para la mayoría que no suelen cambiar de franja horaria prácticamente nunca.

Por si fuera poco, parece que la localización de la zona horaria podría ser la causante de la reducción en la autonomía de la batería de los dispositivos iOS5. Salvo en los casos que se viaje mucho cambiando de zona horaria, puede ser una buena idea desactivarlo ya que no se pierde funcionalidad y puede que se prolongue la duración de la batería.

¡Ayuda! ¡Linux se come mi RAM!

En varias ocasiones me han preguntado, o usado como argumento en contra, por qué en las últimas versiones de los sistemas operativos no queda casi RAM libre y está siempre ocupada. Las variantes son múltiples: “No me queda memoria libre”, “la nueva versión de Windows es peor me consume toda la memoria”…

Finalmente, alguien ha decidido dar respuesta a esta pregunta centrándose en Linux pero, desgraciadamente, en inglés. Este artículo es una traducción libre de Help! Linux ate my RAM!.

Preguntas y respuestas

¿Qué sucede?

Linux está “prestando” la memoria no asignada a la cache de disco. Por esto parece que el equipo está bajo de memoria pero no es así ¡Todo está bien!

¿Por qué hace eso?

La cache de disco hace que el sistema sea mucho más rápido. No existen inconvenientes, a excepción de la confusión que genera. No le quita memoria a las aplicaciones de ninguna manera.

¿Qué pasa si quiero ejecutar más aplicaciones?

Si las aplicaciones necesitan más memoria, se devuelve un bloque prestado a la cache de disco. La memoria ocupada por la cache de disco se puede devolver a las aplicaciones inmediatamente.

¿Necesito incrementar la swap?

No, la cache de disco sólo toma prestada la RAM que no está siendo usada por las aplicaciones. No utiliza swap. Si las aplicaciones necesitan más memoria, se utiliza parte de la cache de disco y no harán swapping.

¿Cómo puedo evitar que Linux haga esto?

La respuesta corta: No se puede deshabilitar la cache de disco.

La única razón que alguien puede tener para deshabilitar la cache de disco es porque piensan que está reduciendo la memoria disponible para las aplicaciones ¡pero no es así!

La caché de disco hace que las aplicaciones carguen más rápido y ejecuten de forma más fluida, pero nunca jamás limita la cantidad de memoria de las aplicaciones.

Por eso no existe ninguna razón para deshabilitarla.

¿Por qué top y free indican que toda mi RAM está utilizada si no es así?

Es sencillamente una confusión de términos.

Todos, incluido Linux, coincidimos en que la memoria asignada a aplicaciones está “usada” mientras que la memoria no asignada a nada está “libre”. El problema es ¿cómo denominamos a la memoria que está utilizada para algo pero disponible para aplicaciones?

Nosotros respondemos “libre” mientras que Linux la considera “usada”

Memoria	Persona	Linux
Asignada aplicación	Usada	Usada
Asignada “algo” (no aplicación)	Libre	Usada
No asignada	Libre	Libre

Ese “asignada en algo” es lo que top y free denominan “buffers” o “cached“. Como nuestra terminología y la de Linux difieren, se genera esta confusión.

¿Cómo puedo ver cuánta memoria RAM libre tengo realmente?

Para saber cuánta memoria RAM está libre hay que ejecutar free -m y fijarse en la columna “free” de la línea “-/+ buffers/cache“. Esa es la memoria disponible para aplicaciones (libre) en megabytes:

$ free -m
             total       used       free     shared    buffers     cached
Mem:          1504       1491         13          0         91        764
-/+ buffers/cache:        635        869
Swap:         2047          6       2041
$

La interpretación habitual hace saltar la alarma al ver que la RAM está ocupada al 99% (13 MB libres) cuando realmente sólo se está en uso el 42%

¿Cómo puedo verificar que esto es verdad?

Ejecutando algunos de los programas y experimentos con la memoria y cache de Linux. Se necesitan algunos conocimientos de programación en sistemas Linux y conocer inglés.

Conclusiones

En la actualidad, la memoria RAM es un recurso físico gestionado por el sistema operativo y puesto a disposición de las aplicaciones en forma de memoria virtual. Si dicho recurso no va a ser utilizado en otro fin es mejor usarlo para cualquier finalidad que pueda mejorar el rendimiento, funcionamiento del sistema que desaprovecharlo sin usar.

Por último, gracias al autor de la página original: vidarholen.net

Captura de pantalla TeXnicCenter (Imagen: Wikipedia)

La última de ellas, sin ir más lejos a través del reciente formulario de contacto.

Escribiendo la respuesta he sufrido un Déjà vu: sentía que ya había escrito lo mismo antes. Por la importancia y utilidad, y para evitarme esta sensación en el futuro, he decidido añadir una nueva entrega al Tutorial de LaTeX por fascículos.

Empecemos con la pregunta (la idea es la misma con múltiples variantes y redacciones):

Al configurar TeXnicCenter con MiKTeX no me genera la salida (DVI, PDF o ambas).

¿Qué pasa? ¿Está bien configurado? ¿cómo lo resuelvo?

Habitualmente el problema suele ser el código del documento LaTeX más que un error en la configuración.

Mi consejo:

1. Actualizar los paquetes de MiKTeX

   Entre los programas instalados por MiKTeX (accesibles desde el menú de inicio) hay un update (y en las más recientes un segundo “update (admin)“. En algunos casos he detectado problemas al instalar/usar un paquete por incompatibilidad con los paquetes básicos de MiKTeX

2. Probar un documento LaTeX básico y simple

   El sistema puede que pida instalar algún paquete pero debería generar DVI y PDF sin problemas (es aconsejable probar a generar ambas salidas que son muy usadas).

   • Si el paso anterior funciona se trata de un error en el documento que debería aparecer en el registro (en la parte inferior de la ventana de TeXnicCenter).
   • Si no funciona con un documento básico, puede que el perfil esté erróneo. En TeXnicCenter los perfiles están en el menú Build > Define output profiles. Lo mejor es ejecutar el asistente (Botón Wizard en la parte inferior izquierda) y verificar que todas las rutas son correctas.
   • Si funciona un tipo de salida y no el otro se trata posiblemente de imágenes con el formato erróneo o inclusiones de paquetes adaptados sólo a una plataforma. En el registro de errores debería indicar qué sucede.

Si tras estos pasos no se genera la salida, es necesaria más información para poder analizar el problema (código del documento, errores generados en el registro…).

Infoxicación: intoxicación por sobreabundancia de información

Como en cualquier adicción, el primer paso es admitirlo. Y tras admitirlo llegan las medidas para desengancharse y organizar la lectura de forma productiva sin renunciar al placer de hacerlo.

Esto es un simple recopilatorio de trucos que en mi caso funcionan pero no tienen por qué ser útiles en otros casos.

Lectura

Al inicio lees con fruición cualquier entrada. Poco a poco el incremento de suscripciones hace que esa tarea se prolongue innecesariamente en el tiempo hasta que genera estrés de no poder leer todo lo que nos llega. Es el momento de establecer un hábito que permita procesar todas las suscripciones de forma rápida:

• Usar una buena aplicación que permita configurarla a los hábitos de lectura.

  Para mis gustos, la mejor interfaz es la denominada “river of news” implementada en muchas y buenas alternativas como FeedDemon, Feedly o Google Reader pero lo importante es que la herramienta se adapte a nosotros y que la dominemos.

• Sondear titulares es una técnica básica.

  La lectura rápida en diagonal y filtrar únicamente aquellos titulares tras los que se encuentran artículos de especial interés. Si alguno de ellos es de especial relevancia, marcarlo o etiquetarlo para una lectura sosegada en el mejor momento (cada gestor permite marcarlos de diferente manera: es clave dominar el lector).

• Reducir el número de veces que se consultan los feeds generando un hábito de lectura.

  No es necesario estar revisando los artículos cada minuto salvo que tu trabajo dependa de ello. Dependiendo del número de fuentes lo ideal es leer una o dos veces al día (y no a primera hora de la mañana cuando se es más productivo: en los ratos muertos del viaje, a la hora de comer, al salir del trabajo) si generan muchos contenidos o cada dos días / una vez a la semana (fin de semana) si generan poco contenido.

• Asignar un tiempo máximo a la lectura

  No hay que perder el foco: salvo contadas excepciones, esto no es una obligación sino una actividad cuya dedicación hay que controlar.

  Si aparecen artículos extensos de relevancia que nos hacen superar el tiempo asignado, lo mejor es marcarlos para una lectura en un mejor momento (usando Instapaper, Read It Later o el sistema integrado en el gestor que dominamos) como puede ser a última hora del día o el fin de semana que somos menos productivos.

• Tener una herramienta para etiquetar y añadir notas a los artículos

  Puede ser un simple lápiz y papel o un sistema on-line (springpad, evernote…)

Para finalizar las prácticas de lectura unos pequeños consejos:

• Crear una categoría “importantes” o “imprescindibles”.

  En caso de saturación o falta de tiempo, es lo único que se leerá (el resto se marca como leído en un segundo con el “botón pánico”). Las herramientas suelen permitir tener la misma fuente en más de una categoría por lo que es muy sencillo marcar una como importante para este recurso.

• Categorizar las entradas por importancia en lugar de temática.

  En lugar de utilizar las típicas categorías por tema (Ciencia, Deportes, Economía, Internet…) podemos utilizar categorías como “imprescindibles” (similar al punto anterior) que se leen si tengo 5 minutos, las que leo si dedico media hora, las que leo en una hora…

  En mi caso esta regla no me ha funcionado bien y he acabado desechándola. El motivo es que se me mezclan temas (quizá me interesan demasiadas cosas) y la lectura no era agradable. Además, mis filtros han hecho que todas mis fuentes sean de gran calidad y deban ser leídas

• Simplificar el número de categorías temáticas

  No significa borrar fuentes sino agruparlas por temáticas más genéricas (por ejemplo, agrupar fútbol y baloncesto en deportes). Esto simplifica la organización (casi todas las fuentes tocan varias temáticas) y permiten descartar duplicados en la fase de escáner de titulares.

  Además simplifica la lectura: puede que hoy no tengas ganas de leer deportes y marques todas las entradas de esa temática como leídas en un segundo.

Y el último consejo pero no por ello el menos importante: no hay que tener miedo al botón marcar todo como leído. Si la cosa se descontrola, se reinicia el contador de leídos a cero, comenzamos de nuevo y no pasa nada.

Revisión

El incremento en el número de suscripciones puede hacer imposible el seguimiento. Por ello de forma constante y regular es necesario realizar un mantenimiento de subscripciones para evitar que nos ahoguen. Ese mantenimiento supone eliminar y reorganizar las distintas fuentes para mejorar los hábitos de lectura y reducir el tiempo que le tenemos que dedicar. No hay que olvidar que, al menos en mi caso, se trata de una actividad lúdica.

1. Barrido inicial.

   Muchas de las subscripciones pueden ser suprimidas únicamente por el nombre: son evitadas en la lectura, te suena que no te gustan los artículos…

2. Las fuentes inactivas no van a generar nuevos contenidos.

   En ocasiones los árboles no dejan ver el bosque y hacer que nos perdamos en el listado.

3. Analizar fuentes de amigos.

   No solemos leerlas y se mantienen por compromiso. Suponen una pérdida tu tiempo así que analiza si realmente tiene sentido mantenerla o eliminarla. Si realmente son tus amigos lo entenderán.

4. Detectar fuentes que no generan valor

   “Si no eres parte de la solución, eres parte del problema”. Fuentes que generan entradas que no vamos a leer o contenido duplicado, lo único que generan es ruido que oculta artículos de interés y generan ansiedad.

   En esta línea hay que buscar cambios de temática: No es extraño que el autor de un blog decida, conscientemente o no, dar un giro a los temas tratados hacia derroteros que no son de nuestro agrado o interés. Estas fuentes, útiles y valiosas para nosotros en un momento, han dejado de serlo porque no nos aportan valor.

Tras este primer filtro nuestro listado quedará reducido a las fuentes más válidas simplificando la siguiente fase: hay que analizar críticamente cada uno de los “supervivientes” y continuar la poda.

En este análisis individualizado se pueden utilizar múltiples criterios para evaluar cada fuente y decidir si se elimina. En mi caso, los motivos para suprimir una fuente son:

• No tienen buenos titulares o abusan de los sensacionalistas.

  Distraen en la rutina de proceso (sondeo de titulares y marcar los artículos interesantes) haciendo perder un valioso tiempo por lo que no hay misericordia con ellas.

• Fuentes sin contenido completo

  Hacen perder tiempo para acceder al contenido en el formato original (y a veces poco amigable para la lectura), algo inadmisible. Salvo contadísimas excepciones, aquellas que generan contenido realmente original que ninguna otra fuente proporcionará (y puedo aplicar Wizard RSS), son sistemáticamente eliminadas.

• Modifican el formato para que no pueda leerse cómodamente

  Los lectores de feeds suelen configurarse con una letra cómoda de leer oscura sobre fondo blanco neutro-grisáceo. Algunas fuentes añaden estilos en línea para poner fuentes blancas (lo que impide su lectura), no incluyen imágenes o añaden distracciones para obligar a leer los contenidos en la web.

• No cuidan la redacción o contienen errores gramaticales y ortográficos sistemáticamente.

  Todos somos humanos y un error lo tiene cualquiera, pero leer jeroglíficos estilo SMS es una pérdida de tiempo y un inútil esfuerzo mental.

• No publican correctamente las horas del artículo

  Rompen el flujo de noticias, generan entradas duplicadas y siempre aparecen las primeras en el listado (posible autobombo).

• No publican al menos 5 entradas o se reinician cada día.

  Para seguirlas es necesario mantener el lector abierto recopilando las entradas por si se pierde alguna. Entonces mejor perderlas todas de vista.

• Incluyen comentarios

  Ya sea en el título o en el cuerpo, ensuciando y dificultando la lectura.

• Con publicidad

  Si se trata de enlaces de autopromoción del autor, una frase o un pequeño banner con un enlace al final de la entrada evalúo si la calidad de los artículos compensa la publicidad. Si el contenido no acompaña o la publicidad es estentórea y molesta se elimina sin dudarlo.

El resultado de este segundo filtro es el listado de fuentes válidas y respetuosas con el lector. Pero aún no hemos acabado: hasta ahora sólo hemos limpiado fuentes analizándolas de forma individual, ahora toca limpiar entradas y fuentes de forma colectiva.

1. Fuentes que publican decenas de artículos por día

   Suelen ser blogs colectivos o redes de blogs. En este caso lo mejor es analizar si todas las entradas nos interesan o es posible reducir el número de entradas a sólo una categoría que podamos subscribirnos.

   Por ejemplo, en un blog de deportes se publican entradas de ciclismo, baloncesto, fútbol, motor, tenis… si sólo nos interesa uno de ellos ¿para qué subscribirnos a todo el feed en lugar de a esa categoría particular? Es más si de la categoría motor (que tendrá formula 1, motociclismo, rally…) sólo me interesa una subcategoría mejor.

   Un buen truco es utilizar las estadísticas de lectura de la aplicación que usemos: fuentes que publican muchos artículos pero con bajos porcentajes de lectura son candidatas de este tipo.

2. Entradas repetidas en múltiples fuentes de temática similar.

   En este caso hay que analizar cuál de ellas nos interesa mantener más por el motivo que sea (es la que primero lo publica, genera otras entradas de interés además de las duplicadas, es más genérica por lo que duplica entradas de varias fuentes que puedo eliminar, me gusta más la forma de escribir…) y eliminar las restantes.

   Nuevamente, las estadísticas de lectura son nuestros aliados: analizar las fuentes que más leemos del grupo y eliminar las restantes.

3. Preguntarnos si cada entrada es esencial, es decir, si es la única fuente por la que podemos acceder a esa información.

   Actualmente, podemos enterarnos por otra fuente, por twitter, por facebook o, incluso, en el telediario o por prensa… así que si ninguna de las entradas de la fuente es importante no tiene sentido mantenerla.

El consejo básico es que no debe temblarnos el pulso al eliminar una suscripción que no supere los filtros: no aporta valor y sólo genera ruido. Cuantas más fuentes, más entradas que leer y menos tiempo para hacerlo lo que supone una lectura rápida y superficial haciendo que nos perdamos joyas e información invaluable.

Tras aplicar estos filtros de limpieza quedará una lista de las fuentes más útiles y significativas. Pero esa lista no es definitiva sino que evolucionará durante el tiempo por lo que es necesario realizar la rutina de revisión de forma periódica (al menos tres veces al año si no hay muchos cambios en las subscripciones y una vez al mes si varía sustancialmente).

Nuevas subscripciones

Tras adquirir los hábitos de lectura y revisión periódica falta el último apartado: a incorporación de nuevas fuentes a la lista. Aunque pueda parecer trivial no lo es ya que, por la sencillez actual de subscripción, se puede malograr el tiempo dedicado a una exhaustiva revisión.

Antes de determinar qué fuentes se van a incorporar a nuestro listado es necesario analizar los motivos por los que añadimos entradas y cómo pueden afectar a nuestros hábitos de lectura y revisiones:

• Para saber más de un tema de nuestro interés sea cual sea dicho tema.

  Si tenemos varias fuentes de la misma temática veremos entradas duplicadas que filtraremos en la revisión deshaciendo la subscripción. Hay que preguntarse si esa fuente sobrevivirá a la revisión o puede llegar a sustituir una o varias de las fuentes ya existentes, sumando una y restando una o varias.

• Para saber algo antes que nadie, muy relacionado con el anterior.

  Pero nuestro hábito de lectura dice que vamos a leer una o dos veces al día por lo que pierde el efecto inmediatez. Además, es más rápido twitter…

• Recomendaciones, habitualmente en otra de nuestras fuentes (es habitual que publiquen recopilaciones de blogs de temática similar) o de nuestro gestor.

  Lo más probable (sobre todo si publican noticias) es que generen entradas duplicadas o repeticiones entre ellos, salvo que se trate de nichos o busquemos artículos de producción propia.

• Nos gusta una entrada a la que llegamos buscando cierta información.

  Pero… ¿nos gustarán las demás o será una excepción? ¿no tendremos una similar ya en nuestra lista?

• Es de un familiar, amigo, colega o conocido.

  Sobran los comentarios: ¿eso es un motivo para subscribirnos? Debe superar nuestros férreos controles de calidad y aportarnos algo más que nuestra relación personal.

Antes de dar al botón subscribir es necesario analizar cuál de estos motivos nos impulsan a ello y analizar las consecuencias. Esto no significa que no nos subscribamos sino que no lo hagamos a la ligera que nos lo pensemos dos veces antes de suscribirnos y valoremos los pros y contras: digamos que aplicamos los filtros de revisión antes de añadir la fuente.

Un buen truco para evitar la subscripción masiva incontrolada es crear una categoría “en pruebas” o “beta”: todos las nuevas subscripciones se añaden a la misma y, pasado un periodo prudencial de tiempo (una o dos semanas) o en la siguiente revisión, supera los filtros sale de beta se añade a la carpeta adecuada.

Conclusiones

Tras seguir estos consejos, lo más probable es que tu lista de fuentes vea mermado su número de forma radical así como el tiempo dedicado pero sin perder ni un ápice de utilidad y valor informativo.

Aplicar estos consejos las primeras veces, hasta que se adquiere el hábito, es duro. Sobre todo la parte de eliminar fuentes (y más aún si son históricas). Pero es un esfuerzo necesario para tener una lectura amena y agradable evitando el estrés y la ansiedad.

Fuentes y más información:

ALT1040:

• Organiza tus feeds con eficacia

Blog and Web:

• Feed RSS: Lee menos y con más calidad

el50:

• Eliminar feeds de tu lector para leer mejor
• Cómo no saturarse de feeds (o de información)

Microsiervos:

• Cinco razones para borrar feeds RSS

Optima Infinito:

• Productividad: Organiza tus feeds con eficacia
• Los feeds cortados cortan mi productividad

Think Wasabi:

• 15 ideas prácticas para gestionar tus feeds
• Mi fórmula personal para leer feeds
• 13 trucos para exprimir al máximo Google Reader

El último blog:

• 5 consejos para leer feeds

Tras investigar un poco el problema, he descubierto que mi enrutador parece saturarse con el envío de paquetes que realiza el nuevo portátil. Tras un poco más de investigación, el círculo se estrecha apuntando directamente a la archiconocida MTU… que casi seguro nunca has oído nombrar.

MTU, pilas de protocolos y muchas siglas

MTU, acrónimo de Unidad Máxima de Transferencia (Maximum Transfer Unit, en inglés), es uno de los parámetros de configuración de la pila de protocolos de red.

El diseño original de las redes de computadoras utiliza un sistema de capas o niveles para permitir su funcionamiento sobre cualquier tecnología presente o futura. Con este diseño cada nivel encapsula los datos del nivel previo añadiendo una cabecera y, en algún caso, cola con los datos necesarios para realizar su misión (direcciones para calcular rutas, orden y cantidad de datos para asegurar la conexión, CRC para verificar errores…) y únicamente debe conocer y tratar los datos que incluye en dicha cabecera: el resto de las capas se encargarán de las suyas. Este esquema permite cambiar uno de los niveles por otro (por ejemplo, de TCP por UDP) e incluso traducir entre niveles equivalentes (Ethernet por WiFi o fibra) sin afectar al resto.

Ejemplo de comunicación usando la pila de protocolos. Cada nivel únicamente habla con su equivalente. (Imagen: Wikipedia)

Gracias a este sistema, se puede analizar cada capa de forma individual. Una trama contiene los datos del nivel superior (Payload), que usualmente ya contiene cabeceras de otros niveles, junto con la cabecera con los datos del nivel actual. Ese paquete completo (datos y cabecera) serán los datos para el nivel inferior y así sucesivamente hasta llegar al punto más bajo de la pila: el nivel de acceso a la red física. Y aquí la cosa se complica.

Ejemplo de paquete de un nivel 2 genérico (imagen: CapaOcho)

Al llegar a la capa más baja entran en juego nuevos factores: intensidad de señal, tiempos de propagación… física pura. Estos factores introducen una serie de límites para asegurar la calidad, fiabilidad, velocidad de transmisión, latencia máxima o para asegurar que un algoritmo de detección de colisiones en el medio funciona. Uno de esos límites es la cantidad de información que puede transmitirse consecutivamente de forma fiable, es decir, el tamaño máximo del paquete (considerando los datos y todas las cabeceras de cada uno de los niveles) que puede enviarse por el medio y ese tamaño máximo es la MTU. Aunque se podría decir que cada nivel podría tener su propia MTU, únicamente se considera la MTU del nivel IP, encargado de enviar datagramas (paquetes o tramas) entre dos equipos.

Por ejemplo, en el caso de una red Ethernet, el tamaño máximo (MTU) es de 1500 bytes. Si es necesario mandar más información se enviarán dos datagramas o paquetes: se fragmentará la información. Esta división se realiza de forma automática en el nivel IP permitiendo el envío de información a través de cualquier red de forma transparente aunque pagando el precio de un menor rendimiento: es menos costoso mandar un paquete grande que varios pequeños.

Internet es un conjunto de redes: ¿cómo afecta la MTU?

La situación se complica cuando los datos deben atravesar varias redes diferentes, cada una con una posible MTU. El proceso de fragmentación se realizará, según las necesidades, en cada uno de los componentes intermedios que comuniquen dos o más redes con el consiguiente coste (almacenamiento temporal, proceso…) además de incrementar la probabilidad de que algún fragmento no llegue al destino. Lo ideal es que el emisor cree directamente paquetes del tamaño justo para atravesar todas las redes implicadas sin necesidad de fragmentar en ningún punto intermedio: la MTU mínima de toda la ruta afectada.

Para determinar ese tamaño máximo de MTU es posible mandar un paquete marcado como “no fragmentable” (se activa enviando un bit en la cabecera del protocolo IP). Si alguna red involucrada no soporta dicho tamaño, el entrutador que lo detecte responderá con un paquete especial ICMP indicando que se debe fragmentar permitiendo al origen adaptar el tamaño de MTU. Tras unas primeras transmisiones de “prueba” se puede enviar información sin pagar el coste de fragmentaciones intermedias.

Pero la evolución de los tiempos ha hecho este sistema inviable: para evitar ataques DoS es muy común deshabilitar el protocolo ICMP imposibilitando el descubrimiento del tamaño de MTU. Esto obliga a que cada elemento fragmente los mensajes para adaptarlos según necesidades incrementando el tiempo de proceso en cada salto.

Solución al problema de la MTU WiFi en Windows 7

Antes de solucionar un problema es necesario conocer el origen. Y en este caso el problema es la MTU que utiliza Windows 7 en la red WiFi: 1500 bytes. Este es el valor de una red Ethernet, la más común en Internet, pero la especificación de WiFi indica que la MTU debería ser 1492 bytes. Esa pequeña diferencia hace que sea necesario fragmentar cada paquete (de tamaño máximo) en dos: uno de algo menos 1492 bytes (hay que incluir la cabecera IP</acronym) y otro de algo más de 8 bytes, con lo que para una transmisión de 15 KB son necesarios se mandan 21 paquetes en lugar de los 11 paquetes si la MTU fuera correcta: ¡un 90% más! y las cosas empeoran según se incremente el tamaño. La carga que recibe el enrutador (paquetes) es prácticamente el doble por lo que las latencias se incrementan y llega a producirse la saturación.

La solución es tan sencilla como bajar la MTU que utiliza Windows 7 al tamaño estándar que necesita la red WiFi. Para ello es necesario abrir una consola en modo administrador (sí, esa cosa negra en la que se escriben órdenes también existe en Windows y es muy útil en algunos casos): buscar la aplicación cmd, abrir el menú contextual y seleccionar “ejecutar como administrador”.

En la consola, se debe teclear:

netsh interface ipv4 show subinterfaces

Se obtendrá una lista de las interfaces de red disponibles en el equipo. Entre ellas debe aparecer la conexión WiFi con una MTU de 1500. Para corregirla y ponerla del tamaño adecuado basta ejecutar:

netsh interface ipv4 set subinterface "Wireless Network Connection" mtu = 1492 store = persistent

El nombre de la red (entre comillas) debe coincidir exactamente con el que se obtuvo en el primer listado. El valor de la MTU es el adecuado para una red WiFi, aunque puede ser necesario bajarlo más en algún caso (equipos más viejos).

Volviendo a ejecutar la primera línea se puede verificar si el cambio se ha realizado.

Conclusiones

En algunas ocasiones surgen problemas escondidos en la profundidad de los sistemas informáticos de difícil diagnóstico.

En este caso un pequeño error en un parámetro de configuración (MTU del protocolo IP) ocasiona el bloqueo de la conexión WiFi. Con este pequeño cambio todo funcionará correctamente sin que se note ninguna pérdida de rendimiento e, incluso, con cierta mejora.

Referencias:

• La importancia del MTU
• Vista MTU for WiFi

Portada
«El hipnotista»

Alexander Ahndoril y Alexandra Coelho Ahndoril, autores bajo el seudónimo Lars Kepler

Escrita bajo el seudónimo Lars Kepler por el matrimonio formado por Alexander Ahndoril y Alexandra Coelho Ahndoril, El hipnotista es una novela negra ambientada en la nórdica Suecia, cuya sociedad es retratada mientras se avanza por el laberíntico entramado en busca de la resolución del rompecabezas. Acción y suspense combinada con flashes al pasado hacen una lectura es la mezcla capaz de generar la tensión necesaria para mantener el interés en la lectura.

Es la primera entrega de una serie que los autores pretendían publicar ocultando su identidad bajo el seudónimo. Tras su éxito, decidieron mostrar quién estaba tras Lars Kepler aunque será la firma de las próximas novelas de la serie.

En mitad de la noche, Simone se despierta repentinamente al notar un pinchazo en el brazo. [...]

Por el espejo del pasillo, Simone ve a alguien inclinado sobre la cama de Benjamín con una jeringuilla en la mano. Los pensamientos se disparan en su mente. Intenta comprender lo que está sucediendo, lo que está viendo.

- ¿Benjamín? – dice con voz ansiosa – ¿Qué estáis haciendo? ¿Puedo pasar?

Se aclara la garganta, da un paso adelante y de repente le fallan las piernas, intenta agarrarse al aparador pero no consigue mantenerse en pie. [...]

Y entonces ve que alguien arrastra a Benjamín por el suelo tirando de sus piernas. [...] Benjamín mira a su madre a los ojos, está aterrorizado, mueve la boca pero no emite ningún sonido. Simone se estira para cogerle la mano pero no la alcanza. Sin fuerzas, trata de arrastrarse tras él, los ojos se le quedan en blanco, no ve nada, parpadea y observa en fragmentos intermitentes cómo arrastran a Benjamín por la entrada hasta el rellano, y cómo luego la puerta se cierra cuidadosamente. Simone intenta gritar para pedir auxilio pero no lo consigue, los ojos se le cierran, respira lenta, pesadamente, no logra inspirar suficiente aire.

A continuación todo se vuelve negro.

Lars Kepler: ‘El hipnotista‘. Planeta Internacional, 2ª edición (Marzo 2010). Página 198.

Antes de empezar ¿qué es un registro de mensajes/eventos? No es más que un lugar en el que almacenar lo que ha sucedido con un doble objetivo: detectar/solucionar problemas en el sistema y auditar las acciones acometidas. Lo más habitual es un fichero (o tabla en una BBDD), ya sea local o remoto, en el que cada línea almacena información que permita responder a las preguntas: ¿Cuándo? ¿Quién? ¿Dónde? ¿Qué?

De la definición anterior ya se vislumbran dos agentes: el mensaje producido y el almacenamiento. El estándar separa claramente estos conceptos: la generación de mensajes (desde sistemas operativos Unix, Linux, Solaris, Windows o MacOs hasta dispositivos de comunicación como routers) de su proceso/almacenamiento (fichero local o remoto, BBDD…) y posterior análisis.

Esta separación aporta una serie de beneficios. Por un lado, proporciona simplicidad para el desarrollador que genera los eventos con un determinado formato y no tiene que preocuparse por detalles de almacenamiento o registro remoto. Por el otro otorga una gran versatibilidad al administrador ya que los receptores proporcionan filtros, envío remoto (que permite recopilar todos los mensajes en una única ubicación), almacenamiento en múltiples soportes…

Esquema ideal de registro remoto de eventos usando el protocolo Syslog (Imagen: Maldito Nerd)

Por ello, bajo la denominación ‘syslog‘ se engloban varios componentes diferenciados: la biblioteca que usan las aplicaciones productoras de eventos, la aplicación/demonio que se encarga de almacenarlos y el protocolo de comunicación que emplean para intercambiar dichos mensajes. Rasquemos la superficie de cada uno de ellos.

Protocolo syslog

El protocolo define un único tipo de mensaje con tres campos que se transmite mediante el puerto UDP 514. Esto permite concentrar los registros de múltiples máquinas en un único punto simplificando la labor de gestión al administrador siendo habitual que múltiples dispositivos lo soporten.

El formato del mensaje se compone de:

1. La cabecera contiene la prioridad, fecha y hora del mensaje, máquina, proceso (nombre e identificador) que lo ha generado y la versión del protocolo utilizado.
2. Una serie de pares clave-valor con metadatos.
3. El texto del mensaje.

La prioridad indicada en la cabecera realmente codifica dos valores (calculados mediante la fórmula ):

Recurso (facility):

Tipo de elemento que ha generado el mensaje. En el RFC 3164 se recopilan los valores generalmente utilizados en las distintas distribuciones en el momento de su redacción:

Valor	Descripción
0	Mensajes del kernel
1	Mensajes del nivel de usuario
2	Sistema de correo
3	Demonios de sistema
4	Seguridad/Autorización
5	Mensajes generados internamente por syslogd
6	Subsistema de impresión
7	Subsistema de noticias sobre la red
8	Subsistema UUCP
9	Demonio de reloj
10	Seguridad/Autorización
11	Demonio de FTP
12	Subsistema de NTP
13	Inspección del registro
14	Alerta sobre el registro
15	Demonio de reloj
16	Uso local 0
17	Uso local 1
18	Uso local 2
19	Uso local 3
20	Uso local 4
21	Uso local 5
22	Uso local 6
23	Uso local 7

Severidad (priority/level):

Indica la gravedad del mensaje según una escala de ocho valores:

Valor	Denominación		Descripción
0	Emergencia	EMERG	Sistema inutilizable
1	Alerta	ALERT	Requiere intervención inmediata
2	Crítico	CRIT	Condición crítica
3	Error	ERR	Condición de error
4	Peligro	WARN	Condición de peligro
5	Aviso	NOTICE	Funcionamiento normal pero con condiciones reseñables
6	Información	INFO	Mensajes informativos
7	Depuración	DEBUG	Mensajes de depuración de bajo nivel

Para simplificar la generación de los mensajes según el protocolo, existe una librería de sistema que proporciona tres funciones básicas de uso: openlog, syslog y closelog. La mayoría de los lenguajes incorporan una API más o menos sofisticada sobre dicha biblioteca.

Receptores

En cuanto a los demonios de proceso y almacenamiento existen varias implementaciones. La funcionalidad básica de todas ellas se resume en: recibir los mensajes (locales o remotos) y escribirlos en algún soporte en base a un conjunto de reglas (por ejemplo, los de prioridad “warning” al fichero /var/log/warnings) especificadas por el administrador.

sysklogd:

Es la opción clásica. Bajo esta denominación realmente se esconden dos demonios separados: syslogd para mensajes de sistema y klogd para los mensajes del kernel.

La última versión publicada (1.5) data de 2007 con poca actividad desde entonces (tanto en el código como en las listas de correo).

syslog-ng “new generation”:

Es una alternativa al sysklogd aparecida a finales de la década de 1990. Sus mayores innovaciones pasan por añadir filtros más potentes (por ejemplo, filtrando por contenido) y la posibilidad de utilizar como transporte TCP, lo que lo hace teóricamente más fiable.

Actualmente está soportado por una empresa quién ha realizado un fork no libre en el que se realizan las principales innovaciones quedando la versión libre algo relegada a segundo plano.

rsyslog:

Es el último contendiente en sumarse a la partida, aparece en 2004, con el ánimo de impulsar la innovación frente al estancamiento de sysklogd y la versión libre de syslog-ng.

Además de las mejoras introducidas por syslog-ng, incorpora múltiples ideas innovadoras:

• Modularidad en la configuración, que además es casi compatible con la original de sysklogd
• Nuevo protocolo RELP, que mejora la fiabilidad sobre TCP evitando duplicados en caso de error
• Escritura en disco local o remoto, volcado a BBDD nativo o envío de e-mail… con gestión automática de colas (en memoria o disco) en caso de ralentización o error de comunicación y planificación horaria.

También incorpora algunas pequeñas mejoras como marcas de tiempo con mayor precisión, soporte nativo de cifrado, repetidores intermedios…

El tándem syslogd/klogd ha sido la primera elección de las distribuciones. Poco a poco, las distintas distribuciones incorporaron syslog-ng como paquete opcional en el sistema pero pocas de ellas (SuSE 9 es la excepción) lo eligieron como opción por omisión.

En los últimos lanzamientos se ha producido una migración a rsyslog en prácticamente todas las distribuciones. Este salto se debe a varios factores determinantes (Ubuntu WhitePaper: Centralised logging with rsyslog incluye las razones de la migración en su página 10, amén de ser una buena guía de cómo diseñar un sistema de logs centralizados):

• rsyslog incluye muchos avances respecto al clásico sysklogd y bastantes mejoras respecto a la estancada versión libre de syslog-ng que lo hacen más flexible, fiable y escalable.
• La configuración es prácticamente compatible con los ficheros de configuración de sysklogd, al contrario que syslog-ng cuya configuración difiere radicalmente. Esto simplifica en gran medida la migración y, gracias a su sistema de inclusión modular, permite utilizar casi sin alterar configuraciones previas existentes.
• El desarrollo tiene en cuenta dos factores importantes: fiabilidad y rendimiento, cualidades cada vez más críticas sobre todo en grandes configuraciones clúster o grid.

Conclusiones

Syslog se asienta sobre tres conceptos básicos: el dispositivo/aplicación generadora de eventos, el protocolo de comunicación y la aplicación/demonio que filtra dichos eventos y los escribe en un soporte según los deseos del administrador. Gracias a este diseño es posible recopilar información de múltiples fuentes, ya sean aplicaciones locales o de múltiples máquinas e, incluso, dispositivos conectados a la red.

Recopilar esta información, aunque importante, no es realmente útil: lo útil es poder analizarla. Desde análisis básicos realizados en consola (less /var/log/messages, grep -i buscar /var/log/messages | ccze -C…) hasta aplicaciones web que simplifican la navegación por los logs (php-syslog-ng, LogAnalyzer…).

Tras este pequeño y fugaz repaso espero que al menos quede un pequeño susurro en la memoria de la existencia de esta pequeña utilidad, habitualmente oculta en las bases de los sistemas operativos.

Durante una visita a un Instituto Psiquiátrico, le pregunté al Director qué criterio se usaba para definir si un paciente debería o no ser internado.

– Bueno — dijo el Director — hacemos la prueba siguiente: Llenamos una bañera, luego al paciente le ofrecemos una cucharita, una taza y un cubo y le pedimos que vacíe la bañera. En función de cómo vacíe la bañera, sabemos si hay que internarlo o no y con qué tratamiento empezar.

– Ah, entiendo — dije — una persona normal usaría el cubo porque es más grande que la cucharita y la taza.

– No — dijo el Director — una persona normal quitaría el tapón… Usted que prefiere: ¿una habitación con o sin vistas al jardín?

Se solicitó a un prestigioso asesor financiero que explicara esta crisis de una forma sencilla, para que la gente de a pie entienda sus causas. Este fue su relato.

Equus africanus asinus, posible responsable del problema

Un señor se dirigió a una aldea donde nunca había estado antes y ofreció a sus habitantes 100 euros por cada burro que le vendieran. Buena parte de la población le vendió sus animales.

Al día siguiente volvió y ofreció mejor precio, 150 por cada burrito, y otro tanto de la población vendió los suyos.

Y a continuación ofreció 300 euros y el resto de la gente vendió los últimos burros.

Al ver que no había más animales, ofreció 500 euros por cada burrito, dando a entender que los compraría a la semana siguiente, y se marchó.

Al día siguiente mandó a su ayudante con los burros que compró a la misma aldea para que ofreciera los burros a 400 euros cada uno. Ante la posible ganancia a la semana siguiente, todos los aldeanos compraron sus burros a 400 euros, y quien no tenía el dinero lo pidió prestado. De hecho, compraron todos los burros de la comarca.

Como era de esperar, este ayudante desapareció, igual que el señor, y nunca más aparecieron. La aldea quedó llena de burros y endeudados.

Hasta aquí lo que contó el asesor. Veamos lo que pasó después:

Estado de las cuentas del ayuntamiento y los habitantes de la aldea

1. Los que habían pedido prestado, al no vender los burros, no pudieron pagar el préstamo.
2. Quienes habían prestado dinero se quejaron al ayuntamiento diciendo que si no cobraban, se arruinarían ellos; entonces no podrían seguir prestando y se arruinaría todo el pueblo.
3. Para que los prestamistas no se arruinaran, el Alcalde, en vez de dar dinero a la gente del pueblo para pagar las deudas, se lo dio a los propios prestamistas. Pero estos, ya cobrada gran parte del dinero, sin embargo, no perdonaron las deudas a los del pueblo, que siguió igual de endeudado.
4. El Alcalde dilapidó el presupuesto del Ayuntamiento, el cual quedó también endeudado. Entonces pide dinero a otros ayuntamientos; pero estos le dicen que no pueden ayudarle porque, como está en la ruina, no podrán cobrar después lo que le presten.

Resultado ¿final? de la operación:

• Los listos del principio, forrados.
• Los prestamistas, con sus ganancias resueltas y un montón de gente a la que seguirán cobrando lo que les prestaron más los intereses, incluso adueñándose de los ya devaluados burros con los que nunca llegarán a cubrir toda la deuda.
• Mucha gente arruinada y sin burro para toda la vida.
• El Ayuntamiento igualmente arruinado.

Solución ¿final?: Para solucionar todo esto y salvar a todo el pueblo, el Ayuntamiento bajó el sueldo a sus funcionarios.

Vía: Un correo de un amigo cuyo nombre no revelaré por si quiere permanecer en el anonimato