Hacking the mele: Intro

Mele A1000

El viernes 18 llegó a casa un nuevo juguete, un Mele A1000 ($100, 77€ con gastos de envío incluidos). Comprado en savingelectronics.com. Tardan 2 semanas, bien envalado y marcado como regalo y valor inferior a $20 (para no pagar aduanas).

Se pueden conseguir más baratos (si hay stock), Tom Cubie ingeniero de AllWinner los compra en fábrica y los vende directamente en su tienda propia con un beneficio mínimo (aliexpress.com).

Realmente es el artifice del exito y verdadero promotor de un “appliance” con una calidad/precio muy interesante, primero promocionandolo y luego ayudando con las especificaciones tecnicas para tener aceleracion hw en linux (originalmente viene con android 2.3 y sin fuentes).
El catalizador de este movimiento modding ha sido la rapsberry pi, $25 por una placa ARM que es un servidor en si mismo. Pero problemas de distribución de la rapsberry y un pack competitivo han hecho que la comunidad se fije en el A10.

Las Specs del mele A1000

  • 1.2ghz Cortex A8 ARM Core
  • MALI400MP OpenGL ES 2.0 GPU
  • DDR3 Controller 800MHz 1GB max
  • 2160p Hardware-accelerated Video playback (4x the resolution of 1080p)
  • a NAND Flash Controller that is capable of 8-way concurrent DMA (8 NAND ICs)
  • 4 SDIO interfaces (SD 3.0, UHI class)
  • USB 2.0 Host as well as a 2nd USB-OTG Interface (USB-OTG can be reconfigured as USB 2.0 Host, automatically)
  • 24-pin RGB/TTL as well as simultaneous HDMI out
  • SATA-II 3gb/sec
  • 10/100 Ethernet (MII compatible), 802.11b/g/n
  • a 2nd 24-pin RGB/TTL interface that is multiplexed (shared) on the same pins for a standard IDE (PATA) interface.
  • GPIO, I2C, PWM, Keyboard Matrix (8×8), built-in Resistive Touchscreen Controller, and much more.

Cuando lo compré lo hice pensando en 3 opciones:

  1.  Plan A: Android Media Center + Server. Mantener el soft original android, configurar el market añadirle “Samba FileSharing” y un cliente torrent.
  2.  Plan B: Linux Media Center + Server. Configurar una Puppy o una debian/ubuntu ARM en una SD. Y tener un servidor con soporte XMBC(http://xbmc.org/) o en su defecto vlc con samba, torrent, frontend web (para controlar remotamente)
  3. Plan C: Linux Server. La versión reducida del plan B. Sin aceleración HW ni TVout HD (720 o 1080P). Se quedaria como mini-barebone o servidor silencioso de bajo consumo 24×7.

En esta semana han pasado bastantes cosas, y exigen posts propios.

El plan A que era el más rapido no están sencillo, el siguiente post irá sobre las tribulaciones con los aparatos chinos.

El Plan B está muy verde, no hay drivers para la GPU o acel. de video. Hay alguna imagen cocinada pero muy alpha. En cualquier caso hay avances importantes y el “applaiance” ha cogido tracción (post de desarrollador xmbc connsiguiendo soporte OpenGL ES).

El Plan C es la última opción si no hay plan A o B (B mejor que A) y ya se verá como evoluciona la plataforma.

AVISO: El producto en su configuración original es un producto chino en todos sus aspectos. No hay documentación de uso o esta en chino,el texto en ingles es minimo o no se corresponde con lo que se obtiene al arrancarlo. Se enciende y esta en chino, incluso cambiendo el idioma a ingles sigue todo en chino menos la configuracion android basica. No es un appleTV.

 

De los champiñones

A menudo otros departamentos o incluso áreas enteras deciden la compra de software, máquinas, contratos con proveedores, etc… por libre, sin contar con infraestructuras.
Esto es una bomba de relojería:

  • Si se saltan los canales en aras de la flexibilidad, es porque no quieren tener en cuenta los protocolos y salvaguardas establecidos por IT.
  • Cuando explote, sera a IT o infraestructuras a quien exigiran solucionar el problema.
  • Algun dpto. de IT habrá estado involucrado aunque sea tangencialmente, cuando explote la responsabilidad sera de IT no de quien se saltó las reglas.

Un ejemplo sencillo: un conocido le vende a alguien de finanzas una cutre aplicación para gestionar contratos. Los de finanzas que ya tienen suficiente trabajo se encuentran entre solicitar a IT y activar un proceso burocrático de semanas o meses o la palabra del amigo que les dice que eso corre en un pc corriente y es siguiente, siguiente, siguiente. Finanzas no sabe si lo quiere o no, si le servirá o no pero tampoco quieren esperar asi que pasan de IT (politicas, seguridad, capacity planning) , hablan con helpdesk (que es IT) les piden un desktop o simplemente instalar esa aplicación en un pc y empiezan a trabajar.
Un año mas tarde con contratos, documentos e información confidencial, el pc se muere y todo son prisas y nervios para recuperar información crítica… que por supuesto nunca ha tenido backup, un servicio y servidor que no está catalogado (ni existe porque es un desktop de un usuario… en realidad sí esta catalogado porque en la gestión de licencias deberia aparecer pero en estos casos solo se controla si se cumple licenciamiento).

Hay pocas cosas más permanentes que una solución temporal. Tampoco hay soluciones milagro, más controles y procedimientos solo dan más burocracia y menos flexibilidad.
En mi opinión, la solución pasa por la educación, lo ideal pasaría por un servicio de IT eficiente (ITIL y demas procedimientos) pero es algo utópico. Hay que ser realistas, si se saltan la burocracia, al menos que tengan presente porque existen y las tengan en cuenta.

¿Como? educando: con correos, boletines de buenas practicas, ideas para mejorar servicios. Siempre en tonos positivos y nunca acusadores, de otra forma se lo tomarían como un ataque y provocarían rechazo. Ademas de esta forma das a conocer los riesgos y los mótivos del procedimiento, haciendo a negocio más receptivo a seguirlos.

En el caso que nos ocupa dando a conocer un pequeño checklist de temas a tener cuenta para evitar futuros problemas (y que mejor que IT para prevenirlos).

  • ¿La solución contempla backup? ¿Que pasa si se pierde el contenido de la maquina?
  • ¿Se integra con el control de acceso de la compañía?
  • ¿Van a entrar múltiples personas y existirá auditoría o si algo sucede no se sabrá quien ha sido?
  • ¿Si se necesita acceso remoto (pj para soporte) funcionara con el servicio vpn de la compañía?
  • ¿Están contemplados parcheados de seguridad, tanto de la aplicación como de la maquina?
  • ¿Hay mantenimiento de la aplicación? ¿Actualizaciones? ¿Soporte? ¿Documentación (instalación, uso, mantenimiento, etc.)?
  • ¿Se integra con otros elementos de la compañía? ¿están avisados de las implicaciones? ¿pueden corromperse?
  • ¿Hay licencias de todos los elementos involucrados? ¿Se cumplen los requisitos de esas licencias?
  • ¿Cumple los requisitos legales a los que esta sujeta la compañia (leyes nacionales, extranjeros, LOPD, SOX, etc.)?
  • ¿Cumple políticas internas de la compañía (éticas, compromisos, etc…)?
    • caso particular delos anteriores: ¿utiliza datos en la nube o se ponen datos privados en manos externas sin contratos de confidencialidad, etc.?

 

El Partido

El día D, el día de la puesta en producción.

La primera regla que hay que tener en cuenta es que siempre hay imprevistos.
Aplicar las previsiones vistas anteriormente minimizan riesgos y dan la confianza necesaria para esperar imprevistos no bloqueantes. Hay que tener muy claro que esto no garantiza que la aplicacion/servicio funcione.

Pueden existir procesos de calidad, pruebas de rendimiento, todo tipo de pruebas y documentación y el dia D, la nueva web se caiga con 5 peticiones porque la “home” hace conexiones sincronas recursivamente.

A veces, es simplemente que no todos los condicionantes estan planificados. Marketing contrata una empresa que le de hits (pj un proveedor de banners que te capture no solo el html de la home sino todo el site completo: html, imagenes,estilos,links…) cada vez que se vea un banner en una pagina de terceros (una razón mas para usar un Adblock) . Marketing y/o SEO han decidido inflar los números (hits y visitas), ingeniería junto a negocio han hecho una estimación realista de uso:  servidores, ancho de banda, pruebas de rendimiento… la suma es un DoS.

Por supuesto siguen estando los sospechosos usuales, elementos de producción no replicables en otros entornos que no se comportan como se esperaba o simplemente no se han tenido en cuenta, dimensionamientos insuficientes (las pruebas de rendimiento son un mundo y un arte). Leyes de Murphy, perversidad de la naturaleza, etc. lo esperable.

Lo importante es tener un buen plan de ruta, no estar perdido y tener claro los procesos de continuar o marcha atras. Todo ello debe estar ya planificado con antelación, incidencias siempre van a suceder.