Los “snaps” de Ubuntu

Una de las recientes novedades de la versión LTS de Ubuntu ha sido la introducción del sistema de paquetes snap. Así que voy a dedicar unos minutos a hablar del tema por alusión reciente.

¿Ubuntu snappy?

Tradicionalmente, a la hora de instalar solíamos pelearnos con los ficheros .deb (de Debian, la distribución padre de Ubuntu), que tenían como ventaja que instalaban “lo que se necesitaba”. Con esta expresión quiero decir que el paquete traía su código y poco más, las dependencias se instalaban según se necesitasen o no, y esto tenía como ventaja que los paquetes eran ligeros y sólo teníamos una única vez instalados en nuestros discos duros. Por supuesto, el mundo no es siempre tan ideal, y al actualizar paquetes de algunas dependencias la aplicación que instalamos con .deb dejaba de funcionar…

Ahí entra snap, un sistema en el que empaquetamos todo, absolutamente todo lo que la aplicación necesita para ejecutarse, como si se tratase de un bloque individual hermético. si bien tendremos código repetido en nuestras unidades de almacenamiento, podemos garantizar que en todo momento nuestra aplicación funcionará, y además la desinstalación será mas limpia.

Así que cada una tiene sus ventajas y sus inconvenientes. Hace unos años, una solución como la de snap era difícil de llevar a cabo porque el almacenamiento en sistemas Linux tendía a ser precario. Seamos honestos, la mayoría de las máquinas en las que se suele hacer correr Linux suelen ser equipos con unos años, a los que les alargamos su ciclo de vida al utilizar un sistema operativo en el que consumamos menos recursos. Pero a día de hoy la memoria es barata: tarjetas SD, pendrives, discos duros externo… es muy fácil ampliar y quitarnos el problema, lo que hace que ahora las bases hayan cambiado.

Vamos a lo técnico, que es muy similar al apt-get clásico:

Para instalar con snap desde consola usamos:

sudo snap install <em>package-name

Para actualizar:

sudo snap refresh <em>package-name

Y para eliminar:

sudo snap remove <em>package-name
Anuncios

Cuando el reloj de sistema de Android se bloqueó

Hoy os hablaré de mi última pelea informática a nivel usuario por si a alguno le es útil. El último fin de semana por la noche se me quedó congelado el reloj de sistema de Android del móvil a cosa de las 4 de la mañana… cosa que no descubrí hasta que me levanté bien entrada la mañana. Era fin de semana así que no me supuso ningún trastorno, asumí que era cosa de ponerlo hora y fuera. No le dí mucha importancia porque el móvil podría haber tenido algún problema momentaneo de conexión al repetidor y lo volví a sincronizar desde las opciones de sistema usando la hora de internet, y adelante. Nota cultural para quien no lo sepa, los teléfonos móviles pueden se pueden sincronizar mediante geolocalización con la ayuda de torres de telefonía, un ejemplo muy claro es por los cambios de hora o los cambios zona horaria al viajar. Un fallo de conexión durante ese protocolo puede provocar una congelación por un tiempo, y con un cierto margen de error, se podría haber asumido que estaba pendiente del cambio de hora de invierno y se quedó ahí frito.

Cuando el reloj de sistema de Android se bloqueó

Pero a la noche se volvió a congelar… y al día siguiente a media mañana. Y cuando me refiero a que el fallo era del reloj interno, lo que quiero decir que la aplicación de widget de reloj no daba problema alguno, solo el de la banda superior del móvil, el que está junto a los iconos de notificación de cobertura, wifi y demás. Si en el momento podría dar igual porque como reloj seguía sirviendo perfectamente, el problema era que las alarmas del móvil no suenan precisamente por ese fallo, y esa es una función a la que le suelo sacar provecho… así que llega la típica pregunta, si antes funcionaba y después no ¿qué había cambiado en ese periodo de tiempo que pudiese haberle afectado?

Tras echar una ojeada al historial de actualizaciones recientes, mi candidatas eran 3: Twitter (no le ví relación algún), Gmail (la lógica me decía que no era muy probable) y Calendar (esa tenía algo mas de sentido). Así que tras andar mirando un rato los changelog (la lista de cambios) ví que las 2 aplicaciones de Google habían tocado los eventos y recordatorios y se interconectaban, ya los recordatorios en ambas están atados a fin de cuentas a fecha y hora. Así que igual algo había ido mal en esa actualización y eso había dejado esa parte del programa frito, porque ya que todos los widgets de reloj independientes se portaban no parecía ser que algo mas gordo se hubiese muerto… En consecuencia volví esas 2 aplicaciones a la versión de fábrica (lo que sería desinstalar dentro de una aplicación atada a la imagen de sistema operativo), limpié, reinicié el sistema para asegurarme que iba desde 0, y tras ese proceso las volví actualizar. Todo fue bien y desde entonces llevo casi una semana sin haber vuelto a tener problemas.

La prueba de los 280 caracteres en Twitter

Quienes hemos desarrollado en algún momento en Twitter conocemos de sobra la tormentosas situación que hay con ellos: se crean clientes externos que hacen mucho mas fácil el uso mediante su API, y cada cierto tiempo, ellos hacen cambios que:

  1. Incluyen algunas de las mejoras desarrolladas por un tercero (han tardado años en darnos un tema oscuro).
  2. Hacen un recorte en las peticiones de la API para limitar el uso desde cliente de terceros (Fenix es la última víctima).
  3. Hacen un cambio repentino en la API que descoloca a todas las terceras partes.

Y así con esa jugada recupera usuarios en su aplicación cliente oficial, que para ser honestos siempe ha sido bastante mediocre.

La prueba de los 280 caracteres en Twitter

En este último mes hemos tenido 3 de 3, y si bien algunos cambios aunque fastidien al desarrollador momentáneamente los veo bien (por jemplo que el DM de los mensajes directos pase a ser metadatos, tal como fue el RT de retweet, y se ganen unos pocos caracteres extra), el cambiar el número de caracteres de 140 a 280 me parece un claro error. Conste que aún está en pruebas, únicamente para unos cuantos usuarios y solo en determinados idiomas.

Si algo ha diferenciado desde un primer momento  a Twitter es que se trata de microblogging, es decir, de entradas muy reducidas. Esto nos lleva a generar un contenido muy conciso, originalmente una idea y quizás un enlace, y hoy en día se pueden incluir fotos, vídeos, gifs o algún emoji (una imagen vale mas que 1000 palabras). ¿Qué pasa si cambiamos el límite de caracteres?

  • La brevedad siempre ha sido un valor diferencial de Twitter: sin él, ¿en qué se diferencia de otras plataformas? Eso y su inmediatez, reflejada en el timeline que vemos nada mas entrar siguiendo un orden cronológico, para cumplir con el “qué está pasando ahora.”
  • Entradas largas: sinceramente, si tengo algo mas largo de escribir, para eso tenemos sistema de blogging o Facebook. Si es algo tipo comunicado oficial, el solemne Medium, que es de la misma casa, puede hacer un trabajo estupendo.
  • La gente tiende a escribr menos: estamos en una época en la que todo sistema de mensajería esta lleno de emojis y gifs, porque una imagen vale mas que 1000 palabras. Se tiende a usar cada vez menos caracteres, así que para uqé aumentar el número.
  • Relleno para llegar a los 280 caracteres: imaginad una entrada formato Trump con cientos de exclamaciones.

Espero sinceramente que se replanteen la situación y quede en algo aislado, similar a cuando cambiaron el orden del timeline a lo que ellos consideraban mas relevante.

¿Por qué los desarrolladores preferimos utilizar temas oscuros en nuestras aplicaciones?

En una época en la que todo son colores brillantes (mirad lo que está haciendo Google, hasta los teclados táctiles ahora son blancos) la mayoría de los desarrolladores seguimos prefiriendo el uso de temas oscuros. Y no, no es por nostalgia de las pantallas de fósforo verde.

  • Salud de la vista evitando la fatiga visual: considerad que quienes desarrolamos software pasamos una media de entre 8 y 10 horas delante de la pantalla, y puede que la pantalla que nos proporcionen no sea la mejor del mundo precisamente. Un monitor a fin de cuentas parpadea, y todos esos íxeles encendidos en color blanco parpadean, mientras que si están en un color negro real, están apagados. Y apagados no hay parpadeo que valga.
  • Ahorro energético: como extra el estar apagados ahorra consumo de energía. De paso si estás usando un termina móvil notarás que consumes mucho menos energía, y aumentar la duración de la batería siempre se agradece.
  • Reducir el desgaste del material, permitiendo que dure por mas años.
  • Prevención del insomnio: el parpadeo es un estímulo que espabila, y si bien a las 8 de la mañana viene bien, cuando toca recogerse para ir a dormir es puede ser un buen problema.

¿Por qué los desarrolladores preferimos utilizar temas oscuros en nuestras aplicaciones?

En consecuencia, una pantalla principalmente negra y tomar descansos de forma regular evita que nos dañemos la vista mas. De ahí que a la hora de configurar mis programas de uso mas frecuente en el trabajo, como Eclipse (cuya imagen podéis ver arriba con el tema darkest dark) o Atom (el tema monokai), use siempre que pueda temas oscuros… Y lo mismo se puede decir de mi cliente API de Twitter o mi lector de ebooks, pues leer por la noche en una pantalla parpadeante no es una gran idea.

La pesadilla informática de LexNET

Quizás hayais oído hablar de LexNET, o quizas vuestros filtros os hayan hecho ignorarlo, como suele pasar con la mayoría de las cosas de derecho. El “legalés” (término jocos que utilizamos para definir la jerga legal) no es un idioma que controle y soy la primera que tiende a desconectar al escucharlo, pero este tema es curioso a la vez que terrible.

La pesadilla informática de LexNET
El logo de LexNET

Para quien no lo sepa, los sistemas digitales de los juzgados son cada uno de su padre y de su madre, lo que probablemente no resulte sorprendente, ya que tenemos una situación similar con los chips de las mascotas a nivel autonómico. LexNET fue un programa que se pretendía implantar a nivel nacional, lo que suena bonito. Lo que no suena tan bien es su extrema inseguridad, lo que me llevó a buscar información mas especializada: resulta que los datos de usuario se pasan en llamadas SOAP no securizadas, lo que quiere decir que los datos se ven de forma plana en la URL (ejemplo el ID de mi usuario), y con sustituir este por cualquier otro, un usuario se puede colar en la pantalla de otro.

¿Qué significa esto? Pues que cualquiera con credenciales de acceso al sistema puede acceder a cualquier cosa del mismo. Imaginaos que las partes enfrentadas puedan acceder a la información de los que sientan enfrente, o mas curioso aún: que alguien que trabaje en el juzgado y tenga alguna denuncia pueda acceder a los datos privados de quien lo ha denunciado.

¿Podría haberse prevenido? Pues de entrada se podrían securizar las llamadas SOAP para comparar el usuario que lo pide con el identificador que está pasando como parámetro, o usar quizás sistemas REST, de manera que los parámetros no se vean en la URL y no sean tan fáciles de hackear. Lo que denota esto es extrema dejadez y lo que es peor… ¿Esta gente no tiene un personal de testing serio? ¿Cuántas leyes de protección de datos se salta esto? Una vez mas me sorprendo del país en el que vivo, y parece que esto solo puede ser la punta del iceberg con lo que han hecho…