Para colores, 32 Bits

Via Xakata (copy & paste).

Ideas que vale la pena difundir. Ese es el lema de las ya casi legendarias charlas TED que nos han acompañado desde hace años y que se han convertido en un referente a la hora de descubrirnos proyectos y reflexiones que afectan a todas las ramas del conocimiento humano.

Es probable que hayáis visto algunas de estas charlas, pero tras el elogio y refutación que ayer hacíamos de estas dosis de conocimiento pop queríamos completar ese recorrido con una selección de algunas de ellas relacionadas con un campo en particular: el del futuro.

Lea el resto »

Ahora que llegan las navidades, uno puede tener la necesidad o la imperiosas ganas de cambiarse de teléfono.

Os traigo una lista de móviles que cubrirán vuestras necesidades.

Lea el resto »

Tras unos 20 años desde que me dí cuenta en primaria, he repetido hasta la saciedad (y sin tener el mínimo apoyo) que la masa es irrelevante en el momento que dos cuerpos se someten a caída libre.

El descubrimiento me lo hizo una profesora, estábamos en clase, y aplicábamos la fórmula de la gravedad, y caídas libres de objetos. No recuerdo la edad que tenía, pero por los 10 o 13 años andaría. Recuerdo la satisfacción que producía poder tachar la variable de la masa de ambas ecuaciones enfrentadas por un igual. Lo que equivalía a decir que daba igual la masa y preocupaba más la altura para saber el tiempo de caída libre.

Lea el resto »

Hace unos días quise cambiar un poco la estructura de los permalinks de la web sobre cine Filmclub.
Pensé que habría que hacer algo, pero comprobando las noticias (de cualquier antigüedad), el propio wordpress redireccionaba a lo que toca. Lo que cambié fue que en lugar de tener la estructura por día, la tuviera por mes (muchas de las webs con más pagerank y más tráfico obvian el día, por algo será). Pasando de tener una url como:

filmclub.es/año/mes/dia/titulodelanoticia/

A quitar el día quedando el tema así:

filmclub.es/año/mes/titulodelanoticia/

Qué fácil, pensé. No podía estar más medio-equivocado. A los pocos días empiezan a saltar errores de 404 en Google Webmaster. En realidad no lo entendía, hasta que vi que, aparte de algunos links mal puestos, lo que fallaba eran las URL que apuntaban a imágenes de posts.

Si ponía la url tal cual, fallo 404.

Si le quitaba el día, cargaba bien.

Si ponía la url tal cual pero quitaba la última parte de la URL, redireccionaba bien y cargaba la noticia.

Así que como no vi ninguna solución consultando por wordpres, nginx y rewrites, era hora de aprender algo sobre Expresiones Regulares, que siempre se me atrancan. Tras mucho probar y buscar, terminé usando un formulario de una web que parece que está hecha para Google Analytics. La web en cuestión es Metriplica, en su apartado de expresiones regulares, con documentación incluída y demás.

Al final es solo poner una regla de rewrite en el fichero .conf del dominio del Nginx. Tras jugar un poco con la web de Metriplica, pude conseguir la expresión regular siguiente (con el rewrite aquí):

rewrite ^/([0-9][0-9][0-9][0-9])/([0-9][0-9])/([0-9][0-9])/(.*) /$1/$2/$4 permanent;

Explicación:

De la URL que te pidan, se coge lo que venga después del dominio.

Si hay 4 separaciones o más, quiero que lo dividas en 4 variables, siendo la primera una que sea numérica de 4 dígitos (el año) de 0 al 9 cada dígito, la segunda también numérica de dos dígitos (el mes), la tercera igual que la segunda (para los días), y el resto (independientemente de que vengan números, letras, o graffitis.

Si lo de arriba coincide, hay que reescribir la URL quitando la tercera variable, ergo tendremos el año, el mes y el resto.

Marcar esto como cambio permanente. El rewrite con esa opción ‘permanent’ al final, devuelve un código 301.

Nada como aprender de esta manera para que se te quede.

DJI ha enseñado hace poco uno de los videos más espectaculares con drones que jamás se hayan visto. Y eso es porque han metido un drone cerca de un volcán en erupción con una cámara GoPro (como no podía ser de otra manera). El piloto del drone, Eric Cheng, capturó el video el sistema volcánico de Bardabunga, en Islandia usando un drone modelo ‘DJI Phantom 2’ con una GoPro Hero 3+. Tras un viaje de 11 horas a través de un terreno casi infranqueable, su equipo llegó a falta de 2 kilómetros del volcán, el cual expulsaba lava hasta los 150 metros de altura.

Lea el resto »

El otro día (en enero), tuve que hacer una migración porque los del datacenter iban a mover cosas. Así que me puse muy nervioso porque las migraciones tienen varios puntos a tener en cuenta, sobretodo si los DNS de varios dominios están involucrados o afectados.

El tema radicaba que realmente iban a darme un servidor nuevo y está localizado en Dusseldorf, cuando el anterior estaba en Munich (mera información adicional que tanto da). Con el mismo precio mensual, me daban una máquina con 8 procesadores, 16 GB de RAM y 4 discos de 1 TB configurados en RAID 5 por hardware, dándome un total de 2’7 TB útiles.
El tema radicaba en cómo mover los datos y que fuera una réplica exacta. Haciendo un poco de búsqueda por google, me encontré con los de 619Cloud que tenían un pequeño script comentado en este artículo. Aunque el script pone que es para CentOS, yo lo probé con Debian tras revisarlo concienzudamente y funciona… pero tiene un par de peros.

Primero:
El script está preparado para migrar máquinas virtuales, esto es que la máquina virtual tiene un hardware común y es una imagen exacta tanto la máquina en producción a migrar como la base sobre la que va a ir destinada. Aquí el único problema son los binarios.
Mientras que la máquina que iba a migrar tenía base 386, la nueva iba a ser x64 (cosa que NO tuve en cuenta). Al final la máquina funciona perfectamente, pero no puedo cambiar la arquitectura y, pese a que la instalación fue una Debian x64, se copiaron los binarios de 386… suerte que no copié la config de arranque del kernel.

Segundo:
Como herramienta principal, se usa RSYNC. Esto tiene varios inconvenientes: el ancho de banda usado será casi todo el disponible mientras ambas máquinas estén más o menos libres de carga (cosa que casi nunca pasa en un server en producción). Por otro lado, generalmente la máquina encargada de hacer los hashes de los ficheros será la de producción. Entre esto y que las transferencias no están maximizadas, se viene a usar 1/3 del ancho de banda disponible. Esto no sería problema si no tuviera montada una partición con datos muy tochos que podría haber desmontado primero y transferido por FTP (más rápido) después. Conclusión: la máquina estuvo 2 días sincronizando. Solución: paciencia y unos cafés.

Tercero:
Otro pequeño problemilla del RSYNC es que para hacer la lista de ficheros a transferir usa el mismo algoritmo que un ‘ls -l’, dando como resultado la ordenación de directorios por orden alfabético. Al hacer eso, hay mil librerias que se copian antes o después de los binarios que las van a ejecutar. Mientras la máquina de destino no se caiga o se corte la transferencia por lo que sea, el procedimiento seguirá su cauce como toca… pero la máquina de destino se comportará de manera errática (no se puede hacer login durante X horas porque los binarios de bash no encuentran su libreria, algunas cuentas de usuarios no aparecen, etc). La solución es la misma que en el apartado 2: paciencia hasta que termine.

Cuarto:
Hay que ir con cuidado a la hora de copiar la config del lilo y del grub, que NO hay que copiarlos. Ya he puesto algunas modificaciones en el script que lo que hacen es saltarse el lilo, la config del lilo, el grub y la config del grub. Así, por mucho que los binarios no sean los mismos, al menos tendrás un punto de arranque.
Aparte de eso hay varios ficheros de configuración que no se deben copiar (casi todo el /etc es útil): el hostname (para no liarse) y la configuración de red son los principales a NO copiar. Ello implica que el resolv.conf tampoco es válido (en realidad sí que es válido, pero más vale dejar el nuevo); otros dos ficheros que no hacen falta son el /etc/mtab y el /etc/fstab.

Como nota, aquí teneis el fichero original y el fichero modificado para migrar con las configuraciones necesarias.

NOTA: me queda pendiente reprogramar el fichero para que en realidad haga una lista de paquetes instalados, la transfiera a la máquina de destino y se instalen los programas en dicha máquina nueva antes de copiar nada, saltándose los directorios binarios y demás. Si alguien tiene ideas, que ponga comentarios.

Hace unos meses me apunté a uno de esos portales de trabajos para freelance. No me olía demasiado bien, porque era español (no es que haya nada en contra de los españoles, pero siempre se crean conflictos internos por el hecho de ser como somos).

Al principio las ofertas iban siendo variadas. Aparte de que no me gusta las restricciones normales por defecto, pero eso no era lo peor. Lo peor es la panda de imbéciles pidiendo trabajos variados pagando una mierda. He visto hasta para montar trackers de piratas…

Ahora os traigo una pequeña muestra, pues ayer recibí muchos proyectos ‘que se ajustan a mi perfil’ y es para descojonarse vivo.

Lea el resto »

Hace unas semanas, Cesar Alierta soltó la burrada de que «sin Telefónica, en España no existiría la banda ancha». Eso me hizo reflexionar en lo que se estuvo comentando hace meses si no años sobre la Tasa Google.

Cierto es que Telefónica impulsó las tecnologías en los 90, pero bajo una dictadura como tal desde su implantación como operadora única y dominante en el país, aparte de los flagrantes precios.
Hoy en día, lo que comentó Alierta ya no es así: ONO es una cablera que rivaliza y da mejor servicio en general donde tienen cobertura. Era una cosa cuestión de tiempo que entraran operadoras extranjeras a hacerse con el pastel.

Así como Telefónica fue una regresión/lastre durante sus ‘años mozos’, la verdad es que Google no existiría si no existieran los Bussiness Angels americanos. Cosa que aquí no pasa.

Intentaré explicar desde un punto de visto objetivo y entendido las dos vertientes de dicha tasa google (sobretodo por qué no es aplicable, o es una completa subnormalidad).

La primera vertiente es la lógica sobre lo que he comentado de los Bussiness Angels.

– Google es una empresa, como tal, es una simple usuaria como los millones de usuarios de eso que llaman Internet. Al igual que el resto, pagamos por un cierto ancho de banda.
Así como nosotros tenemos varios Mbits de bajada, y las empresas pueden acceder porque se lo desgravan como gasto y tienen lineas simétricas tanto de ADSL como de Cables.
ONO, en la última hornada, ofrece 50 Mbits/3Mbits a los usuarios a un precio muy razonable.
Así pues, Google como toda mega empresa que creció sin parar, pasó de estar conectada, a ser parte de esa red con sus propias mega infraestructuras y con canutos de fibra con cantidades ingentes de ancho de banda financiados por su caja.

Después de estas pequeñas divagaciones, voy a entrar en el ‘quid’ de la cuestión. Lo explicado viene a ser el motivo por el cual pagar una tasa de google es algo que no tiene sentido.
Recordemos que la tasa Google por parte de Telefónica era exigir a ciertos proveedores de información, empezando por Google Inc, dado que se usan masivamente (al menos en España) pagar un cierto ‘cánon’ por ‘usar sus redes’.

Para empezar, se ha malinterpretado el sentido de la comunicación… dado que Google no usa sus redes, sino los usuarios son los que acceden a los servicios de Google a través de las redes de las operadoras.
Es como si yo monto algo en mi casa dando un servicio donde la gente se conecta a mi, y tengo que pagar a Telefónica por el uso que hacen sus usuarios de mi conexión, la cual pago religiosamente y, además, es de otra operadora (ONO).

Así que, lectores míos, hacer pagar a Google es lo mismo: ellos ya pagan su megahipercanuto de internet. Además de que ellos no invaden ninguna red, son los usuarios los que usan sus propias conexiones para acceder a los servicios situados en otra operadora.

Algo ilógico el pago de este canon.

La segunda vertiente, adquiere un carácter más ‘bestia’ por decirlo de alguna manera:

– Si hacemos que Google pague, ¿por qué no pedimos lo mismo a proveedores de porno online como RedTube, MegaPorn, PornHub y demás?
Ahora no me digais que no le veis la relación.
Si hacemos que los proveedores de servicio paguen entendiendo el flujo del negocio totalmente a la inversa, los proveedores de porno también deberían pagar.
Una sesión de cualquier usuario consume mucho más ancho de bando que un par de días de navegación por Google.
En Google hacemos una petición y vemos un par de links de la primera página (pocas veces nos metemos a navegar por el resto). 1 MegaByte como mucho en total.
Si es el caso de buscar una imagen, podríamos consumir unos 2-5 MBytes con los previews hechos en su propia web de resultados.

Dicho lo anterior, si cobramos a Google, sitios como los que ofrecen porno o MegaVideo deberían ser requeridos para hacer lo mismo. La premisa es que una sesión con dichas webs consume mucho más ancho de banda que hacer búsquedas incansables durante días en Google.

Con MegaVideo, estamos hablando de que una peli usa entre 700 MBytes y 1 GByte de transferencia. ¡¡¡En 2 horas o menos!!!
El porno (si, si… aquí nadie consume porno, pero nos sabemos posturas, y direcciones web), puede usar unos cientos de megas si nos nutrimos de videos cortos. Si a eso le sumamos que hay más gente viendo porno que viendo pelis en MegaVideo, peor me lo ponen.

Así que solo tenemos dos opciones, en resumen:

– No cobrar porque es una auténtica gilipollez
– Si cobramos, cobramos a todos los sites de videos online, empezando por los porno.

Hace tiempo que no escribo por aquí chorradas de estas, pero esta vez ha tocado.

Voy a relatar mi experiencia comprando en este portal, perteneciente a una empresa mallorquina. Esto es un claro ejemplo de como NO hacer negocios.

No sé mucho sobre compra-venta de cosas, tarjeteros, comisiones ni negocios, pero llevo comprando por internet más de 10 años, sufriendo comisiones y gestionando mi tarjeta de crédito y mi dinero lo mejor que puedo.

Lea el resto »

He unido los plugins necesarios para hacer una instalación de WordPress completamente plana (sin uso de MySQL como base de datos).

El truco radica en que la base de datos se escribe en un fichero usando SQLite (así que el sistema debe tener las librerias SQLite para PHP instalado), y cada vez se consulta ese fichero. La ventaja es no tener que crear usuarios y bases de datos para montar una web simple y con poco movimiento de actualizaciones. Así simplemente se tiene que subir, descomprimir el fichero e instalar.

Esto básicamente es un conjunto de plugins y la última versión de WordPress estable en un ZIP. No he modificado nada, ni reprogramado. Esto TAMPOCO es FlatPRESS. Es otra edición para aprovechar todo el abanico que la comunidad de WordPress ofrece.

Podeis ver más detalles aquí.