06.16.16

Review Oculus Rift CV1, comparación con DK2

Dos añazos han pasado desde mi ultima entrada en el blog, han pasado en un suspiro, vueltas que da la vida.

Al tema. Esta tarde me han llegado las Rift cuyo preorder hice en el minuto 55, allá por Enero. Santa paciencia. El tochamen que viene a continuación lo escribí rapidamente para unos foros, pero ha quedado tan largo que he pensado que sería una buena forma de resucitar el blog. Ahí va!

---

Bueno, esta tarde me ha llegado el mío. Voy a dar impresiones desde mi punto de vista de usuario de DK2 desde hace casi 2 años.

En general
Primera impresion: El packaging muy cuidado. A mi estas cosas de unboxings y demás me la soplan, pero no he podido evitar fijarme en lo bien que han cuidado todos los detalles, y eso quita el miedo de sentir “pa que hostias me he gastado ese dineral”, al contrario, piensas que lo ha valido. Viene hasta con pegatinas swag para que la gente que las vea en tu portatil sepa que eres alguien que mola y te pidan autógrafos.

A destacar: el sistema elástico para ponerse/quitarse las gafas, muy buena solucion, especialmente comparado con el del DK2 que era un engorro.

Tiene una tela elástica que evita que entre el polvo a la pantalla interior, cosa que era una preocupación con el DK2. Con el CV1 lo puedes dejar tirado en cualquier sitio sin andar preocupándote en qué posicion es mejor dejarlo para que no le entre el polvo luego.

El cable es una bendición: viene un HDMI y un USB3 de la torre, y a los 20cms se juntan en un solo cable, manteniendo el grosor del cable HDMI a solas, flipante. Se puede pisar sin preocupaciones (no recomendado, pero con el DK2 parecia que iban a enroscarse los cables internamente y acabar rompiendo a la larga), es tan flexible como en el DK2, y tiene una longitud que deja claro que Oculus no tiene pensado limitarse a una experiencia sentada.

Tracking: como acabo de decir, el cable tiene una longitud decente. He hecho pruebas en un espacio de 1.5m x 2m, y sin problemas, desde estar de pie hasta estar agachado en todo ese volumen. El unico problema es si te agachas “con la espalda” mirando hacia la esquina opuesta de la cámara: al haber ahora mismo solo una cámara, tapas el headset con tu espalda y pierde tracking. Pero si te agachas “con las rodillas” mantiene el tracking sin problemas. No he notado perdidas de precisión obvias hasta 2.5m de distancia.
Aparte, como el casco tiene menos inercia que en el DK2, puedes hacer movimientos mas bruscos sin que se te bailen las gafas de posición en la cabeza, por tanto aguanta más caña dando sensación de solidez.

Audio

El audio es muy bueno. No soy audiófilo pero tampoco me conformo con unos cascos cualquiera y me tiro horas y horas comparando antes de comprar unos. Los del rift son semiabiertos, no me han defraudado en absoluto, tienen una respuesta en graves bastante más que aceptable, dicen que de calidad son similares a unos cascos bien escogidos del rango de 100 euros (no cascos en los que pagues marca y diseño). Hay que destacar que el HRTF es una maravilla. En más de una ocasión he podido sentir perfectamente si un objeto estaba detras, delante, encima o debajo gracias a ello. Es similar a unos 5.1, pero con la diferencia de que el tema también funciona en vertical 🙂

Mandos
El mando de XBox no consigo que funcione el pincho wireless en windows 7. Por suerte ya tenia otro mando identico pero su cable gigantenorme, asi que ese estoy usando de momento para moverme por la habitación. Si algun dia windows update se digna a funcionar, se bajaran los drivers del wireless y lo usaré.

El otro, el minimando, es util para subir/bajar el volumen sin andar buscando el teclado, tiene incluso indicador de bateria en Oculus Home, y es perfecto para experiencias simples de poca interacción en las que no estes sentado frente al teclado. Otro de los motivos por los que creo que Oculus va a cambiar su postura de “seated experiences only”.

El elefante de la habitacion son los Touch, porque no están. Si los rumores son ciertos los veremos antes de fin de año, y van a caer 100% fijo dadas las buenas reviews que estan saliendo.

Imagen

Calidad visual: lo que todo el mundo se pregunta. El SDE (el espacio negro en pixeles adyacentes) esta practicamente solucionado. Si te pones a buscar lo encontrarás, pero en condiciones reales de uso, no se nota.
Queda por tanto el tema principal, la resolución. Se nota la mejora respecto a DK2, y yo creo que merece la pena el upgrade. Para haceros una idea, si poneis el DK2 con pixels per display pixel a 2x (osea, renderizando a más de 4k), entonces el CV1 se ve en toda la pantalla algo mejor que el DK2 en el centro de sus lentes. Si al CV1 le poneis el p/dp a 2x ya la diferencia es clara.

Si alguno le da al Elite Dangerous, con el CV1 se pueden leer absolutamente todos los textos sin tener que inclinarse para verlos más cercanos.

Las lentes estan bien, tienen mas o menos el doble de área de enfoque que en el DK2. Su forma no-circular ayuda a darte más espacio para no chocar con la nariz (el DK2 acaba tocandome las narices con sus amplias lentes, tanto literal como figurativamente), y el ajuste de IPD es muy comodo de usar, modificable al vuelo en cualquier momento desde el menú de Oculus (por si andas haciendo demos al personal y quieres que lo vean perfecto).
Respecto a lo de que sea lentes fresnel hibrida o no, lo unico en que se nota es en los dichosos rayos de dios (god rays). Por si alguien no los conoce, se rata de unos rayos de luz (muy difuminados, eso sí), que parten desde los pixeles más luminosos hacia el exterior de la lente (de forma radial, desde el centro de la lente, para entendernos). Algunos dicen que solo se nota en escenas de alto contraste. Yo lo noto tambien en situaciones de contraste medio-alto. Por ejemplo, el lado a la sombra de un arbol, contrastando con un cielo azul de fondo. Tal vez me acabe acostumbrando y lo acabe ignorando inconscientemente (seguramente si), pero tras 2 horas de uso son claramente visibles y tocan un poco las pelotas. Pero nada grave, simplemente soy un poco quisquilloso.

La diferencia entre 60Hz con alta persistencia y 75Hz con baja persistencia en el DK2 era apreciable. La diferencia entre los 75Hz del DK2 a los 90Hz del CV1 yo sinceramente no la noto de forma directa. Lo que si que creo es que contribuye a la famosa “presencia”. Con el DK2 he tenido muy muy pocos momentos de presencia (de esto que te da por sacar la mano a intentar coger o mover algo, o a apartarte para esquivar un objeto), pero con el CV1 ya he tenido un par en el día de hoy. La escena del T-rex del dreamdeck ha sido una de ellas. Estoy seguro de que el audio con HRTF tambien ha contribuido a ello.

-fútbol +carreras
Ahora voy con el uso en simracing, que es el mayor uso que le doy. En concreto probado con Assetto Corsa. Si con DK2 cuestra leer el tacómetro y demás (hay que acercar un poco la cabeza para poder leer los numeritos), en el CV1 se leen sin tener que acercarse. Los menues se pueden leer todos sin moverte, los textos mas pequeños no estan tan nitidos, pero son legibles, por poco. Ahora, si habilitas el pixel per display pixel poniendolo a 1.4x, la diferencia es clara. Para mi ese es el punto en el que las CV1 me parece “suficiente” sin lugar a dudas para juegos de coches. SI lo subes a 2.0x la cosa mejora algo más, pero en mi equipo en concreto (gtx970) no consigo renderizar esa resolucion de más de 4k a 90fps, me quedo en entre 60 y 90fps segun el circuito y los coches que haya. El que tenga pepinos de la serie 1000, que lo pongan a 2x y disfruten.
Otra cosa que si que se aprecia claramente aqui son los 90Hz cuando miras por los cristales laterales del coche a velocidad. Se ve pasar el paisaje con mas nitidez que en DK2. Entre la resolucion extra, el SDE arreglado, y los 15Hz extra, es algo que se puede notar.
Mirando hacia adelante esos Hz extra no son apreciables conscientemente, pero inconscientemente ayuda a asentar el mundo virtual y que parezca todo más realista, más “estoy ahí metido de verdad” de presencia esporádica, comparado con el DK2. Yo al menos lo noto bastante.

Deberia escribir un libro. Perdon por el tocho pero seguro que a alguno le ayuda para decidirse 🙂

---

Hasta ahi llega la review tras 3 horas de uso. Ahora toca plantearse si vendo el DK2 o lo conservo de recuerdo.

07.5.14

Presentación GIT & GIT-SVN

Aprovechando la coyuntura, publico también unas transpas de una charla que dimos hace mil en la oficina, esta vez en spanish. Estaba orientado a novatos totales del git, pero familiarizados con svn:

11.27.12

Tramitar baja de ADSL YaCom

Interrumpimos temporalmente la emisión de posts en este blog para meter un offtopicazo, porque no me cuesta nada, y si con esto consigo ayudar a algún alma perdida de dios que quiera dar de baja su linea ADSL de yacom (ahora orange), pues algo bueno habré aportado…

 

Procedimiento a seguir (comprobado el día 27-11-2012):

1. Obtener el número de referencia de la baja:
   1. Usar el teléfono 900 900 282 (número  gratuito, aunque no aparezca a día de hoy en nomasnumeros900). Insistir varias veces si nadie coge, a la tercera va la vencida.
   2. Tras una breve charla (de verdad, es breve) sobre el motivo de la baja, se te facilitarán unas instrucciones (que proveo a continuación), así como un número de baja (de 9 cifras en mi caso concreto).
   3. Dar las gracias si la persona que te ha atendido ha hecho un buen trabajo y si te apetece (porque ir de pitufo gruñón por la vida no lleva a nada).
2. Enviar la carta:
   • Remitente: tú mismo…
   • Destinatario: YACOM – Apartado de Correos 35809 – CP 28080 – Madrid
   • Contenido:
     • Carta escrita con:
       • Nombre y apellidos del titular de la cuenta.
       • Tu número de teléfono fijo contratado con YACOM.
       • El número de contrato
       • El motivo de la baja, por ejemplo “Cambio de domicilio”, “Defunción por suicidio tras intentar dar de baja la línea durante varios días”, o cualquier otro motivo igualmente creíble.
       • El número de baja que te han facilitado antes por teléfono.
       • Firma del titular de la cuenta.
     • Fotocopia del DNI por ambas caras.
   • Las gentes de internet recomiendan no enviar una carta tradicional, sino un burofax, aunque vale con una carta certificada. El tema es que no pongan excusas tontas para seguir cobrándote durante meses.
3. La baja se comenzará a tramitar al de 7-10 días de recibir la carta/burofax (aunque legalmente disponen de hasta 15 días, no solamente 7 ó 10). En ese momento dejarán de facturar.
4. Después, esperar a que cobren la última factura. Desde su adquisición por parte de Orange, los cobros de YACOM se realizan después (y no antes) de cada período de facturación (que es del día 16 del mes anterior, al 15 del actual), por lo que tras recibirse la carta/burofax, quedará por llegar la última factura. Ésta debería estar prorrateada para reflejar los días reales que se ha utilizado la línea, y no necesariamente el período completo de facturación. La factura llegara a finales de mes.).
5. Por su seguridad, y con el justificante de envío de la carta/burofax en mano, mandar orden al banco de rechazar recibos de YACOM.
6. Alea jacta est!

 

Por último, no hace falta que leais este párrafo a partir de este punto, porque esgrimiendo mis increíbles habilidades de ese-e-o, escribiré algunas palabras clave para que la gente que quiera dar de baja, cancelar, eliminar o dejar de pagar su línea de conexión de acceso a Internet de banda ancha de ADSL con teléfono fijo del proveedor de Internet y telefonía fija YACOM, a veces también llamado ya.com, y comprado recientemente por Orange, pueda encontrar este post mediante busquedas tan típicas como “Quiero dar de baja mi linea de YACOM”, o “Cómo cancelo mi conexión de internet con ya.com 10 megas”, o tal vez “Hoygan no consigo dar de baja mi adsl de yacom, ¿cómo hago?”, o incluso “Me gusta el olor a ISP quemado por la mañana”, en su buscador preferido.

 

Muchas gracias por su atención, y tengan un buen día.

 

10.24.12

Liberación de recursos en python

f = open("foo.txt", "r")
text = f.readlines()
f.close()        # WAT.

with open("foo.txt", "r") as f: # WAT.
    text = f.readlines()

No es necesario hacer un close:

La vida de las variables en python es un detalle de implementación:

Bugs de terceras partes:

Bugs propios:

Variables de instancia:

def __init__(self):
    self.my_file = open(...)
    print self.my_file.readline()
    # el recurso permanecerá abierto al menos
    # hasta que el objeto self sea eliminado

Variables dentro de una función de larga duración:

my_file = open(...);
print my_file.readline()
while True:
    # bucle principal del programa
    # my_file sigue con el recurso abierto al
    # menos hasta el fin de la función

Variables que por su naturaleza son compartidas:

Variables referenciadas por closures:

def my_function():
    my_file = open("foobar")
    def internal_function():
        return my_file.readline()
    return internal_function
my_closure = my_function()
# my_file sigue existiendo y con el archivo
# abierto, hasta que se destruya my_closure

Ámbito de función, no de bloque:

for path in ["/a.txt", "b.txt"]:
    my_file = fopen(path...)
    print my_file.readline()
print path    # va a imprimir "b.txt", aunque
              # estemos fuera del bucle.
print my_file # lo mismo pasa con my_file, aunque
              # pueda ser anti-intuitivo
del my_file   # si queremos que se elimine esta
              # referencia a la variable, y el GC
              # pueda hacer su trabajo en algún
              # momento indeterminado

while True:
    #bucle principal de duración infinita

01.29.12

Zonas horarias, DST, Desplazamientos y otras zarandajas

[ Ir a la parte 1 de 2: “Sobre la Hora Universal y los relojes atómicos (o qué tienen en común el TomTom y unos trigales)” ]

Continuamos desentrañando el misterio de las horas, orientando la explicación principalmente a programadores.

Hemos establecido qué sistemas de medición de la hora existen. También hemos visto que el estandard de facto es UTC, y por buenas razones.

Y ahora vamos a ver como se pueden representar esas horas en una aplicación.

A efectos prácticos, en este artículo voy a llamar “hora” al conjunto de “fecha+hora“.

 

Conceptos básicos

Repaso de UTC

Quedabamos en que UTC es una hora universal, que trata de indicar la hora del planeta Tierra en general. No está ligado a ningún país en concreto, ni a ningún continente, sino al planeta entero: España no tiene horas UTC. Argentina no tiene horas UTC. El planeta Tierra sí que tiene horas UTC.

Si en una hora UTC particular es pleno día en España, entonces en esa misma hora UTC será noche cerrada en sus antípodas; y será el amanecer o el anochecer si nos quedamos a medio camino entre ambos puntos.

UTC no sufre saltos [*], sino que avanza siempre a una velocidad constante. Porque el planeta Tierra tampoco sufre saltos ni rotaciones bruscas en ningún momento (menos mal :-D).
[*] Técnicamente sí (tiene saltos por debajo del segundo), pero se puede ignorar perfectamente para este artículo.

 

Hora Local (Local Time)

Los habitantes de este planeta estamos acostumbrados a hablar en términos locales. Yo, como habitante de Madrid, puedo decir “Me levanto a trabajar a las 07:00”. Un japonés, a su vez, puede decir “Yo también me levanto a trabajar a las 07:00”. Pero obviamente no hablamos de la misma hora UTC, sino de una hora “local”.

Trabajar con horas locales puede ser complicado, por ejemplo cuando el locutor se desplaza de sitio. Si despegas de Madrid a las 10:00 (hora local madrileña), vuelas 10 horas, y aterrizas en Miami, la hora local de Miami no serán las 20:00, sino otra, que hay que calcular en base a unos cuantos factores.

En cambio, si despegas a las 10:00 UTC, sí que aterrizas a las 20:00 UTC.

Desplazamiento (Offset)

El offset es, literalmente, la siguiente resta matemática: hora local – hora UTC.

Por ejemplo: La hora local actual en Madrid es finales de Enero a las 20:00. La hora UTC actual en el planeta es finales de Enero a las 19:00 UTC. Por tanto, 20:00 – 19:00 = 01:00 de offset.

Inciso sobre el Horario de Verano:

El Horario de Verano, como sabeis, tiene como objetivo reducir el consumo eléctrico, tener más luz durante las horas laborales, etc (al margen de que se consigan o no dichos propósitos :-P).

Consiste en mover las manecillas de los relojes locales de un país, para atrasar o adelantar la hora local durante unos meses determinados, cada año.

• Lo típico es atrasar o adelantarlo 1h, pero en algunos paises es 30 minutos.
• Cada país lo puede aplicar durante unos meses diferentes: de marzo a octubre, de abril a septiembre… Los días exactos también pueden variar.
• En muchos países ni siquiera se aplica el Horario de Verano.

En cualquier caso, el offset ya lleva incluído el horario de verano cuando se usa, puesto que el offset se obtiene restando la hora local (que ya lleva aplicado el cambio horario) y la hora UTC.

Otro ejemplo: En Agosto de este año se habrá aplicado el horario de verano en Madrid, por lo que el offset no será 01:00h sino 02:00h.

El offset de una localización geográfica puede variar tanto a lo largo de un mismo año, como hemos visto, pero también a lo largo de varios años. Por ejemplo:

• Antes del 1901, cada provincia española tenía su propia hora local, en base a su meridiano concreto. Ahora ya no.
• En el 1918, en España se decide empezar a aplicar el horario de verano, que nunca antes se había utilizado. El offset ya no es el mismo todo el año, sino que aumenta 1h en verano (como en el presente).
• El 16 de Marzo de 1940, España decide incrementar todos sus relojes en una hora: el offset pasa de 0h a 1h en invierno, y de 1h a 2h en verano. (se ha cambiado la zona horaria, que explico más abajo)
• Si varios paises con diferentes horas locales eliminan sus fronteras políticas para unirse en un solo país, seguramente modifiquen sus horas locales para coincidir en todo el territorio (variando por tanto el offset).

Por tanto, es perfectamente posible que dos países tengan el mismo offset durante algunos meses del año, pero difieran durante otros.

Dicho de otra forma: a partir de un offset, no se puede deducir en qué localización te encuentras, ni por tanto qué otros offsets existirán en otros momentos del año.

Por ejemplo: Si no sabes si tu +01:00h actual es de Madrid o del Congo, no puedes saber si en Agosto será un +02:00h (caso de Madrid), o se mantendrá en +01:00h (caso de Congo, sin horario de verano).

 

Zona horaria (Time Zone, o TZ)

Se dice que varias poblaciones están en una misma Zona Horaria, cuando desde el año 1970 han compartido siempre la misma hora local. La nomenclatura es “Area/Localización”.

No hay que confundir con los husos horarios, meridianos ni offsets. Son conceptos diferentes: “UTC+02:00” no es realmente una Zona Horaria, es un Offset respecto de UTC.

Por ejemplo: En España, desde el 1970 hasta ahora, han existido tres regiones que no siempre han compartido completamente las horas locales en todo momento. Las tres zonas horarias (o TZs) son:

• Europe/Madrid: para la península y baleares principalmente.
• Atlantic/Canary: para el archipiélago canario.
• Africa/Ceuta: para Ceuta y Melilla.

Actualmente, esas 3 timezones usan horario de verano, por lo que actualmente sus offsets respectivos de invierno son 1h, 0h y 1h; y los de verano 2h, 1h y 2h.

Cada TZ ha tenido un pasado diferente: algunos aplicaron el horario de verano durante 20 años, otros no lo aplicaron; unos tenian un offset de 5h, otros de 10h, etc.

Toda esa información se almacena en lo que se llama tz database (en castellano, base de datos de zonas horarias).

La tz database debe ser actualizada constantemente, reflejando los cambios horarios que se pueden producir a lo largo de los años.

 

Empieza el meollo de la cuestión

Una vez que conocemos los conceptos básicos, podemos pasar a la acción:

¿En qué me influye todo eso a la hora de diseñar mi software?

¿Cómo gestiono las horas correctamente?
¿Y si mi usuario vuela de España a la India y cambia el reloj de su portatil?
¿Y si mi usuario quiere introducir la hora local de despegue y la hora local de aterrizaje en mi software de calendario?
¿Y si mi software tiene varios usuarios simultáneos en diferentes zonas del mundo?

Una política habitual en el mundo de la programación es:

“Almacena y procesa globlamente, muestra localmente“.

Dicho de otra forma: elige un formato neutro para almacenar y operar sobre los datos, y preocúpate de las particularidades culturales cuando debas mostrar o recoger los datos de un usuario final.

Recordemos que en este post se usa la palabra “hora” como abreviación de “fecha+hora“.

 

“Almacena y procesa globalmente”

Empecemos con un ejemplo sencillote:

Tenemos una variable tipo entero, cuyo valor es 7 millones.

• El ordenador almacena y opera globalmente. Concretamente, usa el binario: 00000000011010101100111111000000.
• En cambio al mostrarlo en una hoja de cálculo, nos puede mostrar “7.000.000“, o bien “7,000,000“, o tal vez “7e6“, o incluso “######“, según el contexto local (dónde vivimos, tamaño de la celda, formato del número…).

Tenemos una Hora Local, las 15:00 de un día de Enero. Se le quiere sumar casi medio año (24h*180días=4320h) a esa hora. ¿Cuál será la Hora Local resultante?:

1. Las 15:00 hora local, como en la hora de partida.
2. Las 16:00 hora local, porque hay que aplicar el Horario de Verano.
3. Ninguna de las 2 anteriores.
4. Cualquiera de las 3 anteriores.

Y la solución es 4) Cualquiera de las tres anteriores, puesto que depende de la zona horaria:

• En el Moscú actual o el Madrid del año 1910, no hay horario de verano, luego sería 1) Las 15:00.
• En el Madrid actual hay horario de verano, luego sería 2) Las 16:00.
• En la Isla de Lord Howe hay horario de verano de 30m, en vez de la hora típica, luego sería 3) Las 15:30.

Queda claro entonces que la única forma de operar correctamente con horas es pasarlas a UTC, operar sobre ellas y finalmente (si hace falta), convertirlas a la Hora Local de nuestra elección para mostrárselo al usuario final.

 

“Muestra localmente”

Hemos establecido que, para la interfaz con el usuario final, necesitamos conversiones de UTC a Hora Local (al renderizar en pantalla) y viceversa (al aceptar datos del usuario)

Si habéis entendido perfectamente todo lo explicado hasta hora, se pueden deducir cuáles son las posibles conversiones inequívocas que podemos hacer:

[table id=3 /]

a) Almacenar el offset no vale para mucho

b) El usuario debería poder especificar el offset al introducir una hora

 

Ultílogo

 

[ Ir a la parte 1 de 2: “Sobre la Hora Universal y los relojes atómicos (o qué tienen en común el TomTom y unos trigales)” ]

01.25.12

Sobre la Hora Universal y los relojes atómicos (o qué tienen en común el TomTom y unos trigales)

[ Ir a la parte 2 de 2: “Zonas horarias, DST, Desplazamientos y otras zarandajas” ]

Con este ladrillazo de artículo intento esclarecer unos cuantos detalles sobre esos grandes desconocidos que son UTC, GMT y demás acrónimos indescifrables.

 

Obligatory disclaimer: Intento dar una explicación inteligible, no algo 100% tećnicamente correcto. En parte porque… bueno, tampoco soy aquí un experto en la materia ;-). Tanto mis fuentes como mi interpretación pueden ser erróneas. Así que si algo canta, os ruego dejéis un comentario para corregirlo.

 

TAI

TAI es una medición del tiempo, independiente del planeta Tierra, del sistema solar, y de cualquier astro en general. Está basada en relojes atómicos.
Empezó a medirse en el 1972, y es completamente independiente de cualquier otro sistema de medición.

Si el día de mañana cae un meteorito que ralentiza el giro del planeta, haciendo que los días duren 3 minutos extra desde ese momento, al TAI se la trae floja. 😀

Actualmente el TAI lleva un desfase acumulado de más de medio minuto (porque la Tierra ha ido ralentizándose desde 1972).

 

UT

UT es una medición del tiempo, conforme al planeta Tierra. Por tanto, UT varía si el comportamiento de la Tierra varía.

Ejemplos: movimientos de placas tectónicas, terremotos, el susodicho meteorito de los dinosaurios, mareas por la Luna, o por si al Sol, Saturno y Jupiter les toca alinearse, etc.

El UT puede medirse de muchas formas diferentes. Ninguna de ellas se puede dar como Verdadera ™ realmente, porque la Tierra ni siquiera es una esfera, y esto de “la hora del día” es una invención humana al fin y al cabo.

Existen unos cuantos de esos métodos de medición: UT0, UT1, UT1R, UT2, UT2R, y UTC (para más info: UT Versions).

 

UTC

• UTC, en concreto, usa una especie de media entre varios relojes atómicos situados en diferentes puntos del planeta (por efectos relativistas que no vienen al caso)
• UT1, por su parte, usa fuentes “externas” (como cuásares, posiciones de satélites, etc) para intentar medir el UT. Se suele considerar como la mejor técnica de las existentes. Aunque es algo subjetivo, claro está, y dependerá de la aplicación.
• Al offset que acumula UTC respecto a UT1, se le denomina DUT1.

 

Por definición, UTC debe mantener el DUT1 por debajo de 1 segundo.

 

Este año 2012, el DUT1 anda muy cerca del segundo, por lo que en Junio el UTC sufrirá un salto para corregir ese DUT1 excesivo. A eso se le llama leap-second.

Los ordenadores se suelen sincronizar via NTP con un proveeder de UT basado en relojes atómicos (UTC), de ahí que se use tanto el término UTC en computación.

Si quitas todos los leap-seconds que ha habido, UTC se convierte efectivamente en TAI.

GMT

GMT es lo que se usaba antes de establecerse los UTs actuales para medir el tiempo del planeta Tierra. En el 1972, se decidió pasar a llamarlo “UT”, sin más, así en general. A veces GMT se refiere a UTC, a veces a UT1, y a veces a lo que usaban antes del 1972 (observaciones únicamente desde el meridiano de Greenwhich).

Además, GMT es una zona horaria usada como referencia para otras. Por ejemplo, GMT (ó GMT+0), es usada en ciertas épocas del año por UK.

No solo eso, sino que el viejo GMT tuvo varias definiciones: inicialmente se ponía la “hora cero” al mediodía (muy usada por astrónomos, y ahora llamada GMAT), y más tarde, a la noche. El cambio se produjo al pasar del año 1924 al 1925. Ese año Diciembre no tuvo 31 días, sino 31.5 días.

Resumiendo, tenemos unas cuantas acepciones de GMT:

1. Sistema previo al 1924 (basado en mediodía, también llamado GMAT)
2. Sistema entre 1924 y 1972 (basado en medianoche)
3. Sistema posterior al 1972 (UT1).
4. Sistema posterior al 1972 (UT1+DUT1, es decir, UTC).
5. Zona horaria de algunos países.
6. Otras posibles acepciones (cualquier otro UT) en fechas posteriores a 1972.

Efectivamente: al explicarlas, las siglas GMT suelen ir acompañadas de las siglas WTF.

Por todo ello, GMT se puede usar en entornos informales (peliculeros, noticiarios, o lo que sea). Pero en entornos computacionales, militares, médicos, aeronáuticos, y cualquier otro que sea crítico, lo mentalmente saludable es usar siempre algo como UTC.

 

TomTom y los trigales

En realidad esto de los trigales lo había puesto por atraer un poco la atención (¿¿ha funcionado??), pero ya que estamos, habrá que explicarlo…

El GPS como sabéis, utiliza satélites. Concretamente, utilizan muchísimo las mediciones de tiempo para poder estimar la posición y altitud. Es imperioso que todos los GPS funcionen en un marco horario común, o sino los delicados cálculos de vuestro TomTom no valdrían para nada.

Usar UTC no es muy serio, por el tema de los leap-seconds. UT1 tampoco es especialmente útil, porque cambia continuamente, según cambia el planeta Tierra.

Así que los GPS usan su propio sistema, el GPS-Time. GPS-Time es idéntico al TAI mencionado al principio del post, pero tiene un offset constante de unos 19 segundos. Esto se debe a que el GPS-Time coincidía con UTC en el momento de su creación (en 1980), pero no avanza a la velocidad de UTC, sino a la del TAI.

Si el GPS-Time tuviera una velocidad variable como cualquier UT, entonces sería facil que el navegador del coche acabara situándote 100 metros más allá de donde realmente estás, plantándote en medio de una pradera, o en el fondo de un lago.

Así que, por suerte para los conductores, el TomTom y los trigales tienen pocos puntos en común.

 

Zonas horarias, DST

¿Creíais que empezabais a entender el tema?

Pues olvidaos, porque aún falta todo el tema de zonas horarias y DST, que es la verdadera miga del asunto en lo que a programación se refiere.

Y eso que no se han tocao apenas temas tangenciales, como pueden ser los meridianos de referencia, las horas métricas, las horas decimales como la Internet Time de Swatch, el protocolo NTP con sus stratums…

 

Pero lo dejo ahi, porque bastante gordo ha quedado ya el post!

 

[ Ir a la parte 2 de 2: “Zonas horarias, DST, Desplazamientos y otras zarandajas” ]

02.5.11

Cliente *libre* de mensajeria en la nube (part 2)

(…continuación de la parte 1)

Bueno, andabamos en las nubes con el tema de mensajería. Para recapitular, el objetivo era:

• Conectividad 24/7
• Acceso a todas nuestras redes de IM con el mínimo esfuerzo
• Software libre por donde se pueda.

En la primera parte, hemos solucionado la papeleta mediante GNU Screen, Finch y una conexión SSH. La solución mola porque es completa, y no hace falta ningún software “raro” en los ordenadores cliente (solamente un cliente ssh). Para hacernos a la idea, quedaba tal que asín:

Pero tiene algunos defectos:

• Hay que usar exclusivamente el teclado (finch + screen + ratón es algo lioso de configurar, yo no lo he conseguido).
• Los enlaces multilínea pueden no ser reconocidos en su totalidad por el emulador de terminal que usemos, así que en esos casos, toca copy-paste de los cachos de enlace que haya en cada línea.
• Puede ser poco responsivo dado que, al fin y al cabo, screen+ssh es como un VNC de texto plano… y se nota cuando escasea el ancho de banda.

Así pues, intentaremos arreglar esos defectos:

Segunda solución: Bitlbee + Quassel IRC

Ahora vamos a ponernos en la piel de un Ubuntero típico de hoy en día: apesta andar con conexiones ssh, y más aún aprenderse que alt+n es para el siguiente tab de finch, o que ctrl+a,F redimensiona los contenidos del screen a nuestra terminal, etc…

Así pues, vamos a intentar tener un cliente de IM gráfico: en el que se pueda hacer copy-paste con el ratón, hacer clicks para hablar con las personas, y ese tipo de cosillas que se vienen haciendo desde hace 2 décadas. Por desgracia, no conozco ninguna solución tan elegante como la primera, por lo que esta vez va tocará instalar una aplicación en cada cliente que usemos, con un mínimo de configuración. Tampoco es mucho pedir, no? 🙂

Pasos a seguir:

1. Instalar Quassel Core en el servidor (ponerlo en un bucle o demonio para que esté siempre rulando)
2. Instalar Bitlbee en el servidor (ponerlo tb a lo demonio)
3. Instalar al menos un cliente de Quassel para hacer la configuración inicial.

Pero vamos por partes.

Quassel IRC es un cliente de IRC que tiene una estructura cliente-servidor para la interfaz gráfica. Es decir, puedes tener o no tener una ventana (Quassel Client) abierta, y puede estar en el mismo o en otro ordenador que el servidor (Quassel Core). Lo mismo que hace MLDonkey y Amule, para entendernos.

Podeis pensar que vaya chorrada, que para eso ya hay otros protocolos estandard como VNC, o el propio SSH con X-Forwarding habilitado para usar unas Xorg remotas. El tema es que el protocolo de Quassel está especializado en… en sus cosas, por lo que es mucho más eficiente, más rapido, y a veces hasta te plancha la ropa. No hay color, vamos… si habeis usado VNC o X remotas, sabeis a qué me refiero.

Bitlbee, por otro lado, es una jartada de software que básicamente hace de pasarela desde diversas redes de IM hacia/desde IRC. Es decir, Bitlbee te permite interactuar con MSN, ICQ, Jabber, incluso Twitter y Facebook, mediante cualquier cliente de IRC. Se puede decir, por tanto, que es literalmente un servidor de IRC (uno muy curioso, sí xD).

Bitlbee utiliza un canal IRC especial, el #&bitlbee, dentro del cual mete como participantes a todos tus contactos de IM (del messenger, gtalk, etc). De esta forma, si coges un cliente IRC para conectarte a ese canal, la lista de participantes es realmente tu lista de contactos multiprotocolo. Obviamente, al usar IRC como pasarela, perdemos features (como los avatares del contacto, las razones de estar /away, etc). Basta tirar un /query a cualquier contacto para iniciar una conversación con esa persona.

Así que la idea es, usar un cliente de IRC (Quassel Client) en cada ordenador que queramos conectar a las redes IM, y conectarnos al servidor IRC Bitlbee que aúna todas ellas en un solo punto centralizado y nuboso.

Existe una posible pega: si nuestro build de Bitlbee no tiene libpurple como backend (sí, el mismo que usa Pidgin y Finch, entre otros), no hay soporte de pasarela para redes IRC, con lo que tenemos que configurar nuestras redes IRC en cada cliente/ordenador que usemos. La cosa quedaría tal que asín:

Si os atrevéis a montar todo este lío, los pasos un poco más detallados de configuración inicial son:

1. Instalar como demonio Bitlbee en el servidor. Si no vamos a usar teléfonos moviles, podemos limitarlos a conexiones en 0.0.0.0 (conexiones del core de Quassel, que está en la misma máquina) para mayor seguridad.
2. Instalar como demonio Quassel Core en el servidor.
3. Instalar un Quassel client en un sobremesa o portatil y conectarlo al core.
4. Una vez conectados al core, le añadimos el servidor IRC de bitlbee en “localhost” (el propio servidor nuboso), con puerto default. Adicionalmente, podemos configurarle nuestras redes de IRC habituales (Freenode, etc), a menos que las vayamos a meter en el propio Bitlbee (solo si tiene libpurple de backend, como ya he mencionado).
   Toda esta configuración se guardará en el core, así que no hay que hacerlo de nuevo nunca más.
5. Al conectarnos al servidor IRC de bitlbee, se unirá al canal #&bitlbee automáticamente. Aquí es donde toqueteamos los settings de Bitlbee (todas las redes de IM, etc).
   Primero, nos registramos en Bitlbee con una contraseña, para poder guardar los settings: register <contraseña>
6. Ahora añadimos las cuentas de IM a Bitblee con unos comandos especiales: account add <parámetros>. Para más información, aquí hay una guía rápida de Bitlbee.
7. Una vez añadidas las cuentas IM, guardamos estos settings en Bitlbee con: save
8. Y ya, si queremos, podemos configurar Quassel para que automáticamente ejecute un /identify <contraseña> al conectar, para que se autentique en Bitlbee y nos cargue toda la configuración del tirón (lo mismo que la autenticación de la mayoría de servers IRC, vamos).

Si a estas alturas seguís despiertos, entonces habéis configurado por fin vuestro molón cliente de IM en la nube! Congratulations! 😀

Y para terminar, así es como pinta la cosa una vez hecho todo:

Una vez escrito el post, veo que al final puede ser o parecer un poquillo más complicado que la primera solución, por lo que si tenéis alguna duda, y yo algo de tiempo libre, podéis preguntarme aki abajo (o en mi buzz, o donde queráis, con tal que sea un sitio público para que el resto del internet se pueda beneficiar de las explicaciones), y os intento echar un cable.

Hasta la próxima, frikomaníacos!

02.3.11

Cliente *libre* de mensajeria en la nube (part 1)

Vamos a darle un poco de caña al blog, que lo tengo abandonao! Voy a explicar como tener un cliente de mensajería instantánea en “la nube”. Antes de nada,  vamos a explicar el concepto.

El Concepto

Tradicionalmente, nuestro usuario Joe tiene:
– Un chat en Facebook
– Un chat en Gmail (Google Talk)
– Un chat en su PC (Microsoft Messenger)
Y algunos frikis tenemos además cuentas de ICQ, Jabber, IRC, y quién sabe qué más.

Tanta nube, tanta nube, pero necesitamos configurar un cliente de IM en cada ordenador (sobremesa, netbook, oficina…). Los clientes multiprotocolo (como Kopete o Pidgin) ayudan un poco. Pero cuidado como intentes conectarte desde varios ordenadores a la misma cuenta de MSN o de ICQ (porque es técnicamente imposible). Y si además quieres buscar algo en tu historial de conversaciones, te hará falta mucho café, algunas aspirinas, conectividad a todos los ordenadores y webs por las que hayas hablado, y una buena dosis de bash-fu para parsear todos los logs.

Lo suyo sería olvidarse de tanto protocolo, y usar Apache Wave, pero como a la gente no le gusta el cambio, voy a presentar no una, sino DOS soluciones a este problema. En ambos casos, nos hace falta una nube, es decir, un servidor que vaya a estar online permanentemente. Ya sea algún hierro viejo encendido en el trastero, o un servidor alquilado a terceros en la vasta red.

Ambas soluciones permiten:

• Estar conectado 24/7 a todas nuestras redes de IM, sin necesitar un solo ordenador encendido en casa.
• Tener el historial de conversaciones en un sitio centralizado.
• Poder acceder a esas redes simultáneamente desde varios ordenadores, sin ningún problema en absoluto.
• No necesitar configurar nuestras redes de IM en cada ordenador que toquemos.
• No depender de software propietario para nada.

Primera solución: ssh + screen + finch

Si eres un frikón como dios manda, conocerás GNU screen. Esta utilidad permite tener sesiones de terminal abiertas “en background“, pudiendo verlas en pantalla u ocultarlas cuando se quiera.

SSH, obviamente, es una forma de conectarte de un ordenador a otro, ya sea con putty, openssh, o el cliente de turno.

Y finalmente, Finch es, para entendernos, un Pidgin portado a la terminal. Es un cliente IM multiprotocolo, que en vez de GTK o QT, usa letras en tu terminal. De hecho, tanto Finch como Pidgin se apoyan internamente en libpurple, una librería de IM multiprotocolo.

Como montamos el tinglado entonces?

1. Instalamos screen y finch en nuestro servidor.
2. Configuramos nuestras cuentas de mensajería en ese finch, una sola vez.
3. Creamos un bucle/demonio/cron que mantenga finch arrancado en un screen todo el rato (por si peta, que se arranque de nuevo él solo).

Una vez hecho esto, basta conectarnos vía SSH al servidor, y acceder al screen donde está finch encendido. Por ejemplo:

$ ssh stenyak@servidor.com
$ screen -x miFinch

Y en pantalla veremos nuestro cliente, con su lista de contactos, sus pestañas para cada conversación, etc.

Por ejemplo, he aquí una sesión de Finch conectado a GTalk, MSN y un canal IRC en Freenode:

(por si alguien se pregunta donde entra Facebook en todo esto, comentar que el chat de Facebook tira desde hace bastantes semanas del protocolo Jabber. No es 100% compliant, pero cualquier cliente de Jabber decente debería poder conectarse a él)

Como podéis comprobar, es una solución solo apta para muy frikis. Los logs están todos legibles en texto plano en ~/.purple/logs.

Segunda solución

Pero a estas alturas de la vida, muchos linuxeros prefieren poder hacer clics y cosas así; por ello existe otra segunda solución, que como es un poco tarde, explicaré en el siguiente post.

Stay tuned!

(continúa en la parte 2…)

05.1.10

Yuki TV

Akí teneis a Yuki en vivo y en diferido!

No estaba muy activa en ese momento, pero a veces se pone a dar vueltas por el sofa y no hay quien le haga una foto, así que mejor así.

03.25.10

El nuevo mando para Wii, out now!

Se llama Yuki! Ni lo ha fabricado Nintendo, ni vale como micrófono, pero mola un cacho.

Al igual que Kintaro con sus currelos, todos los días se aprende algo nuevo con los erizos.

Hoy he aprendido que si la eriza quiere suicidarse sofá pabajo, mejor no intentes salvarla. Su técnica ninja de aterrizaje pelota-style funciona. Agujerearte la mano intentando frenar suavemente su caída, no.

Otras cosa que les gustan hacer, aparte de tirarse por precipicios, es engancharse a lo anzuelo en tubos demasiado pequeños.

Como veis, también le gusta programar en PHP. Aunque estoy pensando en enseñarle un lenguaje más apropiado, de más bajo nivel.

Nada más anochecer, se pone a darle un poco al PacMan mientras come (lo que en realidad es su desayuno, $DEITY sabe por qué).

Bueno, hay mil fotos más, pero con esto vale rescatar el blog, y de paso seguir la serie de petposts.

Follow

Tags

Recent Posts

• Diagnosing and disabling bugged CPU cores
• Track Tour Episode 1: Circuit de Spa-Francorchamps (1967 edition)
• VR Showdown – Quick review of 11 headsets
• Review Oculus Rift CV1, comparación con DK2
• Presentación GIT & GIT-SVN
• Grokking Git in 8 slides (for svn users)
• Hacking the LGA 775 socket
• In defense of unformatted source code – breakindent for vim
• Trick of the day: rendering graphics in your terminal
• Helpful VIM highlighting