Universitat Politecnica` de Catalunya

Facultat d’Informatica` de Barcelona

Benchmark para PCs con pocos recursos

Director: Autor: Carlos Alvarez´ Mart´ınez Alexandre Ram´ırezG´omez Co-director: Xavier Martorell Bofill

13 de junio de 2013 ´Indice general

1. Introducci´on 4 1.1. Planteamiento ...... 4 1.1.1. Objetivo ...... 4 1.1.2. Motivaci´on ...... 4 1.2. Estado del arte ...... 5 1.2.1. Contexto ...... 5 1.2.2. Diagramas de flujo ...... 5 1.2.3. Benchmarks globales ...... 6 1.2.4. Benchmarks espec´ıficos ...... 6 1.2.5. Colecciones de tests ...... 6 1.2.6. Conclusiones ...... 7

2. An´alisisde requisitos y planificaci´on 8 2.1. Marco legal ...... 8 2.2. Modalidades del benchmark ...... 8 2.2.1. Modalidad cl´asica...... 8 2.2.2. Modalidad basada en estimaci´on ...... 9 2.2.3. Modalidad basada en la estimaci´onde una distribuci´on live ..9 2.2.4. Comparativa ...... 9 2.3. Metodolog´ıa ...... 9 2.4. Planificaci´ontemporal ...... 10 2.5. Presupuesto ...... 14 2.5.1. Coste de software y hardware ...... 14 2.5.2. Coste espacial ...... 15 2.5.3. Coste de recursos humanos ...... 15 2.5.4. Coste total ...... 17

1 3. Especificaci´ony dise˜no 18 3.1. Encuesta ...... 18 3.2. Versi´onpreliminar del benchmark ...... 19 3.2.1. Mediciones ...... 19 3.2.2. Puntos a mejorar ...... 22 3.3. Versi´onfinal del benchmark ...... 23 3.4. Modalidad basada en estimaci´on...... 24 3.5. Modalidad basada en la estimaci´onde una distribuci´on live ...... 25 3.5.1. ¿Medir o estimar? ...... 26 3.5.2. La distribuci´on live ...... 27 3.5.3. Estimando en base al hardware ...... 28 3.6. Experimentaci´oncon un Pocket PC ...... 30

4. Implementaci´on,pruebas y resultados 31 4.1. Encuesta ...... 31 4.2. An´alisisde las distribuciones ...... 32 4.2.1. Selecci´onde distribuciones candidatas ...... 32 4.2.2. An´alisisde funcionalidades ...... 35 4.3. An´alisisde los PCs ...... 36 4.3.1. PCs de TxT ...... 36 4.3.2. Pruebas de rendimiento preliminares ...... 38 4.4. Criba de distribuciones ...... 40 4.5. Pruebas de rendimiento en PCs de TxT ...... 40 4.5.1. Resultados y reporte de incidencias ...... 40 4.5.2. Conclusiones ...... 41 4.5.3. Interpretaci´onde los resultados ...... 42 4.6. Realizando estimaciones ...... 43 4.7. Comparativa de modalidades del benchmark ...... 44 4.8. Experimentaci´oncon un Pocket PC ...... 47

5. Conclusiones 49 5.1. Conclusiones ...... 49 5.2. Trabajo futuro ...... 50 5.2.1. Comportamientos an´omalos ...... 50 5.2.2. A˜nadiratributos a medir al benchmark ...... 50 5.2.3. Actualizar y expandir la lista de distribuciones ...... 51 5.2.4. Mejorar la estad´ıstica...... 51 5.2.5. Probar distintos Pocket PC ...... 51

2 A. Resultados de la encuesta 53

B. Programas por distribuci´on 56

C. Funcionalidades por programa 59

D. Funcionalidades por distribuci´on 63

E. C´odigofuente del benchmark (versi´on1) 67 E.1. run.sh ...... 67 E.2. benchmark.sh ...... 72 E.3. statistics.sh ...... 77

F. Pruebas de rendimiento en PCs de TxT 81 F.1. PC A ...... 81 F.2. PC B ...... 82 F.3. PC C (Core 2 Duo) ...... 83

G. C´odigofuente del benchmark (versi´on2) 84 G.1. memory disk discard ...... 85 G.2. estimation ...... 86

H. Estimaciones en base a la distribuci´on live 88

I. Ecuaciones para estimar el rendimiento 94 I.1. Ubuntu ...... 94 I.2. Slackware ...... 95 I.3. Linux Mint ...... 95

J. C´odigofuente del benchmark (versi´on3) 97 J.1. run.sh ...... 97 J.2. benchmark.sh ...... 99 J.3. estimation ...... 103

K. Funcionalidades de Raspbian 105

Bibliograf´ıa 109

3 Cap´ıtulo1

Introducci´on

1.1. Planteamiento

1.1.1. Objetivo El objetivo de este proyecto es dise˜nare implementar un sistema capaz de de- terminar la distribuci´onde Linux adecuada para un PC (m´asconcretamente, un PC con pocos recursos). Se tendr´anen cuenta tanto aspectos de funcionalidad como de rendimiento. Para esto ´ultimoser´anecesario crear un benchmark que mida el rendi- miento de distintas distribuciones de Linux para poder decidir con qu´edistribuci´on se aprovecha mejor el escaso potencial de la m´aquina.Se estudiar´andistintas moda- lidades de benchmark con distintos equilibrios entre tiempo de ejecuci´ony precisi´on de las mediciones. Luego se analizar´any se comparar´anentre ellas. Se usar´anlos PCs de la asociaci´onTecnologies per Tothom (de ahora en adelante, TxT) a modo de aplicaci´onreal.

1.1.2. Motivaci´on La idea surge tras haber participado en una actividad organizada por TxT en la que se instalaba el sistema operativo a ordenadores donados, normalmente con pocos recursos. El sistema operativo en cuesti´onera la ´ultima versi´onde Ubuntu. Se ha visto que Ubuntu no es la mejor distribuci´onpara este tipo de sistemas. En cambio, con distribuciones m´asligeras especialmente dise˜nadaspara este cometido se pueden obtener buenos resultados. Creo que los PCs de TxT (y los PCs con pocos recursos en general) podr´ıan tambi´enbeneficiarse de las ventajas que ofrecen estas distribuciones, pero es necesario

4 escoger la m´asadecuada con tal de aprovechar al m´aximoel potencial de la m´aquina. Para ello es necesario poder calcular de manera cuantitativa el rendimiento de cada distribuci´on;es decir, se necesita un benchmark. Adem´as,este benchmark tambi´enpodr´ıa usarse en sistemas del estilo Pocket PC (p. ej., Raspberry Pi), ya que a efectos pr´acticosson PCs con pocos recursos. Actualmente el uso de este tipo de m´aquinasest´aaumentando notablemente, ya que ofrecen una soluci´onbarata y peque˜napara tareas que no requieran una gran capacidad de c´omputoo unas prestaciones fuera de lo com´un.Con este benchmark se podr´ancomparar este tipo de sistemas con PCs antiguos y ver si realmente suponen una alternativa viable.

1.2. Estado del arte

1.2.1. Contexto A la hora de aprovechar un PC con pocos recursos es importante elegir bien qu´esoftware se instalar´acon tal de sacar el m´aximoprovecho a nuestro limitado hardware. Actualmente el sistema operativo para los ordenadores de TxT es elegido de manera informal, sin tener en cuenta muchas alternativas y sin una base obje- tiva. Es mi prop´ositodemostrar que esta elecci´onafecta de manera considerable al rendimiento del sistema y que se podr´ıamejorar haci´endolacon m´asmesura. La soluci´onal problema tendr´aque tener en cuenta tanto aspectos de rendimiento como de funcionalidad para poder decidir de manera objetiva cu´ales la m´asadecuada para una determinada m´aquina.

1.2.2. Diagramas de flujo Actualmente no existe ning´unsoftware que ayude a escoger una distribuci´onde Linux, m´as all´ade los t´ıpicosdiagramas de flujo [1]. Si bien estos diagramas tienen la ventaja de ser sencillos y no requerir ning´unsoftware ni hardware espec´ıfico(porque no son programas, son diagramas), tienen la desventaja de que su granularidad es muy gruesa y solo distinguen entre “PC moderno” y “PC antiguo” como mucho, sin tener en cuenta el rendimiento de la m´aquina.Adem´astampoco tiene en cuenta funcionalidades espec´ıficas,sino que hacen distinciones como “PC de escritorio” o “Servidor”.

5 1.2.3. Benchmarks globales En la actualidad existen pocos benchmarks para Linux que midan el rendimiento de todo el sistema, y los que hay se encuentran desfasados. Unixbench es probablemente el m´asconocido. Aunque fue creado en 1983, ha ido siendo actualizado y hoy en d´ıase sigue usando [3]. El principal defecto de este benchmark es que mide resultados simulando casos de uso extremos que no coinciden con el perfil de uso que normalmente se le da a un PC. Otro conocido benchmark es HINT (Hierarchical INTegration) [4]. Se caracte- riza por su buen balance en la ponderaci´onde los distintos aspectos del sistema. Sin embargo, este benchmark devuelve como resultado un solo valor, que intenta ser una medici´onde la “calidad” del sistema. Actualmente se desaconseja este com- portamiento y se prefiere que se midan los distintos componentes del sistema por separado.

1.2.4. Benchmarks espec´ıficos Existen, por otro lado, benchmarks para medir el rendimiento de un solo aspecto espec´ıfico del sistema o incluso una tarea concreta. Los benchmarks globales suelen ser suites de benchmarks espec´ıficos debidamente ponderados. Los m´ascomunes son los benchmarks que miden la potencia de computaci´on (CPU, FPU y memoria). Estos consisten en hacer c´alculosque sean CPU-intensivos (c´omocalcular d´ıgitosde Pi, por ejemplo). Quiz´asel m´ascom´unde este tipo sea nbench [5] (un port a Linux de BYTEmark 2, anteriormente conocido como BYTE’s Native Mode Benchmarks [6]). No obstante, tambi´enexisten benchmarks dedicados a medir el rendimiento de otras partes del sistema, como IOzone [8] (dedicado a medir el rendimiento de los sistema de ficheros y dispositivos de almacenamiento) o netperf (para medir el ren- dimiento de la conexi´onde red). Incluso hay benchmarks dedicados a tareas tan espec´ıficascomo medir el rendi- miento de distintos temas y configuraciones de GTK+ (gtkperf [7]).

1.2.5. Colecciones de tests Finalmente, tambi´enexisten colecciones de tests no relacionados entre s´ıpara que el usuario elija los tests que desea realizar y pueda crear su propio benchmark global a partir de varios tests espec´ıficos.En este achapterado destaca Phoronix Test Suite [10]. Es una colecci´onde tests bastance reciente (creada en 2008) y amplia (contiene m´asde 60 tests). Adem´asofrece la posibilidad de compartir resultados

6 a trav´esdel servicio OpenBenchmarking http://www.openbenchmarking.org. Es una de las plataformas de benchmarking m´asusadas, tanto a nivel domestico como profesional. Sus mayores cr´ıticas son que el compilador y la configuraci´onque se usen para compilar los tests pueden afectar a los resultados de los mismos y que las comparaciones entre sistemas dispares no son del todo fiables.

1.2.6. Conclusiones Si bien alguno de estos benchmarks podr´ıaservir para medir el rendimiento de los PCs que se tratar´anen este TFG, recordemos que el prop´ositofinal es elegir un sistema operativo. Adem´asdel benchmarking convencional, en este trabajo se estudiar´ala posibilidad de crear un benchmark en una distribuci´on live que estime el rendimiento de las dem´asdistribuciones sin necesidad de instalarlas realmente todas. Esta es una funcionalidad muy dependiente de la situaci´ona tratar, por lo cual es algo que no pueden ofrecer los benchmarks anteriores. Es por esto que es necesario crear un nuevo benchmark.

7 Cap´ıtulo2

An´alisis de requisitos y planificaci´on

2.1. Marco legal

Pese a que los sistemas operativos de la familia Windows son los m´asutilizados en el ´ambito de la inform´aticade escritorio, los PCs que trataremos no los podemos distribuir con estos, ya que Windows se distribuye bajo una licencia de pago [2] que TxT no se puede permitir y que, adem´as, proh´ıbe su redistribuci´on.Por estos motivos la distribuci´onde PCs con sistema operativo Windows queda descartada. Necesitamos, pues, un sistema operativo gratuito y que nos ofrezca libertad de redistribuci´on.Con estas caracter´ısticas, GNU/Linux se presenta como la alternativa m´aspopular. Linux es ampliamente usado en sistemas de escritorio, tanto en el ´ambito personal como en el profesional. Aunque las condiciones y licencias pueden variar entre distribuciones, la mayor´ıa de ellas se ofrecen de manera gratuita y libre. El grado de libertad es variable, dependiendo de la distribuci´on,pero la mayor´ıacumple con creces los requisitos que TxT impone para poder ser instalado y distribuido con sus PCs.

2.2. Modalidades del benchmark

2.2.1. Modalidad cl´asica Un benchmark por si mismo consiste en una colecci´onde pruebas que determinan el rendimiento de una m´aquina(o de alg´unaspecto en concreto). Mi intenci´ones poder decir para cada PC qu´edistribuci´ones mejor, as´ıque el procedimiento ser´ıa:

8 instalar una distribuci´on,medir su rendimiento, repetir con el resto de distribuciones y comparar los resultados. Esta ser´ıa la modalidad cl´asicadel benchmark. Como esto puede llevar mucho tiempo (adem´asde resultar tedioso) se contemplar´an2 modalidades alternativas.

2.2.2. Modalidad basada en estimaci´on La primera consistir´aen instalar una distribuci´on y medirla tal y como se hace en la modalidad cl´asica,pero en lugar de repetir el procedimiento con todas las dem´as distribuciones, simplemente se estimar´asu rendimiento en base a los resultados de las mediciones realizadas en la distribuci´on instalada. De esta forma nos ahorramos tener que instalar y medir todas las distribuciones. No obstante, el precio a pagar por este ahorro de tiempo es la posible inexactitud de las estimaciones.

2.2.3. Modalidad basada en la estimaci´onde una distribu- ci´on live Para acabar de optimizar el tiempo, se crear´auna tercera modalidad similar a la anterior, pero que basar´alas estimaciones en mediciones realizadas con una distribuci´on live muy liviana creada expresamente para este cometido. Con esta modalidad llevamos al extremo las ventajas y los inconvenientes de la modalidad anterior: el proceso ser´amucho m´asr´apido,ya que no habr´aque instalar ninguna distribuci´on,pero los resultados pueden no ser precisos debido a la inexactitud de las estimaciones y a la variabilidad del medio donde se encuentre la distribuci´on live (CD, DVD, USB...).

2.2.4. Comparativa Una vez acabadas las tres modalidades, se comparar´an para ver cu´ales la mejor. Se tratar´ade alcanzar un equilibrio entre el tiempo necesario para realizar las pruebas y la precisi´onde los resultados.

2.3. Metodolog´ıa

En primer lugar, necesitamos conocer las necesidades funcionales de los ususarios para poder seleccionar unas distribuciones adecuadas. Para ello se realizar´auna en- cuesta en la que se consultar´aa los usuarios sobre qu´efuncionalidades necesitan en

9 un PC. Con los resultados de esta encuesta podremos saber qu´egrado de funcionali- dad alcanzan distintas distribuciones y, por tanto, si son adecuadas para instalarlas en nuestros PCs. Una vez tengamos la funcionalidad de cada distribuci´onnos interesa conocer su rendimiento. Para esto habr´aque crear un benchmark. Como ya se ha explicado en el apartado anterior, se implementar´an3 versiones con distintos niveles de equilibrio entre tiempo de ejecuci´ony precisi´on. Con los datos de rendimiento obtenidos con el benchmark y los de funcionalidad obtenidos con la encuesta ya estaremos en disposici´onde decidir qu´edistribuci´ones la m´asadecuada en cada m´aquina.

Finalmente, se usar´aeste mismo sistema para medir el rendimiento y las funcio- nalidades de un Pocket PC para comprobar hasta que punto podr´ıasustituir un PC de sobremesa.

2.4. Planificaci´ontemporal

Ha habido diferencias en la planificaci´oncon respecto a la inicial. En la previsi´on inicial, se seleccionaba un conjunto de distribuciones iniciales, se usaban los resul- tados de la encuesta para hacer una criba y luego se creaba el benchmark en su totalidad. En lugar de eso, tras hacer la encuesta se empez´oa crear el benchmark y se hizo una primera versi´on.Con esa primera versi´on del benchmark se evalu´oel rendimiento de todas las distribuciones iniciales y, con los resultados de la encuesta y los del benchmark se realiz´ola criba. Esto, por una parte, ofrece m´as feedback a la hora de crear el benchmark, ya que se puede probar un prototipo, pero por otra par- te, al tener que hacer mediciones sobre todas las distribuciones iniciales, el trabajo se ha alargado una semana. Adem´as,las tareas de “Finalizaci´ondel benchmark” y “Definir m´etodos de estimaci´on”han tomado m´astiempo del previsto, debido a su complejidad, con lo que, a pesar de planificar una holgura al final del trabajo, hubo que reducir el tiempo de las tareas finales. La planificaci´onqueda entonces tal que as´ı:

1. Realizar una encuesta: Esta fue la primera tarea del trabajo. Consisti´oen confeccionar una encuesta para saber qu´efuncionalidades necesitan los usuarios en varios tipos de programas (p. ej., procesador de textos con compatibilidad con Microsoft Office 2010) y distribuirla. Su duraci´onfue de una semana, co- menzando el d´ıa18 de Febrero. Los ´unicosrecursos que se usaron fueron mi PC personal y la suite de Google Drive para crear la encuesta y recopilar las respuestas. 10 2. Seleccionar distribuciones iniciales: Mientras la encuesta est´aactiva se aprovechar´apara seleccionar las distribuciones iniciales. Esta tarea dur´ouna semana: empez´otras distribuir la encuesta y acab´oal cerrarse la misma. Para esta tarea, adem´as,se usaron datos de la p´aginaweb DistroWatch (http: //www.distrowatch.com).

3. Analizar resultados de la encuesta: Una semana despu´esde distribuir la encuesta esta se cerr´oy ya no admite m´asrespuestas. Entonces se analizaron los resultados y se usaron para decidir qu´edistribuciones pasar´ıanla criba m´as adelante. La duraci´onde esta tarea fue de 3 d´ıasy, al igual que la tarea anterior, solo requise de mi PC y Google Drive para llevarla a cabo.

4. Preparar medios de instalaci´on: Una vez elegidas las distribuciones candi- datas, se crear´any grabar´anlas im´agenesde las distribuciones en CDs y DVDs, ya que los PCs probablemente no dispongan de arranque desde USB. Esta ta- rea tom´oapenas 1 d´ıa.Us´emi PC (con grabador de CD y DVD), conexi´on a Internet para descargar las im´agenesy unos CDs y DVDs v´ırgenes,tantos como distribuciones iniciales.

5. Crear primera versi´ondel benchmark: Tras ultimar los preparativos pro- ced´ı a dise˜nare implementar una primera versi´ondel benchmark. Esto im- plic´odecidir qu´epar´ametrosmedir y c´omohacerlo. Esto llev´o2 semanas. Us´eun PC propio similar a los menos potentes que hay en TxT para hacer pruebas, los CDs y DVDs de la tarea anterior y, como el benchmark medir´ala eficiencia de la red, us´ela conexi´ona Internet de mi casa.

6. Evaluar el rendimiento de las distribuciones iniciales: Con la primera versi´ondel benchmark acabada instal´ecada una de las distribuciones en el mismo PC de la tarea anterior y med´ısu rendimiento. Debido al alto n´umero de distribuciones esta tarea llev´otoda una semana. Los recursos usados fueron los mismos que en la tarea anterior.

7. Analizar resultados del benchmark: Una vez obtenidos los resultados de rendimiento, pude al fin realizar una criba sobre las distribuciones iniciales. Adem´as,con la experiencia obtenida al crear y probar la primera versi´ondel benchmark pude ver qu´easpectos hay que corregir de cara a la versi´onfinal.

11 8. Finalizaci´ondel benchmark: Tomando el esbozo de benchmark como base y los resultados de las pruebas como gu´ıafinalizar´eel benchmakr corrigiendo los errores detectados en las tareas anteriores. Se usar´anlos mismos recursos para realizar pruebas, aunque esta vez se har´ansolo sobre las distribuciones candidatas (las que hayan pasado la criba). Esta tarea es una de las claves del trabajo, y llev´om´astiempo del esperado. 9. Segunda versi´ondel benchmark: Crear la segunda modalidad del bench- mark result´orelativamente sencillo, comparado con la modalidad cl´asica(esta tarea tiene una duraci´onde 10 d´ıas,frente a los m´asde 40 de la creaci´ondel benchmark cl´asico).Se implement´ode tal manera que se pudo aprovechar el c´odigogenerado en la tarea anterior. 10. Definir m´etodos de estimaci´on: A parte de la creaci´ondel benchmark (ta- reas 5 a 8), el otro gran desaf´ıodel trabajo ser´adefinir c´omose calcular´an las estimaciones a partir de los valores medidos en la modalidad de benchmark por estimaci´onbasado en una distribuci´on live. Esta tarea llev´opoco m´asde 2 semanas. Dado que es una tarea de dise˜node benchmark, los recursos que usar´eser´anlos mismos que en la tarea anterior: mi PC personal y mi PC de prueba. 11. Crear distribuci´on live del benchmark por estimaci´on: Para poder usar la modalidad de benchmark basada en estimaci´ontomando como referencia una distribuci´on live liviana, primero hay que crear dicha distribuci´on,con todo el software necesario, y grabarla en un CD. Esta tarea llev´omucho menos de lo previsto. En tan solo 1 d´ıa se pudo completar. Esto fue debido a haber encontrado un programa muy sencillo de usar que se ajustaba perfectamente a las necesidades de la tarea. Los requisitos fueron los mismos que en la tarea 4: mi PC, con grabador de CDs, y un CD virgen. 12. Comparar modalidades del benchmark: Tras implementar las 3 modali- dades del benchmark, se analizaron y se decidi´ocu´alse usar´aen las mediciones. Inicialmente esta tarea iba a ser m´aslarga, pero debido a las modificaciones en la planificaci´ontubo que hacerse en solo 2 d´ıas. Para esta tarea fueron necesarios los PCs de TxT. Durante todo el proceso del trabajo se realizar´ala memoria en paralelo, docu- mentando cada tarea al tiempo que se hace. Durante la creaci´onde la primera modalidad del benchmark (tareas 5 a 8), adem´as de realizar las mediciones sobre las distribuciones candidatas tambi´ense realizaron sobre Raspbian (en la Raspberry Pi).

12

2.5. Presupuesto

2.5.1. Coste de software y hardware En sistemas antiguos como los que se tratar´anen este trabajo es habitual que el arranque desde USB no est´edisponible, as´ıque para no tener que extraer los discos duros y volverlos a instalar, se usar´ael arranque desde la unidad de CD/DVD. Por ello se requerir´anCDs y DVDs en los que grabar las im´agenes de las distribuciones a evaluar y la distribuci´on live para el benchmark basado en estimaci´on.Finalmente se han seleccionado m´asdistribuciones de las previstas, as´ıque el n´umerode CDs/DVDs necesarios ha aumentado con respecto a lo inicialmente planeado. Afortunadamente estos son baratos y el aumento en el precio no es demasiado importante. Los PCs sobre los que se efectuar´anlas pruebas ser´anprestados por TxT, as´ıque no suponen coste alguno. Para poder trabajar desde casa tambi´ense har´anpruebas en PCs antiguos de los que dispongo, lo cual tampoco supone ning´uncoste. Adem´as,se necesitar´aun Raspberry Pi sobre el que efectuar m´aspruebas. Final- mente se ha comprado un pack con placa, tarjeta SD y cable de alimentaci´on. Todo el software que se use ser´alibre o, por lo menos, gratuito. Finalmente, tambi´ennecesitar´eun PC con grabador de CDs y una conexi´ona Internet. Ya dispongo de estos recursos, as´ıque no suponen ning´uncoste, m´asall´adel de amortizaci´on. En el caso de que no los pudiese usar, la facultad ofrece PCs en pr´estamoy acceso a Internet, tambi´ende manera gratuita. Adicionalmente, se ha decidido comprar un medidor de consumo el´ectricopara medir la potencia que consumen los PCs con las distintas distribuciones. Teniendo en cuenta la planificaci´on, los gastos quedar´ıantal que as´ı:

Raz´on Coste Tiempo de Tiempo Coste amortizaci´on de uso imputable Software 0,00 e 3 a˜nos 4 meses 0,00 e PC personal 1000,00 e 3 a˜nos 4 meses 111,11 e PCs de pruebas 0,00 e 3 a˜nos 4 meses 0,00 e Raspberry Pi 40,00 e 3 a˜nos 4 meses 4,44 e 7 CDs 2,00 e 2,00 e 3 DVDs 2,00 e 2,00 e Medidor de con- 13,00 e 5 a˜nos 4 meses 0,86 e sumo el´ectrico Total 120,41 e

14 2.5.2. Coste espacial Adem´asdel coste del equipo, tambi´enhay que contar el coste del mantenimiento del almac´endonde se guardan los PCs y donde se realiza el proyecto. Cuando se realiz´ola proyecci´oninicial todav´ıa no ten´ıa acceso al almac´enen cuesti´ony, por lo tanto, los costes que estimaron “a ciegas”, sin conocer realmente c´omoes el local. Ahora que tengo acceso, puedo aproximar los costes m´asfielmente a la realidad. Raz´on Coste mensual Tiempo Coste total de uso Agua 20,00 e/mes 4 meses 80,00 e Luz 50,00 e/mes 4 meses 200,00 e Gas 50,00 e/mes 4 meses 200,00 e Tel´efonoe Internet 50,00 e/mes 4 meses 200,00 e Total 680,00 e

Sin embargo, hay que tener en cuenta que el almac´enno es de uso exclusivo para mi proyecto, sino que se realiza trabajo diario en ´el.Por lo tanto los costes se deber´an amortizar entre todo el trabajo que se haga en ´el.Supongamos que se reparta a partes iguales entre mi proyecto y el resto de trabajo que se realiza all´ı.Los costes quedan entonces reducidos a la mitad. Raz´on Coste mensual Tiempo Coste total de uso Agua 10,00 e/mes 4 meses 40,00 e Luz 25,00 e/mes 4 meses 100,00 e Gas 25,00 e/mes 4 meses 100,00 e Tel´efonoe Internet 25,00 e/mes 4 meses 100,00 e Total 340,00 e

2.5.3. Coste de recursos humanos Por ´ultimocabe a˜nadirlos costes del personal. Se considera que para la realizaci´on de este proyecto se requerir´an3 roles. Las siguientes tablas muestran las horas que se requieren de cada rol en cada tarea y su precio. Estos datos han sufrido cambios respecto a los entregados en el hito intermedio debido a que la duraci´onde algunas tareas se ha considerado demasiado “hinchada” y a que algunas de las tareas finales se han visto reducidas.

15 Administrador de sistemas experto en atenci´onal usuario Persona conoce- dora de las necesidades de los usuarios, sus preferencias y sus h´abitos.Su prin- cipal cometido ser´aasegurar que las distribuciones que se selecciones sean del agrado de los usuarios y no nieguen funcionalidades b´asicasa costa del rendi- miento.

Administrador de sistemas experto en performance Responsable de la crea- ci´ondel benchmark. Tiene profundos conocimientos de los par´ametrosque m´as influyen en el rendimiento de un sistema. Es capaz de medirlos de manera adecuada, aisl´andolosde otros par´ametrosque pudieran alterar la medici´on, e interpretar los resultados dentro de un contexto.

Administrador de sistemas experto en Linux Comprende los fundamentos de los sistemas operativos basados en Linux. Conoce las diferencias entre distintas distribuciones y el impacto de estas en su funcionamiento y usabilidad. Su tarea consistir´aen contribuir a la selecci´onde distribuciones inicial y crear la distribuci´on live.

Tarea A. usuario A. performance A. Linux Realizar encuesta e inter- 50 h 0 h 0 h pretar resultados Seleccionar y preparar 20 h 20 h 20 h distribuciones iniciales Creaci´onel benchmark 0 h 160 h 0 h Pruebas y mediciones 0 h 120 h 0 h Definir m´etodos de esti- 0 h 100 h 0 h maci´on Comparar modalidades 0 h 10 h 0 h de benchmark Crear distribuci´on live 0 h 0 h 10 h Tiempo total 70 h 410 h 30 h

Rol Tiempo Coste por hora Coste total A. usuario 70 h 20,00 e/h 1400,00 e A. performance 410 h 24,00 e/h 9840,00 e A. Linux 30 h 22,00 e/h 660,00 e Coste total de personal 11900,00 e

16 2.5.4. Coste total Una vez detallados todos los costes, podemos ver el coste total que supone el proyecto.

Concepto Coste Software y hardware 120,41 e Espacial 340,00 e Recursos humanos 11900,00 e Total 12360,41 e

17 Cap´ıtulo3

Especificaci´ony dise˜no

3.1. Encuesta

Tras finalizar GEP el primer punto es crear una encuesta que despu´esse pasar´aa los usuarios para conocer sus preferencias. En un principio la encuesta iba a ser m´as t´ecnica,y el usuario ten´ıaque elegir directamente el programa que prefiere para cada tipo de tarea. Por ejemplo:

Navegador Chrome / Chromium Epiphany Firefox / Iceweasel Konqueror Midori Opera No obstante esto se descart´o,ya que muy posiblemente los usuarios responder´ıan qu´eaplicaciones usan y no cuales son las m´asadecuadas. Adem´as,opciones po- co conocidas quedar´ıanmarginadas, independientemente de las funcionalidades que ofreciesen. Finalmente, la encuesta fue tal que el usuario deb´ıaseleccionar las funcionalida- des que necesita de cada programa, en lugar de elegir los programas directamente. Por ejemplo, para el caso del navegador de Internet se ofrec´ıanlas siguientes funcio- nalidades:

18 Navegador

Bloqueo de pop-ups sin necesidad de complementos

Bloqueo de publicidad sin necesidad de complementos

Control por voz

Gestos de rat´on

Conversi´ontexto-a-voz (text-to-speech)

Incorpora su propio plugin de Flash

Lector de feeds RSS incorporado (sin necesidad de complementos ni herramien- tas externas)

Gestor de contrase˜nas(recordar contrase˜nas,contrase˜namaestra)

Y el usuario deb´ıamarcar las funcionaliades que vea necesarias mediante un check- box. Al final de la encuesta se ofrec´ıaun espacio para a˜nadircomentarios. Solo se recibieron 3 comentarios: uno especificaba que prefer´ıasoftware libre antes que priva- tivo, otro prefer´ıainterfaces sencillas pero customizables y el ´ultimoera un mensaje de ´animo. La encuesta completa puede encontrarse en el ap´endiceA (junto con los resulta- dos, que se tratar´anm´asadelante).

3.2. Versi´onpreliminar del benchmark

Como las modalidades del benchmark se basan cada una en la anterior, es im- portante que el inicio sea s´olido.Para asegurarnos de que la primera modalidad de benchmark es consistente, se realiz´ouna versi´onpreliminar. Se realizar´anpruebas con esta versi´onpara detectar posibles errores y poder corregirlos en la versi´onfinal.

3.2.1. Mediciones La versi´on preliminar del benchmark consisti´oen las siguientes mediciones:

Disco El espacio que ocupa una instalaci´onpor defecto de la distribuci´onen el disco, sin paquetes adicionales. Aunque la mayor´ıade discos cumple con creces los requisitos de todas las distribuciones que se evaluar´an,en otros casos en los

19 que se trate con discos de poca capacidad este par´ametro puede resultar ´util. Un ejemplo es el caso de la Raspberry Pi, cuyo ´unico medio de almacenamiento es una tarjeta SD, que puede no ser muy grande. En todos los casos se usar´ael formato ext4.

Memoria Cantidad de memoria RAM que consume la distribuci´onestando en re- poso (enti´endase“reposo” como el PC encendido, pero sin realizar trabajo; no como un estado idle o de bajo consumo). Este par´ametroresulta particu- larmente decisivo en el rendimiento de una distribuci´on,ya que determina la cantidad de datos que ha de manejar el sistema solo para funcionar. Incluye la memoria ocupada por buffers y cach´e. Si bien el sistema puede liberar este espacio para dedicarlo a aplicaciones del usuario, lo “natural” es que el sistema lo tome.

Tiempo de arranque El tiempo que tarda el sistema en arrancar, hasta que es usable. Es uno de los par´ametrosque m´asvalora el usuario final. Puede verse influenciado por otros par´ametroscomo el disco y la memoria. Este par´ametrose midi´oleyendo el archivo /etc/uptime. Para que la medici´onse hiciese tan pronto como el sistema acabe de iniciar, se us´ola herramienta para configurar la ejecuci´onde aplicaciones al inicio, que var´ıaseg´unla distribuci´on.

Tiempo de arranque de un programa lento El tiempo que tarda un programa pesado desde el momento en que se manda ejecutar hasta que es usable por el usuario. Los usuarios sin conocimientos profundos de inform´aticatienden a usar este par´ametrocomo medida de rendimiento. Como los usuarios finales po- siblemente no sean inform´aticos,este es un par´ametroque resulta conveniente vigilar. Se eligi´oLibreOffice Writer (versi´on3.6.6) como ejemplo de “programa lento”, debido a que muy probablemente sea uno de los programas que m´asusen los usuarios finales, y se ha medido el tiempo de abrir el programa, esperar hasta que sea usable y cerrarlo (de manera manual). De esta manera se pudo usar la herramienta time para medir el tiempo. En las distribuciones que no inclu´ıanLibreOffice se instal´odesde los reposito- rios. En las que s´ılo inclu´ıanse actualiz´otambi´ena trav´esde los repositorios oficiales. En todos los casos se instalaron tambi´enel paquete de ayuda y el de idioma (espa˜nol).En el caso de Puppy Linux se us´oel script getLibreOffice,

20 que crea el paquete correspondiente a partir de los paquetes .deb oficiales. En el caso de Slackware, se crearon los paquetes .tgz a partir de los .deb con la herramienta deb2tgz. En estos dos ´ultimoscasos, hubo que crear soft-links para lowriter, ya que no se crean al instalar los paquetes. Tiempo de apertura de un archivo grande con un programa lento Versi´on m´assofisticada del par´ametroanterior. Algunos programas pueden usar t´ecni- cas para parecer usable cuando en realidad solo lo son parcialmente, de manera que cargan r´apido, pero al interactuar con ellos se ralentizan. Midiendo este par´ametrose fuerza al programa a trabajar desde el principio, con lo que dichas t´ecnicasno funcionan. La metodolog´ıapara medir este par´ametroes similar a la del par´ametroante- rior: se ha elegido LibreOffice, y se incluye el tiempo de cerrar el programa para poder hacerlo con la herramienta time. Como “archivo grande” se ha genera- do un archivo de texto plano cuyo contenido son 1000000 (un mill´on)de ‘a’ seguidas por un car´acter de salto de l´ınea(‘\n’). En esta ocasi´on,en lugar de simplemente esperar a que el programa sea usable, se esper´oa que el recuento de p´aginas (que LibreOffice Writer muestra en la esquina inferior izquierda) llegase al valor correcto. De esta manera se asegura que el archivo se ha le´ıdo completamente. Velocidad de descarga Para comprobar la eficiencia de la gesti´onde la red se descargar´aun archivo de gran tama˜no.este es precisamente el principal uso que se le da a la red, de manera que resulta un buen indicador del rendimiento de la red. Se us´oun archivo de 500 MB almacenado en un servidor en Internet (comple- tamente ajeno a TxT, a la UPC y a este proyecto). Tiempo de compilaci´onde un kernel de Linux en serie La compilaci´onde un kernel de Linux es una de las pruebas de benchmarking m´asusadas. Requiere frecuentes accesos a disco y usa una porci´onconsiderable de la memoria (sufi- ciente para atenuar el efecto de las cach´es).La prueba simplemente consiste en compilar y comprimir una imagen del kernel de Linux (sin m´odulosadicionales) y medir el tiempo que tarda. Para poder comparar los resultados de manera coherente, siempre se compi- lar´ala misma versi´ondel kernel (3.8.4), con las mismas opciones (las opciones por defecto). No se garantiza que se use la misma versi´ondel compilador. Si una distribuci´onincluye un compilador desfasado se ver´acomo un aspecto negativo y quedar´areflejado en el tiempo de compilaci´on.

21 Tiempo de compilaci´onde un kernel de Linux con varios threads ´Idem al par´ametroanterior, pero con varios threads trabajando al mismo tiempo. Con esto podemos medir la eficiencia de la gesti´onde procesos (scheduling) del sistema operativo. Dado que el n´umerom´aximode procesos que los PCs a tratar pueden ejecutar simult´aneamente es de 2 (hay procesadores con 2 cores y procesadores con Hyperthreading) se ha optado por compilar el kernel usando 4 threads, para forzar el scheduling.

Consumo energ´etico Consiste en medir la potencia consumida por el sistema es- tando en reposo (enti´endase “reposo” como el PC encendido, pero sin realizar trabajo; no como un estado idle o de bajo consumo). La medici´onse hizo con un medidor de consumo el´ectrico(una herramienta hardware).

3.2.2. Puntos a mejorar Durante las pruebas se detectaron los siguientes problemas:

Las mediciones del disco sufren una peque˜naperturbaci´on al incluir en el re- sultado el tama˜node los archivos del benchmark. Aunque es una perturbaci´on peque˜na,es f´acilevitarla en versiones sucesivas del benchmark.

Las mediciones que involucran LibreOffice requieren la intervenci´ondel usuario (para cerrar el programa en su debido momento).

Las pruebas se realizaron en mi casa y con mi conexi´onde red. La prueba de medici´onde la velocidad de la red podr´ıatener que modificarse dependiendo de la conexi´onde red del almac´ende TxT (por ejemplo, reemplazar el archivo a descargar por uno m´asgrande o m´aspeque˜noo cambiar a una localizaci´on distinta). Se ha notado que este atributo no var´ıademasiado entre distribuciones, as´ıque posiblemente se dar´ala posibilidad de ignorarlo.

El consumo el´ectricose mide con un hardware que no tiene conexi´oncon el PC y, por lo tanto, el usuario debe tomar nota del valor ´elmismo. De todas formas, este atributo tambi´envar´ıamuy poco entre distribuciones, as´ıque tambi´ense dar´ala posibilidad de ignorarlo en futuras versiones.

22 Algunas distribuciones necesitaron instalar el software necesario para compilar el kernel de Linux. En las distribuciones basadas en Debian/Ubuntu se ins- tal´oel paquete build-essential. En Puppy Linux se instal´oel paquete devx. En la versi´onfinal del benchmark se deber´ainformar al usuario.

3.3. Versi´onfinal del benchmark

La nueva versi´ondel benchmark corrige fallos de la versi´onpreliminar y se ha creado un script para automatizarlo (el c´odigofuente puede verse en el ap´endice E). Estos son los puntos a destacar de la nueva versi´ondel benchmark:

Se resta el tama˜node los archivos del benchmark a la medici´ondel disco.

Se ha creado una funci´onbash que usa el comando top para comprobar cuando LibreOffice ha acabado de trabajar. Con esto, ahora no se medir´asolo hasta que el recuento de p´aginassea correcto, sino hasta que el uso de CPU de LibreOffice sea 0, lo cual puede ser unos segundos despu´esde que el recuento de p´aginas alcance el valor adecuado. Adem´as,como esta funci´onno cierra LibreOffice Writer satisfactoriamente, se eliminan los archivos temporales de LibreOffice antes del iniciarlo, para que no pida recuperarlos.

Los PCs de escritorio no acostumbran a ofrecer una interfaz para consultar el consumo energ´etico,por lo que esta prueba sigue necesitando la intervenci´on del usuario. Si se va a ejecutar el benchmark en un PC capaz de reportar su propio consumo energ´etico(p. ej., un port´atil)se podr´ıaextender el script del benchmark e incorporar esta funcionalidad. Otra posibilidad ser´ıacomprar un medidor de consumo el´ectricocon conexi´onal PC (los hay con conexi´onUSB), pero se decidi´ono gastar m´asen hardware teniendo uno perfectamente funcional.

Si hay alguna dependencia del benchmark sin cumplir se pedir´aen el momento que se vaya a usar. Por ejemplo, si LibreOffice no est´ainstalado, se pedir´aque se instale tras haber hecho las mediciones de disco y memoria. En el caso de que todas las dependencias est´eninstaladas no se requerir´ala intervenci´ondel usuario.

El script es capaz de reiniciar el sistema cuando sea necesario sin la intervenci´on del usuario si se usa el par´ametroadecuado (esto puede requerir permisos).

23 Se pueden ignorar las pruebas de velocidad de la red y de consumo energ´etico (recordemos que la medici´ondel consumo se hace de manera manual por parte del usuario).

Como corolario de los tres ´ultimos puntos, si el sistema cumple las dependen- cias en el momento de ejecutarse, se ignora la prueba de medici´ondel con- sumo el´ectricoy se manda a ejecutar con privilegios y usando el par´ametro adecuado para automatizar los reinicios, el benchmark se puede automatizar completamente (no requerir´aen ning´unmomento la interacci´ondel usuario). No obstante, hay que tener en cuenta que algunos de los PCs de TxT tienen problemas al arrancar sin estar conectados a un monitor (esto es importante si se pretende trabajar con varios PCs a la vez conectados a un multiplexor VGA, como fue mi caso).

Todas las mediciones (excepto la del tiempo de arranque) se har´antras esperar 60 segundos despu´esde que el sistema sea usable, para garantizar que se ha iniciado completamente.

3.4. Modalidad basada en estimaci´on

Una vez que ya se tiene la versi´onfinal de la primera modalidad del benchmark y unas mediciones fiables de todas las distribuciones candidatas, se puede hacer la siguiente modalidad del benchmark. Esta modalidad solo realizar´amediciones sobre una de las distribuciones y extra- polar´alos resultados para determinar el rendimiento de las dem´as.Se ha decidido que la distribuci´onde referencia (sobre la que se har´anlas mediciones) ser´aUbuntu, ya que es la que la mayor´ıade los PCs de TxT llevan ya instalada.1 El c´odigofuente del benchmark se puede reaprovechar casi por completo. El c´odigo resultante se puede ver en el ap´endice G. Las mediciones sobre la distribuci´onse har´anexactamente de la misma manera que en la modalidad de benchmark anterior; la diferencia est´aen que se estimar´ael rendimiento de las dem´asdistribuciones, as´ıque el c´odigode la modalidad anterior del benchmark no se modifica, solo se expande.

1En el momento de dise˜naresta modalidad de benchmark las distribuciones candidatas eran Slackware (con KDE), Ubuntu, Linux Mint y Puppy Linux.

24 Los par´ametrosm´assencillos de medir son el disco y la memoria, ya que solo hay que consultar la cantidad total y la usada. aprovechando esto y, ya que el uso de memoria es el gran discriminante, podemos usar estos par´ametrospara realizar descartes tempranos en el caso de que el sistema no disponga de suficiente memoria y/o disco para algunas de las distribuciones. Para ello se distinguir´aentre 3 casos: Disco y/o memoria insuficientes para Ubuntu En este caso, se pueden des- cartar al instante Ubuntu y Slackware. Se estimar´ael consumo de memoria y disco de Linux Mint. Si las cantidades de memoria y disco son suficientes para correr Linux Mint, se elegir´acomo distribuci´onganadora. En caso contrario, se elegir´aPuppy Linux. Sea cual sea la distribuci´onelegida en este caso, no ser´anecesario completar el benchmark Disco y memoria suficientes para Ubuntu, pero no Slackware En este caso, si Ubuntu tiene un buen rendimiento se elegir´acomo distribuci´onfinal. En caso contrario, se elegir´aLinux Mint. Disco y memoria suficientes para Slackware En este caso habr´aque elegir en- tre Slackware, Ubuntu y Linux Mint. Si Ubuntu tiene un buen rendimiento, se decidir´aentre Slackware y Ubuntu. En caso contrario se elegir´aLinux Mint como distribuci´onideal. Para decidir entre 2 distribuciones, el funcionamiento es el mismo que en la modalidad de benchmark anterior, con la diferencia de que los par´ametrosser´an estimados, no medidos. Debido a que los par´ametrosde velocidad de red y consumo el´ectrico no son decisivos, se ignorar´an.Tambi´ense ignorar´ael tiempo de compilaci´ondel kernel de Linux con 4 threads, ya que esto depender´adel tipo de procesador (n´umero de threads, cores, etc.).

3.5. Modalidad basada en la estimaci´onde una distribuci´on live

Aunque con esta segunda versi´ondel benchmark reducimos considerablemente el tiempo necesario para averiguar la distribuci´onideal, a´untenemos que instalar y una distribuci´on.Adem´asexiste la posibilidad de que esa distribuci´on no sea la ideal y haya que instalar otra despu´es.Para ahorrarnos todas estas instalaciones se cre´ouna tercera versi´ondel benchmark. Esta versi´onno requerir´ainstalar ninguna distribuci´on,ya que se ejecutar´adesde una distribuci´on live. Tampoco requerir´atanto

25 tiempo como las versiones anteriores, ya que la mayor´ıade par´ametrosse estimar´an en base al hardware del PC en cuesti´on.As´ı,pues, esta versi´on ser´ala que menos tiempo necesite, pero tambi´entendr´aunos resultados potencialmente m´asalejados de la realidad.

3.5.1. ¿Medir o estimar? Durante la creaci´onde esta versi´onsurgieron dos ideas sobre c´omodeber´ıafun- cionar este benchmark. Por un lado, exist´ıala posibilidad de simplemente ejecutar el benchmark sobre la distribuci´on live y, a partir de sus resultados, estimar cu´alesser´ıan los resultados de las dem´asdistribuciones de manera similar a la versi´onanterior del benchmark. Por el otro, la idea era que desde la distribuci´on live se consultasen los atributos del hardware del sistema en cuesti´ony se calculase la distribuci´onideal en base a esos atributos. Se hicieron pruebas con la primera alternativa. Estas mediciones se realizaron sobre el PC A (Procesador Intel Core 2 Duo, 2 GiB de memoria). Para poder realizar las pruebas que requieren entorno gr´afico,se instal´oJWM (Joe’s Window Manager) en la distribuci´on live. Este entorno de escritorio es muy ligero y es el que incluye Puppy Linux por defecto. No se realiz´ola prueba de ocupaci´onde disco, porque la distribuci´on live siempre ocupa el mismo espacio. Tampoco se realiz´ola prueba de velocidad de red, porque se vi´oque no era un par´ametrodecisivo (todas las distribuciones daban pr´acticamente el mismo resultado).

Par´amtero CD USB Memoria (MiB) 262 242 Tiempo de arranque del SO (s) 151,12 24,30 Tiempo de arranque de LibreOffice (s) 21,568 9,819 Tiempo de apertura de many_as.txt (s) 141,696 103,413 Tiempo de compilaci´onen serie (s) 263,273 260,172 Tiempo de compilaci´onen paralelo (s) 143,145 142,294 Consumo energ´etico (W) 62,0 56,0

El primer problema que encontr´efue que para poder conservar los resultados de las mediciones durante los reinicios necesarios ser´ıanecesario un medio de almace- namiento persistente. Es decir, la distribuci´on live no podr´ıaser grabada en un CD o DVD. Esto supone un problema, ya que algunos (pocos) de los PCs de TxT no pueden arrancar desde USB. Adem´as,se vio que el medio en el que se grabase la distribuci´on(CD, DVD o USB) afectaba a los valores de las mediciones, debido a que

26 la velocidad de lectura de dicho medio no era la misma que la del disco del sistema a evaluar (adem´asde que tambi´en afectaba otros par´ametros,como el consumo el´ectri- co). Como esta versi´ondel benchmark ya extrapola bastante los datos, se decidi´oque a˜nadiruna variable m´asa las estimaciones (la velocidad del medio de la distribuci´on live) ser´ıademasiado, as´ıque se opt´opor descartar esta alternativa.

3.5.2. La distribuci´on live Para esta versi´ondel benchmark se ha usado una distribuci´on live basada en De- bian 6.0.7. Es la misma distribuci´oncon la que se trabaj´oanteriormente en el trabajo, pero esta vez se usar´asin entorno gr´afico.Con esto conseguimos reducir de manera considerable los recursos necesarios para ejecutarla en tiempos razonables. Adem´as, como esta versi´on simplemente toma las propiedades del hardware y realiza c´alculos (no realiza las mediciones de las versiones anteriores; no se necesitar´aLibreOffice), no es necesario entorno gr´afico. Para crear la distribuci´on live, en primer lugar se cre´ouna m´aquinavirtual en VirtualBox. Los par´ametrosde la m´aquina virtual no afectar´anal resultado, aunque s´ıpuede afectar al tiempo que se tarde en construir la imagen .iso resultante. Du- rante la instalaci´onse eligi´ono instalar el entorno gr´afico,ya que no ser´anecesario para esta tarea y nos permite ahorrar bastante memoria (recordemos que toda la distribuci´onser´acargada en memoria). Una vez instalada la distribuci´onDebian se personaliz´o,instalando los paquetes necesarios para realizar todas las tareas. Esto in- cluy´oel paquete build-essential, para compilar, y el paquete nasm, requisito para el programa bandwidth [11] (el cual se instal´odesde el c´odigofuente proporcionado por el autor). Finalmente, se realiz´ouna “instant´anea”(en ingl´es, snapshot) usan- do el programa refractasnapshot. Este programa crea por defecto un men´uque aparece al arranque y permite elegir entre distintos tipos de arranque (normal, sin entorno gr´afico,cargar a memoria...). Se edit´oeste men´upara que s´oloestuviese la opci´on de cargar a memoria y se redujo el timeout al m´ınimo (porque realmente no es necesario escoger ninguna opci´on,ya que solo hay una). El programa gener´ouna imagen .iso que conten´ıala instant´aneade la distribuci´ontal y como estaba en el momento de la creaci´on.Finalmente se copi´oa un USB usando el programa dd. Tambi´ense podr´ıahaber grabado en un CD o DVD. Debido a las limitaciones del programa de entrega de la memoria de este proyecto (el tama˜nom´aximopara archivos adicionales es de 100 MB) no se podr´aentregar la imagen .iso (que tiene un tama˜node m´asde 200 MB).

27 3.5.3. Estimando en base al hardware De la misma manera que se hizo en la modalidad anterior de benchmark, leer la capacidad del disco y la memoria y comprobar si es suficiente para cada una de las distribuciones es f´acil,ya que estos par´ametros son bastante constantes para una misma distribuci´onen varios PCs. Otros par´ametrosno pueden ser medidos directamente y tienen que ser estimados en base a peque˜naspruebas. Para poder estimar los valores que no podemos medir, es necesario averiguar de qu´eotros par´ametros dependen. Para ello se han realizado un estudio estad´ısticoque puede encontrarse en el ap´endiceH. En este estudio se observaron variables relativas al disco, la memoria y la CPU, por que son las m´asb´asicasy probablemente las que m´asinfluencia tengan. Las variables relativas a la CPU son simplemente el tiempo de compilaci´onde una aplicaci´onde referencia con 1 y 4 threads, tal y como se hace en el benchmark cl´asico.Al tener que cargar la distribuci´on live en la memoria, no queda suficiente para compilar el kernel de Linux, as´ı que se ha optado por una aplicaci´onm´as peque˜nallamada PAPI [12] (la funcionalidad de la aplicaci´onno nos importa; solo su tiempo de compilaci´on). Las variables relativas al disco son el ancho de banda de lectura y la latencia. Estas se pueden medir f´acilmente usando el comando dd; para medir el ancho de banda se leen 1,6 GB y para la latencia, 1 bloque (512 B). Finalmente, las relativas a la memoria son el ancho de banda de lectura de secuencial de archivos de distintos tama˜nos.Se han distinguido 4 casos: archivos menores de 32 kiB, entre 32 y 256 kB, entre 256 kB y 1 MB y superiores a 2 MB. Esta divisi´on se ha realizado tras ver 4 tramos claramente distintos en pruebas realizadas con el programa bandwidth (v´easela figura 3.1).

28 29

Figura 3.1: Gr´aficogenerado por el programa bandwidth. 3.6. Experimentaci´oncon un Pocket PC

Hoy en d´ıa,cuando se habla de PCs de perfil bajo uno no puede evitar pensar en los llamados Pocket PCs; PCs diminutos, que caben en la palma de la mano, con los recursos m´ınimosnecesarios para realizar tareas cotidianas como navegar por Internet, consultar el correo o editar un documento. Sus principales ventajas son su bajo consumo y su precio, lo cual las hace ideales para, por ejemplo, aulas tecnol´ogicas en pa´ısessubdesarrollados, donde la corriente el´ectricaes escasa y el presupuesto muy ajustado. Actualmente la asociaci´onTxT dona equipos de sobremesa con pocos recursos a ONGs con este tipo de finalidades, con lo que resulta interesante comprobar hasta qu´epunto pueden los Pocket PC sustituir los PCs convencionales. Como parte de este trabajo se experiment´ocon una Raspberry Pi (modelo B). La finalidad de estos experimentos fue doble: por un lado, demostrar que el benchmark puede funcionar en cualquier dispositivo capaz de correr Linux; y por otro, medir el rendimiento de un Pocket PC y compararlo con el de PCs convencionales de bajo rendimiento. No se trat´ode comparar las distintas distribuciones disponibles para la Raspberry Pi, ya que todav´ıason pocas y tienen prop´ositosmuy distintos (p. ej., convertir la Raspberry Pi en un media center).

30 Cap´ıtulo4

Implementaci´on,pruebas y resultados

4.1. Encuesta

La encuesta se public´oen los foros de la facultad y permaneci´odisponible durante una semana. Durante este tiempo se consiguieron 88 respuestas; m´asque suficiente para mi prop´osito. A la hora de valorar los resultados de la encuesta y asociar un valor a cada opci´on, inicialmente se pens´oen hacer una traducci´ondirecta: asociar a cada funcionalidad el porcentaje de encuestados que la seleccion´o.Finalmente se opt´opor normalizar el valor. Es decir, el valor asignado a una funcionalidad (x) se obtiene con la siguiente f´ormula: n´umerode votosx valorx = Σtodas las funcionalidadesn´umerode votos De esta manera el valor de cada funcionalidad queda ponderado seg´unsu populari- dad: las funcionalidades populares valdran m´asque las impopulares. Los resultados completos de la encuesta se pueden encontrar en el ap´endice A. Los votos de las opciones de reproducci´onde HD-DVD y Blu-Ray Disc se eliminaron, ya que, al no disponer del hardware necesario, estas opciones resultan irrelevantes.

31 Cuadro 4.1: Fragmento de los resultados de la encuesta.

Votos Votos Valor Funcionalidad (abs) ( %) normalizado Compatible con documentos de 77 87,50 % 3,56 % Office 2010 (.docx) Compatible con documentos de 47 53,41 % 2,17 % LibreOffice y OpenOffice (.swx) Posibilidad de a˜nadir 45 51,14 % 2,08 % comentarios a los documentos Crear gr´aficosy dibujos sin necesidad de una herramienta 54 61,36 % 2,50 % externa Procesador de textos Integraci´oncon una suite 18 20,45 % 0,83 % ofim´aticacompleta Versi´onpara Mac OS X 14 15,91 % 0,65 %

4.2. An´alisis de las distribuciones

4.2.1. Selecci´onde distribuciones candidatas Mientras la encuesta estuvo activa, se seleccionaron las distribuciones candidatas con las que se trabajar´ıa.A continuaci´onse detalla qu´edistribuciones se seleccionaron y por qu´emotivo.

Bodhi Linux

Versi´on: 2.3.0 Motivo: Est´abasada en Ubuntu (que es la distribuci´onque se usa actual- mente), usa el entorno de escritorio Enlightenment, conocido por ser muy ligero. Es muy minimalista y tiene una buena puntuaci´onen DistroWatch.

32 CrunchBang

Versi´on: 11 (Waldorf) Motivo: Es una distribuci´onligera, basada en Debian (anteriormente basada en Ubuntu, que es la distribuci´onque se usa actualmente) y tiene una buena puntuaci´onen DistroWatch. Comentarios: Esta distribuci´ondebe grabarse en un CD de 800 MB como m´ınimo.

Debian

Versi´on: 6.0.7 (Squeeze) Motivo: Es una distribuci´onoriginal (no est´abasada en ninguna otra), es muy conocida y es compatible con paquetes de Ubuntu. Comentarios: solo se usar´ael CD1.

Linux Mint versi´on: 12 (Lisa) Variante: LXDE Motivo: Es la distribuci´onelegida para los PCs m´asantiguos de TxT. Se ha elegido como referencia. Comentarios: No es la versi´onm´asmoderna, pero es la ´ultimaque se puede grabar en un CD de 700 MB.

Puppy Linux

Versi´on: 5.4.3 Variante: Ubuntu Precise Motivo: Es una distribuci´onextremadamente ligera, usa JDM (un entorno de escritorio muy ligero), arranca desde ramdisk y tiene muy buena valoraci´on en DistroWatch. Comentarios: Se usar´ael modo de instalaci´on Full.

33 Slackware

Versi´on: 14.0 Variante: KDE y XFCE Motivo: Es una distribuci´onoriginal de las m´asantiguas y muy completa en cuanto a funcionalidades. fue sugerida por mis directores. Comentarios: Esta distribuci´ondebe ser grabada en un DVD como m´ınimo. Ambas variantes se encuentran en el mismo disco. Se tratar´anlas dos variantes por separado.

Lubuntu

Versi´on: 12.10 Motivo: Versi´onligera de Ubuntu, con escritorio LXDE (muy ligero). Tiene buena puntuaci´onen DistroWatch.

Xubuntu

Versi´on: 12.10 Motivo: ´Idem a la anterior, pero con escritorio XFCE (tambi´enmuy ligero, auque no tanto como LXDE).

Ubuntu

Versi´on: 12.04 Motivo: Distribuci´onmuy popular. Es una versi´onLTS (Long Term Support). Es la que se usa actualmente en la mayor´ıade PCs de TxT. Se ha elegido como referencia. Comentarios: No es la versi´onm´asmoderna, pero es la ´ultimaque se puede grabar en un CD de 700 MB.

Todas las instalaciones se hicieron sin acceso a la red y con todas las opciones por defecto, con las siguientes excepciones:

Se activa la opci´onde auto-login siempre que sea posible. Esto es para favorecer la medici´ondel tiempo de arranque.

En la variante KDE de Slackware no se instala XFCE y viceversa. Esto es para no perturbar la medici´onde la ocupaci´ondel disco.

34 En las distribuciones que no proporcionan un particionamiento del disco por defecto, se instala todo el sistema en una ´unicapartici´on.Tambi´ense hace una partici´on swap de tama˜noigual al doble de la cantidad de memoria del sistema. Siempre se usa ext4.

4.2.2. An´alisis de funcionalidades Una vez elegidas las distribuciones, se calcula su funcionalidad. Para ello, primero se toman de cada distribuci´onlos programas pertenecientes a cada una de las cate- gor´ıasde la encuesta (v´easeel ap´endiceB). Con esto ya podemos ver que algunas de las distribuciones no traen programas para algunas de las categor´ıas.Por ejemplo, Xubuntu no incluye ning´unprograma para trabajar con hojas de c´alculo.Estas dis- tribuciones posiblemente se vean perjudicadas en el aspecto de funcionalidad. Solo se tuvo en cuenta el software incluido en la instalaci´on por defecto. El software in- cluido en el disco que no est´eseleccionado por defecto no se valorar´a.El software no incluido en el disco pero incluido en los repositorios o instalable a trav´esde scripts post-instalaci´onu otros medios tampoco se valorar´a.Si alg´unsoftware incluido en la instalaci´onpor defecto tiene actualizaciones disponibles a trav´esde Internet, estas actualizaciones tampoco se tendr´anen cuenta. Para saber qu´esoftware incluye cada distribuci´onsimplemente se instal´ocada una de ellas en una m´aquinavirtual. Despu´esse mira qu´efuncionalidades tiene cada programa y cuales no (v´ease el ap´endiceC). Aqu´ıpodemos ver como las distintas alternativas para una misma categor´ıatienen distintos equilibrios entre funcionalidad y rendimiento. Por ejemplo, Abiword es m´asligero que LibreOffice Writer, pero tambi´entiene muchas menos funcionalidades. M´asadelante, cuando se eval´ueel renimiento, se podr´aver m´as claramente qu´edistribuciones balancean mejor funcionalidad y rendimiento. Finalmente, uniendo los programas por distribuci´oncon las funcionalidades por programa se puede saber qu´efuncionalidades cumple cada distribuci´on.Esta ser´ala medida que se usar´acomo representativa del nivel de funcionalidad de cada distri- buci´on.Inicialmente se pens´oen contar solo las funcionalidades con m´asdel 50 % de votos, para distinguir las funcionalidades populares de las no populares. Finalmente se opt´opor un total normalizado, usando el valor normalizado que se calcul´ocon los resultados de la encuesta. El desglose de los resultados puede encontrarse en ap´endice D. A continuaci´onse muestran los totales.

35 La fila “Total (abs)” indica el total de votos para las funcionalidades con m´asdel 50 % de votos. La fila “Total ( %)” indica el porcentaje de funcionalidades con m´asdel 50 % de votos que cumple. La fila “Total normalizado” es una ponderaci´onteniendo en cuenta todas las funcionalidades y su valor normalizado (v´easeel ap´endiceA). Leyenda: 1 = S´ı;0 = No; 0,5 = Parcial

Funcionalidad Slackware Lubuntu Ubuntu KDE Xubuntu Debian Bodhi Linux Puppy Linux CrunchBang XFCE Linux Mint Total mayoritarios 2,5 12,5 10 19,5 16,5 23 15 19 13 19 (abs) Total mayoritarios Total 8,33 41,67 33,33 65,00 55,00 76,67 50,00 63,33 43,33 63,33 ( %) Total normalizado 9,49 43,93 38,77 70,14 60,72 83,49 55,77 65,67 51,04 72,72 ( %)

Con estos resultados es f´acilobservar que Bodhi Linux no llegar´alejos, ya que cumple menos del 10 % de las funcionalidades, muy por debajo del resto de distribu- ciones (esto se debe principalmete a que casi no trae ning´unprograma por defecto). Por esta raz´onse decidi´odescartar Bodhi Linux como distribuci´oncandidata, incluso antes de medir su rendimiento.

4.3. An´alisis de los PCs

4.3.1. PCs de TxT Con tal de preparar las pruebas, hice una visita al almac´ende TxT para ver con qu´ePCs tendr´ıaque trabajar. En el momento de la inspecci´on,la mayor´ıade los PCs eran de los siguientes tipos:

36 Modelo A

Procesador: Pentium 4 Frecuencia del procesador: 3,20 GHz N´umerode n´ucleos: 1 N´umerode threads por n´ucleo: 2 (Hyperthreading) Memoria: 2 × 512 MB Disco: 80 GB Lector de DVD: S´ı(DVD-ROM)

Modelo B

Procesador: Pentium D Frecuencia del procesador: 3,00 GHz N´umerode n´ucleos: 2 N´umerode threads por n´ucleo: 1 Memoria: 2 × 512 MB Disco: 160 GB Lector de DVD: S´ı(DVD-RW)

Modelo C

Procesador: Core 2 Duo Frecuencia del procesador: 3,13 GHz N´umerode n´ucleos: 2 N´umerode threads por n´ucleo: 1 Memoria: 2 × 1 GB Disco: 250 GB Lector de DVD: S´ı(DVD-RW)

Nota: La cantidad de memoria y disco puede variar entre PCs del mismo modelo.

37 Aunque hab´ıaPCs de otros tipos (tanto mejores como peores), eran muy pocos y se trataron como outliers. Estos 3 tipos de PCs eran comunes en gran n´umero,probablemente debido a que las donaciones de equipos a TxT se hacen en grandes cantidades. En cambio, los outliers eran escasos; probablemente eran restos o fueron donados por particulares.

4.3.2. Pruebas de rendimiento preliminares En un principio, las pruebas se har´ıanen los PCs antes mencionados, pero la llave del almac´enque me ten´ıanque dar se extravi´oy, durante la mayor parte del trabajo, solo pude entrar cuando hubiese alguien dentro, as´ıque decid´ırealizar las primeras pruebas en mi casa. Para poder hacer pruebas en casa y no tener que depender de TxT dispuse de un PC de las siguientes caracter´ısticas:

Modelo A0

Procesador: Pentium 4 Frecuencia del procesador: 3,00 GHz N´umerode n´ucleos: 1 N´umerode threads por n´ucleo: 2 (Hyperthreading) Memoria: 512 MB + 1 GB Disco: 80 GB Lector de DVD : S´ı(DVD-RW)

La intenci´ones que el PC A0 simule un “suelo” para poder decidir la magnitud de las pruebas; es decir, un PC con los m´asbajos recursos (no queremos un benchmark que tarde demasiado en ejecutarse en un PC lento, ya que la finalidad de este es precisamente ejecutarlo sobre PCs lentos). En principio se eligi´opara que fuese un PC con hardware similar al PC A, que es el PC de TxT con los recursos m´asbajos. Finalmente, a pesar de que tuviese m´asmemoria las pruebas de rendimiento indican que es a´unm´aslento que el PC A. Esto no supone un problema, ya que al quedar por debajo del PC A cumple su cometido correctamente. Con este PC me dispuse a realizar unas pruebas de rendimiento con una versi´on preliminar del benchmark para poder disponer de unos datos sobre el rendimiento de cada distribuci´on,aunque fuesen solo aproximados. Los resultados se muestran a continuaci´on.

38 Par´ametro Slackware Lubuntu Ubuntu KDE Xubuntu Debian Puppy Linux CrunchBang XFCE Linux Mint Ocupaci´ondel disco (GB) 2,3 1,5 2,5 0,72 6,7 5,3 1,8 2,1 2,4 Uso de la memoria (MB) 244 165 295 104 628 298 291 390 683 Tiempo de arranque (s) 36,94 30,20 20,80 21,21 162,14 35,72 18,73 20,72 20,87 Tiempo de arranque de 12,45 10,97 10,01 13,00 18,10 8,31 12,30 10,86 14,32 LibreOffice (s) Tiempo de apertura de 2’ 37” 2’ 15” 2’ 22” 3’ 21” 3’ 22” 3’ 05” 1’ 14” 1’ 11” 3’ 22” many_as.txt 39 Velocidad de descarga 1,03 1,16 1,13 1,11 1,11 1,13 1,12 1,12 1,00 (MB/s) Tiempo de compilaci´ondel 7’ 58” 7’ 07” 7’ 30” 7’ 41” 10’ 32” 8’ 44” 8’ 33” 8’ 27” 9’ 38” kernel (en serie) Tiempo de compilaci´ondel 8’ 56” 5’ 44” 5’ 53” 5’ 56” 10’ 18” 8’ 31” 6’ 12” 6’ 12” 8’ 29” kernel (en paralelo) Consumo energ´etico(W) 59,0 58,0 59,0 55,5 59,0 59,0 58,5 59,0 58,5 4.4. Criba de distribuciones

Una vez obtenidos los datos sobre la funcionalidad y el rendimiento de las dis- tribuciones se puede hacer una criba y escoger solo con las m´asprometedoras, para ahorrar trabajo en las pruebas y mediciones que se har´ıanm´astarde. Se determin´oque la distribuci´onideal ser´ıaaquella que tenga m´asfuncionalidades y supere unos determinados m´ınimosde rendimiento. Por lo tanto, us´ela funciona- lidad de las distribuciones para ordenar las distribuciones y los resultados de las pruebas de rendimiento para hacer la criba. Como resultado, las distribuciones De- bian, CrunchBang, Xubuntu y Slackware (variante XFCE) fueron eliminadas por ser las distribuciones con menor funcionalidad. Slackware (variante KDE) se mantuvo a pesar de tener malos resultados en las pruebas de rendimiento por ser la distribuci´on con mayor funcionalidad. De ahora en adelante, siempre que se haga referencia a Slackware se referir´aa la variante KDE, a menos que se especifique lo contrario.

4.5. Pruebas de rendimiento en PCs de TxT

4.5.1. Resultados y reporte de incidencias Una vez finalizado el benchmark, seleccionadas las distribuciones y analizados los PCs es momento de realizar las mediciones. Los resultados se encuentran en el ap´endiceF. Durante las pruebas se detectaron las siguientes incidencias:

El PC B era incapaz de arrancar desde algunos de los CDs y DVDs (en par- ticular, Linux Mint, Puppy Linux y Ubuntu). Se solucion´oinstalando dichas distribuciones desde USB.

El PC A pide configurar la BIOS y poner el reloj en hora cada vez que se enciende. Posiblemente se deba a que la pila que alimenta la BIOS est´egastada. No fue necesario cambiarla; bast´ocon configurar la BIOS y el reloj cada vez que se encend´ıa(solo la primera vez tras perder la alimentaci´on);esto no afect´oa la medici´ondel tiempo de arranque.

En la tabla de resultados se puede observar que en algunas distribuciones (Slackware y Puppy Linux) el tiempo de apertura del archivo many_as.txt con LibreOffice es bastante mayor que en las dem´as.Esto es debido a que

40 LibreOffice se queda “congelado” durante un tiempo despu´esde abrirse pe- ro antes de mostrar el archivo. Desconozco la causa, pero es obvio que esto penalizar´agravemente a esas distribuciones.

Los tiempos de arranque del PC B son m´asaltos que los del PC A, a pesar de que este es m´asnuevo y dispone de mejor hardware. En cualquier caso, no es el objetivo de este proyecto el descubrir el por qu´ede este fen´omeno.Adem´as, la diferencia no es demasiado grande como para causar un gran impacto en los resultados, as´ıque no se le dar´am´asimportancia al asunto.

LibreOffice en Slackware arranca m´asr´apidoen PCs m´asviejos. Es un dato bastante desconcertante al cual no le encuentro explicaci´on.De todos modos, Slackware es siempre el m´aslento en todos los par´ametros.

La compilaci´ondel kernel de Linux en Slackware muestra un warning, aunque esto no afecta a las mediciones del tiempo de compilaci´onni a los resultados del benchmark.

La conexi´onde red del almac´ende TxT no era la adecuada para llevar a ca- bo las mediciones. La velocidad era muy variable, llegando incluso a mostrar diferencias de cientos de KB/s en una misma distribuci´onen un mismo PC. Presumiblemente esto se debe a que hay m´asgente conectada a la red y hacen un uso intensivo de ella. Para solucionarlo simplemente se usar´anlos datos obtenidos en las pruebas preliminares (las que se hicieron con el PC A0), ya que tras la experimentaci´oncon Raspberry Pi (m´asadelante) se ha visto que la velocidad de red no var´ıademasiado de un hardware a otro y, adem´as,tam- poco var´ıanmucho entre distribuciones, con lo que no resultar´aun par´ametro decisivo.

4.5.2. Conclusiones De las pruebas realizadas con los PCs de TxT se extraen las siguientes conclu- siones:

Disco: Ubuntu, Linux Mint y Lubuntu est´ana la par. Slackware ocupa bastante m´asy Puppy Linux bastante menos. No var´ıamucho entre PCs.

Memoria: Es un poco irregular, pero a´unas´ıes f´acilde ver el requisito de cada distribuci´on.Slackware y Ubuntu son los m´asaltos, Linux Mint y Lubuntu son m´asrazonables y Puppy Linux es diminuto.

41 Tiempo de arranque del SO: Linux Mint arranca bastante m´asr´apidoen el Core 2 duo. Lubuntu y Puppy Linux tambi´enmejoran en este procesador, pero la diferencia es peque˜na.Slackware es siempre muy alto. B´asicamente todos excepto Slackware arrancan en un tiempo aceptable.

Tiempo de arranque de LibreOffice: Muy constante. Ligeramente mejores en el procesador m´asnuevo. La excepci´ones Slackware, que va mejor con el proce- sador m´asviejo.

Tiempo de apertura de many as.txt con LibreOffice: Aqu´ıes notable una gran diferencia en Slackware y Puppy Linux. Esto es debido a que LibreOffice se queda bloqueado durante alg´untiempo antes de mostrar el archivo. El bloqueo dura bastante tiempo (unos 40 segundos) y penaliza gravemente a aquellas distribuciones que lo sufran. Aunque no se ha comentado antes, esto tambi´en suced´ıaen las pruebas en el PC A0, incluso en distribuciones en las que no se produce ning´unbloqueo con los PCs de TxT. No se report´ocomo un inci- dente debido a que ocurr´ıaen muchas otras distribuciones y se vio como algo “normal”.

Velocidad de descarga: Tal y como se ha comentado en la secci´onanterior, esta prueba no se realiz´ocon ´exito.

Tiempos de compilaci´ondel kernel de Linux: Se ven fuertemente influencia- dos por el procesador, sobretodo la compilaci´onen paralelo. Es bastante cons- tante entre distribuciones (excepto Slackware, que es m´aslento).

Consumo energ´etico: Muy influenciado por el procesador (hasta 15 W de diferen- cia). Muy constante entre distribuciones. Puppy consume un par de W menos, pero poca cosa. No es un par´ametrodecisivo.

4.5.3. Interpretaci´onde los resultados Con estos resultados se debe escoger una de las distribuciones como la mejor. Se decidi´oeliminar Lubuntu, ya que casi no ofrece mejoras con respecto a Linux Mint y tiene casi un 5 % menos de funcionalidad. Adem´as,Puppy Linux solo se usar´acomo ´ultimorecurso, en caso de que el sistema no tuviese suficiente memoria para ninguna otra distribuci´on. Para determinar qu´edistribuci´ones mejor para cada PC se seguir´ala metodolog´ıa siguiente:

42 Disco y memoria Deber´ausar como m´aximo la mitad del total (en el caso del disco, exceptuando swap).

Tiempos y consumo Sea xi el valor de la distribuci´on i en el campo x, yx ¯ la media de todas las distribuciones (Slackware, Ubuntu y Linux Mint) en el campo x, se considerar´aque la distribuci´on i cumple el requisito si:

xi <=x ¯ × 110 %

Se ha a˜nadidoun 10 %, porque sino siempre habr´ıa como m´ınimo una dis- tribuci´onque no cumplir´ıacada uno de los requisitos, aunque todas tuviesen resultados muy parecidos.

Velocidad de red ´Idem al anterior, pero cambiando el sentido de la desigualdad, ya que en este campo “m´ases mejor”. Por lo tanto, sea ri la velocidad de red de la distribuci´on i, yr ¯ la media de velocidad de red de todas las distribuciones, se considerar´aque la velocidad de red de la distribuci´on i es aceptable si:

ri × 110 % >=r ¯

Se ha implementado un script que realiza estos c´alculosen base a los resultados de del benchmark. El c´odigofuente de este script se encuentra en el ap´endiceE.3.

4.6. Realizando estimaciones

En la modalidad del benchmark que realiza estimaciones sobre Ubuntu, estas son unas estimaciones muy sencillas, ya que teniendo unas mediciones reales como base se pueden aproximar las mediciones reales de las dem´asdistribuciones de manera moderadamente sencilla con solo a˜nadirun offset a las mediciones reales (la diferencia media entre las distribuciones). En cuanto a las estimaciones en base a la distribuci´on live, debido al bajo n´umero de muestras solo podemos realizar estimaciones en base a 2 variables (+1 variable de offset). Como algunas de las variables est´ancorrelacionadas con m´asde 2 variables, hay que escoger 2 de ellas. Simplemente se escoger´anlas 2 variables con la correlaci´on m´assignificativa.

43 Para calcular en qu´eproporci´onafecta cada variable se har´asimplemente un sistema de ecuaciones. Por ejemplo, para estimar el tiempo de arranque de Ubuntu se resolver´ıael siguiente sistema:

Tiempo de arranquePC A = Ancho de banda del discoPC A × x

+Ancho de banda de la memoria (tramo 4)PC A × y +z

Tiempo de arranquePC B = Ancho de banda del discoPC B × x

+Ancho de banda de la memoria (tramo 4)PC B × y +z

Tiempo de arranquePC C = Ancho de banda del discoPC C × x

+Ancho de banda de la memoria (tramo 4)PC C × y +z

De aqu´ılos valores resultantes son: x = −0, 19 y = 0, 88 z = 32, 10 De manera que se puede estimar el tiempo de arranque de un PC con la siguiente ecuaci´on: Tiempo de arranque = Ancho de banda del disco × −0, 19 +Ancho de banda de la memoria (tramo 4) × 0, 88 +32, 10

Para las dem´asvariables y distribuciones, las ecuaciones resultantes se encuentran en el ap´endiceI: Para comprobar los resultados, se realiz´ouna regresi´onlineal m´ultiple[13] con el programa Minitab [14]. Los resultados coincidieron, con lo que podemos asumir que son correctos.

4.7. Comparativa de modalidades del benchmark

Ahora que se tienen las 3 modalidades del benchmark implementadas, podemos compararlas para conseguir una proporci´onentre tiempo de ejecuci´ony precisi´on

44 ´optimas.Como las estimaciones se han hecho en base a los PCs utilizados a lo largo del trabajo, resulta obvio que todas las modalidades del benchmark devolver´an los mismos resultados para estos PCs. Para poder probar de manera efectiva las distintas modalidades, se deben ejecutar en un PC totalmente nuevo. A continuaci´on se detallan las especificaciones de este nuevo PC:

Modelo X

Procesador: AMD Athlon 64 X2 Frecuencia del procesador: 2,00 GHz N´umerode n´ucleos: 2 N´umerode threads por n´ucleo: 1 Memoria: 1 × 512 + 1 × 256 + 1 × 128 MB Disco: 80 GB Lector de DVD: S´ı(DVD-ROM)

Los resultados obtenidos por las distintas modalidades de benchmark fueron los que se muestran en la tabla 4.5.

Cuadro 4.5: Resultados de las distintas modalidades del benchmark. PC A PC B PC C PC Xa PC Xb Benchmark cl´asico Linux Mint Linux Mint Ubuntu c Linux Mint Benchmark Ubuntu Linux Mint Linux Mint Ubuntu Puppy Linux Linux Mint Benchmark live Linux Mint Linux Mint Ubuntu Puppy Linux Slackware

aUsando descartes tempranos por memoria y disco. bSin usar descartes tempranos por memoria y disco. cLa modalidad de benchmark cl´asicono realiza descartes tempranos.

Como podemos ver, en los PCs con los que se ha trabajado todas las modalidades dan el mismo resultado, como ya se hab´ıaprevisto. Cabe destacar que en los PCs A, B y X se detuvo la ejecuci´ondel benchmark du- rante los descartes por memoria y/o disco, lo que hace pensar que el uso de memoria es un fuerte discriminante en este tipo de PCs. Para comprobar la precisi´onde las estimaciones, se han volvi´oa ejecutar los distintos benchmark deshabilitando la funci´onque realiza los descartes, para as´ıpoder ver los rendimientos estimados y compararlos con los reales.

45 Linux Linux Slackware Ubuntu Linux Slackware Par´amtero Ubuntu Slackware Mint Mint a a b Mint b b Disco (GB) 2,38 2,48 6,68 2,47 c 6,81 c 2,38 c 2,47 c 6,68 c Memoria (MB) 653 451 701 473 c 726 c 680 c 500 c 753 c Tiempo de arranque 24,28 27,33 61,94 27,53 75,97 23,19 -50,72 173,41 del SO (s) Tiempo de arranque 8,934 8,468 12,012 8,340 11,654 4,823 -3,873 -116,047 de LibreOffice (s) Tiempo de apertura 172,682 78,872 130,559 175,112 207,487 82,834 1006,352 -235,406 de many_as.txt (s) Tiempo de compilaci´onen serie 296,913 292,369 334,260 313,123 389,037 211,586 13,142 -71,369 (s) Tiempo de 46 compilaci´onen 155,053 153,121 183,267 602,048 497,402 626,916 paralelo (s)

Cuadro 4.6: Comparaci´ondel rendimiento real de las distribuciones con el rendimiento estimado.

aEstimado en base a Ubuntu. bEstimado en base a la distribuci´on live. cEstimado por la funci´onde descartes tempranos. Como se puede observar, las estimaciones realizadas basadas en Ubuntu son mo- deradamente acertadas. Aunque hay excepciones (p. ej., el tiempo de apertura de many as.txt en Slackware), grosso modo los valores son aceptables y el resultado final (la elecci´onde la distribuci´on´optima)coincide con el benchmark cl´asico,con lo que esta modalidad de benchmark se puede considerar exitosa. En cambio, las estimaciones basadas en la distribuci´on live s´onclaramente err´oneas, llegando incluso a retornar tiempos negativos. Esto es debido muy posiblemente al bajo n´umerode muestras del que se dispone. A pesar de esto, la metodolog´ıapro- puesta es correcta, y se podr´ıanobtener buenas predicciones si se dispusiera de un mayor n´umerode muestras.

4.8. Experimentaci´oncon un Pocket PC

El experimento consisti´osimplemente en ejecutar el benchmark (modalidad cl´asi- ca) en una Raspberry Pi con sistema operativo Raspbian (que es b´asicamente una Debian ARM adaptada a la Raspberry Pi). Se trabaj´ocon 3 versiones de Raspbian: Base, tal cual queda el sistema tras una instalaci´onpor defecto; Mod, tras instalar todos los programas necesarios para maximizar las funcionalidades; y Potencial, igual que Mod, pero incluyendo las licencias para decodificar MPEG-2 y VC-1 (se com- pran por separado). De la versi´onpotencial solo se calcularon las funcionalidades, ya que el rendimiento seguramente no variar´a(solo son un par de codecs) y no se vio necesario comprar las licencias. Los resultados se muestran en la tabla al final de esta secci´on. Si bien los resultados no fueron mejores que los de los PCs de TxT, s´ıque fueron mejores que los del PC A0 (Procesador Pentium IV, 1,5 GiB de RAM). El principal problema es el multitasking: LibreOffice Writer funciona de manera decente, pero a la que abrimos el navegador el sistema se vuelve muy lento y resulta tedioso usarlo. Esto probablemente sea debido a la falta de paralelismo del procesador de la Raspberry Pi. Por desgracia, es muy habitual (o incluso necesario) ejecutar varios programas al mismo tiempo, por lo que no creo que la Raspberry Pi sea adecuada para sustituir un PC de escritorio en tareas ofim´aticas. Tambi´ense puede observar que el tiempo de compilaci´ondel kernel de Linux es muy alto, unas 10 veces m´asalto que en los PCs de TxT, de lo cual se deduce que estas m´aquinasno son adecuadas para cargas de trabajo intensas. No obstante, si miramos el consumo energ´eticovemos que es aproximadamente 20 veces menor que el de un PC de sobremesa, con lo cual el trabajo realizado por unidad de potencia es el doble que el de un PC. Es m´as,la Raspberry Pi disipa tan poca energ´ıaque ni siquiera necesita refrigeraci´on(no tiene ventiladores ni disipadores, y la caja solo

47 tiene respiraci´onen la base). Con esto, la Raspberry Pi se convierte en la elecci´on perfecta para sistemas que requieran estar encendidas de continuo pero cuya carga de trabajo sea baja, como por ejemplo un servidor domestico o un sustituto de un sistema integrado (embedded). No obstante, la Raspberry Pi tiene una buena GPU (capaz incluso de reproducir v´ıdeode alta resoluci´on),con lo cual podr´ıasoportar cargas intensas siempre y cuando sean cargas de GPU, no de CPU. Esto la hace ideal como media center o reproductor multimedia. Tambi´ense podr´ıanrealizar tareas con alto coste de c´omputousando la GPU en lugar de la CPU, pero esto probablemente requerir´amodificar los programas para que funcionen con la GPU de la Raspberry Pi.

Base Par´amtero Base Mod (Pre) Disco (GB) 1,5 1,51 2,53 Memoria (MB) 112 116 115 Tiempo de arranque del SO (s) 37,81 35,65 52,54 Tiempo de arranque de 13,29 16,468 21,945 LibreOffice (s) Tiempo de apertura de 138 145,389 150,274 many_as.txt (s) Velocidad de red (MB/s) 1,13 Tiempo de compilaci´onen serie 2921 2899,735 2864,198 (s) Tiempo de compilaci´onen 2934 paralelo (s) Consumo energ´etico (W) 3,5 3,5 3,5

Cuadro 4.7: La columna “Base (Pre)” corresponde a las mediciones realizadas con la versi´onpreliminar del benchmark. Las columnas “Base” y “Mod” est´anrealizadas con la versi´onfinal del benchmark (primera modalidad), sin prueba de red. Adem´as, en estas columnas no se realiz´ola prueba de medici´onde compilaci´ondel kernel con 4 threads, ya que se ha visto que, al tener solo 1 CPU y un overhead despreciable, no supone diferencia con respecto a la medici´onde compilaci´ondel kernel con 1 thread. Las columnas “Base (Pre)” y “Base” corresponden a la distribuci´onRaspbian por defecto. La columna “Mod” corresponde a la misma distribuci´oncon paquetes adicionales instalados.

48 Cap´ıtulo5

Conclusiones

5.1. Conclusiones

En la actividad en la que yo particip´e(hace m´asde 1 a˜no)se instalaba Ubuntu en todos los PCs, independientemente de sus especificaciones. Actualmente la directiva de TxT a la hora de elegir una distribuci´ones usar Ubuntu si el PC tiene m´asde 1 GiB de memoria y Lubuntu en caso contrario. Con esta directiva, se elegir´ıa Lubuntu para los PCs A y B y Ubuntu para el C, aunque he encontrado PCs con Linux Mint instalado. Seg´un mi benchmark, la distribuci´onideal para cada PC ser´ıaLinux Mint para el A y el B y Ubuntu para el C. Es obvio que durante el ´ultimoa˜noen TxT se han dado cuenta de la importancia de escoger una distribuci´onadecuada para cada PC y han optado por una distribuci´onm´asligera para los PCs menos potentes. No obstante, personalmente creo que han dejado un poco de lado la funcionalidad en favor del rendimiento al escoger Lubuntu frente a Linux Mint. Adem´as,la separaci´on entre ‘m´asde un giga’ y ‘un giga o menos’ no es lo suficientemente fina. En una ocasi´onse encontraron con un PC con 512 MiB de memoria y quisieron instalarle Lubuntu, siguiendo su directiva. No obstante, Lubuntu ocupa hasta 480 MiB en reposo, con lo cual el resultado habr´ıasido nefasto. Una distribuci´oncomo Puppy Linux (∼ 180 MiB) habr´ıasido m´asacertada. No obstante cabe destacar que han acertado al escoger la cantidad de memoria como par´ametrodiscriminante. En las pruebas que he realizado he podido ver que en la mayor´ıa de los casos la ejecuci´ondel benchmark acababa con los descartes realizados a ra´ızde la cantidad de memoria.

49 En resumen, la pol´ıticade TxT en cuanto a qu´edistribuci´onelegir ha mejorado con respecto a la actividad que origin´omi motivaci´onpara realizar este trabajo, pero a´unquedan detalles por pulir. Conf´ıoen que este trabajo ayude a TxT y a sus usuarios a conseguir una mejor experiencia. En cuanto a la Raspberry Pi, su debilidad es la CPU y su fortaleza reside en la GPU. Me parece obvio que los creadores han querido enfocar el aparato m´ashacia la reproducci´onmultimedia que al escritorio. Por suerte, la Raspberry Pi no es el ´unico Pocket PC del mercado, y hay alternativas que quiz´ascumplan mejor como sustituto de un PC de sobremesa. Cubieboard [15], por ejemplo, parece ser m´asadecuada para esta tarea: tiene un procesador de 1 GHz (frente a los 700 MHz de la Raspberry Pi), 1 GiB de memoria RAM (frente a los 512 MiB de la Raspberry Pi) y soporta m´as distribuciones de Linux (Debian, Fedora, Ubuntu, e incluso Android) por un precio muy similar. El procesador sigue siendo de un solo core y thread. Existen otras alternativas con procesadores multicore [16], pero tienen un precio m´aselevado.

5.2. Trabajo futuro

5.2.1. Comportamientos an´omalos Durante la realizaci´onde este trabajo me he encontrado con comportamientos que desaf´ıanla l´ogica. Los ejemplos m´asclaros son el hecho de que Slackware pa- rece funcionar mejor en PCs con menos recursos, a pesar de ser la distribuci´onque m´asrecursos usa y que LibreOffice se quede congelado durante un tiempo al ini- ciar en Slackware (la distribuci´onm´aspesada), pero tambi´enen Puppy Linux (la distribuci´onm´asligera) y no en las dem´as. Entender el por qu´ede estos fen´omenospodr´ıaayudar a realizar estimaciones m´asprecisas y, en general, ayudar en la finalidad de este trabajo, que es seleccionar la distribuci´onm´asacertada para cada PC.

5.2.2. A˜nadiratributos a medir al benchmark Siempre cabe la posibilidad de extender el benchmark a˜nadiendopar´ametros, como podr´ıanser el tiempo de abrir una p´aginaweb (para profundizar m´asen la gesti´onde la red) o el framerate medio al reproducir un v´ıdeoen alta resoluci´on (para profundizar en el aspecto de computaci´ongr´afica).Esto a si vez podr´ıa llevar a hilar m´asfino en el an´alisisde aplicaciones y funcionalidades. Por ejemplo, teniendo en cuenta el entorno de escritorio y/o el gestor de ventanas expl´ıcitamente.

50 5.2.3. Actualizar y expandir la lista de distribuciones Durante este trabajo se ha tratado con distribuciones desfasadas, principalmente porque no estaba seguro de si los PCs de TxT soportar´ıanel arranque desde DVD. Ahora que he visto que s´ı lo soportan (la mayor´ıa, aunque hay outliers que a´un leen solo CDs) se podr´ıaaprovechar para probar con versiones m´asactuales de las distribuciones escogidas o incluso con distribuciones nuevas que no se hayan tratado en este trabajo.

5.2.4. Mejorar la estad´ıstica Debido a las pocas muestras, la estad´ısticaen la que se basan las estimaciones de la distribuci´on live no son muy s´olidas.Esto podr´ıasolucionarse tomando m´as muestras de m´astipos de PCs (nuevos PCs llegan a TxT continuamente). La distri- buci´on live y los scripts ya est´anhechos, a modo de prueba de concepto, ahora solo ser´ıacuesti´onde ampliar la poblaci´onde muestras con nuevos PCs. Adem´as,las estimaciones basadas en los resultados de Ubuntu son muy na¨ıve y, aunque funcionan bien en este conjunto de PCs, pueden no ser precisas en PCs con los que no se haya tratado durante este trabajo.

5.2.5. Probar distintos Pocket PC Si bien la Raspberry Pi parece no ser la alternativa m´asadecuada a un PC de sobremesa, existen otros modelos de Pocket PC m´asdirigidos a estas funciones que podr´ıaquedar en mejor lugar. Como ya se ha demostrado, el benchmark puede funcionar perfectamente en dispositivos de este tipo, as´ıque no ser´ıadif´ıcilampliar el trabajo por esta rama.

51 Ap´endices

52 Ap´endiceA

Resultados de la encuesta

Las columnas “Votos (abs)” y “Votos ( %)” indican el n´umerode votos que ha obtenido la respuesta y el porcentaje de encuestados que la seleccionaron respecti- vamente. La columna “Valor normalizado” indica la proporci´onde votos que corresponden a esta respuesta respecto a los votos totales (de todas las respuestas). Las funcionalidades “soporte para HD-DVD” y “soporte para Blu-Ray” ser´an ignoradas, ya que los PCs con los que se tratar´ano disponen del hardware necesario.

Votos Votos Valor Funcionalidad (abs) ( %) normalizado Compatible con documentos de 77 87,50 % 3,56 % Office 2010 (.docx) Compatible con documentos de 47 53,41 % 2,17 % LibreOffice y OpenOffice (.swx) Posibilidad de a˜nadir 45 51,14 % 2,08 % comentarios a los documentos Crear gr´aficosy dibujos sin necesidad de una herramienta 54 61,36 % 2,50 % externa Procesador de textos Integraci´oncon una suite 18 20,45 % 0,83 % ofim´aticacompleta Versi´onpara Mac OS X 14 15,91 % 0,65 %

53 Votos Votos Valor Funcionalidad (abs) ( %) normalizado Corrector ortogr´afico 36 40,91 % 1,67 % Imprimir selecci´on(no toda la 61 69,32 % 2,82 % p´agina) Alto n´umerode celdas (m´asde 1000 columnas por p´agina,56000 16 18,18 % 0,74 % filas por p´agina,256 p´aginaspor

Hoja de c´alculo libro) Immobilizar paneles (cabeceras 46 52,27 % 2,13 % siempre visibles) Importar / exportar tablas 21 23,86 % 0,97 % LaTeX Interfaz en catal´an 45 51,14 % 2,08 % Soporte para escritura de 8 9,09 % 0,37 %

Locali. derecha a izquierda Filtro anti-phishing (estafa cibern´etica)sin necesidad de 52 59,09 % 2,41 % complementos Lector de feeds RSS sin 10 11,36 % 0,46 % necesidad de complementos Vista previa de documentos de 64 72,73 % 2,96 % texto (pdf, doc, xls, odt, ods) Cliente de correo Bloqueo de pop-ups sin 73 82,95 % 3,38 % necesidad de complementos Bloqueo de publicidad (AdBlock) 75 85,23 % 3,47 % sin necesidad de complementos

Navegador Control por voz 9 10,23 % 0,42 % Gestos de rat´on 11 12,50 % 0,51 % Conversi´ontexto-a-voz 10 11,36 % 0,46 % (Text-to-speech) Incorpora su propio plugin Flash 47 53,41 % 2,17 % Lector de feeds RSS incorporado sin necesidad de complementos 16 18,18 % 0,74 % ni herramientas externas Gestor de contrase˜nas(recordar 69 78,41 % 3,19 % contrase˜nas,contrase˜na maestra)

54 Votos Votos Valor Funcionalidad (abs) ( %) normalizado Yahoo! Mail 6 6,82 % 0,28 % Windows Live messenger 22 25,00 % 1,02 % XMPP (Google talk, Facebook 63 71,59 % 2,92 % chat) IRC 17 19,32 % 0,79 % Skype 60 68,18 % 2,78 %

Protocolos MI MySpaceIM 0 0,00 % 0,00 % Emoticonos gr´aficos 51 57,95 % 2,36 % Emoticonos gr´aficosdefinidos 27 30,68 % 1,25 % por el usuario Chat de voz 64 72,73 % 2,96 % Chat de v´ıdeo 58 65,91 % 2,68 % Cliente MI Escritura a mano 24 27,27 % 1,11 % Soporte multi-cuenta 54 61,36 % 2,50 % Corrector ortogr´afico 35 39,77 % 1,62 % Soporte para subt´ıtulos 76 86,36 % 3,52 % Control de imagen (color, 48 54,55 % 2,22 % contraste, brillo) Control de sonido (tono) 54 61,36 % 2,50 % Resincronizaci´onde audio 53 60,23 % 2,45 % Resincronizaci´onde subt´ıtulos 56 63,64 % 2,59 % Soporte para VCD 26 29,55 % 1,20 % Soporte para SVCD 24 27,27 % 1,11 % Soporte para DVD 62 70,45 % 2,87 % Reproductor de v´ıdeo Soporte para HD-DVD 42 47,73 % Soporte para Blu-Ray 48 54,55 % Miniaturas (Thumbnails) 56 63,64 % 2,59 % Pesta˜nas 63 71,59 % 2,92 % Doble panel 32 36,36 % 1,48 % Previsualizaciones 59 67,05 % 2,73 % Navegar por archivos 57 64,77 % 2,64 % Gestor de ar. comprimidos Total 88 100,00 % 100,00 %

55 Ap´endiceB

Programas por distribuci´on

El navegador Iceweasel ser´atratado como Firefox, debido a que es pr´acticamente el mismo (el cambio de nombre es debido a un conflicto de licencias). El mismo tratamiento se dar´aa Icedove / Thunderbird.

Bodhi Linux CrunchBang Debian Linux Mint Procesador de Ninguno Abiword Ninguno Abiword textos Hojas de Ninguno Gnumeric Ninguno Gnumeric c´alculo Cliente de Ninguno Ninguno Evolution Thunderbird correo Epiphany, Navegador Midori Iceweasel Firefox Iceweasel Cliente de MI Ninguno Ninguno Ninguno Pidgin Reproductor MPlayer, Ninguno VLC Totem de v´ıdeo VLC Gestor de Enlightenment Thunar Nautilus PCManFM archivos File Manager Interfaz en Parcial Parcial S´ı Parcial catal´an Soporte para escritura de No S´ı S´ı S´ı derecha a izquierda

56 Slackware Puppy Linux KDE XFCE Procesador de Abiword Calligra Words Ninguno textos Hojas de Gnumeric Calligra Sheets Ninguno c´alculo KMail, Cliente de SeaMonkey, SeaMonkey SeaMonkey, correo Thunderbird Thunderbird Firefox, Firefox, Navegador SeaMonkey Konkeror, SeaMonkey SeaMonkey Cliente de MI Ayttm Kopete, Pidgin Pidgin Dragon Player, Reproductor MPlayer, MPlayer KPlayer, de v´ıdeo xine MPlayer, xine Gestor de Dolphin, ROX Filer Thunar archivos Konkeror Interfaz en Parcial S´ı S´ı catal´an Soporte para escritura de No S´ı S´ı derecha a izquierda

57 Lubuntu Xubuntu Ubuntu Procesador de LibreOffice Abiword Abiword textos Writer Hojas de LibreOffice Gnumeric Ninguno c´alculo Calc Cliente de Sylpheed Thunderbird Thunderbird correo Navegador Chromium Firefox Firefox Cliente de MI Pidgin Pidgin Empathy Reproductor MPlayer Parole Totem de v´ıdeo Gestor de PCManFM Thunar Nautilus archivos Interfaz en S´ı S´ı S´ı catal´an Soporte para escritura de S´ı S´ı S´ı derecha a izquierda

58 Ap´endiceC

Funcionalidades por programa

Cuadro C.1: Procesador de textos Calligra LibreOffice Abiword Words Writer Compatible con documentos .docx No S´ı S´ı (Office 2010) Compatible con documentos .swx No S´ı S´ı (LibreOffice, OpenOffice) Posibilidad de a˜nadir comentarios a los S´ı S´ı S´ı documentos Crear gr´aficosy dibujos sin necesidad de una No No S´ı herramienta externa Integraci´oncon una suite ofim´atica No S´ı S´ı completa Versi´onpara Mac OS X S´ı S´ı S´ı

59 Cuadro C.2: Hoja de c´alculos Calligra LibreOffice Gnumeric Sheets Calc Corrector ortogr´afico S´ı No S´ı Imprimir selecci´on S´ı S´ı No Alto n´umero de celdas No S´ı No Inmobilizar paneles No S´ı No Importar / exportar No S´ı S´ı tablas LaTeX

Cuadro C.3: Cliente de correo KMail SeaMonkey Sylpheed Thunderbird Filtro S´ı No No S´ı anti-phishing Lector de feeds RSS sin necesidad No S´ı No S´ı de complementos Vista previa de No No No No documentos

Cuadro C.4: Navegador Chromium Dillo Epiphany Firefox Konkeror Midori NetSurf SeaMonkey Bloqueo popups S´ı No No S´ı S´ı No S´ı S´ı Bloqueo publicidad No No No S´ı S´ı S´ı S´ı S´ı Control por voz No No No S´ı No No No No Gestos de rat´on No No No No S´ı S´ı No No Conversi´ontexto-a-voz (Text-to-speech) No No No No No No No No Su propia versi´onde Flash S´ı No No No No No No No Lector de feeds RSS incorporado No No No S´ı S´ı No No S´ı Gestor de contrase˜nas S´ı No S´ı S´ı S´ı No No S´ı

60 Cuadro C.5: Protocolos MI Ayttm Empathy Kopete Pidgin Yahoo! Mail S´ı No S´ı S´ı Windows Live S´ı S´ı S´ı S´ı Messenger XMPP S´ı S´ı S´ı S´ı IRC S´ı S´ı S´ı S´ı Skype No No No No MySpace IM No No No S´ı

Cuadro C.6: Cliente MI Ayttm Empathy Pidgin Emoticonos gr´aficos S´ı S´ı S´ı Emoticonos gr´aficos S´ı S´ı S´ı definidos por el usuario Chat de voz No S´ı S´ı Chat de v´ıdeo No S´ı S´ı Escritura a mano No No No Soporte multi-cuenta S´ı S´ı S´ı Corrector ortogr´afico S´ı S´ı S´ı

61 Cuadro C.7: Reproductor de v´ıdeo Dragon player KPlayer MPlayer omxplayer Parole Totem VLC XBMC Xine Soporte subt´ıtulos S´ı S´ı S´ı No S´ı S´ı S´ı S´ı S´ı Control de imagen No S´ı S´ı No No S´ı S´ı S´ı S´ı Control de sonido No S´ı S´ı No No No S´ı S´ı No Re-sincronizaci´onde audio No S´ı S´ı No No No S´ı S´ı S´ı Re-sincronizaci´onde v´ıdeo No S´ı S´ı No No No S´ı S´ı S´ı Soporte para VCD S´ı S´ı S´ı No S´ı S´ı S´ı S´ı S´ı Soporte para SVCD S´ı S´ı S´ı No S´ı S´ı S´ı S´ı S´ı Soporte DVD S´ı S´ı S´ı No S´ı S´ı S´ı S´ı S´ı Soporte para HD-DVD No No No No No No No S´ı No Soporte Blu-ray No No No No No No No S´ı No

Cuadro C.8: Gestor de archivos EFM Konkeror Nautilus PCmanFM ROX Filer Thunar Miniaturas S´ı S´ı S´ı S´ı S´ı S´ı Pesta˜nas No S´ı S´ı S´ı No No Doble panel S´ı S´ı S´ı No No No Previsualizaciones No S´ı S´ı No S´ı No Navegar por archivos comprimidos No S´ı No No No No

62 Ap´endiceD

Funcionalidades por distribuci´on

El protocolo de mensajer´ıainstant´anea“MySpace IM” se ha descartado, ya que no recibi´oning´unvoto y resulta irrelevante. Las funcionalidades “compatible con HD-DVD” y “compatible con Blu-ray” se han eliminado debido a que los PCs con los que se tratar´ano disponen del hardware necesario. La fila “Total (abs)” indica el total de votos para las funcionalidades con m´asdel 50 % de votos. La fila “Total ( %)” indica el porcentaje de funcionalidades con m´asdel 50 % de votos que cumple. La fila “Total normalizado” es una ponderaci´onteniendo en cuenta todas las funcionalidades y su valor normalizado (v´easeel ap´endiceA).

63 Leyenda: 1 = S´ı;0 = No; 0,5 = Parcial

Funcionalidad Slackware Lubuntu Ubuntu KDE Xubuntu Debian Bodhi Linux Puppy Linux CrunchBang XFCE Linux Mint Compatible con 0 0 0 0 0 1 0 0 0 1 documentos .docx Compatible con 0 0 0 0 0 1 0 0 0 1 documentos .swx Posibilidad de a˜nadir comentarios a los 0 1 0 1 1 1 0 1 1 1 documentos Crear gr´aficosy 0 0 0 0 0 0 0 0 0 1 dibujos Procesador de textos Integraci´oncon una suite ofim´atica 0 0 0 0 0 1 0 0 0 1 completa Versi´onpara Mac OS 0 1 0 1 1 1 0 1 1 1 X Corrector ortogr´afico 0 0 0 0 0 1 0 0 0 1 Imprimir selecci´on 0 1 0 1 1 1 0 1 0 0 Alto n´umerode 0 1 0 1 1 0 0 1 0 0 celdas Immobilizar paneles 0 1 0 1 1 0 0 1 0 0 Importar / exportar 0 1 0 1 1 0 0 1 0 1 Hoja de c´alculo tablas LaTeX Interfaz en catal´an 0,5 0,5 1 0,5 0,5 1 1 1 1 1 Soporte para escritura de derecha a 0 1 1 1 0 1 1 1 1 1

Localiza. izquierda

64 Funcionalidad Slackware Lubuntu Ubuntu KDE Xubuntu Debian Bodhi Linux Puppy Linux CrunchBang XFCE Linux Mint Filtro anti-phishing 0 0 1 1 0 1 1 0 1 1 Lector de feeds RSS 0 0 1 1 1 1 1 0 1 1 Vista previa de

Correo 0 0 0 0 0 0 0 0 0 0 documentos de texto Bloqueo de pop-ups 0 1 1 1 1 1 1 1 1 1 Bloqueo de publicidad 1 1 1 1 1 1 1 0 1 1 Control por voz 0 1 1 1 0 1 1 0 1 1 Gestos de rat´on 1 0 0 0 0 1 0 0 0 0 Conversi´on Navegador 0 0 0 0 0 0 0 0 0 0 texto-a-voz Incorpora su propio 0 0 0 0 0 0 0 1 0 0 plugin Flash Lector de feeds RSS 0 1 1 1 1 1 1 0 1 1 Gestor de contrase˜nas 0 1 1 1 1 1 1 1 1 1 Yahoo! Mail 0 0 0 1 1 0 0 1 1 0 Windows Live 0 0 0 1 1 1 1 1 1 1 messenger XMPP (Google talk, 0 0 0 1 1 1 1 1 1 1 Facebook chat) IRC 0 0 0 1 1 1 1 1 1 1 Protocolos MI Skype 0 0 0 0 0 0 0 0 0 0 Emoticonos gr´aficos 0 0 0 1 1 1 1 1 1 1 Emoticonos gr´aficos definidos por el 0 0 0 1 1 1 1 1 1 1 usuario Chat de voz 0 0 0 1 0 1 1 1 1 1 Cliente MI Chat de v´ıdeo 0 0 0 1 0 1 1 1 1 1 Escritura a mano 0 0 0 0 0 0 0 0 0 0 Soporte multi-cuenta 0 0 0 1 1 1 1 1 1 1 Corrector ortogr´afico 0 0 0 1 1 1 1 1 1 1

65 Funcionalidad Slackware Lubuntu Ubuntu KDE Xubuntu Debian Bodhi Linux Puppy Linux CrunchBang XFCE Linux Mint Soporte para 0 1 1 1 1 1 1 1 1 1 subt´ıtulos Control de imagen 0 1 1 1 1 1 1 1 0 1 Control de sonido 0 1 0 1 1 1 0 1 0 0 (tono) Resincronizaci´onde 0 1 0 1 1 1 1 1 0 0 audio Resincronizaci´onde 0 1 0 1 1 1 1 1 0 0 subt´ıtulos Reproductor de v´ıdeo Soporte para VCD 0 1 1 1 1 1 1 1 1 1 Soporte para SVCD 0 1 1 1 1 1 1 1 1 1 Soporte para DVD 0 1 1 1 1 1 1 1 1 1 Miniaturas 1 1 1 1 1 1 1 1 1 1 (Thumbnails) Pesta˜nas 0 0 1 1 0 1 0 1 0 1 Doble panel 1 0 1 0 0 1 0 0 0 1 Previsualizaciones 0 0 1 0 1 1 0 0 0 1

Gestor de ar. Navegar por archivos 0 0 0 0 0 1 0 0 0 0 comprimidos Total mayoritarios 2,5 12,5 10 19,5 16,5 23 15 19 13 19 (abs) Total mayoritarios Total 8,33 41,67 33,33 65,00 55,00 76,67 50,00 63,33 43,33 63,33 ( %) Total normalizado 9,49 43,93 38,77 70,14 60,72 83,49 55,77 65,67 51,04 72,72 ( %)

66 Ap´endiceE

C´odigofuente del benchmark (versi´on1)

E.1. run.sh

Este archivo contiene el orden en el que deben medirse los par´ametrosy otras instrucciones necesarias (comprobaciones, pausas, reinicios, etc.). #!/bin/bash

#In order to measure the boot time, this script must be executed at boot. cd ~/benchmark#files must be located here params=${*:1} if hash lsb_release 2> /dev/null; then output_file=‘lsb_release-is‘ else output_file="unknown" fi output_file="results-$output_file.txt" if[[$params==*-h*]]; then echo"Usage:$0[PARAMETERS]"

67 echo"Valid parameters:" echo"-h: Show this message." echo"-r: Reboot automatically(may require permissions)." echo"-n: Do not measure network speed." echo"-p: Do not measure power consumption(this measurement requires user input)." echo"-i: Install dependencies automatically( uses commands.sh; may require permissions)." echo"Results will be written to$output_file." exit1 fi

[[$params==*-n*]]&&n=true; [[$params==*-p*]]&&p=true; [[$params==*-i*]]&&i=true; function reboot{ if![[$params==*-r*]]; then read-p"Ready to reboot(y/n)?"-n 1-r if[[$REPLY=~ ^[Yy]$]] then /sbin/reboot|| echo"Done. Please, reboot the system now." fi exit1 fi /sbin/reboot|| echo"Done. Please, reboot the system now." } if[!-f state]; then echo1> state fi state=‘cat state‘ function save_state{ if[["$1"==""]]; then

68 state=‘expr$state+1‘ else state=$1 fi echo$state> state } function check_install{ if[$i]; then source ./install_cmd.sh if[["$1"=="/usr/bin/time"]]; then install_cmd time else install_cmd$1 fi fi while! hash$1 2> /dev/null; do read-p"Please, install$1 now and press Enter when finished." done } if[$state-le 4]; then echo"Phase$state of4" echo"------" fi case$state in 1 ) check_install"/usr/bin/time" echo"There will now bea 60 second pause." if![$p]; then echo"User input will be needed at the end of the pause."#in order to measure power consumption fi sleep 60

69 ./benchmark.sh MEMORY DISK>$output_file # memory_disk_discard check_install bc if![$p]; then ./benchmark.sh POWER>>$output_file fi check_install make check_install gcc echo"Compiling the Linux kernel. This may takea while." ./benchmark.sh KERNEL1>>$output_file save_state reboot ;; 2 ) ./benchmark.sh BOOT>>$output_file echo"There will now bea 60 second pause." sleep 60 echo"Compiling the Linux kernel. This may takea while." ./benchmark.sh KERNEL4>>$output_file check_install libreoffice #execute libreoffice for the first time, just for good measure. lowriter& sleep 20&& killall soffice.bin if![$n]; then while ! ping-q-c 1 example.org> /dev/null; do read-p"Please, connect to the Internet now and press Enter when finished." done echo"Downloadinga big file. This may takea while." ./benchmark.sh NETWORK>>$output_file fi save_state reboot

70 ;; 3) echo"There will now bea 60 second pause." sleep 60 ./benchmark.sh LO_STARTUP>>$output_file save_state reboot ;; 4) echo"There will now bea 60 second pause." sleep 60 echo"Openinga big file. This may takea while." ./benchmark.sh LO_FILE_STARTUP>>$output_file echo"Benchmark finished." save_state # estimate #./statistics.sh ;; esac

71 E.2. benchmark.sh

Este archivo contiene el c´odigocapaz de medir los par´ametrospor separado. #!/bin/bash

#tests: #BOOT: boot time #DISK: disk usage #MEMORY: memory usage #NETWORK: network speed #KERNEL1: time to compilea Linux kernel, using1 thread #KERNEL4: time to compilaa Linux kernel, using4 threads #LO_STARTUP: time to start LibreOffice #LO_FILE_STARTUP: time to opena(big) file in LibreOffice tests=${*:1} cd ~/benchmark

#configuration #file to download in the network test URL="http://speedtest.wdc01.softlayer.com/downloads/ test500.zip" #file to use in the lo_file test perl-e ’print"a"x1000000; print"\n"’> many_as.txt LO_FILE="many_as.txt"

#auxiliary functions function round{ rounded=‘echo"($1+0.5)/1"| bc‘ echo$rounded } function lobench{ delay=1 rm-rf /tmp/*.tmp lowriter${*:1}>/dev/null 2>&1& while["$pid"==""]; do pid=‘pidof soffice.bin‘

72 done iddle="0" while["$iddle"=="0"]; do cpu_usage=‘top-bn 2-p$pid-d$delay| tail-n 2 |grep-v M‘ cpu_usage=‘echo$cpu_usage| cut-f9-d’ ’| seds /,/./‘ iddle=‘echo"$cpu_usage==0"| bc‘ done kill$pid } function get_time{ cmd=${*:1} time=‘{ time$cmd>/dev/null 2>&1;}2>&1| grep real | cut-f2| sed s/h/*3600+/| sed s/m/*60+/| sed s/s//| bc‘ echo$time } function compile{ THREADS=$1 if["$THREADS"==""]; then THREADS=1 fi cd$KERNEL_FOLDER> /dev/null make alldefconfig-j$THREADS> /dev/null KERNEL_TIME=‘get_time make bzImage-j$THREADS‘ make distclean-j$THREADS> /dev/null cd-> /dev/null echoKERNEL$THREADS$KERNEL_TIME seconds }

#startup time #Assuming the script is run at startup. You should remove any possible delays at startup(grub timeout, login screens...). if[[$tests==*BOOT*]]; then

73 BOOT_TIME=‘cat /proc/uptime| awk’{print$1}’‘ echoBOOT$BOOT_TIME seconds fi

#memory if[[$tests==*MEMORY*]]; then MEMORY=‘free-m|sed-n 2p| awk’{print$3}’‘ echoMEMORY$MEMORYMB fi

#disk if[[$tests==*DISK*]];then DISK=‘df| grep rootfs‘ if[["$DISK"!=""]]; then #Raspberry Pi DISK=‘df-m| grep rootfs| awk’{print$3}’‘ DISK=$(echo"scale=2;${DISK}/ 1024"| bc) else #DISK=‘df-m| sed-n2p| awk’{print$3}’‘ DISK=‘df-m| grep sda| awk’{print$3}’‘ DISK=‘echo$DISK| sed ’s/ /+/g’| bc‘ DISK=$(echo"scale=2;(${DISK}- 71)/ 1024"| bc) # 71 MiB is the size of the benchmark files fi echoDISK$DISKGB fi

#network if[[$tests==*NETWORK*]]; then NETWORK=‘wget-O /dev/null$URL 2>&1| grep ’\([0-9]\+ [KM]B/s\)’| cut-f3,4-d ’’| sed ’s/(//’| sed ’s/) //’| sed ’s/B\/s//’| sed ’s/K/*1024/’| sed’ s/M/*1024*1024/’‘ NETWORK=‘echo$NETWORK / 1024| bc‘ echoNETWORK$NETWORK KB/s fi

#kernel compilation

74 if[[$tests==*KERNEL*]]; then KERNEL_FILE=‘ls linux-[0-9]*.[0-9]*.[0-9]*.tar.xz‘ KERNEL_FOLDER=‘echo$KERNEL_FILE| sed ’s/.tar.xz//’‘ tar-xf$KERNEL_FILE--xz fi

#compile using1 thread if[[$tests==*KERNEL1*]]; then compile fi

#compile using4 threads if[[$tests==*KERNEL4*]]; then compile 4 fi if[[$tests==*KERNEL*]]; then rm-rf$KERNEL_FOLDER fi

#libreoffice if[[$tests==*LO_STARTUP*]]; then LO_TIME=‘get_time lobench‘ echoLO_STARTUP$LO_TIME seconds fi if[[$tests==*LO_FILE_STARTUP*]]; then LO_FILE_TIME=‘get_time lobench$LO_FILE‘ echoLO_FILE_STARTUP$LO_FILE_TIME seconds fi

#power if[[$tests==*POWER*]]; then echo-n"Please, enter the power consumption of the system(in Watts):"

while[["$power"==""]]; do read power

75 power=‘echo$power| sed s/,/./‘ if![[$power=~ ^[0-9]+([.][0-9]+)?$]]; then echo Please, enter only a number. power="" fi done echoPOWER$power W fi

76 E.3. statistics.sh

Este script toma los archivos resultantes de correr el benchmark en las distin- tas distribuciones, calcula cu´antos requisitos cumple cada distribuci´ony ordena las distribuciones en orden de adecuaci´on. #!/bin/bash x=$0 [[${*:1}==*-n*]]&&n=true [[${*:1}==*-p*]]&&p=true while(("$#")); do if[["$1"=="-h"]]; then echo"Usage:" echo"$x[-dTOTAL_DISK][-mTOTAL_MEMORY][-n ][-p]" echo"$x-h" echo"" echo"-dTOTAL_DISK: Specify the size of the disk (in GiB, not counting swap)." echo"-mTOTAL_MEMORY: Specify the size of the memory(in MiB)." echo"-n: Ignore network speed tests." echo"-p: Ignore power consumption tests." echo"-h: Show this message." exit1 elif[["$1"=="-d"]]; then shift total_disk=‘echo$1| sed s/,/./g‘ if![[$total_disk=~ ^[0-9]+([.][0-9]+)?$]]; then echo"Disk size must bea number." exit1 fi elif[["$1"=="-m"]]; then shift total_memory=‘echo$1| sed s/,/./g‘

77 if![[$total_memory=~ ^[0-9]+([.][0-9]+)?$]]; then echo"Memory size must bea number." exit1 fi fi shift done filenames=(results-*.txt) n=${#filenames[@]} for filename in${filenames[@]}; do memory+=(‘grep MEMORY$filename| cut-d’ ’-f2‘) disk+=(‘grep DISK$filename| cut-d’ ’-f2‘) boot_time+=(‘grep BOOT$filename| cut-d’ ’-f2‘) lo_startup+=(‘grep LO_STARTUP$filename| cut-d’ ’- f2‘) lo_file_startup+=(‘grep LO_FILE_STARTUP$filename| cut-d’ ’-f2‘) kernel1+=(‘grep KERNEL1$filename| cut-d’ ’-f2‘) kernel4+=(‘grep KERNEL4$filename| cut-d’ ’-f2‘) network+=(‘grep POWER$filename| cut-d’ ’-f2‘) if![$n]; then network+=(‘grep POWER$filename| cut-d’ ’-f2‘) fi if![$p]; then power+=(‘grep POWER$filename| cut-d’ ’-f2‘) fi done avg_boot_time=‘echo"scale=2;(0$(printf"+ %s""${ boot_time[@]}"))/$n"| bc‘ avg_lo_startup=‘echo"scale=3;(0$(printf"+ %s""${ lo_startup[@]}"))/$n"| bc‘ avg_lo_file_startup=‘echo"scale=3;(0$(printf"+ %s""${ lo_file_startup[@]}"))/$n"| bc‘

78 avg_kernel1=‘echo"scale=3;(0$(printf"+ %s""${kernel1[@ ]}"))/$n"| bc‘ avg_kernel4=‘echo"scale=3;(0$(printf"+ %s""${kernel4[@ ]}"))/$n"| bc‘ if![$n]; then avg_network=‘echo"scale=3;(0$(printf"+ %s""${ network[@]}"))/$n"| bc‘ fi if![$p]; then avg_power=‘echo"scale=1;(0$(printf"+ %s""${power[@ ]}"))/$n"| bc‘ fi

[["$total_disk"==""]]&& total_disk=‘df-m| grep sda | awk’BEGIN{ORS="+";}{print$2}’‘&& total_disk=‘ echo"scale=2;($total_disk 0)/1024"| bc‘ [["$total_memory"==""]]&& total_memory=‘free-m| sed -n 2p| awk’{print$2}’‘ for((i=0;i<$n;++i)); do filenames[$i]=‘echo${filenames[$i]}| sed s/results- //| sed s/.txt//‘ done results=() for((i=0;i<$n;++i )); do fails[$i]=‘echo"${disk[$i]}>$total_disk/2"| bc‘ fails[$i]=‘expr${fails[$i]}+$(echo"${memory[$i]}> $total_memory/2"| bc)‘

fails[$i]=‘expr${fails[$i]}+$(echo"${boot_time[$i] }>$avg_boot_time*1.1"| bc)‘ fails[$i]=‘expr${fails[$i]}+$(echo"${lo_startup[$i ]}>$avg_lo_startup*1.1"| bc)‘ fails[$i]=‘expr${fails[$i]}+$(echo"${ lo_file_startup[$i]}>$avg_lo_file_startup*1.1"| bc)‘

79 fails[$i]=‘expr${fails[$i]}+$(echo"${kernel1[$i]} >$avg_kernel1*1.1"| bc)‘ fails[$i]=‘expr${fails[$i]}+$(echo"${kernel4[$i]} >$avg_kernel4*1.1"| bc)‘ if![$n]; then fails[$i]=‘expr${fails[$i]}+$(echo"${network[$ i]}*1.1<$avg_network"| bc)‘ fi if![$p]; then fails[$i]=‘expr${fails[$i]}+$(echo"${power[$i] }>$avg_power*1.1"| bc)‘ fi

results+=("${fails[$i]} flaw(s):${filenames[$i]}") done readarray-t sorted < <(for a in"${results[@]}"; do echo "$a"; done| sort) for((i=0;i<$n;++i )); do echo${sorted[$i]} done

80 Ap´endiceF

Pruebas de rendimiento en PCs de TxT

F.1. PC A

Procesador: Pentium 4 @ 3, 20 GHz (Hyperthreading)

Memoria: 2 × 512 MB

Linux Puppy Slackware Par´amtero Lubuntu Ubuntu Mint Linux (KDE) Disco (GB) 2,48 0,67 6,67 1,84 2,37 Memoria (MB) 477 183 684 480 670 Tiempo de arranque del SO 31,99 21,06 74,34 26,86 25,20 (s) Tiempo de arranque de 4,591 7,811 5,700 6,156 5,631 LibreOffice (s) Tiempo de apertura de 74,111 118,034 73,021 74,909 72,019 many_as.txt (s) Tiempo de compilaci´onen 420,378 360,252 528,270 389,047 366,772 serie (s) Tiempo de compilaci´onen 296,251 301,140 350,220 320,031 299,772 paralelo (s) Consumo energ´etico(W) 72,5 73,0 73,0 73,0 73,0

81 F.2. PC B

Procesador: Pentium D @ 3,00 GHz (Dual core)

Memoria: 2 × 512 MB

Linux Puppy Slackware Par´amtero Lubuntu Ubuntu Mint Linux (KDE) Disco (GB) 2,45 0,79 6,68 1,82 2,38 Memoria (MB) 448 105 867 370 722 Tiempo de arranque del SO 34,22 29,12 78,65 33,76 27,33 (s) Tiempo de arranque de 5,554 7,492 12,826 5,121 5,313 LibreOffice (s) Tiempo de apertura de 72,186 116,605 116,925 72,321 70,280 many_as.txt (s) Tiempo de compilaci´onen 357,118 358,394 424,427 386,490 362,490 serie (s) Tiempo de compilaci´onen 190,793 191,345 228,274 203,620 190,887 paralelo (s) Consumo energ´etico(W) 66,0 64,0 67,0 65,5 66,0

82 F.3. PC C (Core 2 Duo)

Procesador: Core 2 Duo 3,13 GHz (Dual core)

Memoria: 2 × 1 GB

Linux Puppy Slackware Par´amtero Lubuntu Ubuntu Mint Linux (KDE) Disco (GB) 2,48 0,70 6,68 1,84 2,38 Memoria (MB) 575 180 707 480 647 Tiempo de arranque del SO 20,39 24,92 78,93 21,17 24,31 (s) Tiempo de arranque de 5,630 6,076 9,134 5,455 5,002 LibreOffice (s) Tiempo de apertura de 73,113 115,364 126,590 72,735 69,822 many_as.txt (s) Tiempo de compilaci´onen 239,780 243,958 292,331 258,470 239,966 serie (s) Tiempo de compilaci´onen 127,990 133,732 158,848 143,930 133,058 paralelo (s) Consumo energ´etico(W) 57,0 55,5 57,0 57,0 57,0

83 Ap´endiceG

C´odigofuente del benchmark (versi´on2)

El archivo benchmark.sh es exactamente el mismo (aunque las funciones para medir la velocidad de red y el consumo el´ectricono se usaran). ´Idem con el archivo statistics.sh. El archivo run.sh tambi´enes igual, con la excepci´onde que se des- comentan las funciones memory_discard y estimation. A continuaci´onse muestra la implementaci´onde dichas funciones.

84 G.1. memory disk discard

Esta funci´onintenta determinar la distribuci´onideal en base a la cantidad de memoria y disco usados y las totales disponibles. En caso de que se pueda determinar la distribuci´onganadora con solo estos datos, el benchmark no continuar´a. function memory_disk_discard{ total_memory=‘free-m| sed-n 2p| awk’{print$2}’‘ memory_usage=‘grep MEMORY$output_file| cut-d’ ’-f2 ‘

# in MiB, not GiB total_disk=‘df-m| grep sda| awk’{print$3}’‘ total_disk=‘echo$total_disk| sed ’s/ /+/g’| bc‘ disk_usage=‘df-m| grep sda| awk’{print$4}’‘ disk_usage=‘echo$disk_usage| sed ’s/ /+/g’| bc‘

if[[$memory_usage-gt$((total_memory/2))]]||[[$ disk_usage-gt$total_disk]]; then if[[$((memory_usage-180))-le$((total_memory/2) )]]&&[[$((disk_usage+90))-le$((total_disk /2))]]; then echo"Due to memory and/ or disk limitations, the best option is Linux Mint." else echo"Due to memory and/ or disk limitations, the best option is Puppy Linux." fi save_state 5 exit0 fi }

85 G.2. estimation

Esta funci´ondecide qu´edistribuci´ones la ideal una vez se han realizado todas las mediciones para una de las distribuciones. function estimation{ MEMORY_USAGE=‘grep MEMORY_USAGE results-ubuntu.txt| cut-d-f2‘ DISK_USAGE=‘grep DISK_USAGE results-ubuntu.txt| cut- d-f2‘ BOOT=‘grep BOOT results-ubuntu.txt| cut-d’ ’-f2‘ DISK_USAGE=‘grep DISK_USAGE results-ubuntu.txt| cut- d’ ’-f2‘ MEMORY_USAGE=‘grep MEMORY_USAGE results-ubuntu.txt| cut-d’ ’-f2‘ KERNEL1=‘grep KERNEL1 results-ubuntu.txt| cut-d’ ’- f2‘ # KERNEL4=‘grep KERNEL4 results-ubuntu.txt| cut-d’’- f2‘ LO_STARTUP=‘grep LO_STARTUP results-ubuntu.txt| cut- d’ ’-f2‘ LO_FILE_STARTUP=‘grep LO_FILE_STARTUP results-ubuntu. txt| cut-d’ ’-f2‘

#estimate Slackware’s performance echoMEMORY_USAGE$((MEMORY_USAGE+ 73))> results- slackware.txt echoDISK_USAGE$((DISK_USAGE+ 4403))>> results- slackware.txt BOOT_SLACKWARE=‘echo"scale=2;${BOOT}+ 51.69"| bc‘ echoBOOT$BOOT_SLACKWARE>> results-slackware.txt echoDISK_USAGE$((DISK_USAGE+ 4608))>> results- slackware.txt echoMEMORY_USAGE$((MEMORY_USAGE+ 73))>> results- slackware.txt KERNEL1_SLACKWARE=‘echo"scale=2;${KERNEL1}+ 92.124" | bc‘ echo KERNEL1$KERNEL1_SLACKWARE>> results-slackware. txt

86 # KERNEL4_SLACKWARE=‘echo"scale=2;${KERNEL4}+"| bc‘ # echo KERNEL4$KERNEL4_SLACKWARE>> results-slackware. txt LO_STARTUP_SLACKWARE=‘echo"scale=2;${LO_STARTUP}+ 2.72"| bc‘ echoLO_STARTUP$LO_STARTUP_SLACKWARE>> results- slackware.txt LO_FILE_STARTUP_SLACKWARE=‘echo"scale=2;${ LO_FILE_STARTUP}+ 34.805"| bc‘ echoLO_FILE_STARTUP$LO_FILE_STARTUP_SLACKWARE>> results-slackware.txt

#estimate Linux Mint’s performance echoMEMORY_USAGE$((MEMORY_USAGE- 180))> results- slackware.txt echoDISK_USAGE$((DISK_USAGE+ 90))>> results- slackware.txt BOOT_MINT=‘echo"scale=2;${BOOT}+ 3.25"| bc‘ echoBOOT$BOOT_MINT>> results-mint.txt echoDISK_USAGE$((DISK_USAGE+ 367))>> results-mint. txt echoMEMORY_USAGE$((MEMORY_USAGE+-180))>> results- mint .txt KERNEL1_MINT=‘echo"scale=2;${KERNEL1}+ 16.21"| bc‘ echo KERNEL1$KERNEL1_MINT>> results-mint.txt # KERNEL4_MINT=‘echo"scale=2;${KERNEL4}+"| bc‘ # echo KERNEL4$KERNEL4_MINT>> results-mint.txt echoLO_STARTUP$LO_STARTUP>> results-mint.txt LO_FILE_STARTUP_MINT=‘echo"scale=2;${LO_FILE_STARTUP }+ 2.43"| bc‘ echoLO_FILE_STARTUP$LO_FILE_STARTUP_MINT>> results- mint .txt }

87 Ap´endiceH

Estimaciones en base a la distribuci´on live

Los par´ametroscalculados (columnas) son los siguientes: r: Coeficiente de correlaci´onde Pearson. Si r es cercana a 1, indica una fuerte co- rrelaci´onlineal directa; si es cercana a -1 indica una fuerte correlaci´onlineal inversa; si es cercana a 0, indica que no existe correlaci´onlineal. StdErr: Error est´andarde r. Test hipo.: Test de hip´otesis de r. Es igual al error est´andarde r × t de student para el intervalo de confianza del 80 % y n − 2 grados de libertad (= 3,08). Sign.: Indica si la correlaci´onentre la variable y el tiempo de arranque es estad´ısti- camente significativa. Es decir, si r >el test de hip´otesisde r.

Las variables observadas son las siguientes: Tiempo de arranque del SO: Valor medido por el benchmark (Ubuntu). Tiempo de arranque de LO: Tiempo de arranque de LibreOffice Writer. Valor medido por el benchmark (Ubuntu).

Tiempo de arranque de many as: Tiempo de arranque de LibreOffice Writer abrien- do un archivo grande. Valor medido por el benchmark (Ubuntu). Ancho de banda del disco: Ancho de banda de lectura del disco. Latencia: Tiempo que se tarda en leer un byte del disco.

88 Compilaci´on(1 thread): Tiempo que tarda el sistema en compilar un programa de referencia usando solo 1 thread.

Compilaci´on(4 threads): Tiempo que tarda el sistema en compilar un programa de referencia usando 4 threads.

Lectura RAM: tramo 1: Ancho de banda de lectura de la memoria para archivos de tama˜nomenor a 32 kiB.

Lectura RAM: tramo 2: Ancho de banda de lectura de la memoria para archivos de tama˜noentre 32 kiB y 256 kiB.

Lectura RAM: tramo 3: Ancho de banda de lectura de la memoria para archivos de tama˜noentre 256 kiB y 1 MiB.

Lectura RAM: tramo 4: Ancho de banda de lectura de la memoria para archivos de tama˜nomayor a 2 MiB.

89 Cuadro H.1: Correlaci´onentre el tiempo de arranque del SO y distintas variables. Test PC A PC B PC C r StdErr Sign. hipo. Tiempo de arranque del SO 25,20 27,33 24,31 (s) Ancho de banda del disco 58,1 42,6 62,7 -1,00 0,07 0,22 S´ı (MB/s) Latencia (ms) 16,9465 21,5512 23,6888 -0,08 1,00 3,07 No Compilaci´on(1 thread) (s) 141,983 148,85 107,143 0,82 0,57 1,74 No Compilaci´on(4 threads) (s) 105,713 79,778 57,85 0,24 0,97 2,99 No Lectura RAM: tramo 1 46 43 32 0,57 0,82 2,52 No (GB/s) Lectura RAM: tramo 2 26 24 16 0,58 0,81 2,50 No 90 (GB/s) Lectura RAM: tramo 3 20 19 16 0,54 0,84 2,59 No (GB/s) Lectura RAM: tramo 4 5 4 5 -0,96 0,29 0,88 S´ı (GB/s) Cuadro H.2: Correlaci´onentre el tiempo de arranque de LibreOffice Writer y distintas variables. Test PC A PC B PC C r StdErr Sign. hipo. Tiempo de arranque de LO 5,631 5,313 5,002 (s) Ancho de banda del disco 58,1 42,6 62,7 -0,21 0,98 3,01 No (MB/s) Latencia (ms) 16,9465 21,5512 23,6888 -0,98 0,20 0,62 S´ı Compilaci´on(1 thread) (s) 141,983 148,85 107,143 0,77 0,63 1,95 No Compilaci´on(4 threads) (s) 105,713 79,778 57,85 1,00 0,04 0,13 S´ı Lectura RAM: tramo 1 46 43 32 0,95 0,32 0,98 No (GB/s) Lectura RAM: tramo 2 26 24 16 0,94 0,33 1,03 No 91 (GB/s) Lectura RAM: tramo 3 20 19 16 0,96 0,28 0,87 S´ı (GB/s) Lectura RAM: tramo 4 5 4 5 0,01 1,00 3,08 No (GB/s) Cuadro H.3: Correlaci´onentre el tiempo de arranque de LibreOffice Writer abriendo un archivo grande y distintas variables. Test PC A PC B PC C r StdErr Sign. hipo. Tiempo de arranque de 72,019 70,280 69,822 many as (s) Ancho de banda del disco 58,1 42,6 62,7 0,10 0,99 3,06 No (MB/s) Latencia (ms) 16,9465 21,5512 23,6888 -0,99 0,12 0,36 S´ı Compilaci´on(1 thread) (s) 141,983 148,85 107,143 0,54 0,84 2,59 No Compilaci´on(4 threads) (s) 105,713 79,778 57,85 0,96 0,27 0,84 S´ı Lectura RAM: tramo 1 46 43 32 0,80 0,60 1,85 No (GB/s)

92 Lectura RAM: tramo 2 26 24 16 0,79 0,61 1,88 No (GB/s) Lectura RAM: tramo 3 20 19 16 0,82 0,57 1,75 No (GB/s) Lectura RAM: tramo 4 5 4 5 0,32 0,95 2,92 No (GB/s) Cuadro H.4: Correlaci´onentre el tiempo de el tiempo de compilaci´ondel kernel de Linux con un solo thread y distintas variables. Test PC A PC B PC C r StdErr Sign. hipo. Tiempo de compilaci´on(s) 366,200 362,490 239,366 Ancho de banda del disco 58,1 42,6 62,7 -0,66 0,75 2,32 No (MB/s) Latencia (ms) 16,9465 21,5512 23,6888 -0,76 0,65 2,00 No Compilaci´on(1 thread) (s) 141,983 148,85 107,143 0,98 0,18 0,55 S´ı Compilaci´on(4 threads) (s) 105,713 79,778 57,85 0,85 0,52 1,60 No Lectura RAM: tramo 1 46 43 32 0,98 0,18 0,55 S´ı (GB/s) Lectura RAM: tramo 2 26 24 16 0,99 0,16 0,50 S´ı 93 (GB/s) Lectura RAM: tramo 3 20 19 16 0,98 0,22 0,66 S´ı (GB/s) Lectura RAM: tramo 4 5 4 5 -0,48 0,88 2,70 No (GB/s) Ap´endiceI

Ecuaciones para estimar el rendimiento

I.1. Ubuntu

Tiempo de arranque = Ancho de banda del disco × −0, 19 +Ancho de banda de la memoria (tramo 4) × 0, 88 +32, 10

Tiempo de arranque de LibreOffice Writer = Latencia del disco × 0, 02 +Tiempo de compilaci´on(4 threads) × 0, 02 +3, 48

Tiempo de apertura de un archivo grande = Latencia del disco × −0, 58 +Tiempo de compilaci´on(4 threads) × −0, 04 +85, 52

Tiempo compilaci´ondel kernel (1 thread) = Tiempo de compilaci´oncon 1 thread × 1, 57 +Ancho de banda de la memoria (tramo 2) × 7, 23 + − 44, 03

Tiempo compilaci´ondel kernel (4 thread2 ) = Tiempo de compilaci´oncon 4 threads × 0, 74 +Latencia del disco × −19, 50 +552, 35

94 I.2. Slackware

Tiempo de arranque = Ancho de banda del disco × 1 +Ancho de banda de la memoria (tramo 4) × −0, 77 +115,25

Tiempo de arranque de LibreOffice Writer = Latencia del disco × 5, 56 +Tiempo de compilaci´on(4 threads) × 0, 71 + − 163, 73

Tiempo de apertura de un archivo grande = Latencia del disco × 15, 70 +Tiempo de compilaci´on(4 threads) × 1, 09 + − 308, 61

Tiempo compilaci´ondel kernel (1 thread) = Tiempo de compilaci´oncon 1 thread × −4,11 +Ancho de banda de la memoria (tramo 2) × 37, 80 +129, 36

Tiempo compilaci´ondel kernel (4 thread2 ) = Tiempo de compilaci´oncon 4 threads × 1, 29 +Latencia del disco × −19, 24 +540, 18

I.3. Linux Mint

Tiempo de arranque = Ancho de banda del disco × −2, 52 +Ancho de banda de la memoria (tramo 4) × 36, 86 + − 5, 78

Tiempo de arranque de LibreOffice Writer = Latencia del disco × 0, 42 +Tiempo de compilaci´on(4 threads) × 0, 04 + − 6, 56

95 Tiempo de apertura de un archivo grande = Latencia del disco × −1, 46 +Tiempo de compilaci´on(4 threads) × −0, 18 +118, 44

Tiempo compilaci´ondel kernel (1 thread) = Tiempo de compilaci´oncon 1 thread × −1, 97 +Ancho de banda de la memoria (tramo 2) × 24, 87 +53, 54

Tiempo compilaci´ondel kernel (4 thread2 ) = Tiempo de compilaci´oncon 4 threads × 1, 39 +Latencia del disco × −15, 06 +404, 05

96 Ap´endiceJ

C´odigofuente del benchmark (versi´on3)

El archivo statistics.sh es igual que el de la primera modalidad de benchmark (incluyendo la opci´onde la compilaci´ondel kernel con 4 threads), pero sin las opciones de velocidad de red y consumo el´ectrico.

J.1. run.sh

Este archivo contiene el orden en el que deben medirse los par´ametrosy otras instrucciones necesarias (comprobaciones, pausas, reinicios, etc.). Es completamente disinto al de las modalidades de benchmark anteriores. #!/bin/bash cd ~/benchmark#files must be located here params=${*:1} source memory_disk_discard.sh source estimation.sh temp_file=temp-results.txt echo"There will now bea 60 second pause." #sleep 60 memory_disk_discard

97 [!-f memory_bandwidth.txt]&& echo"Measuring memory bandwidth. This may takea while."&& ./benchmark.sh MEMORY_BW2 MEMORY_BW4>$temp_file echo"Measuring disk bandwidth. This may takea while." ./benchmark.sh DISK_BW DISK_LAT>>$temp_file ./benchmark.sh COMPILE1 COMPILE4>>$temp_file

DISK_BW=‘grep DISK_BW$temp_file| cut-d’ ’-f2| seds /,/./‘ MEMORY_BW2=‘grep MEMORY_BW2$temp_file| cut-d’ ’-f2| sed s/,/./‘ MEMORY_BW4=‘grep MEMORY_BW4$temp_file| cut-d’ ’-f2| sed s/,/./‘ DISK_LAT=‘grep DISK_LAT$temp_file| cut-d’ ’-f2| seds /,/./‘ COMPILE1=‘grep COMPILE1$temp_file| cut-d’ ’-f2| seds /,/./‘ COMPILE4=‘grep COMPILE4$temp_file| cut-d’ ’-f2| seds /,/./‘ estimation ./statistics.sh

98 J.2. benchmark.sh

Este archivo contiene el c´odigocapaz de medir los par´ametrospor separado. Es completamente distinto al de las modalidades de benchmark anteriores. Mide los par´ametrosque se usar´anpara realizar las estimaciones (ancho de banda del disco, la latencia, etc). #!/bin/bash

#tests: #DISK_BW: disk bandwidth #DISK_LAT: disk latency #MEMORY_BW1: memory bandwidth(1st segment) #MEMORY_BW2: memory bandwidth(2nd segment) #MEMORY_BW3: memory bandwidth(3rd segment) #MEMORY_BW4: memory bandwidth(4th segment) #COMPILE1: time to compilea program, using1 thread #COMPILE4: time to compilaa program, using4 threads tests=${*:1} cd ~/benchmark

MEMORY_BW_FILE=memory_bandwidth.txt

#auxiliary functions function round{ rounded=‘echo"($1+0.5)/1"| bc‘ echo$rounded } function get_time{ cmd=${*:1} time=‘{ time$cmd>/dev/null 2>&1;}2>&1| grep real | cut-f2| sed s/h/*3600+/| sed s/m/*60+/| sed s/s//| bc‘ echo$time } function compile{

99 THREADS=$1 if["$THREADS"==""]; then THREADS=1 fi cd$COMPILE_FOLDER> /dev/null ./configure> /dev/null COMPILE_TIME=‘get_time make-j$THREADS‘ make clean-j$THREADS> /dev/null cd-> /dev/null echoCOMPILE$THREADS$COMPILE_TIME seconds } function drop_caches{ sudo sh-c"echo1>/proc/sys/vm/drop_caches" sudo sh-c"echo2>/proc/sys/vm/drop_caches" sudo sh-c"echo3>/proc/sys/vm/drop_caches" }

#memory_bw if[[$tests==*MEMORY_BW*]]; then sudo /home/user/bandwidth-0.32p/bandwidth32--quick> $MEMORY_BW_FILE fi if[[$tests==*MEMORY_BW1*]]; then MEMORY_BW1=‘grep"Sequential read(128-bit), size= 16 kB"$MEMORY_BW_FILE| cut-d’ ’-f11‘ MEMORY_BW1=‘echo"scale=2;${MEMORY_BW1}/ 1024"| bc‘ echo MEMORY_BW1$MEMORY_BW1 MB/s fi if[[$tests==*MEMORY_BW2*]]; then MEMORY_BW2=‘grep"Sequential read(128-bit), size= 128 kB"$MEMORY_BW_FILE| cut-d’ ’-f11‘ MEMORY_BW2=‘echo"scale=2;${MEMORY_BW2}/ 1024"| bc‘ echo MEMORY_BW2$MEMORY_BW2 MB/s fi if[[$tests==*MEMORY_BW3*]]; then

100 MEMORY_BW3=‘grep"Sequential read(128-bit), size= 512 kB"$MEMORY_BW_FILE| cut-d’ ’-f11‘ MEMORY_BW3=‘echo"scale=2;${MEMORY_BW3}/ 1024"| bc‘ echo MEMORY_BW3$MEMORY_BW3 MB/s fi if[[$tests==*MEMORY_BW4*]]; then MEMORY_BW4=‘grep"Sequential read(128-bit), size= 2.5MB"$MEMORY_BW_FILE| cut-d’ ’-f11‘ MEMORY_BW4=‘echo"scale=2;${MEMORY_BW4}/ 1024"| bc‘ echo MEMORY_BW4$MEMORY_BW4 MB/s fi

#disk_bw if[[$tests==*DISK_LAT*]];then drop_caches DISK_LAT=‘sudo dd if=/dev/sda1 of=/dev/null count=1 2> &1| tail-n1| cut-d’ ’-f 6‘ TEMP=‘echo$DISK_LAT| grep e‘ if[[!$TEMP]]; then echo DISK_LAT 0 else echoDISK_LAT$DISK_LAT s fi fi if[[$tests==*DISK_BW*]];then drop_caches DISK_BW_TMP=‘sudo dd if=/dev/sda1 of=/dev/null count=3 M 2>&1| tail-n1‘ DISK_BW=‘echo$DISK_BW_TMP| cut-d’ ’-f8‘ DISK_BW_UNIT=‘echo$DISK_BW_TMP| cut-d’ ’-f9‘ if["$DISK_BW_UNIT"=="GB/s"]; then DISK_BW=‘echo"scale=2;${DISK_BW}* 1024"| bc‘ fi echoDISK_BW$DISK_BW MB/s fi

#compilation if[[$tests==*COMPILE*]]; then

101 COMPILE_FILE=‘ls papi*.tar.gz‘ COMPILE_FOLDER=‘echo$COMPILE_FILE/src| sed ’s/.tar. gz //’‘ tar-xzf$COMPILE_FILE fi

#compile using1 thread if[[$tests==*COMPILE1*]]; then compile fi

#compile using4 threads if[[$tests==*COMPILE4*]]; then compile 4 fi if[[$tests==*COMPILE*]]; then COMPILE_FOLDER=‘echo$COMPILE_FILE| sed ’s/.tar.gz//’ ‘ rm-rf$COMPILE_FOLDER fi

102 J.3. estimation

En esta funci´onradica la estad´ısticaque estima el rendimiento de las distribucio- nes. function estimations{ #estimate Ubuntu’s performance BOOT=‘echo"scale=2;${DISK_BW}*-0.19+${MEMORY_BW4} * 0.87+ 32.10"| bc‘ LO_STARTUP=‘echo"scale=2;${DISK_LAT}* 0.02+${ COMPILE4}* 0.02+ 3.48"| bc‘ LO_FILE_STARTUP=‘echo"scale=2;${DISK_LAT}*-0.58+$ {COMPILE4}*-0.04+ 85.52"| bc‘ KERNEL1=‘echo"scale=2;${COMPILE1}* 1.57+${ MEMORY_BW2}* 7.23- 44.03"| bc‘ KERNEL4=‘echo"scale=2;${COMPILE4}* 0.74+${DISK_LAT }*-19.50+ 552.35"| bc‘

echo"BOOT_TIME$BOOT"> results-ubuntu.txt echo"LO_STARTUP$LO_STARTUP">> results-ubuntu.txt echo"LO_FILE_STARTUP$LO_FILE_STARTUP">> results- ubuntu .txt echo"KERNEL1$KERNEL1">> results-ubuntu.txt echo"KERNEL4$KERNEL4">> results-ubuntu.txt

#estimate Slackware’s performance BOOT_SLACKWARE=‘echo"scale=2;${DISK_BW}+${ MEMORY_BW4}*-0.77+ 115.25"| bc‘ LO_STARTUP_SLACKWARE=‘echo"scale=2;${DISK_LAT}* 5.56 +${COMPILE4}* 0.71- 163.73"| bc‘ LO_FILE_STARTUP_SLACKWARE=‘echo"scale=2;${DISK_LAT}* 15.70+${COMPILE4}* 1.09- 308.61"| bc‘ KERNEL1_SLACKWARE=‘echo"scale=2;${COMPILE1}*-4.11+ ${MEMORY_BW2}* 37.80+ 129.26"| bc‘ KERNEL4_SLACKWARE=‘echo"scale=2;${COMPILE4}* 1.29+ ${DISK_LAT}*-19.24+ 540.18"| bc‘

echo"BOOT_TIME$BOOT_SLACKWARE"> results-slackware. txt

103 echo"LO_STARTUP$LO_STARTUP_SLACKWARE">> results- slackware.txt echo"LO_FILE_STARTUP$LO_FILE_STARTUP_SLACKWARE">> results-slackware.txt echo"KERNEL1$KERNEL1_SLACKWARE">> results-slackware .txt echo"KERNEL4$KERNEL4_SLACKWARE">> results-slackware .txt

#estimate Linux Mint’s performance BOOT_MINT=‘echo"scale=2;${DISK_BW}*-2.52+${ MEMORY_BW4}* 36.86- 5.78"| bc‘ LO_STARTUP_MINT=‘echo"scale=2;${DISK_LAT}* 0.42+${ COMPILE4}* 0.04- 6.56"| bc‘ LO_FILE_STARTUP_MINT=‘echo"scale=2;${DISK_LAT}*- 1.46+${COMPILE4}*-0.18+ 118.44"| bc‘ KERNEL1_MINT=‘echo"scale=2;${COMPILE1}*-1.97+${ MEMORY_BW2}* 24.87+ 53.54"| bc‘ KERNEL4_MINT=‘echo"scale=2;${COMPILE4}* 1.39+${ DISK_LAT}*-15.06+ 404.05"| bc‘

echo"BOOT_TIME$BOOT_MINT"> results-mint.txt echo"LO_STARTUP$LO_STARTUP_MINT">> results-mint.txt echo"LO_FILE_STARTUP$LO_FILE_STARTUP_MINT">> results-mint.txt echo"KERNEL1$KERNEL1_MINT">> results-mint.txt echo"KERNEL4$KERNEL4_MINT">> results-mint.txt }

104 Ap´endiceK

Funcionalidades de Raspbian

El protocolo de mensajer´ıainstant´anea“MySpace IM” se ha descartado, ya que no recibi´oning´unvoto y resulta irrelevante. Las funcionalidades “compatible con HD-DVD” y “compatible con Blu-ray” se han eliminado debido a que la Raspberry Pi no dispone del hardware necesario. La fila “Total (abs)” indica el total de votos para las funcionalidades con m´asdel 50 % de votos. La fila “Total ( %)” indica el porcentaje de funcionalidades con m´asdel 50 % de votos que cumple. La fila “Total normalizado” es una ponderaci´onteniendo en cuenta todas las funcionalidades y su valor normalizado (v´easeel ap´endiceA).

105 Leyenda: 1 = S´ı;0 = No; 0,5 = Parcial

Funcionalidad Mod Base Potencial Compatible con 0 1 1 documentos .docx Compatible con 0 1 1 documentos .swx Posibilidad de a˜nadir comentarios a los 0 1 1 documentos Crear gr´aficosy 0 1 1 dibujos Procesador de textos Integraci´oncon una suite ofim´atica 0 1 1 completa Versi´onpara Mac OS 0 1 1 X Corrector ortogr´afico 0 1 1 Imprimir selecci´on 0 1 1 Alto n´umerode 0 1 1 celdas Immobilizar paneles 0 1 1 Importar / exportar 0 1 1 Hoja de c´alculo tablas LaTeX Interfaz en catal´an 1 1 1 Soporte para escritura de derecha a 0 1 1

Localiza. izquierda

106 Funcionalidad Mod Base Potencial Filtro anti-phishing 0 1 1 Lector de feeds RSS 0 1 1 Vista previa de

Correo 0 0 0 documentos de texto Bloqueo de pop-ups 0 1 1 Bloqueo de publicidad 1 1 1 Control por voz 0 1 1 Gestos de rat´on 1 1 1 Conversi´on Navegador 0 0 0 texto-a-voz Incorpora su propio 0 1 1 plugin Flash Lector de feeds RSS 0 1 1 Gestor de contrase˜nas 0 1 1 Yahoo! Mail 0 1 1 Windows Live 0 1 1 messenger XMPP (Google talk, 0 1 1 Facebook chat) IRC 0 1 1 Protocolos MI Skype 0 0 0 Emoticonos gr´aficos 0 1 1 Emoticonos gr´aficos definidos por el 0 1 1 usuario Chat de voz 0 1 1 Cliente MI Chat de v´ıdeo 0 1 1 Escritura a mano 0 0 0 Soporte multi-cuenta 0 1 1 Corrector ortogr´afico 0 1 1

107 Funcionalidad Mod Base Potencial Soporte para 0 1 1 subt´ıtulos Control de imagen 0 1 1 Control de sonido 0 1 1 (tono) Resincronizaci´onde 0 1 1 audio Resincronizaci´onde 0 1 1 subt´ıtulos Reproductor de v´ıdeo Soporte para VCD 0 0 1 Soporte para SVCD 0 0 1 Soporte para DVD 0 0 1 Miniaturas 1 1 1 (Thumbnails) Pesta˜nas 0 1 1 Doble panel 1 1 1 Previsualizaciones 0 1 1

Gestor de ar. Navegar por archivos 0 0 0 comprimidos Total mayoritarios 3 24 25 (abs) Total mayoritarios Total 10,00 80,00 83,33 ( %) Total normalizado 10,57 84,21 89,62 ( %)

108 Bibliograf´ıa

[1] Jack Wallen. Linux distribution choice flow chart. http://cdn.ghacks.net/ wp-content/uploads/2010/01/choosing_linux.jpg

[2] T´erminosde licencia de Windows 7 Ultimate. https://www.microsoft.com/ latam/socios/OEM/Licenciamiento/licencias.aspx

[3] Nicholas Hatt, Axis Sivitz and Benjamin A. Kuperman. “Benchmarking Ope- rating Systems”, 2007.

[4] John L. Gustafson and Quinn O. Snell. HINT: A New Way To Measure Com- puter Performance. Proceedings of the 28th Annual Hawaii International Con- ference on Systems Sciences, IEEE Computer Society Press, 1995.

[5] Uwe F. Mayer. Linux/Unix nbench. http://www.tux.org/~mayer/linux/ bmark.html

[6] BYTE magazine (currently defunct). Snapshot available at http://www.tux. org/~mayer/linux/byte/bdoc.pdf (thanks to Mayer, Uwe F.) [7] Kaj Gr¨onholm.GTK+ toolkit on mobile Linux devices. Master thesis.

[8] Don Capps. IOzone Filesystem Benchmark. http://www.iozone.org/, 2008.

[9] R. Jones. “Netperf: A network performance benchmark, versi´on2.1”, 1995.

[10] Phoronix test suite. http://www.phoronix-test-suite.com/

[11] Zack Smith. Bandwidth: a memory bandwidth benchmark. http://zsmith.co/ bandwidth.html

[12] PAPI (Performance Application Programming Interface) http://icl.cs.utk. edu/papi/index.html

109 [13] Renatas Kizys, Angel´ A. Juan. Modelo de regresi´onLineal M´ultiple http:// www.uoc.edu/in3/emath/docs/T01_Reg_Lineal_Multiple.pdf

[14] Minitab, software estad´ıstico. http://www.minitab.com/

[15] Cubieboard, a small, high-performance arm box. http://cubieboard.org/

[16] Wandboard, ultra low power complete computer with high performance multi- media capabilities. http://www.wandboard.org/

110