Tener un televisor full-hd y no poder elegir la resolución correcta desde Windows

¿Te ha pasado que tienes una pantalla full-hd pero al conectarla a tu laptop con un cable VGA sólo puedes elegir hasta 1366x768 o alguna otra resolución inferior? ¿O te pasa que la imagen se ve estirada, distorsionada o borrosa? ¿Notas que las letras no se ven con la misma nitidez que en la pantalla de la laptop?

Esto ocurre cuando Windows no puede manejar correctamente la pantalla, porque esta última le da información errada sobre sus características. Existe una pequeña herramienta gratuita llamada Custom Resolution Utility (CRU) que puede resolverlo.

Resulta muy fácil: ejecutamos el programa del link mencionado antes, descomprimimos el zip (no hace falta instalarlo) y ejecutamos cru.exe. La imagen que veremos será como esta:

En la parte superior hay un selector donde deberemos elegir la pantalla que queremos modificar. En la imagen mostrada ya he seleccionado mi pantalla LCD y ya he agregado una resolución que no estaba disponible: 1920x1980 (16:9) @ 60 Hz. Para ello todo lo que hay que hacer es usar el botón ADD de la lista "Standard resolutions":

Elegimos la resolución full-hd tal como se muestra, pulsamos OK para regresar a la ventana principal y estando allí volvemos a pulsar OK. Reiniciamos el equipo y listo, problema resuelto!

Si deseas saber por qué ocurre, aquí una breve explicación: las pantallas plug & play comparten información sobre sus capacidades mediante un formato de datos llamado EDID (Extended display identification data). Algunas pantallas brindan información incompleta o incorrecta, lo que causa que Windows no pueda manejar correctamente el dispositivo.

Es posible proporcionarle manualmente a Windows estos datos (lo mismo que haría un driver), pero implica manipular el registro. Aquí es donde CRU nos resulta muy útil, ya que nos permite fácilmente "agregar" una resolución específica que teóricamente nuestra pantalla no soporta. Por supuesto debemos tener cuidado porque algunas pantallas muy antiguas podrían incluso averiarse, pero cualquier televisor decente mostrará un aviso de "resolución no soportada".

Evitar que YUM actualice ciertos paquetes

Directo al grano:

Para evitar actualizar -por ejemplo- tomcat, en /etc/yum.conf agregar la línea

exclude=tomcat*

Ahora los rodeos que normalmente irían antes:

Algunas veces ocurre que tenemos una configuración especial en un servidor o equipo. Algo que es mejor no tocar porque es demasiado crítico. O también puede ser que pretendamos mantener una versión específica de ciertos programas, para pruebas de compatibilidad.

Me pasó con un cliente que utilizaba mailman para distribuir información bursatil muy importante. Un buen día la distribución no funcionó y no había tiempo para investigaciones. No tuve más remedio que "retroceder" el sistema a un estadio previo (menos mal que era una VM de la cual tenía backup).

La solución fue simple (CentOS 6.4), en /etc/yum.conf agregué

exclude=mailman*

Santo remedio, nunca más se actualizó (ni ofreció actualizar) mailman.

Y si se trata de mantener un sistema sin actualizar, se puede desactivar los repositorios básicos de yum. En /etc/yum.repos.d existen archivos por cada repositorio. Se puede crear excludes en cada uno de ellos (a diferencia del anterior que es global). O se puede desactivar completamente un determinado repositorio (enable=0) mientras que otros quedan activos.

Por ejemplo, en mi caso desactivé los repositorios base de CentOS pero (por ser una VM manejada con Cloudmin/Virtualmin) mantuve activo el repositorio virtualmin-universal porque actualiza el manejador de la máquina virtual pero no el sistema operativo.

Máquinas Virtuales

Una máquina virtual (VM por Virtual Machine) es un entorno de software que recrea las características de un equipo real de modo que podamos -para decirlo en términos simples- tener una computadora dentro de otra. Una máquina virtual tiene su propio Bios, hardware y sistema operativo con independencia de lo que utilice la máquina real que la aloja.

Las aplicaciones son variadas, desde emular entornos de hardware no disponibles por antiguedad, precio, etc. hasta consolidar múltiples equipos en uno sólo con fines de ahorro o simplificación de administración.

Hemos experimentado con máquinas virtuales desde hace varios años, pero siempre sólo para probar aplicaciones desarrolladas en VIS bajo diferentes entornos. También para probar algunas aplicaciones externas o software de dudosa procedencia sin comprometer las máquinas reales.

Recientemente, nos hemos aventurado a utilizarlo con un fin más interesante: nuestros servidores de hosting compartido. Las ventajas son enormes, especialmente por la forma en que VIS organiza sus servicios.

Concentrar todos los servicios en un único servidor es una pésima idea.

Separar todos los servicios en equipos independientes es muy costoso.

Una buena opción es agrupar los servicios en dos o tres equipos.

Una opción mucho mejor es separar todo en máquinas virtuales y distribuirlas en los mismos dos o tres equipos reales. ¿Por qué?

Las ventajas son muchas:

• La administración puede ser más refinada y precisa: se puede afinar al detalle los servicios o mantenerlos separados y controlados de manera que no interfieran entre ellos.
• Se puede ajustar los recursos asignados a cada servicio según la demanda lo requiera. Incluso se puede independizar un servicio en un equipo real independiente si el consumo así lo requiere.
• Se puede "clonar" equipos muy fácilmente, con toda la configuración ya lista.
• El costo no se eleva significativamente pero sí se requiere mayores conocimientos para poder administrar el conjunto.
• Migrar a equipos más potentes se reduce a mover la máquina virtual de un equipo a otro.

Existen muchas plataformas de virtualización en constante desarrollo, algunas comerciales, otras de código abierto: VMware, Hyper-V, KVM, VirtualBox, Xen, etc.

Como siempre, es cuestión de darse el tiempo -nunca suficiente- para experimentar con ellas y ver la forma de sacarles provecho.

Hosting compartido: ¿Todos los huevos en una sola canasta?

El hosting tradicional consiste en tomar UN servidor, instalarle un panel de control (cpanel en el 99% de los casos), agregarle todos los servicios necesarios (correos, webmail, sitios web, bases de datos, listas, filtros anti-spam, etc.) y repartir el acceso entre una determinada cantidad de clientes.

Suele suceder que -por ahorro de costos- se agregan demasiados clientes a un único servidor y entonces los problemas de rendimiento se agravan.

Imaginen a una sola persona que debe atender el teléfono, tomar notas de una reunión, escribir una carta, calcular los impuestos a pagar, atender a un cliente presencialmente, etc. todo al mismo tiempo. Basta que alguna de esas actividades le demande demasiada atención para que inevitablemente descuide las otras.

Es lo que sucede si al mismo servidor se le instalan cosas tan diferentes como una base de datos, un servidor de correo y un servidor web. Basta que a un usuario se le ocurra abrir un buzón muy grande o que el filtro anti-spam deba analizar un mail con attachments muy pesados o que un sitio web deba realizar una tarea pesada, para que el resto de servicios se vean afectados.

En una situación ideal, tendríamos varios servidores, uno por cada tarea de modo que puedan estar especialmente configurados para realizarla de la mejor manera. Siendo más servidores, pueden manejar una mayor cantidad de usuarios, lo que en cierta forma compensa el costo adicional, pero no evita que el conjunto sea más complicado de manejar. El principal problema es que las herramientas comúnmente utilizadas para administración (por ejemplo: cpanel) no están concebidas para este tipo de operación, por lo que simplemente los proveedores optan por el único camino que tienen (todo en el mismo server).

Como los extremos nunca son buenos, una solución intermedia aceptable es utilizar al menos dos servidores: uno para correo y otro para web. El servidor de correo puede concentrarse en los servicios SMTP, POP3, IMAP y quizá su propio webmail. El otro puede concentrarse en el sitio web (apache, php y mysql).

Otras tareas que demandan un elevado consumo de recursos de procesamiento pueden ser delegadas a servidores especializados. El mejor ejemplo es el filtrado anti-spam.

VIS emplea un esquema similar al mencionado, empleando no uno sino dos servidores de filtrado para todos sus servidores de correo. Funciona muy bien y permite realizar una serie de complejos procesos sin mayor impacto en el nivel de servicio, aunque muchas veces resulta complicado explicarle a un potencial nuevo cliente por qué un servicio cuesta significativamente más que el otro.

Conclusión: es mejor usar varios servidores especializados en determinadas tareas. Concentrar todos los servicios en un único equipo es una bomba de tiempo.

Made in Perú

He pasado las últimas 3 horas leyendo diversos webs, blogs, etc. sobre desarrollo de software en Perú. Con tanto trabajo algunas veces olvidamos darnos un baño de información nueva. ¿Mi conclusión? Mucho floro, palabreo y sigla bonita, pero muy poco desarrollo realmente peruano.

Drupal, Joomla, etc. ganan terreno. Veo con pánico cómo la historia de los ochentas a noventas parece repetirse: luego de un inicio humilde pero auspicioso, caemos en el facilismo de simplemente usar lo que otros producen en el extranjero.

Sólo basta navegar por los sitios web de los principales medios, tal parece que crear aplicaciones web se está convirtiendo en cuestión de crear skins, adecuar estilos y algunos plugins?

En los ochentas, cuando reinaban las computadoras de 8 bits, hubo algunos pocos que le encontraron el gusto a la programación. De esos pocos, un número aún menor se organizó en pequeños grupos que intentaban crear pequeñas producciones netamente peruanas. Era usual comprar revistas españolas de muy buena calidad sobre computación, donde además de aprender, se podía mirar de lejos la gran actividad del joven mundo informático en Europa.

Yo tenía 14 años cuando quedé sorprendido al encontrar en El Comercio un aviso buscando programadores que manejaran assembler, con el cuál yo había estado jugando/descubriendo desde hacía pocos meses. Por supuesto que fui y en verdad estos tipos sabían del asunto, se hacían llamar "Software Home" y antes que nada me pidieron que mostrara lo que había hecho (un muy simplón juego de serpientes come-números, pero escrito en assembler, que me había costado sangre!). Espero haberles causado una buena impresión, el hecho es que luego me mostraron lo que estaban creando y fue impresionante! Un video juego a la altura de los que llegaban del extranjero. Por diversas razones luego de un tiempo no supe más de ellos. Otros como TEG (hoy Tegmo.com) continuaron la pelea.

Todo ese mundo murió con la masificación de las PCs y terminamos simplemente consumiendo software pirata.

Lo que no he perdido es la convicción de que más que simplemente usar, se debe crear. Por eso VIS emplea su propio framework, para poder controlar cada aspecto a nuestro antojo. Desde hace casi 10 años lo hemos usado para incontables proyectos en diferentes encarnaciones y nos ha permitido diferenciarnos y poder transferir a cada cliente, la experiencia del proyecto anterior, siempre mejorando nuestro arsenal de herramientas.

Esperemos que el tema comercial no termine -otra vez- convirtiéndonos en simples consumidores. En nuestro medio es muy común "seguir a la manada", usando siglas, abreviaturas, etc. casi como alarde de que supuestamente conocemos un tema. Aquí los "monstruos en computación" usan Firefox, instalan Linux, recompilan Kernels y hasta "hackean" messengers :) pero son contados los que realmente entienden por qué lo hacen, menos aún los que modifican código o crean patchs. Ni qué decir de creaciones propias.

Mi pesadilla con phpMyAdmin sobre IIS 7

El título puede resultar decepcionante no? Instalar phpMyAdmin es un juego de niños! o al menos siempre ha sido así para mi hasta HOY, pero finalmente luego de más de 5 horas encontré la solución. Y no me tomó mas que apenas 5 segundos.

La receta fatal es esta:
Windows 2008
IIS 7
MySQL 5.0.5
PHP 5.3.1 (FastCGI)
phpMyAdmin 3.2.5

Configuras phpMyAdmin, todo OK. Luego entras al login, luce perfecto, escribes tu login/pass y.... esperas, esperas, esperas una ETERNIDAD hasta que te aparece HTTP Error 500 con el MUY UTIL mensaje "ha ocurrido un error interno" :) Haces de todo, pruebas permisos, versiones, hasta le activas el Trace al IIS, nada de nada.

...pero al final del día, la culpa de todo la tiene el chin... digo... Windows 2008 :)

LA SOLUCIÓN? Probablemente tu config.inc.php incluye "localhost" como nombre de servidor MySQL, pero resulta que en Windows 2008 ese nombre no existe (está comentado en el archivo hosts). No me he tomado la molestia de averiguar por qué aún. Así que con tan sólo cambiarlo por "127.0.0.1", EUREKA! todo funciona de maravillas!

Ojalá esto sirva para salvar a alguien del martirio que tuve hoy.

FTP Pasivo con Windows 2008

Clásico problema: quiero conectar el Filezilla a uno de nuestros nuevos servidores con Windows 2008 y no funciona como Pasivo, sólo como Activo. Reviso el firewall y tiene una regla para el FTP que obviamente funciona con el modo Activo únicamente.

Luego de buscar un poco por internet encontré estas casi mágicas líneas:

netsh advfirewall firewall add rule name="FTP (no SSL)" action=allow protocol=TCP dir=in localport=21

netsh advfirewall set global StatefulFtp enable

La primera se ocupa del puerto 21 y la segunda del StatefulFtp que aperturará dinámicamente los puertos necesarios para el FTP Pasivo.