Canonical Voices

Prakash

IoT Standards – LMFAO

If you are a company that is interested in connected devices or the Internet of Things (IoT), you better not be waiting for standards to emerge. This will not be happening anytime soon. IoT is a multi-trillion dollar market, and, with so much potential business on the line, the big technology companies are all angling to create their own standard.
Of course these companies all say they want to create common protocols and framework. But let’s face it, there is too much at stake for any of these companies to not try and get the upper hand on the competition. As a result, we have an explosion of consortiums and “open source” projects that are intended to create these standards.

Read more
facundo


¿Qué es?

La CDPedia es la Wikipedia Offline. O sea, la Wikipedia, lo más fiel posible a su formato y contenido original, pero armada (construida, compactada) de una manera que no se necesita nada de Internet para acceder a toda la info de la misma.

Se llama CDPedia porque la idea original era meterla en un CD. Hoy por hoy generamos cuatro imágenes en cada liberación de CDPedia: un CD, un DVD, y dos archivos comprimidos (uno mediano y otro grande) que se pueden poner en un pendrive o en cualquier disco rígido.

La CDPedia es multiplataforma: el mismo CD, DVD o archivo comprimido se puede usar en Linux, Windows, o Mac, sin necesitar nada instalado previamente por fuera de lo que cada sistema trae normalmente.

CDPedia


¿Cómo se usa? ¿Cómo se ve?

Para usarla, lo primero es descargarla. Pueden acceder a la página del proyecto y ahí encontrarán info acerca de las cuatro versiones que tenemos actualmente, con el detalle de cuantas páginas y cuantas imágenes tiene cada una. Para bajarlo, necesitan un cliente de Torrent; para Linux a mí me gusta mucho el Deluge, que también puede usarse en Windows y Mac; otro cliente recomendado para las tres plataformas es qBittorrent.

Si descargan la versión CD o DVD, lo primero que tienen que hacer es grabarlo a un disco virgen, para lo cual necesitan una grabadora y un software para grabar. Si usan Windows y no tienen ninguno instalado, les recomiendo InfraRecorder que es software libre y muy fácil de usar. Pongan el disco generado en el equipo y ejecuten la CDPedia.

Si descargan las versión tarball, directamente descompriman los archivos en el disco rígido. Entren a la carpeta descomprimida y ejecuten la CDPedia.

¿Cómo se ejecuta la CDPedia? Bueno, depende de cada sistema. En Windows con hacer doble click en cdpedia.exe, alcanza. En Linux o Mac, si tienen bien configurado el navegador de archivos, debería funcionar haciendo doble click en cdpedia.py, pero siempre pueden recurrir a abrir una terminal, ir hasta el directorio en cuestión, y hacer ./cdpedia.py.

En cualquier caso al ejecutar ese archivo se va a levantar el Server de CDPedia, y al mismo tiempo se abrirá un navegador apuntando a ese Server local. Luego, es sólo usarla, ya que se explora y utiliza de la misma manera que la Wikipedia Online (con la excepción obvia que la CDPedia es de lectura solamente: no permite editar el contenido como sí lo hace la Wikipedia).

(a este y otros screenshots, hagan click para verlos más grandes)

Cómo se ve la CDPedia

Una decisión estratégica de la CDPedia es tomar el HTML generado por los servers de Wikipedia y usarlos casi directamente (les recortamos unos headers, optimizamos algunas cositas). Exploramos en algún momento tomar la info de la base de datos directamente, pero no logramos generar una página web igual a la de Wikipedia online.

Y eso es una fortaleza de la CDPedia: por la manera en que armamos las páginas, la forma de ver y usar las páginas, de explorar y acceder a la información, es igual a la Wikipedia online, de manera que el usuario no tiene un costo cognitivo en pasar de la versión online a offline. Es más, también se puede considerar a la CDPedia como el paso previo de consumo de contenido a la Wikipedia: una persona se puede acostumbrar a explorar las páginas, leer, cruzar y criticar la información, etc, y recién cuando tiene todo armado va a la Wikipedia Online y al resto de Internet para completar su investigación.

Más allá de la página a nivel contenido, lo que sí modificamos mucho es la barra de la izquierda. No tiene la original de Wikipedia, porque no tiene sentido al ser todo offline, así que reemplazamos los botones y enlaces por otros: hay un botón para ver una página al azar, un campo de texto de búsqueda, el logo de CDPedia, el logo de PyAr, enlace a una página de ayuda, etc...

Algo que también modificamos bastante es como señalizamos los enlaces en la página misma, en el contenido de Wikipedia. Hay principalmente tres tipos, distinguibles en cómo decoramos el texto convertido en enlace:

  • Azul: un link normal, apunta a otra página de Wikipedia que se incluyó dentro de CDPedia.
  • Rojo, subrayado con guiones: un enlace a otra página de Wikipedia pero que no fue incluida en CDPedia por razones de espacio.
  • Azul, subrayado con guiones: un link que los sacaría de CDPedia, ya que apunta a recursos online (útiles solamente si tenés Internet, claramente).

Muestra de enlaces

Otra sección que modificamos es el pie de cada página: ponemos un enlace a la misma página pero online, en Wikipedia misma, por si el usuario necesita la información actualizada. También aquí incluimos el contenido original, ponemos algún disclaimer extra, mencionamos que CDPedia es un proyecto de Python Argentina (y apuntamos al tutorial de Python que está incluido en la CDPedia).

Cabe mencionar que la CDPedia funciona también en Modo Servidor. De esta manera, se puede instalar la CDPedia en el servidor de una escuela, y que todas las computadoras del establecimiento puedan usar la información desde allí. Así logramos el efecto deseado de que los chicos puedan tener acceso al contenido de Wikipedia sin realmente tener Internet, pero sin la complicación o el incordio de tener que instalar CDPedia en cada una de las computadoras. Acá hay más instrucciones para configurarla de este modo.


¿Qué contenido tiene?

El contenido de la CDPedia está fuertemente determinado por dos características intrínsecas del proyecto: la CDPedia es estática y fácilmente distribuible en un disco o pendrive.

Digo que la CDPedia es estática porque una vez armada, no se actualiza. Es por eso una especie de "fotografía de un momento de Wikipedia" que, por definición, siempre va a estar desactualizada.

Cuando se comienza a generar una nueva versión de la CDPedia, se baja la versión más actualizada de todo el contenido de Wikipedia y se empieza a procesar. Este procesamiento puede llevar varias semanas, incluso unos meses. Entonces, cuando se libera una nueva versión de CDPedia, no incluye todos los cambios que se generaron en Wikipedia misma desde que se empezó a procesar.

Es por esto que se trata de liberar una versión de CDPedia al menos una vez por año, para que contenga la información lo más actualizada posible.

Ejemplo de un artículo

También digo que la CDPedia se puede distribuir fácilmente: sólo hace falta quemar un CD o DVD, o incluso pasarse los archivos mediante un pendrive. En casi todas las versiones (menos la más grande), por una cuestión de formato, no entra todo el contenido de la Wikipedia. Por ejemplo, para la versión 0.8.3, tenemos lo siguiente:

  • CD (693 MB): 54 mil páginas y 5% de las imágenes
  • Tarball medio (3.6 GB): 400 mil páginas y 20% de las imágenes
  • DVD (4.3 GB): Todas las páginas y 8% de las imágenes
  • Tarball grande (8.7 GB): Todas las páginas y todas las imágenes

Entonces, a menos que estemos armando el tarball grande, es evidente que tenemos que decidir cuáles páginas e imágenes van a entrar, y cuáles van a quedar afuera.

Esa decisión se toma ordenando todas las páginas por un determinado puntaje (que explico abajo), y se eligen las primeras N páginas (para el ejemplo anterior, las primeras 54 mil para el CD, las primeras 400 mil para el tarball medio, etc). Esas páginas tienen a su vez imágenes, que naturalmente también quedan ordenadas por el puntaje de las páginas: se toma un primer porcentaje de imágenes que se incluyen al 100%, otro porcentaje de imágenes que se escalan al 75%, otro porcentaje de imágenes que se escalan al 50%, y el resto no se incluye.

Analizando las páginas

Como vieron, un tema clave en la selección es darle un puntaje a las páginas. Este puntaje está formado (hoy por hoy) en base a dos factores: levemente por el largo de la página (una página larga tiene más puntaje que una corta), y fuertemente por lo que llamamos "peishranc", que es la cantidad de otras páginas que enlazan a la que estamos evaluando. Entonces, si a una página se la menciona en otras mil páginas es mucho más importante que una página que casi no se la menciona en el resto de la Wikipedia.

Otro gran detalle en lo que es "contenido" es qué hacemos para mitigar el problema de la vandalización. O sea, cómo evitamos en lo posible incluir páginas que fueron vandalizadas. Cuando comienza el proceso de generar una nueva versión de la CDPedia, como les comentaba antes, bajamos todas las páginas de Wikipedia, ¡pero no siempre bajamos la última versión! Lo que hacemos es revisar cuándo fue modificada y por quién: si fue modificada por un usuario normal, perfecto; pero si fue modificada por un usuario anónimo (como sucede en la mayoría de las vandalizaciones) nos fijamos cuando fue modificada: si fue hace más de varios días, la incluimos (asumimos que la gente de Wikipedia ya tuvo tiempo de verificar el cambio), pero si es muy reciente evitamos la última versión de la página, y agarramos la versión anterior (y aplicamos nuevamente todos estos mismos controles).


¿Cómo surgió el proyecto?

Cuenta la leyenda que el proyecto arrancó en el sprint posterior al primer PyDay de Santa Fé, en Junio del 2006, con la idea base de poder distribuir la Wikipedia a aquellos lugares que no tenían o tienen acceso a Internet (en particular teníamos en mente a escuelas de frontera o de ciudades chicas, bibliotecas de barrio, centros culturales de pueblos pequeños, etc.).

El proyecto continuó, y aunque no siempre le pudimos dedicar tiempo, tampoco nos alejamos nunca demasiado. Las mejoras en el proyecto fueron muy por ráfagas. Quiero destacar que fuimos muchos los que colaboramos con el proyecto, a lo largo de los años, ¡casi 30 personas!

Se trabajó mucho en este proyecto durante los PyCamps (los dos en Los Cocos, el de Verónica, y el de La Falda), donde muchas personas le dedicaron un buen tiempo, y también se realizó bastante durante otras reuniones, especialmente durante el 2010 y 2011.

Trabajando en un PyCamp

A modo de ejemplo, dos sprints: uno fue en un incipiente hacklab, donde se experimentó mucho sobre el índice para las búsquedas, y también durante la fundación de Wikimedia Argentina, donde se presentó por primera vez el proyecto y se realizó un gran avance en la primera parte del procesamiento de datos.

En años más cercanos yo traté de involucrar colaboradores en algunos sprints efímeros que armé, con poca suerte. Lamentablemente en el último tiempo fui principalmente sólo yo el que empujó el proyecto (lo cual es una autocrítica, más que un autoreconocimiento).

Una gran característica de la CDPedia, indiscutiblemente el proyecto más grande y más largo de Python Argentina, es que siempre se mantuvo orientado a los mismos objetivos: tener una Wikipedia offline con fines sociales (distribuir en escuelas sin conexión a Internet, que el conocimiento sea libre, etcétera), que sea divertido de hacer (es decir, hacerlo en Python), y mantenerlo libre (no sólo el producto final, que recomendamos copiarlo y repartirlo, sino el código en sí).


¿Se logró cumplir el objetivo social?

Como decía arriba, uno de los objetivos de la CDPedia es difundir el conocimiento, lograr que gente que no tenga acceso a Internet igual pueda acceder a la información de la Wikipedia, que es tan valiosa. Siendo PyAr una comunidad relativamente pequeña, era difícil escalar a tener un impacto nacional en el común de la gente.

En su momento queríamos que se viralice persona a persona: que alguien la baje y haga un par de CDs y los reparta, que los que reciben cada CD hagan a su vez varias copias y las repartan a otras personas, a escuelas, bibliotecas de barrio, etc. Pero no tuvimos mucho éxito con esa movida.

Pero resulta que Martín Varsavsky se casó, y Jimmy Wales le regaló para el casamiento la posibilidad de que se distribuya una Wikipedia offline en Argentina. Preguntó cuáles habían, la CDPedia era la que mejor se ajustaba a lo que se necesitaba, y vino Jimmy a Buenos Aires, le mostramos la CDPedia, y luego hubo una reunión en Educ.ar para terminar de acordar esto (fueron Jimmy por Wikimedia, Enrique Chaparro por Wikimedia Argentina y Alecu por PyAr).

En gran parte porque Educ.ar quería meter la CDPedia en un disco de ellos (con carátula de ellos, algunas otras páginas, etc), se logró que dicha institución becara a dos chicos de PyAr, Diego Mascialino y Hernán Olivera, para trabajar part time en esto.

Así que agarraron la versión 0.6 que recién había salido (Alecu y yo nos habíamos apurado a cerrar muchos detalles para tener algo funcionando presentable a Jimmy Wales), y entraron a darle. Esto le dio bastante impulso al desarrollo del proyecto, sumado a que también aporté regularmente al proyecto, y a que luego de que se terminara la beca Diego siguió trabajando en CDPedia, y que se sumó como "laburante regular" Santiago Piccinini.

Con todo este trabajo, y un nuevo empujón en el PyCamp del 2011, pudimos terminar de cerrar la versión 0.7, que se entregó a Educ.ar y se distribuyó a todas las escuelas del pais.

Sin embargo el mayor hito a nivel de distribución masiva de la CDPedia es que en algún momento fue incluida en las notebooks que el Estado argentino distribuye a los chicos de escuelas de todo el país como parte del programa Conectar Igualdad. Y también se la muestran a alumnos y docentes en los talleres que hacen como parte del programa.


¿Se puede espiar abajo del capot?

¿Cómo se arma la CDPedia? ¿Cómo se logra cumplir todo lo que expliqué arriba?

Es bastante sencillo: hay que bajar el código con git desde la página del proyecto en github, y luego correr un script que hace todo solo: el cdpetron.

Este script tiene bastantes opciones (especialmente para no repetir partes del proceso: que no vuelva a listar todas las páginas, que no vuelva a bajarlas, que no limpie todo antes de comenzar, etc), pero lo básico es que se le especifica de dónde tomar el código, donde bajar y dejar páginas e imágenes, y en qué idioma trabajar.

Incluso hay una manera de correrlo en modo test, para que haga solo una parte del trabajo y poder arrancar pronto a probar cosas, ideal para mezclarlo con la opción de generar una sola de las versiones:

    $ utilities/cdpetron.py --test-mode --image-type=beta . /tmp/dumpcdpedia es

El comando anterior tarda relativamente poco (menos de cinco minutos en una máquina normal y con buena conexión a Internet) y nos deja todo el proceso realizado, pero con pocas páginas.

Ver lo que obtuvimos es sencillo, porque más allá de generarnos el tarball o el .iso correspondiente, podemos probar la CDPedia directamente del directorio donde realizamos el proceso, haciendo...

    ./cdpedia.py

...lo cual levantará el server y nos abrirá el browser, tal cual si lo hiciéramos de la versión final (pero con la ventaja que podemos pararlo, cambiar el código para probar el algo, levantarlo de nuevo, ver los resultados, etc.)

¿Y cómo es el proceso que realiza? Bueno, la estructura interna (y el proceso para obtenerla) de la CDPedia está muy influida por la necesidad de optimizar al máximo la compresión y el acceso a la información, de manera de poder meter en cada formato (CD, etc...) la mayor cantidad posible de artículos e imágenes.

Podemos delinear el proceso que se realiza en en el siguiente gráfico:

Proceso de la CDPedia

El primer paso es bajar de la Wikipedia misma todas las páginas (lo que realmente tiene dos sub-pasos, un listado general de todas las páginas que nos interesan, y luego efectivamente bajarlas). Esas páginas son pasadas por diferentes preprocesadores que hacen distintos trabajos. Algunas las filtran y eliminan páginas que no queremos, otras les asignan puntajes, otras las modifican mejorándolas para nuestro objetivo, otras extraen información que va a ser útil luego.

Al final de ese preprocesamiento tenemos dos grandes resultados intermedios: los HTMLs "útiles", más un montón de metadata. Aquí se abren tres grandes ramas de trabajo.

La primera es el manejo de las imágenes. Se buscan los enlaces en las páginas, se descargan todas las imágenes necesarias (que pueden no ser todas, dependiendo de la versión generada), se reducen las que corresponden (algunas se incluyen al 75% o 50% de su tamaño) y finalmente se arman los llamados "bloques de imágenes".

Por otro lado, con los resultados intermedios se generan los "bloques de artículos".

Y finalmente, se procesan todos los títulos de las páginas más algo de metadata y se hace pasar por un complejo algoritmo matemático que nos pre-arma la información para generar los "bloques del índice".

A esta altura tengo que explicar qué son estos "bloques" de imágenes, artículos o índice. Es una estructura no demasiado compleja pero muy bien pensada para el objetivo de la CDPedia que es funcionar sin usar demasiada memoria y poco espacio en disco. Básicamente tenemos bloques de información comprimidos de forma independiente: es un equilibrio entre comprimir todo por separado, o comprimir todo junto; logramos mejor ratio de compresión que comprimiendo la info por separada, y no tenemos que descomprimir algo demasiado grande al no estar todo junto. Para decidir qué bloque consultar hay un hasheo y selección, y luego dentro de cada bloque hay un índice binario de contenidos, pero no mucho más.

Finalmente, con estos bloques, más algunos recursos estáticos (imágenes, CSSs, algo de JSs, el tutorial de Python comprimido, etc.), más el código de Python propiamente dicho para servir la CDPedia, se arman los tarballs o .ISOs.


¿En qué situación está el proyecto actualmente?

El proyecto avanza, pero lento.

Hay varios bugs abiertos, incluso algunos que son críticos porque se muestran un par de cosas feas luego de un cambio de formato de las páginas de Wikipedia, pero yo personalmente no estoy haciendo foco ahí, sino que estoy empujando un par de cambios más grandes.

Uno de ellos es lograr la internacionalización de la CDPedia. Cuando esté terminado, se van a poder crear CDPedias no sólo a partir de la Wikipedia en español, sino también de la Wikipedia en otros idiomas: portugués, aymara, guaraní, alemán, ruso, etc...

El otro cambio es más bien la construcción de una infrastructura en particular. Mi idea es tener una generación continuas de CDPedias, que se arme la CDPedia en español, y automáticamente luego se arme la de otro idioma, y otro, y otro, y otro, y luego de varios meses, vuelva a arrancar con la de español.

Trabajando

Pero, como decía, hay mil cosas para hacer.

Unos chicos en un PyCamp hicieron una app para Android que, luego de copiar los datos a mano, correría la CDPedia en cualquier teléfono o tablet (yo traté recientemente de usarlo y tuve unos problemas y no lo pude hacer andar del todo).

Otro detalle que necesita trabajo es que el código en sí está bastante feo... mezcla inglés y castellano, no cumple PEP 8 ni PEP 257, tiene poco y nada de pruebas de unidad, etc.

Si tienen ganas de participar de cualquier manera, lo principal es que se pongan en contacto con el grupo en general, a través de la lista de correo o del foro asociado (son espejo uno del otro, usen el
que sientan más cómodo). Lo mismo si desean hacer cualquier consulta, o ponerse en contacto para cualquier inquietud.

CDPedia necesita amor. Programadores con ganas de trabajar y aprender, tiempo de programador para continuar llevando este proyecto tan interesante y valioso por buen camino.

Read more
pitti

The last two major autopkgtest releases (3.18 from November, and 3.19 fresh from yesterday) bring some new features that are worth spreading.

New LXD virtualization backend

3.19 debuts the new adt-virt-lxd virtualization backend. In case you missed it, LXD is an API/CLI layer on top of LXC which introduces proper image management, seamlessly use images and containers on remote locations, intelligently caching them locally, automatically configure performant storage backends like zfs or btrfs, and just generally feels really clean and much simpler to use than the “classic” LXC.

Setting it up is not complicated at all. Install the lxd package (possibly from the backports PPA if you are on 14.04 LTS), and add your user to the lxd group. Then you can add the standard LXD image server with

  lxc remote add lco https://images.linuxcontainers.org:8443

and use the image to run e. g. the libpng test from the archive:

  adt-run libpng --- lxd lco:ubuntu/trusty/i386
  adt-run libpng --- lxd lco:debian/sid/amd64

The adt-virt-lxd.1 manpage explains this in more detail, also how to use this to run tests in a container on a remote host (how cool is that!), and how to build local images with the usual autopkgtest customizations/optimizations using adt-build-lxd.

I have btrfs running on my laptop, and LXD/autopkgtest automatically use that, so the performance really rocks. Kudos to Stéphane, Serge, Tycho, and the other LXD authors!

The motivation for writing this was to make it possible to move our armhf testing into the cloud (which for $REASONS requires remote containers), but I now have a feeling that soon this will completely replace the existing adt-virt-lxc virt backend, as its much nicer to use.

It is covered by the same regression tests as the LXC runner, and from the perspective of package tests that you run in it it should behave very similar to LXC. The one problem I’m aware of is that autopkgtest-reboot-prepare is broken, but hardly anything is using that yet. This is a bit complicated to fix, but I expect it will be in the next few weeks.

MaaS setup script

While most tests are not particularly sensitive about which kind of hardware/platform they run on, low-level software like the Linux kernel, GL libraries, X.org drivers, or Mir very much are. There is a plan for extending our automatic tests to real hardware for these packages, and being able to run autopkgtests on real iron is one important piece of that puzzle.

MaaS (Metal as a Service) provides just that — it manages a set of machines and provides an API for installing, talking to, and releasing them. The new maas autopkgtest ssh setup script (for the adt-virt-ssh backend) brings together autopkgtest and real hardware. Once you have a MaaS setup, get your API key from the web UI, then you can run a test like this:

  adt-run libpng --- ssh -s maas -- \
     --acquire "arch=amd64 tags=touchscreen" -r wily \
     http://my.maas.server/MAAS 123DEADBEEF:APIkey

The required arguments are the MaaS URL and the API key. Without any further options you will get any available machine installed with the default release. But usually you want to select a particular one by architecture and/or tags, and install a particular distro release, which you can do with the -r/--release and --acquire options.

Note that this is not wired into Ubuntu’s production CI environment, but it will be.

Selectively using packages from -proposed

Up until a few weeks ago, autopkgtest runs in the CI environment were always seeing/using the entirety of -proposed. This often led to lockups where an application foo and one of its dependencies libbar got a new version in -proposed at the same time, and on test regressions it was not clear at all whose fault it was. This often led to perfectly good packages being stuck in -proposed for a long time, and a lot of manual investigation about root causes.

.

These days we are using a more fine-grained approach: A test run is now specific for a “trigger”, that is, the new package in -proposed (e. g. a new version of libbar) that caused the test (e. g. for “foo”) to run. autopkgtest sets up apt pinning so that only the binary packages for the trigger come from -proposed, the rest from -release. This provides much better isolation between the mush of often hundreds of packages that get synced or uploaded every day.

This new behaviour is controlled by an extension of the --apt-pocket option. So you can say

  adt-run --apt-pocket=proposed=src:foo,libbar1,libbar-data ...

and then only the binaries from the foo source, libbar1, and libbar-data will come from -proposed, everything else from -release.

Caveat:Unfortunately apt’s pinning is rather limited. As soon as any of the explicitly listed packages depends on a package or version that is only available in -proposed, apt falls over and refuses the installation instead of taking the required dependencies from -proposed as well. In that case, adt-run falls back to the previous behaviour of using no pinning at all. (This unfortunately got worse with apt 1.1, bug report to be done). But it’s still helpful in many cases that don’t involve library transitions or other package sets that need to land in lockstep.

Unified testbed setup script

There is a number of changes that need to be made to testbeds so that tests can run with maximum performance (like running dpkg through eatmydata, disabling apt translations, or automatically using the host’s apt-cacher-ng), reliable apt sources, and in a minimal environment (to detect missing dependencies and avoid interference from unrelated services — these days the standard cloud images have a lot of unnecessary fat). There is also a choice whether to apply these only once (every day) to an autopkgtest specific base image, or on the fly to the current ephemeral testbed for every test run (via --setup-commands). Over time this led to quite a lot of code duplication between adt-setup-vm, adt-build-lxc, the new adt-build-lxd, cloud-vm-setup, and create-nova-image-new-release.

I now cleaned this up, and there is now just a single setup-commands/setup-testbed script which works for all kinds of testbeds (LXC, LXD, QEMU images, cloud instances) and both for preparing an image with adt-buildvm-ubuntu-cloud, adt-build-lx[cd] or nova, and with preparing just the current ephemeral testbed via --setup-commands.

While this is mostly an internal refactorization, it does impact users who previously used the adt-setup-vm script for e. g. building Debian images with vmdebootstrap. This script is now gone, and the generic setup-testbed entirely replaces it.

Misc

Aside from the above, every new version has a handful of bug fixes and minor improvements, see the git log for details. As always, if you are interested in helping out or contributing a new feature, don’t hesitate to contact me or file a bug report.

Read more
Colin Ian King

The other day I needed to incorporate a large blob of binary data in a C program. One simple way is to use xxd, for example, on the binary data in file "blob", one can do:

xxd --include blob 

unsigned char blob[] = {
0xc8, 0xe5, 0x54, 0xee, 0x8f, 0xd7, 0x9f, 0x18, 0x9a, 0x63, 0x87, 0xbb,
0x12, 0xe4, 0x04, 0x0f, 0xa7, 0xb6, 0x16, 0xd0, 0x70, 0x06, 0xbc, 0x57,
0x4b, 0xaf, 0xae, 0xa2, 0xf2, 0x6b, 0xf4, 0xc6, 0xb1, 0xaa, 0x93, 0xf2,
0x12, 0x39, 0x19, 0xee, 0x7c, 0x59, 0x03, 0x81, 0xae, 0xd3, 0x28, 0x89,
0x05, 0x7c, 0x4e, 0x8b, 0xe5, 0x98, 0x35, 0xe8, 0xab, 0x2c, 0x7b, 0xd7,
0xf9, 0x2e, 0xba, 0x01, 0xd4, 0xd9, 0x2e, 0x86, 0xb8, 0xef, 0x41, 0xf8,
0x8e, 0x10, 0x36, 0x46, 0x82, 0xc4, 0x38, 0x17, 0x2e, 0x1c, 0xc9, 0x1f,
0x3d, 0x1c, 0x51, 0x0b, 0xc9, 0x5f, 0xa7, 0xa4, 0xdc, 0x95, 0x35, 0xaa,
0xdb, 0x51, 0xf6, 0x75, 0x52, 0xc3, 0x4e, 0x92, 0x27, 0x01, 0x69, 0x4c,
0xc1, 0xf0, 0x70, 0x32, 0xf2, 0xb1, 0x87, 0x69, 0xb4, 0xf3, 0x7f, 0x3b,
0x53, 0xfd, 0xc9, 0xd7, 0x8b, 0xc3, 0x08, 0x8f
};
unsigned int blob_len = 128;

..and redirecting the output from xxd into a C source and compiling this simple and easy to do.

However, for large binary blobs, the C source can be huge, so an alternative way is to use the linker ld as follows:

ld -s -r -b binary -o blob.o blob  

...and this generates the blob.o object code. To reference the data in a program one needs to determine the symbol names of the start, end and perhaps the length too. One can use objdump to find this as follows:

 objdump -t blob.o  
blob.o: file format elf64-x86-64
SYMBOL TABLE:
0000000000000000 l d .data 0000000000000000 .data
0000000000000080 g .data 0000000000000000 _binary_blob_end
0000000000000000 g .data 0000000000000000 _binary_blob_start
0000000000000080 g *ABS* 0000000000000000 _binary_blob_size

To access the data in C, use something like the following:

 cat test.c  

#include <stdio.h>
int main(void)
{
extern void *_binary_blob_start, *_binary_blob_end;
void *start = &_binary_blob_start,
*end = &_binary_blob_end;
printf("Data: %p..%p (%zu bytes)\n",
start, end, end - start);
return 0;
}

...and link and run as follows:

 gcc test.c blob.o -o test  
./test
Data: 0x601038..0x6010b8 (128 bytes)

So for large blobs, I personally favour using ld to do the hard work for me since I don't need another tool (such as xxd) and it removes the need to convert a blob into C and then compile this.

Read more
Colin Ian King

Firmware Test Suite, 15.12.00

The Canonical Hardware Enablement Team and myself are continuing the work to enhance the Firmware Test Suite (fwts) on a regular monthly cadence.  The latest changes in FWTS 15.12.00 includes the following new features and changes:

  • ACPI: ASPT (System Performance Tuning Table)
  • Update ACPICA to version 20151124 
  • Boot path sync with UEFI specification 2.5 adding:
    • SD device path 
    • Bluetooth device path
    • Wireless device path
    • Ramdisk device path
  • Mixed tests and test category options, e.g. fwts --uefitests klog cpufreq will run all the UEFI tests as well as klog and cpufreq tests
  • A new --log-level option that allows one to log test that fail at specified a level or higher, e.g. fwts --log-level high will just show high and critical test failures.
  • The apcidump table dump pseudo-test is now aligned with the ACPICA table dumping (disassembly) engine.
  • Various bug fixes.
It is also worth mentioning that the UEFI Board of Directors recommends FWTS as the ACPI v5.1 Self-Certification Test (SCT). This is exciting news and we welcome this decision for FWTS to be recognised in this way.

We are also very grateful for the community contributions to FWTS, this buy-in from community is appreciated and makes FWTS a better tool to support different architectures and systems.

As ever, with new releases, please consult the release notes.

Read more
April Wang

2015中国移动全球合作伙伴大会于2015年12月14日在广州保利世贸博览馆正式开启,此次大会以“和移动助力互联网+”为主题,由中国移动通信集团有限公司主办,聚百家终端、互联网、渠道等合作伙伴于一堂共同展示一年来的进程和未来新一年的合作远景。科能(Canonical)公司也受邀参加了此次活动,在独立展位展出了目前Ubuntu操作系统在移动手机端和智能硬件方面的最新亮点及开发进程。 

Ubuntu的展台除了展示目前已上市欧洲的两款现有Ubuntu手机机型,还有核心的三大亮点部分组成,首先展出了即将推出的一个重大手机功能性更新 - 让Ubuntu手机轻松变身个人电脑的Convergence技术,此外亮相现场的还有目前与中国移动合作研发的一款手机展示,以及Ubuntu系统在智能物联网硬件芯片上应用的展示。 

从今年初开始Ubuntu陆续有三款机型上市欧洲,首款BQ E4.5机型还在2015年的MWC大会上有展出,此后魅族MX4和BQ E5也陆续上架欧洲。 除了欧洲市场,今年Ubuntu的BQ版手机还在印度, 俄罗斯两国分别进行了销售,让当地的小伙伴们也尝到了鲜。 

在此次中国移动全球合作伙伴大会上,有一项会让现有手机功能极大提升的特征,又被称为Convergence的技术,在现场亮相展出。 它通过蓝牙连接无线鼠标,键盘,HDMI接线连接显示屏,可以将手机内容呈现到屏幕上;这样用户可以将自己的手机作为一台电脑来使用,完成一些很难或根本无法操作的任务,比如在数据表中进行数据统计等等。这是一个移动设备发展的趋势,科能(Canonical)公司早在2013年就提出了讲个人手机转型成个人电脑的设想,并在国外众筹平台提交次项目,虽然项目没还有筹备到目标金额,却依然很明显的证明了整个移动设备和传统个人电脑边界模糊的趋势,以及现存的市场需求。而在这次的大会中,现场的小伙伴们可以亲身体验一下了。目前版本依然处于一个Alpha版本状态, 但是喜欢自己动手“折腾”的小朋友现在就可以通过使用Nexus 4手机或Nexus 7的平板来使用Ubuntu移动产品这一先锋性的技术。

而展台另一面的亮点便是和中国移动合作研发中的一款硬件设备,这款设备上除了Ubuntu特有的常用型Scope,还展现了集合中国移动咪咕平台内容的几款Scope,包括和阅读, 和音乐,以及和彩云服务。除了内容上的亮点,重头戏其实是这款设备上呈现的RCS技术。 RCS英文全名又被称为Rich Communication Services,简单而言这套技术就是可以让手机用户在传统手机短信的基础上可以有更加丰富的信息数据的发送接收, 例如语音对话,视频对话,发送图片,甚至类似阅后即焚的功能。RCS技术其实在国外已经有很多家运营商实现了此功能,中国移动是国内首家开始正式研发RCS的中国运营商,而在此次大会上这款技术首次在一款Ubuntu手机上展示了出来,不能不说这是很重要的一个亮点。 

Ubuntu作为一款开源操作系统除了运行在云,PC,和手机移动设备之外, 在智能物联网的世界其实已经存在有一段时间了。很多早期开发机器人,无人机的先锋都是在使用Ubuntu操作系统。Ubuntu还是开源机器人基金(Open source robotics foundation)的软件平台基础。目前戴尔的Edge Gateway 5000 Series,以及DJI大疆的机载电脑“妙算 Manifold”也都是运行着Ubuntu的系统。这次移动大会现场,大疆的妙算也亮相现场。 

中国移动全球合作伙伴大会历时三天,展示了整个移动硬件,软件,系统, 芯片等等一整套生态线。 科能也有幸通过这次机会给所有参会伙伴们展示了Ubuntu在2015年一年来的进展和未来手机移动开发的方向和在智能物联网行业的长久计划。 
 

 

Read more
Nicholas Skaggs

Google Code In: Week One Summary

As we are now one week in, I thought I would give a little update on what's been happening inside Ubuntu for Google Code In (GCI). This is Ubuntu's first time as a GCI mentoring organization, and so far it's been a wonderful experience! I want to thank all the mentors and students who have already completed tasks for the greater Ubuntu community.

In the numbers
How about some raw numbers from the first week:

- More than 200 active students worked on tasks for ubuntu
- More than 30 mentors are lending there expertise and help on tasks
- 182 tasks were completed by students

That last number makes us the organization with the most tasks completed thus far. Amazing. It was a very busy week for everyone and the numbers help verify that. I've personally been blow away at some of the work the students have been able to accomplish already.

Details, please!
To name just a few cool tasks that have already landed, we have a wonderful new Bacon2D tutorial, HTML5 theming has gotten some love, and we've gotten some new inspired designs and bug fixes for the core apps. On the quality side of things, we've gotten new manual test runs for images and packages, the QATracker has seen a slew of long-standing bugs get fixed, and lest you think the desktop got left out, even Unity7 is receiving attention and getting bugs like this one fixed! That's on top of all the introductions in the the community, new installs, and socializing that has happened during the week.

If you are a high school student, I encourage you to check out GCI and consider participating with any of the great organizations available to mentor you in a variety of tasks. For those already a part of GCI, I invite you to check out what we have to offer within the ubuntu community. I look forward to meeting and working with you on some fun tasks.

And finally for who are ubuntu community members, it's not too late to become a mentor and be a part of this event. We are still welcoming new mentors and new tasks. Get in touch with myselfpopey, or José who can get you started.

Read more
David Henningsson

2.1 surround sound is (by a very unscientific measure) the third most popular surround speaker setup, after 5.1 and 7.1. Yet, ALSA and PulseAudio has since a long time back supported more unusual setups such as 4.0, 4.1 but not 2.1. It took until 2015 to get all pieces in the stack ready for 2.1 as well.

The problem

So what made adding 2.1 surround more difficult than other setups? Well, first and foremost, because ALSA used to have a fixed mapping of channels. The first six channels were decided to be:

1. Front Left
2. Front Right
3. Rear Left
4. Rear Right
5. Front Center
6. LFE / Subwoofer

Thus, a four channel stream would default to the first four, which would then be a 4.0 stream, and a three channel stream would default to the first three. The only way to send a 2.1 channel stream would then be to send a six channel stream with three channels being silence.

This was not good enough, because some cards, including laptops with internal subwoofers, would only support streaming four channels maximum.

(To add further confusion, it seemed some cards wanted the subwoofer signal on the third channel of four, and others wanted the same signal on the fourth channel of four instead.)

ALSA channel map API

The first part of the solution was a new alsa-lib API for channel mapping, allowing drivers to advertise what channel maps they support, and alsa-lib to expose this information to programs (see snd_pcm_query_chmaps, snd_pcm_get_chmap and snd_pcm_set_chmap).

The second step was for the alsa-lib route plugin to make use of this information. With that, alsa-lib could itself determine whether the hardware was 5.1 or 2.1, and change the number of channels automatically.

PulseAudio bass / treble filter

With the alsa-lib additions, just adding another channel map was easy.
However, there was another problem to deal with. When listening to stereo material, we would like the low frequencies, and only those, to be played back from the subwoofer. These frequencies should also be removed from the other channels. In some cases, the hardware would have a built-in filter to do this for us, so then it was just a matter of setting enable-lfe-remixing in daemon.conf. In other cases, this needed to be done in software.

Therefore, we’ve integrated a crossover filter into PulseAudio. You can configure it by setting lfe-crossover-freq in daemon.conf.

The hardware

If you have a laptop with an internal subwoofer, chances are that it – with all these changes to the stack – still does not work. Because the HDA standard (which is what your laptop very likely uses for analog audio), does not have much of a channel mapping standard either! So vendors might decide to do things differently, which means that every single hardware model might need a patch in the kernel.

If you don’t have an internal subwoofer, but a separate external one, you might be able to use hdajackretask to reconfigure your headphone jack to an “Internal Speaker (LFE)” instead. But the downside of that, is that you then can’t use the jack as a headphone jack…

Do I have it?

In Ubuntu, it’s been working since the 15.04 release (vivid). If you’re not running Ubuntu, you need alsa-lib 1.0.28, PulseAudio 7, and a kernel from, say, mid 2014 or later.

Acknowledgements

Takashi Iwai wrote the channel mapping API, and also provided help and fixes for the alsa-lib route plugin work.

The crossover filter code was imported from CRAS (but after refactoring and cleanup, there was not much left of that code).

Hui Wang helped me write and test the PulseAudio implementation.

PulseAudio upstream developers, especially Alexander Patrakov, did a thorough review of the PulseAudio patch set.

Read more
David Planella

Ubuntu is about people

Ubuntu has been around for just over a decade. That’s a long time for a project built around a field that evolves at such a rapid pace as computing. And not just any computing –software made for (and by) human beings, who have also inevitably grown and evolved with Ubuntu.

Over the years, Ubuntu has changed and has lead change to keep thriving in such a competitive space. The first years were particularly exciting: there was so much to do, countless possibilities and plenty of opportunities to contribute.

Everyone that has been around for a while has fond memories of the Ubuntu Developer Summit, UDS in short. An in-person event run every 6 months to plan the next version of the OS. Representatives of different areas of the community came together every half year, somewhere in the US or Europe, to discuss, design and lay out the next cycle, both in terms of community and technology.

It was in this setting where Ubuntu governance and leadership were discussed, the decisions of which default apps to include were made, the switch to Unity’s new UX, and much more. It was a particularly intense event, as often discussions continued into the hallways and sometimes up to the bar late at night.

In a traditionally distributed community, where discussions and planning happen online and across timezones, getting physically together in one place helped us more effectively resolve complex issues, bring new ideas, and often agree to disagree in a respectful environment.

Ubuntu Catalan team party

This makes Ubuntu special

Change takes courage, it takes effort in thinking outside the box and going all the way through, but it is not always popular. I personally believe, though, that without disruptive changes we wouldn’t be where we are today: millions of devices shipped with Ubuntu pre-installed, leadership in the cloud space, Ubuntu phones shipped worldwide, the convergence story, Ubuntu on drones, IoT… and a strong, welcoming and thriving community.

At some point, UDS morphed into UOS, an online-only event, which despite its own merits and success, it does admittedly lack the more personal component. This is where we are now, and this is not a write-up to hark back to the good old days, or to claim that all decisions we’ve made were optimal –acknowledging those lead by Canonical.

Ubuntu has evolved, we’ve solved many of the technological issues we were facing in the early days, and in many areas Ubuntu as a platform “just works”. Where we were seeing interest in contributing to the plumbing of the OS in the past, today we see a trend where communities emerge to contribute taking advantage of a platform to build upon.

Ubuntu Convergence

The full Ubuntu computer experience, in your pocket

Yet Ubuntu is just as exciting as it was in those days. Think about carrying your computer running Ubuntu in your pocket and connecting it to your monitor at home for the full experience, think about a fresh and vibrant app developer community, think about an Open Source OS powering the next generation of connected devices and drones. The areas of opportunity to get involved are much more diverse than they have ever been.

And while we have adapted to technological and social change in the project over the years, what hasn’t changed is one of the fundamental values of Ubuntu: its people.

To me personally, when I put aside open source and exciting technical challenges, I am proud to be part of this community because its open, welcoming, it’s driven by collaboration, I keep meeting and learning from remarkable individuals, I’ve made friendships that have lasted years… and I could go on forever. We are essentially people who share a mission: that of bringing access to computer to everyone, via Free Software and open collaboration.

And while over the years we have learnt to work productively in a remote environment, the need to socialize is still there and as important as ever to reaffirm this bonding that keep us together.

Enter UbuCons.

The rise of the UbuCons

UbuCons are in-person conferences around the world, fully driven by teams of volunteers who are passionate about Ubuntu and about community. They are also a remarkable achievement, showing an exceptional commitment and organizational effort from Ubuntu advocates to make them happen.

Unlike other big Ubuntu events such as release parties -celebrating new releases every six months- UbuCons happen generally once a year. They vary in size, going from tens to hundreds to thousands, include talks by Ubuntu community members and cross-collaboration with other Open Source communities. Most importantly, they are always events to remember.

UbuCons across the globe

A network of UbuCons

A few months back, at the Ubuntu Community Team we started thinking of how we could bring the community together in a similar way we used to do with a big central event, but also in a way that was sustainable and community-driven.

The existing network of UbuCons came as the natural vehicle for this, and in this time we’ve been working closely with UbuCon organizers to take UbuCons up a notch. It has been from this team work where initiatives such as the UbuContest leading to UbuCon DE in Berlin were made possible. And more support for worldwide UbuCons general: in terms of speakers and community donations to cover some of the organizational cost for instance, or most recently the UbuCon site.

It has been particularly rewarding for us to have played even a small part on this, where the full credit goes to the international teams of UbuCon organizers. Today, six UbuCons are running worldwide, with future plans for more.

And enter the Summit

Community power

Community power

But we were not content yet. With UbuCons covering a particular geographical area, we still felt a bigger, more centralized event was needed for the community to rally around.

The idea of expanding to a bigger summit had already been brainstormed with members of the Ubuntu California LoCo in the months coming to the last UbuCon @ SCALE in LA. Building up on the initial concept, the vision for the Summit was penciled in at the Community Leadership Summit (CLS) 2015 together with representatives from the Ubuntu Community Council.

An UbuCon Summit is a super-UbuCon, if you will: with some of the most influential members of the wider Ubuntu community, with first-class talks content, and with a space for discussions to help shape the future of particular areas of Ubuntu. It’s the evolution of an UbuCon.

UbuCon Europe planning

The usual suspects planning the next UbuCon Europe

As a side note, I’m particularly happy to see that the US Summit organization has already set the wheels in motion for another summit in Europe next year. A couple of months ago I had the privilege to take part in one of the most reinvigorating online sessions I’ve been in recent times, where a highly enthusiastic and highly capable team of organizers started laying out the plans for UbuCon Europe in Germany next year! But back to the topic…

Today, the first UbuCon Summit in the US is brought to you by a passionate team of organizers in the Ubuntu California LoCo, the Ubuntu Community Team at Canonical and SCALE, who hope you enjoy it and contribute to the event as much as we are planning to :-)

Jono Bacon, who we have to thank for participating in and facilitating the initial CLS discussions, wrote an excellent blog post on why you should go to UbuCon in LA in January, which I highly recommend you read.

In a nutshell, here’s what to expect at the UbuCon Summit:
– A two-day, two-track conference
– User and developer talks by the best experts in the Ubuntu community
– An environment to propose topics, participate and influence Ubuntu
– Social events to network and get together with those who make Ubuntu
100% Free registration, although we encourage participants to also consider registering for the full 4 days of SCALE 14x, who are the host to the UbuCon

I’m really looking forward to meeting everyone there, to seeing old and new faces and getting together to keep the big Ubuntu wheels turning.

The post Ubuntu is about people appeared first on David Planella.

Read more
Louis

gtimelog is a great tool to keep track of the time you spend  on your work. To me, its major advantage is to log the time at the end of the task and not at the beginning.

The format of the entry should be : {Category} : {Task}

It has a useful reporting functionality that will craft an email with the details of your tasks with the time spent on each one.  When used with the format described above, the reporting will be done according to each {Category} and a summary of the categories with the sum of the time spent on each.

The GUI is very simple :

gtimelog1

There is one line at the bottom that let you enter the task  you  have just completed.  Tasks are logged in a flat text file so it is very simple to use.

Command Line Interface (CLI) helper : tl.py

Since I spend most of my time using the CLI in a shell environment, I thought that it would be useful to log my gtimelog entries using a one line command.  So I wrote a simple python script called tl.py that will add one entry in the gtimelog log file with the correct timestamp format.

You can download the script here : https://github.com/karibou/tl

The other motivation for this script is to maintain the same spelling for each repetitive task, so the accounting remain coherent.  It also avoids to have to retype the same information over and over.

So when I start a new day, I simply let gtimelog know that a new day is starting by typing :

$ tl.py new

This will add the new : Arrived entry in gtimelog.

The categories that I use most frequently are hard coded in the script :

 'ua': 'L3 / L3 support', 
 'up': 'Upstream', 
 'ubu': 'Upstream Ubuntu', 
 'meet': 'Internal meetings', 
 'pers': 'Personal management', 
 'skill': 'Skills building', 
 'know': 'Knowledge transfer', 
 'team': 'Team support', 
 'comm': 'Community Involvment',

You can modify those to your own needs by editing the script.

To list each category available, just use ? as the argument :

$ tl.py ?
Categories : ['comm', 'know', 'meet', 'pers', 'skill', 'team', 'ua', 'ubu', 'up']

When I enter a new task, I simply use the syntax :

$ tl.py ubu : LP1104303 : gtimelog missing icon

ubu corresponds to the category of the task (Upstream Ubuntu) and whatever comes after the colon is the task.

The next time I want to report activity against this task, I simply use the script with the category of the task only and it will list all existing tasks for that category  :

$ tl.py ubu
1) LP1104303 : gtimelog missing icon
2) sosreport CVE-2015-7529
3) nut merge
4) LP: #1318111 - repetitive crashkernel=
5) liblinear library transition
6) makedumpfile packaging
7) LP1506550 - quassel sound bug
8) Xenial upgrade
9) sosreport autopkgtests for SRU
10) LP: #1496317 - kdump OOM killer failure
Select task (0 to exit,<CR> to continue):

Entering the task index number will add a new entry in gtimelog. If more than 10 tasks are available, enter <CR> to continue the listing of the tasks.

Using tl.py from multiple systems

It may be useful to be able to log your activity from multiple systems.  For instance, you may be working off your laptop while travelling and a desktop at home.  One possibility to achieve this is to use Cloud storage services like Dropbox and share the text file that holds your gtimelog tasks.

On Ubuntu, the file is located at $HOME/.local/share/gtimelog/timelog.txt

If you replace this file by a symbolic link to a file stored in the directory shared in the cloud, you can access the same file from different systems.

The Dropbox example

I already have my Dropbox files shared on my laptop so there is a ~/Dropbox directory available.  To host my gtimelog file, I create a gtimelog directory and copy the timelog.txt file there :

$ mkdir ~/Dropbox/gtimelog
$ cp ~/.local/share/gtimelog/timelog.txt ~/.local/share/gtimelog/timelog.bak
$ mv ~/.local/share/gtimelog/timelog.txt ~/Dropbox/gtimelog
$ ln -s ~/Dropbox/gtimelog/timelog.txt ~/.local/share/gtimelog/timelog.txt

By doing using such a configuration on each system where you want to enter gtimelog tasks, you will be able to share your gtimelog data in an easy manner.

Using tl.py on Ubuntu Server

In my specific case, I needed to go one step further : my second system is a server which does not have a graphical interface. Using this[1] blog entry, I was able to setup my server to receive the ./gtimelog/timelog.txt file only by doing a selective sychronization of the gtimelog directory.  The URL for the dropbox_temp file in the blog post is no longer valid but you can download it from github[2] . It only needs to be renamed to dropbox_temp.

[1] Simplify your server using Dropbox, Selective Sync

[2] dropbox_temp script

Read more
Prakash

If you purchased your computer in the last decade, it probably has a 64-bit-capable processor. The transition to 64-bit operating systems has been a long one, but Google is about to give Linux users another push. In March 2016, Google will stop releasing Chrome for 32-bit Linux distributions.

Read More: http://www.pcworld.com/article/3010404/browsers/googles-killing-chrome-support-for-32-bit-linux-ubuntu-1204-and-debian-7.html

Read more
facundo

Escapándose


El jueves pasado jugué a mi primer "juego de escape". Fuimos a Eureka con mi amiga Silvana y dos compañeras de trabajo de ella.

Un juego de escape es como un juego de aventura gráfica, pero de forma reducida y en la vida real. En Eureka lo explican así:

Estas encerrado con tu equipo en una habitación y tenés 60 minutos para escapar. La única forma de lograrlo es ir develando pista por pista y avanzar hasta encontrar la llave que les permitirá abrir la puerta y salir de la habitación. Es una carrera contra el tiempo y el momento perfecto para dejar fluir tus habilidades como detective.

Nosotros jugamos a Enigma. Básicamente entramos a una habitación, y la persona del lugar nos dio algunas reglas básicas: tienen una hora, lo que se abre se abre sin esfuerzo (no hay que sacudirlo hasta que se abra, digamos, sino que hay que resolver algo que lo abre), hay una puerta que va a permanecer cerrada, etc.

Luego se fue, cerró la puerta por donde entramos, y empezó el juego. Una tele nos dió una explicación de escenario (o sea, nos puso en el contexto de lo que había que resolver... me hizo acordar mucho a los videos del japonés en Lost), y luego empezó a contar el tiempo.

La habitación era grande, y había varios elementos interesantes (tranquilos, no les voy a spoilear el juego, esto es lo que uno ve al entrar): una máquina con botones, perillas e interruptores, una mochila colgada, una computadora que decía "entren el código de los misiles (tienen 10 intentos)", un mapamundi con leds marcando algunas ciudades, un tablero con tres relojes, un par de mesas y sillas, y algunas cosas más (algunas importantes, otras no).

Y desde ahí para adelante es como jugar una aventura gráfica: hay que explorar, entender qué tenés que hacer, vas encontrando cosas, vas tratando de descifrar donde se usa lo que encontraste (si se usa), algunas cosas salen fáciles, a veces te trabás, no sabés como seguir y vas repasando lo que tenés y como puede servir, etc.

Estuvo muy bueno.

Read more
Colin Ian King

Another seasonal obfuscated C program

During an idle moment while on vacation I was reading the paper "Reliable Two-Dimensional Graphing Methods for Mathematical Formulae with Two Free Variables" by Jeff Tupper and I stumbled upon rather amusing inequality at the end of section 12.   In tribute to this most excellent graphing formula, I felt inspired to use the same concept in my Christmas 2015 obfuscated C offering.

tupper.c

I cheated a little by also using a Makefile, but I hope this also adds to the magic of the resulting code.  To make the program more fun I thought I'd use a lot of confusion logic operator names in the code and mix in some incorrect Roman numeral constants too.  I could have obfuscated the code more and made it smaller, but life is too short. I will leave that as an exercise to the reader.

The source is available in my Christmas Obfuscated C git repository if you want to try it out:

 git clone https://github.com/ColinIanKing/christmas-obfuscated-C.git  
cd christmas-obfuscated-C/2015
make
./tupper | less

Enjoy!

Read more
Prakash

WHAT do you do when you have 30 seconds to spare? It may not sound like a lot of time, but there are productive things which you can try when the clock’s ticking away.

Here’s a list of 15 productive things for you to do within 30 seconds or less. No more complaints about “I don’t have time”, okay?

Read More: http://mypaper.sg/lifestyle/do-something-useful-within-30-seconds-20151117

Read more
Femma

We arrived in Helsinki on Sunday evening, ready to start our week long SDK sprint on Monday. Our hotel was in a nice location, by the sea.

The work stuff

The SDK is a core part of Ubuntu and provides an array of components and flexibility needed to create applications across staged and windowed form factors, with good design and user experience in mind.

The purpose of the sprint was to have the designers and engineers come together to work on tools and components such as palette themes, bottom edge, header, scrollbars, focus handling, dialogs, buttons, menus, text selections and developer tasks such as IDE, packaging and application startup.

Monday morning started with walking into our venue that looked somewhat like a classroom.

 

Classroom

The first task of the day required some physical activity of moving all the tables around so that the environment was much more conducive to a collaborative sprint.

Jouni presenting

Each day we broke off into working groups for our respective sessions and ironed out any existing issues, as well as working through new and exciting features that would enhance different SDK components.

Theme palette sessionJamie, Pierre and Zsombor working hard on the colour palette.

Jamie the professor

Old school pointing devices, Jamie gives it a go, looking very much like a professor!

What we achieved

During the course of the week we achieved what we’d set out to do:

  • Amended the theme palette to include any missing colours and then apply these to various components
  • Completed the implementation and release the bottom edge component into the staging environment
  • Completed the section scrolling prototype and have it reviewed by visual design and UX
  • Completed the portrait and landscape edit mode header prototype
  • Worked out behaviour of complex SDK components for focus handling and added some best practice examples to the specification
  • Communicated and gained concensus on the context menu design, who are now gearing up for some pre-requisite work and then implementation of context menus
  • Prepared the visual rules for buttons and made the Ubuntu shape ready to use for buttons
  • Completed the design for sliders  
  • Discussed a tree view component for navigation
  • Created a first draft of tabs wireframes and functionality agreed
  • Created a first draft of text selections visuals and reviewed, UX and functionality was discussed ready to include in the specification
  • Created the Libertine packaging project and containers
  • Tidied up the IDE
  • Created some Snapp packages and got them working
  • Ramped up some new  investigative work that arose in our collaboration

The planets aligned… literally

In the early hours of Wednesday morning  (before breakfast) a few of us managed to witnessed a planetary conjunction (Venus, Mars and Jupiter) which was truly amazing… a surprise benefit of sprinting in the arctic circle.
Even though there were a few hours of daylight, we managed to embrace the cold and stand outside to enjoy the beautiful views during lunch and coffee breaks.

The bay

All in all, it was a very productive and fun sprint. We left with a sense of accomplishment and camaraderie.

Read more
Stéphane Graber

TLDR: NorthSec is an incredible security event, our CTF simulates a whole internet for every participating team. This allows us to create just about anything, from a locked down country to millions of vulnerable IoT devices spread across the globe. However that flexibility comes at a high cost hardware-wise, as we’re getting bigger and bigger, we need more and more powerful servers and networking gear. We’re very actively looking for sponsors so get in touch with me!

What’s NorthSec?

NorthSec is one of the biggest on-site Capture The Flag (CTF), security contest in North America. It’s organized yearly over a weekend in Montreal (usually in May) and since the last edition, has been accompanied by a two days security conference before the CTF itself. The rest of this post will only focus on the CTF part though.

the-room

A view of the main room at NorthSec 2015

Teams arrive at the venue on Friday evening, get setup at their table and then get introduced to this year’s scenario and given access to our infrastructure. There they will have to fight their way through challenges, each earning them points and letting them go further and further. On Sunday afternoon, the top 3 teams are awarded their prize and we wrap up for the year.

Size wise, for the past two years we’ve had a physical limit of up to 32 teams of 8 participants and then a bunch of extra unaffiliated visitors. For the 2016 edition, we’re raising this to 50 teams for a grand total of 400 participants, thanks to some shuffling at the venue making some more room for us.

Why is it special?

The above may sound pretty simple and straightforward, however there are a few important details that sets NorthSec apart from other CTFs.

  • It is entirely on-site. There are some very big online CTFs out there but very few on-site ones. Having everyone participating in the same room is valuable from a networking point of view but also ensures fairness by enforcing fixed size teams and equal network bandwidth and latency.
  • Every team gets its very own copy of the whole infrastructure. There are no shared services in the simulated world we provide them. That means one team’s actions cannot impact another.
  • Each simulation is its own virtual world with its own instance of the internet, we use hundreds of LXC containers and thousands of VLANs and networks FOR EVERY TEAM to provide the most realistic and complete environment you can think of.
World map of our fake internet

World map of our fake internet

What’s our infrastructure like?

Due to the very high bandwidth and low latency requirements, most of the infrastructure is hosted on premises and on our hardware. We do plan on offloading Windows virtual machines to a public cloud for the next edition though.

We also provide a mostly legacy free environment to our contestants, all of our challenges are connected to IPv6-only networks and run on 64bit Ubuntu LTS  in LXC with state of the art security configurations.

Our rack

Our rack, on location at NorthSec 2015

 

All in all, for 32 teams (last year’s edition), we had:

  • 48000 virtual network interfaces
  • 2000 virtual carriers
  • 16000 BGP routers
  • 17000 Ubuntu containers
  • 100 Windows virtual machines
  • 20000 routing table entries

And all of that was running on:

  • Two firewalls (DELL SC1425)
  • Two infrastructure servers (DELL SC1425)
  • One management server (HP DL380 G5)
  • Four main contest hosts (HP DL380 G5)
  • Three backup contest hosts (DELL C6100)

On average we had 7 full simulations and 21 virtual machines running on every host (the backup hosts only had one each). That means each of the main contest hosts had:

  • 10500 virtual network interfaces
  • 435 virtual carriers
  • 3500 BGP routers
  • 3700 Ubuntu containers
  • 21 Windows virtual machines
  • 4375 routing table entries

Not too bad for servers that are (SC1425) or are getting close (DL380 G5) to being 10 years old now.

Past infrastructure challenges

In the past editions we’ve found numerous bugs in the various technologies we use when put under such a crazy load:

  • A variety of switch firmware bugs when dealing with several thousand IPv6-only networks.
  • Multiple Linux IPv6 kernel bugs (and one security issue) also related to an excess of IPv6 multicast traffic.
  • Several memory leaks and other bugs in LXC and related components that become very visible when you’re running upwards of 10000 containers.
  • Several more Linux kernel bugs related to performance scaling as we create more and more namespaces and nested namespaces.

As our infrastructure staff is very invested in these technologies by being upstream developers or contributors to the main projects we use, those bugs were all rapidly reported, discussed and fixed. We always look forward to the next NorthSec as an opportunity to test the latest technology at scale in a completely controlled environment.

How can you help?

As I mentioned, we’ve been capped at 32 teams and around 300 attendees for the past two years. Our existing hardware was barely sufficient  to handle  the load during those two editions, we urgently need to refresh our hardware to offer the best possible experience to our participants.

We’re planning on replacing most if not all of our hardware with slightly more recent equivalents, also upgrading from rotating drives to SSDs and improving our network. On the software side, we’ll be upgrading to a newer Linux kernel, possibly to Ubuntu 16.04, switch from btrfs to zfs and from LXC to LXD.

We are a Canadian non-profit organization with all our staff being volunteers so we very heavily rely on sponsors to be able to make the event a success.

If you or your company would like to help by sponsoring our infrastructure, get in touch with me. We have several sponsoring levels and can get you the visibility you’d like, ranging from a mention on our website and at the event to on-site presence with a recruitment booth and even, if our interests align, inclusion of your product in some of our challenges.

Also, as I briefly mentioned at the beginning, we have a two days, single-track conference ahead of the CTF. We’re actively looking for speakers, if you have something interesting to present, the CFP is here.

Extra resources

Read more
facundo

Cerrando etapas


El tiempo pasa, nos vamos volviendo tecnos.

No me voy a poner a hablar de la inevitabilidad del paso del tiempo, de que la flecha de la entropía sólo apunta para un solo lado, ni de esas cosas.  Quiero hacer foco en que hay que aprovechar el tiempo que tenemos.

Esta genial foto es de una de las últimas clases de natación donde llevé a Malena.

Male y Facu en el agua

Fuimos todo el año, una vez por semana. Empezó tímida, y terminó pasando más tiempo abajo del agua que arriba, totalmente acuática. Para mi fue un placer llevarla y disfrutar esa evolución con ella, lo mismo que hice con Felipe dos años atrás. Y ya está, ese tiempo pasó y nunca más los meteré en el agua con ellos agarrándose a mi. Más allá de la nostalgia anticipada, lo importante es que cuando tuve la oportunidad, la aproveché :)

Sé que van a haber mil otros momentos donde los lleve de la mano a territorios para ellos desconocidos. La clave es estar ahí, darles la mano, acompañarlos, y disfrutar ese proceso.

Otra foto del paso del tiempo: Felipe, en su acto de graduación del Jardín, donde él mismo estaba emocionado mientras otros compañeros pasaban a buscar sus diplomas (todavía no le había llegado su turno), y luego estudiaba la medallita que le habían dado...

Felu graduado

Read more
Daniel Holbach

It’s been a while since our last Snappy Clinic (here’s a link to all videos) and since Ubuntu Online Summit a lot of great things happened in Snapcraft:

Among the changes: a nil plugin, support of pip packages, support globs in the copy plugin, a nodejs plugin, add go-packages to the go plugin, countless bugfixes and tests, a more beautiful interface and more documentation.

The above and to get Sergio Schvezov on camera are reasons enough for us to have another Snappy Clinic

See you later! :-)

Read more
facundo


¡¡Salió la versión 4 de fades!!

Mucho mucho laburo le pusimos con Nico a esta versión (y tuvimos bastante ayuda de otros colaboradores, en particular durante el último PyCamp).

¿Pero qué es fades? Es un sistema que maneja automáticamente los virtualenvs de sistemas Python en los casos que uno normalmente encuentra al escribir scripts y programas pequeños, e incluso ayuda a administrar proyectos grandes.

Crea automáticamente un nuevo virtualenv (o reusa uno creado previamente) instalando las dependencias necesarias, y ejecutando el script dentro de ese virtualenv.

Todo lo que se necesita hacer es ejecutar el script con fades (en lugar de Python) y también marcar las dependencias necesarias. Más detalles en la documentación misma.

fades

¿Qué hay de nuevo en esta release?

  • Nueva opción para usar iPython en el interprete interactivo: --ipython (gracias Ariel Rossanigo)
  • Ahora es posible ejecutar un programa dentro del virtualenv con -x (gracias Ricardo Kirkner). Por ejemplo es posible crear un proyecto de django sin tener django instalado en tu sistema usando: fades -d django -x manage startproject foo
  • Podés ejecutar fades como un módulo de python. Simplemente hay que ejecutar python3 -m fades (gracias Javi Mansilla)
  • Soportamos Python 3.3 para ejecutar fades
  • Si sos un usuario especial y no te alanzan las opciones que tenemos tenemos cosas para vos!  Podes pasarle opciones a virtualenv con --virtualenv-options, también a pip con --pip-options, e incluso es posible eliminar un virtualenv con --rm <uuid>
  • Tenemos un logo!! (el que se ve arriba, claro)
  • Los tests de fades se ejecutan con fades! No hay necesidad de instalar nada previamente
  • Se pueden crear virtualevs con --system-site-packages
  • Varios bug fixeados y otros nuevos ;)

Para instrucciones de cómo obtenerlo o instalarlo, miren en la página del proyecto o la de PyPI.

Por otro lado, con Nico habíamos decidido que era importante para fades que puede ser instalado con apt-get install en Debian y Ubuntu.

Entonces, me puse con eso, pedí en el laburo si algún Debian Developer quería darme una mano para meter fades en Debian, y se copó uno de los mejores: Barry Barsaw. Me estuvo ayudando un montón, contestándome preguntas simples y complicadas.

Nosotros ya teníamos un .deb, pero no del todo bien armado. Al final, terminé dando vuelta completamente todo pero quedó todo más simple, más limpio, y con mejor forma. El .deb que generamos es un lujo, y además fades terminó entrando en Debian, en unstable al principio y luego en testing, :D. Es mi primer programa que entra en Debian, y para mí es todo un orgullo :).

El camino natural es que entre en Xenial Xerus (Ubuntu 16.04), que es LTS, así que seguramente liberaremos la v5 la primer quincena de febrero.

Rock.

Read more