TFI 000

Today is Tuesday, so it’s a Tecno-day. However, I’m presenting you a comic that is not just a comic.

«The Future is ******» is what happens when a security company makes a comic just for lols.

It’s a comic created by Rekcahhacker» in a mirror), a project from Black Hills Information Security Company, after a Kickstarter campaign that funded the first issue of TFI: a 100-page book with a great story and lots of «games». Now there are at least 4 issues, and more are coming.

On its pages, you can find URLs and other tips that lead you to some «Capture the Flag» games. CTFs are tests that you can solve using coding, debugging, and other hacker skills.

You can also see a scoreboard hosted by MetaCTF, showing the scores of everyone playing those games, and access to a Discord server where you can ask for help.

In the next Tecno-days, I’ll explain some of the techniques used to solve those tests. But you’ll have to learn the basics and solve them on your own, because I’m not giving you the solutions.

Stay in touch.

Lo de la IA

En esta época de hype, se ve que no puede haber nada sin Inteligencia Artificial. Está en todas partes y no hay innovación posible si no pasa porque tengas que hablar con un agente automático (el bot de toda la vida, que ahora parece más listo), o si no lleva la etiqueta IA (o AI) como coletilla.

Para no ser yo menos que nadie, a pesar de que en general lo de la IA no me gusta demasiado, voy a entrar en materia, a mi estilo, explicando las cosas de un modo claro y conciso. Creo que es un buen modo de volver a escribir sobre tecnología, entrar en un tema tan omnipresente y a la vez tan desconocido.

A pesar de que en agosto se cumplirán 5 años desde que la médica me dijo aquello de «te tengo que dar la baja, no puedes seguir trabajando así», creo que todos mis años de experiencia desarrollando soluciones de lo más variado me acreditan lo suficiente como para no decir demasiadas tonterías. Tened en cuenta que mucho de lo que viene es una opinión, un modo de ver las cosas, que irá en contra de lo que hayáis leído hasta ahora, puede que por mi simplificación absurda 🙂

Vamos al lío.

¿Qué es?

¿Qué es la Inteligencia Artificial? Menuda preguntita, tiene muy mala leche. Podríamos entrar en que es un tipo nuevo de inteligencia que acerca a las máquinas al conocimiento humano, con todas las implicaciones filosóficas que conlleva. Sin embargo, eso me parece meternos en un auténtico barrizal.

A mí me gusta verlo como que es un «nuevo» paradigma de programación.

Para los ajenos al mundo del desarrollo de software, un paradigma de programación no es más que un modo de hacer programas. Algunos de ellos son:

  • Imperativo: se especifica qué y cómo se tiene que ejecutar un programa paso a paso.
  • Declarativo: se especifica el qué ha de hacer el programa, pero no el cómo.
  • Funcional: el programa se forma por la composición de funciones de manipulación de datos.
  • Dinámico: algunas cosas como los tipos de datos se establecen en el momento de ejecución y no cuando se hace (compila) el programa.
  • Orientado a objetos: se definen tipos de datos complejos que encapsulan la información junto a las funciones que se les puede aplicar.

MovGP0, CC BY-SA 3.0, via Wikimedia Commons

Hay muchos paradigmas de programación y varios se pueden aplicar a la vez, o se puede aplicar distintos paradigmas con una única tecnología. Por ejemplo, en PHP se suele ver mucho script dinámico e imperativo, aunque se pueden crear programas estáticos y orientados a objetos.

Pues bien, la IA no es más que otro paradigma. Específicamente, es uno en el que se le da al sistema un conjunto (masivo) de datos y se le marca un modo de aprendizaje automático, y el sistema aprende por sí mismo a trabajar con los datos para crear un programa que los procese en adelante. A ese programa resultante se le llama modelo*.

* No el 100% de lo de la IA es esto, pero permitidme la reducción para facilitar la explicación.

Al usar términos distintos de los habituales se puede caer en el error de que es algo totalmente distinto, pero no, si lo piensas con detalle verás que definir un conjunto de datos y decidir que se use K-means para catalogarlos, no es muy distinto de declarar una lógica en Prolog, o definir un conjunto de clases y sus interacciones.

Las principales diferencias con los paradigmas más habituales son:

  • Los recursos (tiempo y potencia) que se requieren para la «compilación» (la creación del modelo).
  • En el momento de la declaración (cuando estableces los datos y los algoritmos estadísticos a usar) no se puede predecir el resultado. Ni siquiera usando lógica difusa se puede aventurar la exactitud del modelo, aunque con experiencia se pueda intuir una aproximación.

Ahora, como con todo paradigma, se puede conocer a varios niveles, desde ser un experto a no tener ni idea, pasando por infinitos puntos intermedios. Del mismo modo que puedes conocer lo básico de programación funcional sin saber lo que son las mónadas, o hacer programación dinámica sin siquiera entender lo que hace la reflexión, puedes usar sistemas y librerías de IA para crear modelos (programas) sin conocer, por ejemplo, cómo funcionan las redes neuronales.

¿Es nueva? ¿Por qué este boom?

La Inteligencia Artificial es un campo de estudio que existe desde hace décadas, casi desde el momento de alumbramiento de la informática. La mayoría de técnicas usadas ya existían el siglo pasado. Entonces ¿por qué ahora?

Creo que influyen dos circunstancias muy concretas que se han dado en las últimas décadas y han hecho que surja este auge actual:

  • El boom del Big Data, que también estuvo hasta en la sopa aunque ya nadie se acuerde de él, que hizo que se almacenasen cantidades ingentes de información que luego se intentaban explotar con las técnicas de la época.
  • Los avances en procesamiento paralelo que se dieron principalmente desde el surgimiento de la PlayStation 2, con los chips de tarjetas gráficas que han permitido usar técnicas de programación concurrente (otro paradigma) para procesar el Big Data en un tiempo computacional aceptable.

Parafraseando a aquella: «mezclando ácido clorhídrico con sulfato de sodio, ha hecho una reacción que flipas».

¿Es inteligente?

Deberíamos, primero, filosofar sobre qué es la inteligencia y qué tipos hay, pero muy a grosso modo podemos concretar en: NO.

Hablando de Inteligencia Artificial es seguro que todos tenemos en mente ChatGPT que es un LLM (modelo «largo» de lenguaje). Parece muy inteligente, pero en EGB un profesor (hablando con él de un niño que memorizaba la enciclopedia) me dijo que la memoria es muy diferente de la inteligencia entendida como la capacidad de razonar y resolver problemas.

ChatGPT recuerda muchas cosas, en concreto recuerda especialmente bien la cercanía estadística entre unas palabras y otras. También puede simular cierto razonamiento, haciendo deducciones básicas a partir de datos, pero le falta mucho para que podamos llamarlo inteligente en cuanto a un caso general.

Por ejemplo, las IAs generativas actuales que crean respuestas de texto, música o imágenes, no pueden actualizar sus modelos insertando en ellos nuevos casos aprendidos mientras se usan (aunque sí que se aprovechan esos datos para entrenamientos de futuras versiones del modelo). Esto es, no pueden aprender sobre la marcha (por ahora).

IA General

Lo que entendemos por inteligencia (inteligencia cognitiva al nivel de un humano), es lo que en el campo se conoce como Inteligencia Artificial General.

Es SkyNet en Terminator, la «voz del pinganillo» de Her, o el científico de Trascendence. Esa que Hollywood nos ha mostrado innumerables veces, que es capaz de realizar razonamientos lógicos y dado su acceso a todo el conocimiento humano puede convertirse en una super inteligencia que lo arregle todo.

Como el resto de la gente, no puedo ver el futuro, pero ahora mismo esa IAG no existe y estamos lejos de conseguirla.

De hecho, hace poco Apple sacó un controvertido paper (The illusion of thinking) en el que explicaba que lo que hay ahora no es más que una «burda» imitación de pensamiento. ¡No se podía saber!

Aunque es muy probable que en este caso la opinión de Apple tenga un gran sesgo por estar quedándose muy atrás en el campo de la IA y de los agentes (LLMs) con su otrora popular Siri y sus experimentos no demuestren nada, eso no hace falsa a la conclusión: los sistemas de inteligencia artificial actuales no piensan como lo haríamos los humanos.

¿Acabará con los trabajos?

¡Ojalá! Un sistema capitalista como es el mundo actual, requiere necesariamente que la gente tenga ingresos para poder ser consumidores. Si se acaba con los trabajos, el sistema debería reformularse para que la gente siga teniendo ingresos, o bien abandonar el capitalismo de manera inmediata. ¡Doble win!

Desde el momento en el que el luteranismo calvinista instauró ese «amor» por el trabajo, por el progreso (económico) y prosperar, el sistema se ha alimentado de la mano de obra que era a la vez productora y consumidora. No me pondré muy anarquista con esto, pero el «trabajo» remunerado es un pilar del capitalismo y no se puede acabar con uno sin hacerlo con el otro.

Sí que es cierto que introducirán modificaciones. Del mismo modo que la máquina de vapor cambió, por ejemplo, cómo se producían tejidos en las fábricas inglesas, la Inteligencia Artificial y los agentes conversacionales están cambiando algunos procesos que se irán depurando con el tiempo y afectará significativamente a algunas profesiones.

Sin embargo, toda introducción de una nueva tecnología ha traído cambios de este tipo y ha hecho que los profesionales se especialicen o se conviertan en artesanos, dando un nuevo valor a la producción. Volviendo al ejemplo inglés, tras la revolución industrial hubo (además de hambre y miseria) quienes se especializaron en controlar y arreglar las máquinas, y quienes siguieron haciendo las telas de un modo tradicional dándoles un extra de valor por la exclusividad.

Uno de los campos que más rápido está adoptando estas tecnologías es la programación de software, pero esto dudo que vaya a tener más implicaciones que el dejar de ver valor en el número de líneas de código, centrándose en lo importante: entender el problema y determinar la mejor solución. Esto dejaría la profesión de programador relegada a ser operadores y supervisores de estos nuevos sistemas de generación de código (especialización) o a seguir haciendo las cosas como «antiguamente» de un modo artesano que tendrá más valor simplemente por la componente «artística».

Ahora que lo dices ¿Y el arte?

Bien, hemos dado con una piedra bien gorda. Es una de las críticas más grandes que hay de las IAs generativas (además del gran consumo de recursos).

¿Se puede considerar arte algo hecho por una Inteligencia Artificial? ¿No deja de tener alma? ¿Para que queremos que las IAs hagan arte en lugar de recoger la basura?

A estas alturas de la batalla, todos hemos escuchado argumentos en una línea y su contraria. Desde que las técnicas que se usan para crear imágenes son las mismas que se usan para predecir la forma de plegar proteínas, hasta que es un robo y un plagio a los artistas.

Sin entrar en gustos, el arte generativo existe hace mucho tiempo. Es una modalidad artística en el que el artista crea máquinas o algoritmos que a partir de datos pseudoaleatorios producen piezas de arte. Por ejemplo, ahora mismo en el Centro Botín (un museo de Santander) se puede ver una exposición en la que el artista ha generado unas pistas de audio a partir del análisis de datos de la bahía de Santander como la altura de las mareas o la velocidad del viento, el artista ha hecho un algoritmo que es el que genera como resultado la obra final.

Si se considera el arte generativo como arte, hay que permitir llamar arte a las obras creadas por la IA. En este caso, los programadores de la IA serían los artistas y el operador no sería mucho más que un generador de datos pseudoaleatorios.

¿Y los datos? ¿Me van a robar? ¿Me han robado ya?

Como ya hemos dicho, para programar uno de estos sistemas de Inteligencia Artificial, uno de los elementos necesarios son datos. Muchos.

Aquí hay mucho debate por la fuente de esos datos. Por ejemplo, en el uso de descargas ilegales por parte de Meta (Facebook), o la venta de datos tan personales como puede ser el ADN.

Los temas legales suelen ser complejos y más en estos campos en los que hay que observar legislaciones de diversos países y continentes. Simplificando mucho, en España (Europa) hay dos puntos clave a tener en cuenta:

  • Datos de caracter personal. Son aquellos que permiten identificar a una persona como nombre, teléfono o dirección. Si se almacenan estos datos ha de ser por el menor tiempo necesario, haber informado claramente de que se van a recopilar y cómo se van a procesar. En principio, dado el funcionamiento de la IA, no deberían ser parte del entrenamiento porque luego no se podrían sacar del modelo generado si el usuario lo solicita.
  • Copyright. Aquí, la autoría no se puede transferir de ningún modo, sólo se pueden ceder derechos para el uso que sea hasta 70 años después de la muerte del autor, momento en el que pasa a dominio público. Por tanto, si yo compongo una canción tendría que ceder sus derechos para que una empresa de IA pueda usarla para entrenar sus modelos generativos.

Esto es lo que dice la teoría y la teoría está estupenda pero sabemos todos que la realidad es otra. Las multas que se imponen a las empresas que hacen mal uso de la información suelen ser irrisorias y los términos de uso que aceptamos para poder usar servicios en Internet acostumbran a ser tremendamente abusivos ya que no te dan opción y sólo puedes decidir entre tener el servicio o no tenerlo.

Además nos preocupamos mucho de datos tan comunes (y públicos) como el número de DNI mientras aireamos alegremente nuestras relaciones sentimentales o que estamos de vacaciones (y nuestra casa vacía), que son cosas mucho más íntimas.

Por tanto, no puedo hacer más que dar el mismo consejo que me dió Paula en su día: si no estás dispuesto a que lo sepa tu abuela, no lo pongas en Internet porque en cualquier momento puede quedar expuesto.

Si creas una obra del tipo que sea y no quieres que se use para entrenamientos, puedes poner unos términos de uso y no ceder el copyright, pero si realmente no quieres que se use lo único que está en tu mano hacer es no subirlo a Internet.

¿Cómo funciona todo esto?

No es porque lleve varias horas escribiendo, ni porque crea que no voy a saber explicarlo de un modo comprensible, pero me vais a permitir que de una explicación muy somera de cómo se hace lo de la IA. Si tenéis interés y os gusta como explico, siempre me lo podéis decir en un comentario y entramos en otros posts en materia de cómo se enseña a las IA.

Lo primero es obtener una fuente de datos y prepararla para su procesamiento. Estos datos se separan en dos paquetes, uno de entrenamiento (por ej. con el 80% de ellos) y el resto para comprobar el modelo resultante.

Con estos datos, se determina que tipo de algoritmo estadístico sirve mejor para el trabajo que queremos que haga el modelo y se entrena el modelo con ellos de tal manera que el sistema aprende por comparación.

Una vez que el modelo ha sido entrenado, se testea con el resto de datos. En caso de que el porcentaje de acierto sea suficientemente alto (un 90% por ej.), se da el modelo por bueno. Si no es así, hay que volver atrás y enfocarlo de otro modo.

En este proceso influyen muchas cosas, desde cómo se selecciona qué datos serán para entrenamiento y cuales para test, hasta cómo determinar si un resultado es satisfactorio, pero la base es esta.


Visto todo esto, la única conclusión que me gustaría dejar es que lo de la IA ni es tan nuevo, ni es tan bueno, ni es tan complejo.

Y como decía la entradilla de mi primer libro de Inteligencia Artificial:

Todo conocer depende de la estructura que conoce.

¡Ojo! Cuidado en Firebase con el forEach de los Snapshots de la Realtime Database

Firebase es un PaaS de Google con un nivel de abstracción muy alto que te permite tener un completo backend serverless. Hacía años que no lo usaba y estoy encantado con él, pero hay que andarse con ojo porque ningún entorno ni tecnología llega a ser perfecto.

La semana pasada estaba programando una cosa en Javascript usando la librería de Firebase, para un proyecto en el que he usado su Realtime Database para montar un sistema de presencia que me diga en todo momento quién está on y quién está off.

En un momento dado, detecté un problema que no entendía de dónde podía venir:

Hacía una query a la base de datos, que me devolvía unos resultados que yo procesaba. Sin embargo, el resultado era un único dato cuando en la BBDD tenía que haber más. Tras unos cuantos tests, me di cuenta de que si lo mismo lo programaba de distintos modos (que deberían comportarse igual) ¡el resultado era distinto!

snapshot.forEach(s=> array.push(s.val()));
//vs
snapshot.forEach(s=>{array.push(s.val())});

Esas dos estructuras, daban resultados distintos ¿cómo podía ser?

Tras darle unas cuantas vueltas con cara de absoluta incredulidad llegué a la clave del asunto en el último sitio que me quedaba por mirar de la documentación de Firebase:

Último ejemplo de la documentación de Firebase
https://firebase.google.com/docs/reference/js/firebase.database.DataSnapshot#for-each

Se habían alineado Roma con Santiago:

  • Un desarrollador/diseñador había elegido usar un nombre habitual, dándole un comportamiento no habitual.
  • En Javascript todo lo que no sea falso/0/undefined se evalua como true.
  • La información referente a como funcionaba estaba en el último rincón de la documentación.

Todo habría sido distinto si el método se hubiese llamado cancellableForEach; o si al menos hubiesen comprobado que el valor recibido era verdadero comparándolo con el operador de igualdad estricta («=== true»); o si, ya cogiéndolo por los pelos, la ejecución del método cuando reciba algo que no sea booleano arrojase un warning…

En cualquier caso, tras un rato de frustración el problema quedó solucionado.

Valga este post tanto para recordar que hay que tener cuidado en Firebase con el forEach de los Snapshots de la Realtime Database, como para recordar la importancia de los nombres que ponemos a las cosas.

El nivel de acceso Archive en Azure

En las cuentas de Storage en Azure, disponemos de varios elementos de configuración que influyen directamente en la disponibilidad de la información que vamos a almacenar, el precio de tenerlo guardado, el de acceder a los datos y la latencia que tendremos hasta poder leer el primer byte de información. Entre esos elementos está el propio tipo de cuenta y el nivel de rendimiento, así como el tipo de replicación. Para simplificar todo y no desviarnos del objetivo de este artículo, nos centraremos en las cuentas de tipo propósito general V2 (StorageV2) con nivel de rendimiento estándar y replicación LRS (Locally-redundant storage). De este modo nos podremos centrar en el elemento que nos interesa explicar hoy: el nivel de acceso.

Nivel de acceso Azure

Seguir leyendo en CompartiMOSS.

Montar blobs de Azure en Windows

Tal y como hicimos hace unas semanas con Linux, vamos a montar blobs de Azure en Windows para poder usar un container como una unidad de almacenamiento barato.

La verdad es que con Azure CLI y usando el comando subst sería muy fácil montar algo. Sin embargo, todo buen programador ha de revisar si alguien antes que él ya se ha enfrentado al mismo problema. En este caso, así es.

La empresa Gladinet mantiene (o mantenía, ya que no parece muy actualizado y algunos conectores han dejado de funcionar) un software que te permite montar como una unidad virtual casi cualquier repositorio online que se os podáis imaginar.

La página de descargas es una locura, y sólo uno de los enlaces parece llevar a su última versión (la 4) que es la que incluye un conector a los blobs de Azure que funciona.

Una vez instalado y conectado con vuestro container, ya podréis acceder a su contenido y subir archivos como si de cualquier otra carpata de vuestro sistema se tratase.

Montar blobs de Azure en Linux

Si necesitas más espacio en un sistema, por ejemplo, para almacenar copias de seguridad, puedes montar un almacenamiento en la nube como los blobs de Azure en Linux para dotar a tu sistema de almacenamiento «infinito» a un precio muy competitivo aprovechando el Storage.

Se puede hacer con cualquiera, yo lo voy a hacer con Azure porque es con el que suelo trabajar por defecto, aunque haya trabajado con muchos otros.

Esto lo he hecho en Ubuntu 18.04 aunque debería de poderse hacer con más o menos complicaciones en cualquier versión de Linux.

  1. Actualizar repositorios
    wget https://packages.microsoft.com/config/ubuntu/18.04/packages-microsoft-prod.deb
    dpkg -i packages-microsoft-prod.deb
    apt-get update
    
  2. Instalar paquetes
    apt-get install blobfuse fuse -y
    
  3. Crear directorio temporal
    mkdir /mnt/resource/blobfusetmp -p
    
  4. Crear archivo de configuración
    vi ~/fuse_connection.cfg
    #Hay que poner las siguientes líneas sin comentarios y con los valores de tu cuenta, tu key y tu container
    #accountName myaccount
    #accountKey storageaccesskey
    #containerName mycontainer
    chmod 600 fuse_connection.cfg
    
    
  5. Montar en un directorio
    mkdir ~/disks
    blobfuse /root/disks --tmp-path=/mnt/resource/blobfusetmp  --config-file=/root/fuse_connection.cfg -o attr_timeout=240 -o entry_timeout=240 -o negative_timeout=120
    

Si esta última llamada la metes en un script que se llame, por ejemplo, desde rc.local te asegurarás de que la «unidad cloud» que has creado en Azure se monte con cada arranque del sistema.

Con esto habrás conseguido tener una nueva unidad montada aprovechando los blobs de Azure en Linux que, aunque sí tendrá más latencia que las unidades físicas de las que dispongas, su precio será mucho menor.

Best papers awards in Computer Science of 2018

2018 has finished with a lot of innovations. It brought a lot of awards for papers about several disciplines of Computer Science at different conferences this year. Here we have the abstract of some of them:

  • Memory-Augmented Monte Carlo Tree Search

    This paper proposes and evaluates Memory-Augmented Monte Carlo Tree Search (M-MCTS), which provides a new approach to exploit generalization in online realtime search. The key idea of M-MCTS is to incorporate MCTS with a memory structure, where each entry contains information of a particular state. This memory is used to generate an approximate value estimation by combining the estimations of similar states. We show that the memory based value approximation is better than the vanilla Monte Carlo estimation with high probability under mild conditions. We evaluate M-MCTS in the game of Go. Experimental results show that MMCTS outperforms the original MCTS with the same number of simulations.

  • Finding Syntax in Human Encephalography with Beam Search

    Recurrent neural network grammars (RNNGs) are generative models of (tree,string) pairs that rely on neural networks to evaluate derivational choices. Parsing with them using beam search yields a variety of incremental complexity metrics such as word surprisal and parser action count. When used as regressors against human electrophysiological responses to naturalistic text, they derive two amplitude effects: an early peak and a P600-like later peak. By contrast, a non-syntactic neural language model yields no reliable effects. Model comparisons attribute the early peak to syntactic composition within the RNNG. This pattern of results recommends the RNNG+beam search combination as a mechanistic model of the syntactic processing that occurs during normal human language comprehension.

  • Voice Interfaces in Everyday Life

    Voice User Interfaces (VUIs) are becoming ubiquitously available, being embedded both into everyday mobility via smartphones, and into the life of the home via ‘assistant’ devices. Yet, exactly how users of such devices practically thread that use into their everyday social interactions remains underexplored. By collecting and studying audio data from month-long deployments of the Amazon Echo in participants’ homes-informed by ethnomethodology and conversation analysis-our study documents the methodical practices of VUI users, and how that use is accomplished in the complex social life of the home. Data we present shows how the device is made accountable to and embedded into conversational settings like family dinners where various simultaneous activities are being achieved. We discuss how the VUI is finely coordinated with the sequential organisation of talk. Finally, we locate implications for the accountability of VUI interaction, request and response design, and raise conceptual challenges to the notion of designing ‘conversational’ interfaces.

  • Relevance Estimation with Multiple Information Sources on Search Engine Result Pages

    Relevance estimation is among the most important tasks in the ranking of search results because most search engines follow the Probability Ranking Principle. Current relevance estimation methodologies mainly concentrate on text matching between the query and Web documents, link analysis and user behavior models. However, users judge the relevance of search results directly from Search Engine Result Pages (SERPs), which provide valuable signals for reranking. Morden search engines aggregate heterogeneous information items (such as images, news, and hyperlinks) to a single ranking list on SERPs. The aggregated search results have different visual patterns, textual semantics and presentation structures, and a better strategy should rely on all these information sources to improve ranking performance. In this paper, we propose a novel framework named Joint Relevance Estimation model (JRE), which learns the visual patterns from screenshots of search results, explores the presentation structures from HTML source codes and also adopts the semantic information of textual contents. To evaluate the performance of the proposed model, we construct a large scale practical Search Result Relevance (SRR) dataset which consists of multiple information sources and 4-grade relevance scores of over 60,000 search results. Experimental results show that the proposed JRE model achieves better performance than state-of-the-art ranking solutions as well as the original ranking of commercial search engines.

  • An empirical study on crash recovery bugs in large-scale distributed systems

    In large-scale distributed systems, node crashes are inevitable, and can happen at any time. As such, distributed systems are usually designed to be resilient to these node crashes via various crash recovery mechanisms, such as write-ahead logging in HBase and hinted handoffs in Cassandra. However, faults in crash recovery mechanisms and their implementations can introduce intricate crash recovery bugs, and lead to severe consequences.In this paper, we present CREB, the most comprehensive study on 103 Crash REcovery Bugs from four popular open-source distributed systems, including ZooKeeper, Hadoop MapReduce, Cassandra and HBase. For all the studied bugs, we analyze their root causes, triggering conditions, bug impacts and fixing. Through this study, we obtain many interesting findings that can open up new research directions for combating crash recovery bugs.

  • Delayed Impact of Fair Machine Learning

    Fairness in machine learning has predominantly been studied in static classification settings without concern for how decisions change the underlying population over time. Conventional wisdom suggests that fairness criteria promote the long-term well-being of those groups they aim to protect.
    We study how static fairness criteria interact with temporal indicators of well-being, such as long-term improvement, stagnation, and decline in a variable of interest. We demonstrate that even in a one-step feedback model, common fairness criteria in general do not promote improvement over time, and may in fact cause harm in cases where an unconstrained objective would not.
    We completely characterize the delayed impact of three standard criteria, contrasting the regimes in which these exhibit qualitatively different behavior. In addition, we find that a natural form of measurement error broadens the regime in which fairness criteria perform favorably.
    Our results highlight the importance of measurement and temporal modeling in the evaluation of fairness criteria, suggesting a range of new challenges and trade-offs.

  • Large-Scale Analysis of Framework-Specific Exceptions in Android Apps

    Mobile apps have become ubiquitous. For app developers, it is a key priority to ensure their apps’ correctness and reliability. However, many apps still suffer from occasional to frequent crashes, weakening their competitive edge. Large-scale, deep analyses of the characteristics of real-world app crashes can provide useful insights to guide developers, or help improve testing and analysis tools. However, such studies do not exist — this paper fills this gap. Over a four-month long effort, we have collected 16,245 unique exception traces from 2,486 open-source Android apps, and observed that framework-specific exceptions account for the majority of these crashes. We then extensively investigated the 8,243 framework-specific exceptions (which took six person-months): (1) identifying their characteristics (e.g., manifestation locations, common fault categories), (2) evaluating their manifestation via state-of-the-art bug detection techniques, and (3) reviewing their fixes. Besides the insights they provide, these findings motivate and enable follow-up research on mobile apps, such as bug detection, fault localization and patch generation. In addition, to demonstrate the utility of our findings, we have optimized Stoat, a dynamic testing tool, and implemented ExLocator, an exception localization tool, for Android apps. Stoat is able to quickly uncover three previously-unknown, confirmed/fixed crashes in Gmail and Google+; ExLocator is capable of precisely locating the root causes of identified exceptions in real-world apps. Our substantial dataset is made publicly available to share with and benefit the community.

  • SentiGAN: Generating Sentimental Texts via Mixture Adversarial Networks

    Generating texts of different sentiment labels is getting more and more attention in the area of natural language generation. Recently, Generative Adversarial Net (GAN) has shown promising results in text generation. However, the texts generated by GAN usually suffer from the problems of poor quality, lack of diversity and mode collapse. In this paper, we propose a novel framework – SentiGAN, which has multiple generators and one multi-class discriminator, to address the above problems. In our framework, multiple generators are trained simultaneously, aiming at generating texts of different sentiment labels without supervision. We propose a penalty based objective in the generators to force each of them to generate diversified examples of a specific sentiment label. Moreover, the use of multiple generators and one multi-class discriminator can make each generator focus on generating its own examples of a specific sentiment label accurately. Experimental results on four datasets demonstrate that our model consistently outperforms several state-of-the-art text generation methods in the sentiment accuracy and quality of generated texts.

  • Understanding Ethereum via Graph Analysis

    Being the largest blockchain with the capability of running smart contracts, Ethereum has attracted wide attention and its market capitalization has reached 20 billion USD. Ethereum not only supports its cryptocurrency named Ether but also provides a decentralized platform to execute smart contracts in the Ethereum virtual machine. Although Ether’s price is approaching 200 USD and nearly 600K smart contracts have been deployed to Ethereum, little is known about the characteristics of its users, smart contracts, and the relationships among them. To fill in the gap, in this paper, we conduct the first systematic study on Ethereum by leveraging graph analysis to characterize three major activities on Ethereum, namely money transfer, smart contract creation, and smart contract invocation. We design a new approach to collect all transaction data, construct three graphs from the data to characterize major activities, and discover new observations and insights from these graphs. Moreover, we propose new approaches based on cross-graph analysis to address two security issues in Ethereum. The evaluation through real cases demonstrates the effectiveness of our new approaches.

  • LegoOS: A Disseminated, Distributed OS for Hardware Resource Disaggregation

    The monolithic server model where a server is the unit of deployment, operation, and failure is meeting its limits in the face of several recent hardware and application trends. To improve heterogeneity, elasticity, resource utilization, and failure handling in datacenters, we believe that datacenters should break monolithic servers into disaggregated, network-attached hardware components. Despite the promising benefits of hardware resource disaggregation, no existing OSes or software systems can properly manage it. We propose a new OS model called the splitkernel to manage disaggregated systems. Splitkernel disseminates traditional OS functionalities into loosely-coupled monitors, each of which runs on and manages a hardware component. Using the splitkernel model, we built LegoOS, a new OS designed for hardware resource disaggregation. LegoOS appears to users as a set of distributed servers. Internally, LegoOS cleanly separates processor, memory, and storage devices both at the hardware level and the OS level. We implemented LegoOS from scratch and evaluated it by emulating hardware components using commodity servers. Our evaluation results show that LegoOS’s performance is comparable to monolithic Linux servers, while largely improving resource packing and failure rate over monolithic clusters.

  • Should I Follow the Crowd? A Probabilistic Analysis of the Effectiveness of Popularity in Recommender Systems

    The use of IR methodology in the evaluation of recommender systems has become common practice in recent years. IR metrics have been found however to be strongly biased towards rewarding algorithms that recommend popular items –the same bias that state of the art recommendation algorithms display. Recent research has confirmed and measured such biases, and proposed methods to avoid them. The fundamental question remains open though whether popularity is really a bias we should avoid or not; whether it could be a useful and reliable signal in recommendation, or it may be unfairly rewarded by the experimental biases. We address this question at a formal level by identifying and modeling the conditions that can determine the answer, in terms of dependencies between key random variables, involving item rating, discovery and relevance. We find conditions that guarantee popularity to be effective or quite the opposite, and for the measured metric values to reflect a true effectiveness, or qualitatively deviate from it. We exemplify and confirm the theoretical findings with empirical results. We build a crowdsourced dataset devoid of the usual biases displayed by common publicly available data, in which we illustrate contradictions between the accuracy that would be measured in a common biased offline experimental setting, and the actual accuracy that can be measured with unbiased observations.

  • SuRF: Practical Range Query Filtering with Fast Succinct Tries

    We present the Succinct Range Filter (SuRF), a fast and compact data structure for approximate membership tests. Unlike traditional Bloom filters, SuRF supports both single-key lookups and common range queries: open-range queries, closed-range queries, and range counts. SuRF is based on a new data structure called the Fast Succinct Trie (FST) that matches the point and range query performance of state-of-the-art order-preserving indexes, while consuming only 10 bits per trie node. The false positive rates in SuRF for both point and range queries are tunable to satisfy different application needs. We evaluate SuRF in RocksDB as a replacement for its Bloom filters to reduce I/O by filtering requests before they access on-disk data structures. Our experiments on a 100 GB dataset show that replacing RocksDB’s Bloom filters with SuRFs speeds up open-seek (without upper-bound) and closed-seek (with upper-bound) queries by up to 1.5× and 5× with a modest cost on the worst-case (all-missing) point query throughput due to slightly higher false positive rate.

  • A Constant-Factor Approximation Algorithm for the Asymmetric Traveling Salesman Problem

    We give a constant-factor approximation algorithm for the asymmetric traveling salesman problem. Our approximation guarantee is analyzed with respect to the standard LP relaxation, and thus our result confirms the conjectured constant integrality gap of that relaxation.
    Our techniques build upon the constant-factor approximation algorithm for the special case of node-weighted metrics. Specifically, we give a generic reduction to structured instances that resemble but are more general than those arising from node-weighted metrics. For those instances, we then solve Local-Connectivity ATSP, a problem known to be equivalent (in terms of constant-factor approximation) to the asymmetric traveling salesman problem.

  • Authoring and Verifying Human-Robot Interactions

    As social agents, robots designed for human interaction must adhere to human social norms. How can we enable designers, engineers, and roboticists to design robot behaviors that adhere to human social norms and do not result in interaction breakdowns? In this paper, we use automated formal-verification methods to facilitate the encoding of appropriate social norms into the interaction design of social robots and the detection of breakdowns and norm violations in order to prevent them. We have developed an authoring environment that utilizes these methods to provide developers of social-robot applications with feedback at design time and evaluated the benefits of their use in reducing such breakdowns and violations in human-robot interactions. Our evaluation with application developers (N=9) shows that the use of formal-verification methods increases designers’ ability to identify and contextualize social-norm violations. We discuss the implications of our approach for the future development of tools for effective design of social-robot applications.

  • HighLife: Higher-arity Fact Harvesting

    Text-based knowledge extraction methods for populating knowledge bases have focused on binary facts: relationships between two entities. However, in advanced domains such as health, it is often crucial to consider ternary and higher-arity relations. An example is to capture which drug is used for which disease at which dosage (e.g. 2.5 mg/day) for which kinds of patients (e.g., children vs. adults). In this work, we present an approach to harvest higher-arity facts from textual sources. Our method is distantly supervised by seed facts, and uses the fact-pattern duality principle to gather fact candidates with high recall. For high precision, we devise a constraint-based reasoning method to eliminate false candidates. A major novelty is in coping with the difficulty that higher-arity facts are often expressed only partially in texts and strewn across multiple sources. For example, one sentence may refer to a drug, a disease and a group of patients, whereas another sentence talks about the drug, its dosage and the target group without mentioning the disease. Our methods cope well with such partially observed facts, at both pattern-learning and constraint-reasoning stages. Experiments with health-related documents and with news articles demonstrate the viability of our method.

If you want more, you can visit the Jeff Huang’s list.