LibreSoft Planet

Syndicate content
Updated: 5 years 44 weeks ago

Bicho 0.9 is comming soon!

Thu, 2011-06-09 10:06

During last months we’ve been working to improve Bicho, one of our data mining tools. Bicho gets information from remote bug/issue tracking systems and store them in a relational database.

Bicho

 

The next release of Bicho 0.9 will also include incremental support, which is something we’ve missed for flossmetrics and for standalone studies with a huge amount of bugs. We also expect that more backends will be created easily with the improved backend model created by Santi Dueñas. So far we support JIRA, Bugzilla and Sourceforge. For the first two ones we parse HTML + XML, for sourceforge all we have is HTML so we are more dependent from the layout (to minimize that problem we use BeautifulSoup). We plan to include at least backends for FusionForge and Mantis (which is partially written) during this year.

Bicho is being used currently in the ALERT project (still in the first months) where all the information offered by the bug/issue reports will be related to the information available in the source code repositories (using CVSAnaly) through semantic analysis. That relationship will allow us to help developers through recommendations and other more pro-active use cases. One of my favorites is to recommend a developer to fix a bug through the analysis of the stacktraces posted in a bug. In libre software projects all the information is available in the internet, the main problem (not a trival one) is that it is available in very different resources. Using bicho against the bts/its we can get the part of the code (function name, class and file) that probably contains the error and the version of the application. That information can be related to the one got from the source code repository with cvsanaly, in this case we would need to find out who is the developer that edit that part of the code more often. This and other uses cases are being defined in the ALERT project.

If you want to stay tunned to Bicho have a look at the project page at http://projects.libresoft.es/projects/bicho/wiki or the mailing list libresoft-tools-devel _at__ lists.morfeo-project.org

 

Categories: FLOSS Research

ARviewer, PhoneGap and Android

Thu, 2011-06-09 05:44
ARviewer is a FLOSS mobile augmented reality browser and editor that you can easily integrate in your own Android applications. This version has been developed using PhoneGap Framework. The browser part of ARviewer draws the label associated with an object of the reality using as parameters both its A-GPS position and its altitude. The system works both outdoors and indoors in this latest case with location provided by QR-codes. ARviewer labels can be shown through a traditional list based view or through an AR view a magic lens mobile augmented reality UI.    The next steps are: 
  • Testing this source code in IOS platform to check the real portability that phoneGap provide us.
  • We plan to add the “tagging mode” with phoneGap to allow tag new nodes/objetcs from the mobile. 
  Are very very similar the next images, right? We only have found a critical problem with the refresh of nodes in the WebView using PhoneGap. We will study and analyze this behavior.  

ARviewer PhoneGap

 

ARviewer Android (native)

  More info: http://www.libregeosocial.org/node/24  Source Code: http://git.libresoft.es/ARviewer-phoneGap/  Android Market: http://market.android.com/details?id=com.libresoft.arviewer.phonegap
Categories: FLOSS Research

Finding code clones between two libre software projects

Thu, 2011-05-12 09:05

Last month I’ve been working in the creation of a report with the aim of finding out code clones between two libre software projects. The method we used was basically the one that was detailed in the paper Code siblings: Technical and Legal Implications by German, D., Di Penta M., Gueheneuc Y. and Antoniol, G.

It is an interesting case and I’m pretty sure this kind of reports will be more and more interesting for entities that publish code using a libre software license. Imagine you are part of a big libre software project and your copyright and even money is there, it would be very useful to you knowing whether a project is using your code and respecting your copyright and the rights you gave to the users with the license. With the aim of identifying these scenarios we did in our study the following:

  • extraction of clones with CCFinderX
  • detection of license with Ninka
  • detection of the copyright with shell scripts

The CCFinderX tool used in the first phase gives you information about common parts of the code, it detects a common set of tokens (by default it is 50) between two files, this parameter should be changed depending on what it is being looked for. In the following example the second and third column contain information about the file and the common code. The syntax is (id of the file).(source file tokens) so the example shows that the file with id 1974 contains common code with files with id 11, 13 and 14.

...
clone_pairs {
19108 11.85-139 1974.70-124
19108 13.156-210 1974.70-124
19108 14.260-314 1974.70-124
12065 17.1239-1306 2033.118-185
12065 17.1239-1306 2033.185-252
12065 17.1239-1306 2033.252-319
12065 17.1239-1306 2141.319-386
...

In the report we did we only wanted to estimate the percent of code used from the “original” project in the derivative work, but there are some variables that are necessary to take into account. First, code clones can appear among the files of the same project (btw this is clear sign of needing refactorization). Second, different parts of a file can have clones in different files (a 1:n relationship) in both projects. The ideal solution would be to study file by file the relationship with others and to remove the repeated ones.

Once the relationship among files is created is the turn of the license and copyright detection. In this phase the method just compares the output of the two detectors and finally you get a matrix where it is possible to detect whether the copyright holders were respected and the license was correctly used.

Daniel German’s team found interesting things in their study of the FreeBSD and Linux kernels. They found GPL code in FreeBSD in the xfs file system. The trick to distribute this code under a BSD license is to distribute it disabled (is not compiled into FreeBSD) and let the user the election of compiling it or not. If a developer compiles the kernel with xfs support, the resulting kernel must be distributed under the terms of the GPLx licence.

Categories: FLOSS Research

OpenBSD 4.9 incorpora el sistema /etc/rc.d

Wed, 2011-05-04 17:23
Algo de historia  

Como cualquier administrador de sistemas Unix sabe, init es el primer proceso en ejecución tras la carga del kernel, y da inicio a los demonios ("servicios") estándar del sistema. En el Unix original de Bell Labs, el proceso init arrancaba los servicios de userland mediante un único script de shell denominado /etc/rc. La Distribución de Berkeley añadió años después otro script denominado /etc/rc.local para arrancar otros servicios. 

Esto funcionó así durante años, hasta que Unix se fue fragmentando y, con la aparición del software empaquetado de terceros, la versión System V del Unix de AT&T introdujo un nuevo esquema de directorios en /etc/rc.d/ que contenía scripts de arranque/parada de servicios, ordenados por orden de arranque, con una letra-clave delante del nombre de fichero (S- arrancar servicios y K- detener el servicio). Por ejemplo: S19mysql inicia [S] el servicio mysql. Estos scripts (situados en /etc/init.d) se distribuyeron en niveles de ejecución (runlevels, descritos en /etc/inittab), asociando los scripts con enlaces simbólicos en cada nivel de ejecución (/etc/rc0.d, rc1.d, rc2.d, etc.). Los niveles de ejecución en cada directorio representan la parada, el reinicio, arranque en monousuario o multiusuario, etc. Este esquema, conocido como "System V" (o "SysV"), es, por ejemplo, el que adoptaron las distribuciones de Linux (con algunas diferencias entre ellas en cuanto a la ubicación de subdirectorios y scripts). Tenía la ventaja de evitar el peligro de que cualquier error de sintaxis introducido por un paquete pudiera abortar la ejecución del único script y por tanto dejar el sistema en un estado inconsistente. A cambio, introdujo cierto grado de complejidad en la gestión y mantenimiento de scripts de inicio, directorios, enlaces simbólicos, etc. 

Otros sistemas de tipo Unix, como los BSD, mantuvieron el esquema tradicional y simple de Unix, con solo uno o dos únicos ficheros rc y sin niveles de ejecución[*], si bien fueron incorporando algunos otros aspectos del esquema SysV de inicialización de los servicios del sistema. Por ejemplo, NetBSD incluyó un sistema de inicio System V similar al de Linux, con scripts individuales para controlar servicios, pero sin runlevels. FreeBSD, a su vez, integró en 2002 el sistema rc.d de NetBSD y actualmente cuenta con decenas de demonios de inicio que funcionan de forma análoga a SysV: 

$ /etc/rc.d/sshd restart

 

OpenBSD incorpora /etc/rc.d

 

OpenBSD, sin embargo, no había adoptado hasta ahora el subsistema de scripts individuales para controlar los servicios, lo que a veces causaba cierto pánico, como si les faltase algo esencial, a quienes desde el mundo Linux (u otros Unices)

entraban por primera vez en contacto con este sistema (aunque luego la cosa tampoco era tan grave, es cuestión de hábitos). La actual versión OpenBSD 4.8, publicada en noviembre de 2010, todavía utiliza únicamente dos scripts de inicio (/etc/rc y /etc/rc.local). En OpenBSD 4.9, que se publicará el próximo 1 de mayo, se ha implementado por primera vez esta funcionalidad mediante el directorio /etc/rc.d

Como suele ser habitual en OpenBSD, no se implementa algo hasta que se está seguro que se gana algo y que hay un modo sencillo y fiable de utilizarlo para el usuario final. El mecanismo es análogo al de otros sistemas de tipo Unix, pero más sencillo y con algunas sutiles e importantes diferencias que vale la pena conocer. Veámoslo. 


Descripción del nuevo subsistema /etc/rc.d de OpenBSD  

En /etc/rc.conf (donde se incluye las variables de configuración para el script rc)  nos encontraremos una nueva variable denominada rc_scripts: 

# rc.d(8) daemons scripts # started in the specified order and stopped in reverse order rc_scripts=

Incluimos en esa variable (o mejor, como se recomienda siempre, en /etc/rc.conf.local, un fichero opcional que sobreescribe las variables de /etc/rc.conf) los demonios que deseamos arrancar de inicio, por orden de arranque:

rc_scripts="dbus_daemon mysql apache2 freshclam clamd cupsd"

Los scripts de inicio de servicios residirán, como suele ser habitual, en el directorio /etc/rc.d. Pero una diferencia clave es que, aunque los scripts estén ahí situados, no arrancará nada automáticamente que no esté listado en la variable rc_scripts, siguiendo el principio de OpenBSD de evitar presumir automatismos predeterminados. Cada script responderá a las siguientes acciones:

  • start    Arranca el servicio si no está ya corriendo.
  • stop     Detiene el servicio.
  • reload   Ordena al demonio que recargue su configuración.
  • restart  Ejecuta una parada del demonio (stop), y a continuación lo inicia (start).
  • check    Devuelve 0 si el demonio está corriendo o 1 en caso contrario. 

Actualmente, este sistema solo se usa para demonios instalados desde paquetes, no para el sistema base de OpenBSD. Por ejemplo, para gestionar los estados del servicio "foobar", que habremos antes instalado desde ports o paquetes, basta ejecutar:

/etc/rc.d/foobar reload /etc/rc.d/foobar restart /etc/rc.d/foobar check /etc/rc.d/foobar stop

La última orden ("stop") se invoca también en un reinicio (reboot) o parada (shutdown) desde /etc/rc.shutdown, en orden inverso al que aparece en la variable en rc_scripts, antes de que se ejecute la orden "stop/reboot" para todo el sistema. No es necesario preocuparse por el orden de ejecución o por el significado de S17 al comienzo del nombre de los scripts.

Otra ventaja de esta implementación es lo extraordinariamente sencillos que es escribir esos scripts, frente a otras implementaciones que precisan scripts de decenas o incluso cientos de líneas. En su forma más simple:

daemon="/usr/local/sbin/foobard" . /etc/rc.d/rc.subr rc_cmd $1

Un ejemplo algo más complejo:

#!/bin/sh # # $OpenBSD: specialtopics.html,v 1.15 2011/03/21 21:37:38 ajacoutot Exp $ daemon="${TRUEPREFIX}/sbin/munin-node" . /etc/rc.d/rc.subr pexp="perl: ${daemon}" rc_pre() { install -d -o _munin /var/run/munin } rc_cmd $1

Como puede observarse, el script típico solo necesita definir el demonio, incluir /etc/rc.d/rc.subr y opcionalmente definir una expresión regular diferente a la predeterminada para pasársela a pkill(1) y pueda encontrar el proceso deseado (la expresión por defecto es "${daemon} ${daemon_flags}").

El nuevo script debe colocarse en ${PKGDIR} con extensión .rc, por ejemplo foobard.rc. TRUEPREFIX se sustituirá automáticamente en el momento de instalarlo.

La sencillez y limpieza es posible gracias al subsistema rc.subr(8), un script que contiene las rutinas internas y la lógica más compleja para controlar los demonios. Así y todo, es muy legible y contiene menos de 100 líneas. Existe también una plantilla para los desarrolladores de paquetes y ports que se distribuye en "/usr/ports/infrastructure/templates/rc.template".

Y eso es todo. Cualquier "port" o paquete que necesite instalar un demonio puede beneficiarse ahora de los scripts rc.d(8). Quizá el nuevo sistema no cubra todos los supuestos, pero cubre las necesidades de los desarrolladores de ports para mantener un sistema estándar y sencillo para arrancar servicios). En marzo de 2011, ya hay más de 90 ports de los más usados que los han implementado. Por supuesto, el viejo sistema sigue funcionando en paquetes no convertidos, pero es indudable que los desarrolladores de OpenBSD (especial mención para Antoine Jacuotot (jacuotot@) y Robert Nagy (robert@)) han logrado una vez más un buen balance entre simplicidad y funcionalidad. Por supuesto, para ampliar detalles, nunca debe eludirse leer las páginas correspondientes del manual: rc.subr(8), rc.d(8), rc.conf(8) y rc.conf.local(8) y la documentación web


Referencias


(*) Que BSD no implemente "/etc/inittab" o "telinit" no significa que no tenga niveles de ejecución (runlevels), simplemente es capaz de cambiar sus estados de inicio mediante otros procedimientos, sin necesidad de "/etc/inittab".

 
Categories: FLOSS Research

Brief study of the Android community

Mon, 2011-04-18 12:19

Libre software is changing the way applications are built by companies, while the traditional software development model does not pay attention to external contributions, libre software products developed by companies benefit from them. These external contributions are promoted creating communities around the project and will help the company to create a superior product with a lower cost than possible for traditional competitors. The company in exchange offers the product free to use under a libre software license.

Android is one of these products, it was created by Google a couple of years ago and it follows a single vendor strategy. As Dirk Riehle introduced some time ago it is a kind of a economic paradox that a company can earn money making its product available for free as open source. But companies are not NGOs, they don't give away money without expecting something in return, so where is the trick?

As a libre software project Android did not start from scratch, it uses software that would be unavailable for non-libre projects. Besides that, it has a community of external stakeholders that improve and test the latest version published, help to create new features and fix errors. It is true that Android is not a project driven by a community but driven by a single vendor, and Google does it in a very restricted way. For instance external developers have to sign a Grant of Copyright License and they do not even have a roadmap, Google publish the code after every release so there are big intervals of time where external developers do not have access to the latest code. Even with these barriers there are a significant part of the code that is being provided from external people, it is done directly for the project or reused from common dependencies (GIT provides ways to reuse changes done to remote repositories).


The figures above reflect the monthly number of commits done by people split up in two, in green colour commits from mail domains google.com or android.com, the study assumes that these persons are Google employees. On the other hand in grey colour the rest of commits done by other mail domains, these ones belong to different companies or volunteers.

According to the first figure (on the left), which shows the proportion of commits, during the first months that were very active (March and April 2009) the number of commits from external contributors was similar to the commits done by Google staff. The number of external commits is also big in October 2009, when the total amount of commits reached its maximum. Since April 2009 the monthly activity of the external contributors seems to be between 10% and 15%.

The figure on the left provides a interesting view of the total activity per month, two very interesting facts here: the highest peak of development was reached during late 2009 (more than 8K commits per month during two months). The second is the activity during the last months, as it was mentioned before the Google staff work in private repositories so until they publish the next version of Android, we won't see another peak of development (take into account that commits in GIT will modify the history when the code is published, thus the last months in the timeline will be overwritten during the next release)


More than 10% of the commits used by Google in Android were committed using mail domains different to google.com or android.com. At this point the question is: who did it?

(Since October 2008) # Commits Domain 69297 google.com 22786 android.com 8815 (NULL) 1000 gmail.com 762 nokia.com 576 motorola.com 485 myriadgroup.com 470 sekiwake.mtv.corp.google.com 422 holtmann.org 335 src.gnome.org 298 openbossa.org 243 sonyericsson.com 152 intel.com



Having a look at the name of the domains, it is very surprising that Nokia is one of the most active contributors. This is a real paradox, the company that states that Android is its main competition helps it!. One of the effects of using libre software licenses for your work is that even your competition can use your code, currently there are Nokia commits in the following repositories:

  • git://android.git.kernel.org/platform/external/dbus
  • git://android.git.kernel.org/platform/external/bluetooth/bluez


This study is a ongoing process that should become a scientific paper, if you have feedback please let us know.



CVSAnalY was used to get data from 171 GIT repositories (the Linux kernel was not included). Our tool allow us to store the metadata of all the repositories in one SQL database, which helped a lot. The study assumes that people working for Google use a domain @google.com or @android.com.

 

References:

Categories: FLOSS Research

AR interface in Android using phoneGap

Tue, 2011-03-29 06:51

Since 6 months ago we have evaluated the possibility to implement a new AR interface (based in our project ARviewer) using phoneGap. phoneGap is a mobile framework based in HTML5/JS that allow execute the same source code HTML5 in differents mobile platforms (iphone, android, blackberry). It seem a good way to create portable source code. Since 3 years ago I work in this project with Raúl Román, a crack coder!!

Currently using phoneGap is not possible obtain the stream camera in the webView widget. So, this part of the source code must be developed in the native platform. We find another problem. We could not put the webview transparent so it would look the camera in the background, and paint objects on top with HTML. In this case, we asked for this to David A. Lareo (Bcultura) and Julio Rabadán (Somms.net) and gave us some very interesting clues about this problem.

The solution is implemented in the source code that you can see below. It's necessary that our main view (R.layout.main) is the main view, for this we do 'setContentView' and later we add the main view of 'DroidGap' using 'addview' and 'getParent'. Once we have our view mixed with phonegap main view, we set the backgroundColor transparent.

@Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); super.init(); super.loadUrl("file:///android_asset/www/index.html"); setContentView(R.layout.main); RelativeLayout view = (RelativeLayout) findViewById(R.id.main_container); // appView is the WebView object View html = (View)appView.getParent(); html.setBackgroundColor(Color.TRANSPARENT); view.addView (html, new LayoutParams(LayoutParams.FILL_PARENT, LayoutParams.FILL_PARENT)); appView.setBackgroundColor(Color.TRANSPARENT); }  

  Currently, we have started this project so I will post the full source code in this blog
Categories: FLOSS Research