la solucion esta en ser libres

espacio producto

Orisinal, juegos con arte

Por Facundo Ferré
Web Designer de OpenSistemas

Nunca es pronto para jurar que todo está dicho, sobre todo cuando en la Red el acceso a múltiples puntos de vista sobre un mismo concepto puede resultar un auténtico abanico de experiencias inauditas.

En el caso que nos ocupa, pretendo hablaros de los juegos hechos en flash. Pese a que todos conocemos cientos de páginas que cosechan estos entretenimientos por docenas, pocas veces nos podemos encontrar con un diseño tan mimado tanto en la forma como en el contenido. Me refiero a los juegos de Ferry Halim, disponibles en su página Orisinal.

Ferry Halim es un diseñador de juegos en flash y tiene una amplia galería de su vertiente comercial en su web, que además de darle de comer a la tripa alimenta también su mente inquieta. Con juegos no venden nada ni a nadie.

El autor concibe el juego como algo tan básico como sencillo, y así nos sumerge en acuarelas y otros brochazos multicolores para hacer deambular a su antojo, siempre con gracia y delicadeza, a personajes de aspecto inocente en un mundo no menos inocuo.

No hay disparos a partes innobles, ni hemoglobina brotando como manantiales, ni siquiera un miserable misil teledirigido. No, Halim no se conforma con lo ya hecho, sino que satisface su paladar con lo que nadie aún ha querido probar. De hecho, ha descartado ideas muy buenas para sus juegos porque ya había sido explotado en la Red… “Siempre trato de hacer algo diferente -explica- y ese el problema. A veces se me ocurre una buena idea, pero es muy difícil de llevar a cabo. Así que la deshecho”.

Todo esto da como resultado un mundo de juegos a explorar que, a modo de marca personal, combinan a la perfección el arte del acabado artístico con lo aditivamente simplón de su planteamiento.

Y si el apartado plástico de los juegos ya es para quedarse con un cubo bajo la barbilla que recoja las babas, la selección musical lo acompaña como cogido de la mano. En la mayor parte, son piezas de musicales del país del sol naciente, “el problema es que no sé leer japonés -confiesa Halim- así que muchas veces no tengo ni idea de cuál es el título de la canción”.

El resultado no podría ser menos sorprendente, lo que tiene el mérito de sobresalir en una red llena de juegos de todo tipo. Tal vez lo que realmente le haga único es precisamente haber sabido pulir la misma idea de un modo tan sencillo que cala hondo. Su concepto es de cuento, de niño, sumamente inocente. No deja de notarse la mano del autor en todos sus juegos y eso le confiere un encanto especial que es difícil de definir hasta que no juegas con ellos, es la firma del artesano. Es, en resumen, un autor de juegos.

The post Orisinal, juegos con arte appeared first on Blog de OpenSistemas.

¿Qué pasa cuando pulsamos el botón de encendido de nuestro ordenador?

Por Laura Maño
Desarrolladora Open Source en OpenSistemas

Una de las cosas que más me ha llamado la atención siempre es cómo con un simple gesto podemos convertir un montón de hierros y plástico en una máquina tan compleja como es un ordenador. ¿Qué pasa cuando pulsamos el botón de encendido de nuestro ordenador? ¿Cómo se define este proceso y qué partes tiene? Voy a intentar explicarlo de la manera más sencilla posible.

Empecemos por la definición…

El proceso de arranque de un ordenador es un conjunto de acciones que inician el sistema operativo cuando el usuario enciende la máquina, y termina una vez el ordenador está preparado para contestar a los requerimientos del exterior.

La parte más o menos física es algo que podemos entrever: el botón de encendido está conectado con la fuente, esta se enciende y convierte la corriente de alterna a continua y empezamos a pasarla a través de los circuitos de la placa. Después, llegamos a la BIOS y aquí ya entran en juego los programas aun a medio camino entre el software y el hardware. En este punto la BIOS pide un chequeo de los dispositivos conectados al ordenador y lee la CMOS-RAM que contiene la información de los dispositivos físicos. Aquí ya ha reconocido el disco duro principal, la hora y la fecha del sistema y está preparado para cargar el sistema operativo, leyendo el primer sector del disco, que en él se encuentra el MBR (master boot record), un programa que determina el proceso de arranque.

La principal diferencia entre los sistemas Linux y Windows en el proceso de arranque reside en este punto. Mientras que en Linux este sector está vacío, en Windows además del código ejecutable, tiene información sobre el sistema de archivos.

En el MBR de Windows hay una partición del disco duro marcada como activa, y busca en ella el SO, comprueba si este sector es válido y carga el código del mismo sector. Después aparece el promt o la interfaz de Windows. En el caso del Linux existe un programa, el gestor del arranque, que busca el núcleo
del SO, lo carga en memoria y le cede el control. Algunas veces, también se lo pasa la dirección del disco duro que contiene el sistema de ficheros.

Un gestor de arranque (bootloader) es un programa sencillo que está diseñado para preparar todo lo que necesita el sistema operativo para funcionar. En la década de los 50 se utilizaban tarjetas perforadas para arrancar el SO y que estaban preparadas para ejecutar en la máquina (bastaba con apretar un botón para que se cargara el programa en la memoria).

Actualmente, el sistema de arranque es más complejo pero la idea es la misma, como hemos visto antes y dependiendo de las características los gestores pueden clasificarse de varias maneras.

Ficheros Map

El principal problema que tenemos cuando cargamos el sistema de arranque es que el kernel se encuentra en alguna parte del disco duro, en algún sector, y esto no es comprensible para la BIOS.

Para solucionar este problema tenemos los ficheros MAP, en los cuales se anotan los bloques físicos que contienen archivos lógicos. La BIOS los lee en orden de este fichero y se anotan los archivos lógicos en la RAM.

E gestor de arranque LILO se basa principalmente en estos mapas, cuando queremos cambiar algo en el gestor debemos reinstalarlo. El gestor tiene que volver a escribir los bloques físicos donde están ubicados los sistemas operativos, que daremos como opción de arranque.

Actualmente el sistema de arranque es más complejo, pero la idea es la misma. El gestor de arranque GRUB los utiliza pero se libera de ellos porque es capaz de examinar el sistema de archivos; esto le facilita acceder a ellos mediante la ruta y no mediante números de bloque.

Este es solo un pequeño ejemplo de las diferencias que existen entre los distintos gestores de arranque más conocidos en Linux. Ambos pertenecen al tipo de gestor de arranque de segunda etapa, ya que consisten en varios programas pequeños que se llaman los unos a los otros hasta que el último carga el sistema operativo. Este tipo es el más común aunque existen otros como los gestores de arranque flash, de red, para sistemas empotrados, etc.

Proyecto GNU GRUB

GNU GRUB (GNU Grand Unified Bootloader) es un gestor múltiple desarrollado por el proyecto GNU y se usa sobre todo en sistemas operativos GNU/Linux. La versión más conocida de este gestor es GRUB Legacy, aunque es mejor que sus predecesoras, se ha optado por cambiar completamente el gestor, reescribirlo de nuevo y crear GRUB 2.

Este proyecto se inició con el nombre de PUPA. Su objetivo era desarrollar un GRUB más limpio, seguro, robusto y potente, así como más portable y con soporte para diferentes idiomas.

El proyecto PUPA fue apoyado por la organización IPA (Information-technology
Promotion Agency) en Japón. PUPA se integró en el desarrollo de GRUB 2 alrededor del 2002 cuando la versión 0.9x de GRUB fue renombrada como GRUB Legacy. Desde febrero del 2008, GRUB 2 sigue en desarrollo y ha sido renombrada formalmente como GRUB, aunque está siendo usado en las versiones más recientes de distribuciones de GNU/Linux.

Fue diseñado por Erich Stefan Boleyn para formar parte del sistema GNU Hurd, en 1999. Gordon Matzigkeit y Yoshinori Okuji consiguieron que este fuera parte del paquete oficial del proyecto GNU, además de permitir que se pueda desarrollar libremente. Algunos de los objetivos del proyecto incluyen numerosas funcionalidades como, por ejemplo, el soporte de plataformas no-x86, la internacionalización, localización, caracteres no ASCII, módulos dinámicos, gestión de memoria, un mini-lenguaje de escritura de scripts, la migración de plataforma específica (x86) de código a la plataforma de módulos específicos y un marco orientado a objetos…

Arranque con GRUB

Este gestor tiene dos etapas. La primera está guardada en el MBR o en el sector de arranque de una partición. La etapa 1 puede cargar ya sea la etapa 1.5 o directamente, la 2.

La etapa 1.5 de GRUB Legacy, ubicada en los siguientes 30 kilobytes del disco duro, carga la etapa 2. En GRUB, esta fase ha dejado de existir. La segunda etapa contiene el código del gestor que presenta al usuario un menú de inicio y puede acceder al sistema de archivos, esta etapa se carga el núcleo del SO.

Cuando GRUB arranca vuelve a acceder a los archivos del menú de inicio, incluyendo las rutas, las particiones actuales hacia el kernel y el Ramdisk de inicio encuentra los archivos rápidamente.

El menú de arranque que vemos cuando inicia el ordenador está almacenado el
/boot/grub/menú.lst. Este archivo contiene la información de las particiones o de los sistemas operativos que se pueden arrancar desde el menú.
Dicho fichero está compuesto por comandos sencillos tipo bash, cada línea contiene un comando seguido de un parámetro.

Para reconocer cada entrada de un sistema operativo diferente se le da el título que vemos en el menú, esto nos permitirá seleccionar la partición que queremos. Por ello, el gestor puede acceder a los sistemas de archivos en los dispositivos de disco soportados por la BIOS antes de arrancar el SO, de esta forma los cambios en la BIOS no obligan a reinstalarlo. Esto es una gran ventaja, ya que permite cambiar todos los parámetros de arranque antes de reiniciar el ordenador y, además, podemos introducir parámetros en la consola del gestor, comprobar el kernel y el initrd antes de arrancar.

Este gestor nos ofrece múltiples posibilidades de arranque. Podemos seleccionar un SO concreto para que arranque si expira un tiempo de espera, un tiempo que también podemos modificar. Además del menú tenemos varios archivos más que nos permiten cambiar las direcciones de los archivos lógicos, darle una contraseña para el arranque, etc.

La diferencia que observamos a primera vista es que si solo tenemos un sistema operativo, el menú desparece y entramos directamente en la pantalla principal. En el caso de tener más de un sistema instalado en el equipo, el aspecto del menú es muy parecido al anterior.

Otras diferencias que encontramos son, por ejemplo, que la etapa 1,5 ha sido
eliminada, el gestor arranca directamente desde la dirección guardada en el MBR. La lista de kernels disponibles se genera automáticamente mientras actualizamos el archivo de configuración del gestor, incluso busca la de otros sistemas operativos tipo Windows.

Con un enfoque hacia el interior del gestor debemos comentar que la numeración de las particiones cambia, la primera es 1 en lugar de 0, aunque se puede modificar si es necesario en el archivo device.map en la carpeta /boot/ grub.

El archivo menú.lst ha sido reemplazado por grub.cfg, que es el producto de varios scripts y normalmente no debería ser editado directamente. Este archivo se actualiza cuando se modifica el núcleo o si el usuario ejecuta update-grub.
Este comando lanza la ejecución de los scripts del directorio etc/grub.d que genera automáticamente el fichero anterior con los ajustes del menú contenidos en /etc/default/grub.

Como hemos podido comprobar, la tarea de encender un ordenador es compleja y sumamente importante, así que resulta bastante interesante conocer un poco nuestros sistemas operativos y los diferentes tipos de arranque que nos pueden proporcionar e, incluso, podemos ser parte de su creación o mantenimiento.

The post ¿Qué pasa cuando pulsamos el botón de encendido de nuestro ordenador? appeared first on Blog de OpenSistemas.

OpenSistemas acelera su internacionalización en Oriente Medio como compañía experta en Cloud Linux y Educación

OpenSistemas, compañía española líder en proyectos y soluciones innovadoras en las áreas de análisis de datos, educación y gestión de contenidos sobre plataformas Open Source y sistemas Linux, ha reforzado su estrategia de expansión en el exterior gracias al partnership que mantiene con Microsoft como socio open source de Azure.

En este contexto de colaboración y desarrollo de negocio conjunto entre ambas compañías, Microsoft EMEA ha demandado los servicios de OpenSistemas como expertos en Cloud Linux y Educación para ofrecer a la comunidad académica una formación especializada en Moodle sobre Azure Linux. Read the rest of this entry »

Mi experiencia en CoderDojo

Por Luis Flores
CEO de OpenSistemas

Aunque hace apenas poco más de dos meses que comencé mi colaboración como mentor en el grupo de Scratch de CoderDojo Madrid, parece que hubiera pasado ya más tiempo por lo interesante de la iniciativa, lo motivadora y lo inspiradora que sin ninguna duda ha resultado ser.

Me gustaría en todo caso comenzar diciendo que CoderDojo es una iniciativa internacional surgida en 2011 en Irlanda con el objetivo de enseñar a niños y jóvenes a programar. En los últimos años se ha extendido para convertirse en una red de centros en diversos países alrededor de todo el Planeta.

Actualmente existen varios CoderDojo en España y el grupo de Madrid se reúne en el espacio MediaLab Prado, del Ayuntamiento de la capital. Recientemente y a  través de Ashoka ―la mayor red internacional de Emprendedores Sociales Innovadores―, CoderDojo contó con una presentación en el entorno del Senado y que ofrece una idea del enorme potencial de esta iniciativa.

Lo primero que subrayaría de Dojo es que se trata de un proyecto de carácter privado al que se unen alumnos y mentores de forma libre, compartiendo un mismo espacio e intereses y bajo un enfoque lúdico, creativo y algo desestructurado. Personalmente, y en un país donde nos hemos acostumbrado demasiado a que ‘papá’ Estado nos resuelva las cosas, movimientos de este tipo resultan de gran valor y constituyen, bajo mi punto de vista, el germen de una sociedad futura más libre, más centrada en los intereses del ciudadano y en la actividad privada como motor de cambio.

Por otro lado, Dojo enlaza de manera ideal con nuestros valores como empresa en lo referente al fomento de la tecnología entre los más jóvenes, ya que resulta un laboratorio perfecto dentro del cual colaborar de manera individual y altruista en este orden de cosas y un ejemplo a imitar en este sentido.

El tercer aspecto realmente valioso de sitios como Dojo es la enorme cantidad de talento y buena gente que te puedes encontrar por la vida a poco que apagues el televisor. Montones de personas dedican voluntariamente su tiempo libre a ayudar a otros, a aprender, a enseñar o a compartir ideas y experiencias valiosas. En OpenSistemas nos gusta ese talento, que por otro lado enlaza históricamente con el asociacionismo y el movimiento del Software Libre y Linux, que es la razón de ser originaria de nuestro proyecto.

Y, por último y lo más importante, la pieza angular de todo esto son los niños. El primer reto cuando trabajas con niños es evidente: un chico de 8 años solo irá a un evento un sábado a las 5 de la tarde si se divierte y se lo pasa bien, así que partiendo de ese punto se acaban las imposiciones u obligaciones de carácter formativo: no es formación, es juego. La iniciativa tiene que funcionar desde el punto de vista de quienes la consumen y quienes la consumen, al menos en esas edades, buscan jugar y divertirse.

En el grupo de Scratch, y en particular en la lista de correo asociada al grupo, son habituales los comentarios acerca de cómo atraer la atención y motivar a los chavales: trabajando sobre todo juegos donde ellos pueden probar jugando lo que han programado, planificando actividades para varias sesiones que les permiten establecer metas más ambiciosas, modificando juegos que otros han hecho, pensando detalles que facilitan su creatividad (un niño puede dedicar horas a elegir el fondo de pantalla que más le gusta para su juego del espacio) o compartiendo con los compañeros los avances realizados.

Es particularmente interesante la idea de comenzar las sesiones con una dinámica de grupo donde se plantea ejemplificar a través de una actividad lo que posteriormente puede desarrollarse en la sesión de Scratch, ya que establece un nexo de unión entre lo que ocurre dentro de un ordenador y fuera de él, sugiriendo la aplicación de la tecnología como solución a un problema físico real, tecnología como herramienta y no como fin en sí mismo.

En el otro lado de la balanza está la necesidad de establecer una metodología sobre cómo hacer que el juego implique también nuevo aprendizaje, con posiciones más cercanas a un modelo más estructurado y lineal de aprendizaje, o más libre y anárquico, ambos con sus ventajas e inconvenientes, y donde todos aprendemos seguramente a valorar el extremo que menos apoyábamos inicialmente.

Y el último pero no menos valioso elemento de esta cadena de valor que acabo de presentar someramente, son los padres, algunos de los cuales llegan a ser verdaderos expertos en la materia a fuerza de ayudar y colaborar en todo.

¡Toda una experiencia que no ha hecho más que comenzar y de la que seguiremos disfrutando!

The post Mi experiencia en CoderDojo appeared first on Blog de OpenSistemas.

Because 3D printers are so mainstream these days…

By Fernando Apesteguía
Project manager at OpenSistemas

…we are going to build a very humble 3D scanner :)

But before you read any further, here are some things you should know:

  • This is just a proof of concept. Don’t expect anything near production quality.
  • All the software used for this pet project is Open Source.
  • Some of the materials are inexpensive (a.k.a a little crappy)
  • Now that you are warned about what this post is about, let’s begin.

First off, this is a list of the things I used to build the scanner:

  • Wires
  • Some tape
  • Double-sided tape

The general idea behind the scanner is this: we will build a small square platform to place the object we want to scan. This platform will turn by one of the stepper motors. On one side, we will build a small wall with a couple of rails. We will place the distance sensor in between these rails and we will use some tether to lift the sensor when necessary. Of course, this is just a simple design. You can always choose the opposite philosophy: sit the object still and make the sensor spin around it.

This is a picture of the scanner with some of the interesting points highlighted:

scanner1

In my code, I perform 64 steps for every 360º turn, meaning I take measures every 5.625º. This seems pretty good, but you can change it easily in the code. Once we have measured the whole contour, we lift the sensor a little and start over. I take 15 measures every time, discard the highest and lowest (outliers) and compute the average.

How does this relate to a 3D object representation? What we are measuring is actually a point in a 3D space (with x, y and z axis) using polar coordinates. We know the z component (the height of the sensor), and the angle (we turn 5.625º each time) and r is the result (the average) of the output of the sensor.

scanner2

How do we convert from r and the angle to x and y? This is simple:

codigo1codigo2

We are not using the angle as is because the C library trigonometry functions expect radians (thanks Revi for pointing this out).

Most of the precision of this method is based on how we measure r with the sensor. Ah… the sensor… The Sharp GP2D120X is an infrared distance measurement sensor. It is pretty cheap and has a good precision, but probably not enough to scan objects with a lot of detail. Anyway, if you want to use another sensor (like a laser based one) you can reuse most of the code. Unfortunately for this sensor, the output is not linear. As you can see in the datasheet, the output follows a nice curve that we have to approximate as best as we can. In my case, the closest I could get was this: codigo3 that is based on this post.

 

Connections
This is a schematics of the whole set up:

scanner3

About the code

Things you need to make this code work:

  • A free Unix-like OS. I use FreeBSD (but Linux will do fine)
  • The avr-gcc suite to compile the code for the Arduino
  • A C compiler. I use clang.
  • glib
  • gnuplot

There are two separate software components in this project:

  • One for the Arduino: it takes care of measuring and turning the platform and lifting the sensor too. It also sends the data to the computer via the USB cable.
  • The compositor: it converts the readings from the Arduino to cartesian coordinates, uses the curve to interpolate and sends them to gnuplot to show them in the monitor.

The Arduino’s code is pure C with some avr-libc stuff. Why is it C and not Processing? Well… Processing is good for prototyping, but honestly, with C you know what you are actually doing when you set a pin as input, for example. The problem with this approach (it isn’t a problem actually) is that you must read the datasheet for the Atmel microcontroller.

A third-party program is necessary to plot the coordinates in the screen. I evaluated several options, like Wings3d, blender, cloudcompare, Google sketchup, jsc3d… Then I realized that there is a very well-known software that could do the job just fine: gnuplot. It is a really good program and you can pipe commands to it so it is really easy to interact with it (see gnuplot_bridge.[ch] for the details). A 3D model program would provide shadows that make the object more easy to recognize, but most of them don’t accept commands from the standard input.

The code for the Arduino has the following files:

  • common.h has a definition needed by the avr includes
  • infrared.[ch] does the same to interact with the infrared sensor
  • scanner3d.c is the main program
  • serial.h does some avr-libc magic to use printf with the serial port
  • stepper.[ch] contains the code to interact with the stepper motors
  • 3d_limits.h contains all the constants used during the run (max height, number of IR reads…)

The second part of the software (the compositor) is a small piece of software written in C + GLib. I really like the way GLib handles IO with the IOChannels. It makes everything really easy. These are the relevant files:

  • data_writer.[ch] well… yes, it writes to disk :)
  • channels.[ch] implements the callbacks for the IOChannels
  • compositor3d.c is the main file
  • gnuplot_bridge.[ch] implements the communication with gnuplot

 

Compiling and running the code

You can download the code from here. These steps will help you compiling and running the code:

Unpack the software:

$ tar xvzf scanner3d-0.1.tar.gz

Enter the directory

$ cd scanner3d-0.1

and type

$ make

to compile the software and

$ avrdude -V -F -c stk500v1 -p m168 -b 19200 -P /dev/cuaU0 -U flash:w:scanner3d.hex

to load it to the Arduino. Note that the MCU part (flag -p) and the programmer id (flag -c) might change if you use another Arduino board. The device file might change too. Once the program is loaded, it waits about 5 seconds before it starts the scan. This operation accesses the usb port so you will need the proper permissions for that.

Unpack the compositor:

$ tar xvzf compositor3d-0.1.tar.gz

Enter the directory

$ cd compositor3d-0.1

and bootstrap the software

$ ./bootstrap.sh

The line above will generate the necessary files and will compile the software. If you want to use a specific compiler (as clang for instance), re-run configure like this:

$ CC=clang ./configure

and then type

$ make

To run the compositor, type the following

$ ./compositor3d /dev/cuaU0

And substitute the device file by whatever applies to your system. You will need the proper permissions for this too.

 

The test

These are a couple of videos that show a teapot (the lorem ipsum of 3d objects as a friend of mine told me) and a foam tux toy.

teapot

penguin

 

Conclusions

It was pretty fun to work in this pet project. If you want to try it yourself, please feel free to use and change the code as long as you respect the license (Simplified BSD License).

Last, here you have some notes that can be of interest:

  • Use the best sensor you can get. The Sharp one is not bad for a small project like this one.
  • I am not specially gifted in handcrafting: the rotating base moves a little, the sensor inclines to one side due to the tension of the wires, etc. All these factors affect the quality of the scanning.
  • The motors I used are pretty good and cheap.
  • If you want to make your reads usable by other programs, use a standard format.
  • The capacitor between Vcc and GND improves the reads from the sensor. It should be a must in your schematics.

Enjoy!

The post Because 3D printers are so mainstream these days… appeared first on Blog de OpenSistemas.