Lesbian in the shell

Desde que instalé Debian por primera vez, hará ya unos 14 años, tengo la costumbre de llamar «Lesbian» a cualquier ordenador de mi propiedad que lleve Linux. Por cierto, casi siempre he usado la distribución Debian o una variante.

Lesbian in the shell

Shell in the Lesbian

Ghost in the shell

Ghost in the shell. De moda otra vez después de más de 20 años. Ahora Motoko Kusanagi sufre un whitening.

Javascript ya no es un lenguaje de juguete

Hace años que Javascript ya no es un lenguaje de juguete con el que manipular con Dios y ayuda el DOM del navegador1 y para muestra un botón, ¡pero qué botón!

Emulador de PC con Javascript

También incorpora una versión reducida del compilador gcc

Se trata de un simulador de PC desarrollado en Javascript que puede ejecutarse perfectamente en tu navagador. Concretamente emula un procesador 486 (sin coprocesador matemático), RTC (reloj interno), puerto serie, disco duro, etc.

Además el emulador no viene solo sino que incorpora un Linux (Kernel 2.6.20) y una versión del compilador GCC que el mismo programador del emulador creó: Tiny C Compiler. Se trata de una versión mucho mucho más ligera y rápida que el compilador original.

El genial autor de esta obra es el francés Fabrice Bellard. Es un su web podéis encontrar otras muestras de su genio.

Desde que en 2008 los navegadores empezaron a incorporar compiladores JIT en vez de interpretar el código Javascript, la velocidad de ejecución dio un enorme salto. A medida que van mejorando (hoy en día son capaces incluso de optimizar código) siguen reduciéndose los tiempos. Esto ha dado más alcance a Javascript, por ejemplo Node.js funciona mediante una implementación en el lado servidor del compilador JIT para Chrome llamado V8.

Eso sí, a pesar de todas las librerías y software que ha crecido entorno a este lenguaje, y a pesar de su evolución, sigue teniendo características que hacen difícil la vida del programador:


1 Posiblemente las dificultades más que ser debidas a carencias de Javascript lo eran por los bugs de los navegadores a la hora de manipular el Document Object Model y a las diferencias entre ellos para implementar su manipulación (o el estándar no era muy concreto o era ignorado donde convenía implementarlo de otra manera, no lo sé). En todo caso, sobre Javascript recaían parte de las culpas con el consiguiente desprestigio.

Cómo instalar XCache en un servidor compartido

La semana pasada quise instalar en un servidor compartido (Hostmonster para más señas) alguno de los diferentes sistemas de caché que existen para PHP. El único que ofrecen es un paquete de PEAR llamado “Cache” pero necesitaba instalar Apc, Xcache, MemCache o Redis. Me puse en contacto con su departamento técnico para consultar si era posible y la respuesta fue un no. Como cuando instalamos Subversion tampoco fueron ni muy optimistas ni proactivos, no hice demasiado caso a su respuesta y me lancé a intentarlo. Como Apc parecía que iba a ser problemático pues por lo que leí necesitaba ser root, lo intenté con Xcache. En primer lugar, en el directorio “home” de mi usuario en Hostmonster creé los directorios y bajé la versión de xCache para la versión de PHP que corre el servidor:

  1. mkdir modules xcache
  2. wget http://xcache.lighttpd.net/pub/Releases/1.3.2/xcache-1.3.2.tar.gz

Después descomprimí el módulo y lo compilé para la versión de PHP del servidor:

  1. tar -zxf xcache-1.3.2.tar.gz
  2. cd xcache-1.3.2
  3. phpize
  4. ./configure –enable-xcache
  5. make

Compruebo que esté bien:

  1. make test

Y ya sólo queda mover el módulo recién compilado a su directorio de destino:

  1. cd modules
  2. mv xcache.so /home2/usuario/modules

Ahora debemos editar php.ini para que PHP empiece a trabajar con Xcache. Añadí las siguientes líneas:

  1. zend_extension = /home2/usuario/modules/xcache.so
  2. zend_extension_ts = /home2/usuario/modules/xcache.so
  3. xcache.shm_scheme = «mmap»
  4. xcache.size = 32M
  5. xcache.count = 8
  6. xcache.slots = 8K
  7. xcache.ttl = 0
  8. xcache.gc_interval = 0
  9. xcache.var_size = 16M
  10. xcache.var_count = 1
  11. xcache.var_slots = 8K
  12. xcache.var_ttl = 0
  13. xcache.var_maxttl = 0
  14. xcache.var_gc_interval = 300
  15. xcache.test = Off
  16. xcache.readonly_protection = Off
  17. xcache.mmap_path = «/dev/zero»
  18. xcache.coredump_directory = «»
  19. xcache.cacher = On
  20. xcache.stat = On
  21. xcache.optimizer = Off
  22. xcache.coverager = Off
  23. xcache.coveragedump_directory = «»

También le podemos añadir un usuario y contraseña, ésta última debe ir “hashed” con md5 según explica la documentación:

  1. xcache.admin.user = «nombre_del_usuario»
  2. xcache.admin.pass = «4c882dcb24bcb1bc225391a602feca7c»

Para que la configuración tenga efecto deberíamos reiniciar los procesos fcgiphp5 pero eso no es siempre posible en un servidor compartido, así que no me quedó otra que esperar a que ello sucediera. Se pueden ver los procesos de la siguiente forma:

  1. ps aux | grep fcgiphp5

A continuación obtenemos la id del proceso y mediante kill mandamos la señal para matarlo. En todo caso, sea de este modo o bien esperando, en el resultado de phpinfo() deberíamos ver esto si XCache está funcionando correctamente:
XCache correctamente instalado

Configuración XCache

Configuración XCache

Instalarlo es muy fácil, ¿verdad? A continuación me puse otra vez en contacto con ellos para preguntarles si tenían algún inconveniente con la instalación pues mejor prevenir a que deshabiliten la web y su respuesta fue que no veían ningún inconveniente. Como pueden observar, en este tipo de servicios de alojamiento web es mejor ser proactivo y lanzarse a ver si es técnicamente posible.

Ventajas de los Unix-like para un profesional

Primero permítanme definir quien está a cada lado. Los Unix-like son todos los sistemas operativos Unix, por ejemplo OS X, FreeBSD, OpenBSD, Solaris… En este lado también pongo a Linux, aunque no sea exactamente un UNIX pues la licencia GNU significa «GNU’s not Unix» y una distribución Linux es básicamente el kernel de Linux más las herramientas GNU. Por otro lado… Windows, ¿es que hay alguno más? 🙂

Los Unix-like tienen la ventaja de que nos permiten optimizar esfuerzos pues los conocimientos adquiridos con ellos no caducan. Incluso conocimientos adquiridos en los años 70, antes de que surgieran los ordenadores personales o los modernos lenguajes de programación, siguen siendo válidos hoy en día. El equivalente en historia a 40 años en tecnología serían muchos siglos. En un mundo tan cambiante, donde en menos de una década todo cambia, Unix es la única constante de la que tengo constancia. El lenguaje C, las llamadas al sistema, los comandos, las «pipes»… ahí están desde el principio de los tiempos con pocas variaciones, así como su filosofía, probablemente la responsable de que haya podido sobrevivir tantas décadas.

Los desarrolladores y administradores de sistemas del otro lado siempre tienen que estar pendientes de lo que la compañía propietaria decida. Por ejemplo a finales del año pasado a todos los desarrolladores .NET les preocupó el anuncio de que se enfatizaría HTML y Javascript  como plataforma de desarrollo para Windows 8. ¿Iba .NET a ser extinguido? ¿Y todo el tiempo que le dedicaron y títulos oficiales de Microsoft pagados a precio de oro? Al final parece ser que la Runtime va a ser cambiada a COM y si los programadores .NET no quedan tirados es porque será accesible desde C/C++, .NET, etc. Aunque no sería la primera vez ni la última que una empresa deja abandonados a su suerte a los especialistas en alguna de sus tecnologías. ¿Qué pasaría por ejemplo si Sun abandonase Java? Tres años atrás me habrían tildado de loco por el mero hecho de plantear la posibilidad. Ahora las tecnologías de Sun pertenecen a Oracle, quien adquirió a la primera. ¿Qué futuro reserva Oracle para MySQL y Java? El que más le convenga a sus accionistas, obviamente.

Desde una perspectiva más general, las soluciones tecnológicas de Microsoft, Sun y demás enmascaran el problema solucionado detrás de otros problemas. Un profesional en una de esas soluciones tecnológicas es experto en solucionar esos problemas, pero si desconoce el problema principal, el problema que tecnologías como Java, .NET o Windows Server 200X quieren solucionar, al ser reemplazadas esas soluciones por otras el profesional tiene que partir otra vez, casi de cero, a aprender el reemplazo a la vieja solución y pagar de nuevo certificaciones que cuando proceden de grandes multinacionales son siempre costosas.

Nunca he odiado a Microsoft, algo bastante extendido entre los seguidores de las soluciones open source, bien al contrario le reconozco su gran labor de sacar la informática de las grandes multinacionales, bancos, ejércitos y grandes universidades y llevarla a los hogares, escuelas, oficinas y universidades, algo que les agradezco como esperan: pagando las licencias del software suyo que utilizo, básicamente Windows. Ahora bien, por el futuro de mi carrera profesional, prefiero soluciones open source como muchos de los Unix-like que existen ahora mismo y recomendaría lo mismo.