Universidade de Brasília - UnBFaculdade UnB Gama - FGA

Engenharia de Software

Algoritmo para Qualificação das Saídas deBuscas em Gerenciadores de Repositórios de

Distribuições Linux

Autor: Luiz Fernando Gomes de OliveiraOrientador: Dr. Edson Alves da Costa Júnior

Brasília, DF2014

Luiz Fernando Gomes de Oliveira

Algoritmo para Qualificação das Saídas de Buscas emGerenciadores de Repositórios de Distribuições Linux

Monografia submetida ao curso de graduaçãoem Engenharia de Software da Universidadede Brasília, como requisito parcial para ob-tenção do Título de Bacharel em Engenhariade Software.

Universidade de Brasília - UnB

Faculdade UnB Gama - FGA

Orientador: Dr. Edson Alves da Costa JúniorCoorientador: Dr. Fábio Macêdo Mendes

Brasília, DF2014

Luiz Fernando Gomes de OliveiraAlgoritmo para Qualificação das Saídas de Buscas em Gerenciadores de Re-

positórios de Distribuições Linux/ Luiz Fernando Gomes de Oliveira. – Brasília,DF, 2014-

72 p. : il. (algumas color.) ; 30 cm.

Orientador: Dr. Edson Alves da Costa Júnior

Trabalho de Conclusão de Curso – Universidade de Brasília - UnBFaculdade UnB Gama - FGA , 2014.1. Palavra-chave01. 2. Palavra-chave02. I. Dr. Edson Alves da Costa Júnior. II.

Universidade de Brasília. III. Faculdade UnB Gama. IV. Algoritmo para Qualifica-ção das Saídas de Buscas em Gerenciadores de Repositórios de Distribuições Linux

CDU 02:141:005.6

Luiz Fernando Gomes de Oliveira

Algoritmo para Qualificação das Saídas de Buscas emGerenciadores de Repositórios de Distribuições Linux

Monografia submetida ao curso de graduaçãoem Engenharia de Software da Universidadede Brasília, como requisito parcial para ob-tenção do Título de Bacharel em Engenhariade Software.

Trabalho aprovado. Brasília, DF, 01 de junho de 2013:

Dr. Edson Alves da Costa JúniorOrientador

Dr. Paulo Roberto Miranda MeirellesConvidado 1

Dr. Fábio Macêdo MendesConvidado 2

Brasília, DF2014

Este trabalho é dedicado àqueles que tem sede de conhecimento,mas não temem compartilhar o pouco que têm.

Emotion, yet peace.Ignorance, yet knowledge.

Passion, yet serenity.Chaos, yet harmony.Death, yet the Force.

ResumoEste trabalho vem apresentar propostas para melhor apresentação de resultados de buscasem gerenciadores de repositórios de pacotes presentes nas distribuições Linux, com ointuito de apresentar os resultados mais relevantes ao usuário com base nos valores deentrada e também de tratar os casos onde a entrada possuir erros ortográficos, sejampor desconhecimento do nome do pacote, seja por casual escrita incorreta. Tais propostasforam construídas a partir de algoritmos de string matching presentes na literatura e nasbibliotecas da linguagem Python.

Palavras-chaves: Linux. Gerenciadores de pacotes. APT. Python.

AbstractThis paper presents proposals for better presentation of search results in managers packagerepositories present in Linux distributions, with the intention of presenting the mostrelevant results to the user based on the input values and also to treat the cases wherethe input has spelling mistakes are due to ignorance of the name of the package, eitherby casual misspellings. Such proposals were constructed from string matching algorithmsin the literature and in the Python’s libraries.

Key-words: Linux. Packages Managers. APT. Python.

Lista de ilustrações

Figura 1 – Apresentação de resultados da busca do termo pdf usando o apt-cache 22Figura 2 – Apresentação de resultados da busca do termo pdf usando o apt . . . . 22Figura 3 – Exemplo do uso do comando time . . . . . . . . . . . . . . . . . . . . . 42Figura 4 – Amostra de comparação dos resultados . . . . . . . . . . . . . . . . . . 44Figura 5 – Heranças de algumas das distribuições Linux existentes hoje . . . . . . 71

Lista de tabelas

Tabela 1 – Comandos para atualização do banco de dados dos gerenciadores derepositórios mais populares. . . . . . . . . . . . . . . . . . . . . . . . . 30

Tabela 2 – Principais comandos dos gerenciadores de repositórios mais populares. 31Tabela 3 – Comparação de resultados . . . . . . . . . . . . . . . . . . . . . . . . . 43Tabela 4 – Comparação de resultados com entradas contendo erros de ortografia . 45

Lista de códigos

3.1 Implementação da distância de Levenshtein . . . . . . . . . . . . . . . . . . 323.2 Visão atômica do cálculo da distância de Levenshtein . . . . . . . . . . . . 333.3 Implementação da distância de Damerau-Levenshtein . . . . . . . . . . . . 34A.1 Protótipo em Python para estudo do pacote apt. . . . . . . . . . . . . . . . 55A.2 Protótipo do algoritmo de match exato. . . . . . . . . . . . . . . . . . . . . 57A.3 Protótipo do algoritmo de Levenshtein. . . . . . . . . . . . . . . . . . . . . 61A.4 Protótipo do algoritmo de Damerau-Levenshtein. . . . . . . . . . . . . . . 63A.5 Protótipo do algoritmo de Smith-Waterman. . . . . . . . . . . . . . . . . . 65

Sumário

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2 OBJETIVOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.1 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.2 Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3 FUNDAMENTAÇÃO TEÓRICA . . . . . . . . . . . . . . . . . . . . 273.1 Gerenciadores de pacotes . . . . . . . . . . . . . . . . . . . . . . . . . 273.1.1 Contextualização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.1.2 Gerenciadores de pacotes e Gerenciadores de Repositórios . . . . . . . . . . 273.1.2.1 APT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.1.2.2 YUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.1.2.3 Portage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.1.2.4 Comandos básicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.2 Algoritmos de comparação de string . . . . . . . . . . . . . . . . . . . 313.2.1 Levenshtein . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.2.1.1 Exemplo de cálculo de distância entre strings . . . . . . . . . . . . . . . . . . . . 31

3.2.1.2 Distância de Levenshtein . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.2.2 Damerau-Levenshtein . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.2.2.1 Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.2.3 Smith-Waterman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.2.3.1 Algoritmo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.2.3.2 Implementação do algoritmo . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4 DELIMITAÇÃO DO ASSUNTO . . . . . . . . . . . . . . . . . . . . 37

5 METODOLOGIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.1 Levantamento bibliográfico . . . . . . . . . . . . . . . . . . . . . . . . 395.2 Ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.3 Algoritmos Propostos . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.4 Execução dos experimentos . . . . . . . . . . . . . . . . . . . . . . . . 405.5 Funcionalidades descartadas . . . . . . . . . . . . . . . . . . . . . . . 42

6 RESULTADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

7 CRONOGRAMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477.1 Planejamentos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

APÊNDICES 53

APÊNDICE A – PROTÓTIPOS ELABORADOS NO TRABALHO 55

ANEXOS 69

ANEXO A – FIGURAS . . . . . . . . . . . . . . . . . . . . . . . . . 71

21

1 Introdução

Um dos processos que novos usuários Linux tem dificuldade em se adaptar é ainstalação de novas aplicações. Hoje é comum haver nas plataformas uma aplicação quecentraliza a instalação das demais aplicações. Visto como uma loja em algumas plata-formas, o gerenciador de aplicações tão comum nos dias atuais era, há alguns anos umdiferencial dos sistemas Linux. Usuários do sistema operacional Windows que iniciavamo aprendizado do sistema Linux tinham dificuldade para compreender que não precisa-vam acessar o site de um fabricante como a Adobe para instalar o leitor de PDF, oufrequentar sites como Baixaki para fazer o download de aplicações diversas. Tudo o queprecisavam era abrir o terminal e com alguns comandos o software era instalado de umafonte confiável.

A compreensão deste processo abria novas fronteiras para o usuário, que agorabuscava expandir seu conhecimento e testar novas aplicações dentre as milhares que es-tavam à sua disposição. Obviamente que o processo de instalação e remoção de pacoteseventualmente torna-se dependente de uma ferramenta que possibilite realizar buscas poraplicações e filtragem das aplicações retornadas. E este é o ponto onde os novos usuáriosencontravam maiores dificuldades.

Quando realizadas em linha de comando, as buscas por pacotes podem ser comple-xas para usuários inexperientes em relação ao uso de comandos no terminal, e a ordenaçãodos resultados é ainda menos intuitiva. Uma busca por “pdf” no apt leva hoje a um resul-tado que, além de estourar o buffer de linhas da janela do terminal, apresenta o popularevince aproximadamente como 14a opção dentre os pacotes disponíveis para instalação,dependendo das listas de repositórios adicionados na distribuição e qual gerenciador estasendo usado. Alem disso, aplicações que não tem relação com leitores de pdf, tais comoo antivírus clamav ou o produtor de documentação doxygen, aparecem antes do evince

devido a ordenação alfabética.

O resultado é ainda menos preciso quando utilizada a interface do apt ao invés doapt-cache. Como esta interface apresenta todos os resultados em uma única ordenaçãoalfabética, temos na 11a posição um visualizador de PDF (apvlv), porém o popular evince

nem mesmo entra na lista dos 20 primeiros.

Dentre os diversos gerenciadores de repositório utilizados atualmente para a ins-talação de pacotes em distribuições Linux, podemos apontar alguns que se destacam porvirem instalados de padrão nas distribuições mais comuns hoje e, consequentemente sendoos mais utilizados, como o apt ou o yum.

Porém, os principais gerenciadores possuem em comum o mesmo problema de

22 Capítulo 1. Introdução

Figura 1 – Apresentação de resultados da busca do termo pdf usando o apt-cache

Figura 2 – Apresentação de resultados da busca do termo pdf usando o apt

ordenação dos resultados de uma busca. A apresentação de resultados de uma busca nãoé personalizável, não permitindo classificar a listagem de pacotes por nome, por exemplo,nem fazem matching de aproximação entre o pacote pesquisado e os possíveis candidatos.Desta forma a procura por um pacote do qual não se tenha o nome correto pode se tornarcansativa e desgastante, especialmente para um novo usuário Linux, que desconhece deferramentas como o grep, more ou less.

No próximo capítulo abordados os objetivos que deseja-se alcançar com este tra-balho. Em seguida será apresentada a fundamentação teórica levantada para a produçãodo estudo. Apresentada a fundamentação, seguirá uma delimitação do assunto, afim de

23

restringir as propostas do trabalho e estabelecer oportunidades para trabalhos posteri-ores. Em seguida será apresentada a metodologia adotada no trabalho para que fossemalcançados os resultados apresentados no último capítulo.

25

2 Objetivos

Primeiramente, este trabalho tem como objetivo a avaliação de diferentes algorit-mos de string matching, com o intuito de evidenciar o potencialde melhoria dos gerencia-dores de pacotes atuais em relação à apresentação de resultados de pesquisa por pacotes.Consciente do objetivo deste trabalho, será evitado o desenvolvimento dos códigos de al-goritmo de ordenação, visto que o objetivo não é a implementação dos algoritmos, mas acomparação dos resultados obtidos através dos algoritmos de string matching e suas per-formances nos estados atuais de implementação. Assim, serão utilizadas bibliotecas quepossuem implementações dos referidos algoritmos, citando suas respectivas referências ecréditos.

2.1 Objetivo GeralEste trabalho tem como objetivo apresentar métodos de qualificação dos resultados

de busca de modo que apresentem resultados mais próximos do esperado pelos usuários,quando estes forem realizar a busca por pacotes disponíveis para instalação em suasdistribuições.

2.2 Objetivos Específicos

∙ Implementar ou usar bibliotecas que implementam algoritmos de string matchingque venham a qualificar a saída apresentada em uma busca por pacotes.

∙ Implementar protótipos de qualificação da saída das buscas que torne a localiza-ção dos pacotes desejados menos dependentes de ferramentas complementares comogrep, more ou less.

∙ Implementar protópios que possibilitem a apresentação de resultados de uma buscapor pacotes, mesmo quando inserido o nome de um pacote inexistente ou com errosortográficos.

27

3 Fundamentação Teórica

3.1 Gerenciadores de pacotes

3.1.1 Contextualização

Desde o lançamento das distribuições Debian e Slackware em 1993, diversas distri-buições tiveram seu ciclo de vida realizado por completo, apresentando e amadurecendoa filosofia por trás da distribuição, gerando novas ramificações e por fim sendo aban-donadas. Hoje, se escolhermos alguma distribuição Linux dentre as inúmeras existentes,provavelmente ela será descendente de uma das principais distribuições: Debian, Red Hatou Slackware. A Figura 5, no Anexo A apresenta um modelo de herança entre as distribui-ções Linux onde pode-se observar a influência que estas distribuições tiveram em relaçãoa um grupo de novas distribuições que se ramificaram delas1.

Em sistemas operacionais Linux há muito foi proposto uma alternativa para dis-tribuições de aplicações para o sistemas: os pacotes. A filosofia por trás da comunidadelivre (BRETTHAUER, 2001) e o interesse em buscar novas formas de armazenamento edistribuição de pacotes fez com que surgissem diversos gerenciadores de pacotes, voltadosà determinadas distribuição cada (BECK; MAGNUS; KUNITZ, 2002).

Devido grande parte das distribuições hoje existentes serem ramificações das dis-tribuições Debian, Red Hat ou Slackware,os diversos gerenciadores de pacotes hoje dispo-níveis também possuem muitas similaridades entre eles. É o caso do dpkg e o rpm, ondeas funcionalidades de instalação, remoção e provimento de informações de pacotes estapresente em ambos. Ambos também são escritos predominantemente em C e Perl. Suasdiferenças surgem quando chegamos a averiguar quais pacotes cada aplicação suporta. Odpkg esta voltado para os pacotes .deb, enquanto o rpm esta voltado para os pacotes rpm.Como há uma distinção em como estes pacotes são montados (BAILEY, 1997), há umaincompatibilidade entre as duas aplicações.

3.1.2 Gerenciadores de pacotes e Gerenciadores de Repositórios

Um ponto de vista importante de ser caracterizado neste trabalho é a diferençaentre os termos gerenciadores de pacotes e gerenciadores de repositórios. É importantecaracterizar a diferença estes dois termos comumente utilizados como sinônimos devidoa sua similaridade. A proximidade é tamanha que na própria documentação oficial do1 Apesar da difícil visualização da imagem no documento, o intuito dela aqui é apresentar a vasta quan-

tidade de distribuições que surgiram de bifurcações das distribuições Debian, Red Hat e Slackware,tal como alterações nelas provavelmente viriam a influenciar as demais distribuições.

28 Capítulo 3. Fundamentação Teórica

Debian não há uma caracterização de gerenciadores de repositórios, citando apenas quegerenciadores como o aptitude ou dselect dependem do APT, que por sua vez dependedo dpkg (DEBIAN, 2013). Essa cadeia de dependências indicam as camadas de interface,onde o dpkg é responsavel pela instalação, remoção e gerência dos pacotes, enquanto o APT

está relacionado aos repositórios onde são armazenados os pacotes. Já aplicações como oaptitude ou o synaptic visam oferecer uma camada user friendly, com interfaces gráficase menos informações textuais.

Assim, definimos o termo gerenciadores de pacotes àquelas aplicações dedicadasao manuseio dos pacotes( instalação e remoção, por exemplo), enquanto gerenciadores derepositórios são as aplicações voltadas ao controle da lista de repositórios de pacotes einterface para instalação, remoção e pesquisa de pacotes, fazendo de uso dos gerenciadoresde pacotes quando necessário.

Tendo em vista que este trabalho busca apresentar uma melhor apresentação dosresultados de uma busca por um pacote a ser instalado em uma pesquisa realizada em umgerenciador de repositórios, devemos inicialmente elencar os possíveis candidatos a seremavaliados no trabalho.

3.1.2.1 APT

O APT, Advanced Package Tool, é um gerenciador de repositórios amplamente uti-lizado em distribuições oriundas da Debian (Debian-like). É provavelmente o gerenciadormais comum atualmente devido a popularidade de distribuições como Ubuntu, Mint eDebian. Projetado inicialmente para substituir o gerenciador dselect, o APT teve suasprimeiras builds distribuídas via IRC em Agosto de 1998, sendo integrado ao Debian narelease de Março de 1999 (GARBEE et al., 2008). O APT pode ser considerado comouma interface para o dpkg, gerenciando as dependências de um pacote para a instalação eremoção, alem de apresentar uma listagem dos pacotes disponíveis na lista de repositórios.

Um dos recursos que o APT fornece de forma transparente para o usuário é aordenação de pacotes para instalação ou remoção com o uso das chamadas do dpkg,suprindo as dependências dos pacotes que são requisitos para o pacote ao qual o usuáriodeseja instalar na máquina. Dentre as desvantagens que o APT pode apresentar, as quese destacam são justamente o fato de estar escrito em C++, que apesar do ganho deperformance que apresenta aos seus concorrentes, carrega junto uma maior dificuldade demanutenção devido ao tamanho e complexidade.

Outro problema do APT é sua fragmentação. Apesar de serem tratados como partedo APT, as aplicações como apt-get ou apt-cache são na realidade aplicações que fazemde uso do APT como uma biblioteca para interface, mas são comumente tratadas comoaplicações integradas ao APT. Como consequências, o APT possuiu uma das interfacesmenos intuitivas quando comparado com gerenciadores como o YUM ou o Portage jus-

3.1. Gerenciadores de pacotes 29

tamente por frequentemente serem apresentadas soluções utilizando as aplicações como oapt-get ao invés do apt.

Por ser um gerenciador de repositórios, o APT trabalha unicamente com os arquivos.deb que possuem seus respectivos endereços registrados no arquivo /etc/apt/sources.

list, possibilitando o uso de diretórios remotos ou locais para a disponibilização dospacotes a serem gerenciados. Requisitada a instalação de um pacote ao APT, será feito odownload do pacote e suas respectivas dependências e estes arquivos são repassados aodpkg para que seja realizado o processo de instalação.

O APT possui como repositório oficial o <git://anonscm.debian.org/apt/apt.git>,apesar de também ser hospedado em outros repositórios, tal como o <https://github.com/Debian/apt>. Neste trabalho estaremos trabalhando em busca de soluções que venha acontribuir e enriquecer em especial a aplicação apt-cache, em especial o comando search.Segundo podemos observar o código disponibilizado do APT, a apresentação dos resulta-dos de uma busca são ordenados alfabeticamente, de acordo com a lista de repositóriosdisponíveis.

3.1.2.2 YUM

O Yellowdog Updater, Modified (YUM) é o gerenciador de repositórios padrãodas distribuições oriundas da Red Hat Linux, como o Fedora e CentOS ou demaisdistribuições com sistema de pacotes baseados no padrão RPM. Semelhante ao APT, oYUM consegue trabalhar com repositórios locais ou remotos. Semelhante a como o DPKGé usado pelo APT para o processo de instalação e remoção de pacotes, o YUM faz de usodo RPM como dependência para processamento de pacotes.

Escrito predominantemente em Python, o YUM surgiu da reescrita do YellowdogUpdater (YUP) e tinha como objetivo a manutenção do gerenciador para sistemas RedHat Linux no Departamento de Física da Universidade de Duke e teve como seus de-senvolvedores iniciais Seth Vidal e Michael Stenner (BROWN; PICKARD, 2003). Tendosua primeira documentação publicada em 2003 por Robert G. Brown (BROWN, 2003), oYUM foi reconhecida como o gerenciador de repositórios padrão para sistemas RPM-likeapenas em 2007 (FUSCO, 2007).

Por ser escrito em Python, o YUM apresenta uma performance de desempenhoinferior ao APT (escrito predominantemente em C++), porém possui uma interface como usuário em linha de comando mais amistosa e intuitiva.

3.1.2.3 Portage

O Portage é o gerenciador de repositórios padrão da distribuição Gentoo e suasramificações (VERMEULEN et al., 2005). O Portage consiste, de fato, em duas aplicações

30 Capítulo 3. Fundamentação Teórica

trabalhando em conjunto para o funcionamento de um todo: o ebuild cuida do processode building e instalação dos pacotes enquanto o emerge providência a interface ao usuário.O Portage foi predominantemente escrito em Python.

O Portage, por padrão, não faz de uso de pacotes binários, tais como RPM ouDEB, mas sim códigos-fontes que são compilados durante o processo de instalação. Comoresultado o Portage mantém uma alta compatibilidade da aplicação com a máquina ealta flexibilidade com as arquiteturas de suporte, ao custo da demora na instalação. Essaflexibilidade permite que o Portage não seja em momento algum dependente do sistema,sendo por vezes utilizado para gerenciar outros sistemas, tais como o BSD, Mac OS eSolaris (RYAN, 2010). Eventualmente, forks do Portage são por vezes apresentados comosoluções para sistemas embarcados pelo fato da portabilidade da aplicação depender ape-nas da presença do compilador (GUO; WU, 2009). Todavia, o Portage apresenta tambémuma solução de instalação com empacotamento de binários através das flags –usepkg

–getbinpkg (GENTOO FOUNDATION, 2001) para instalações mais rápidas.

3.1.2.4 Comandos básicos

Por ser baseados em uma lista de repositórios, os gerenciadores de repositóriosrecomendam uma atualização de seus bancos de dados antes de realizar qualquer sequênciade operações para garantir que seus links serão válidos. A Tabela 1 apresenta os comandospara a atualização ou sincronização da lista de repositórios e pacotes dos gerenciadores.Os comandos de atualização de lista de repositórios precisam de permissão administrativae devem ser relizados como usuário root ou ter a invocação do comando sudo antes docomando de instalação/ remoção. Seguindo a padronização adotada pelas distribuiçõesLinux para apresentação de comandos em terminal (HEKMAN; ORAM, 1996), comandosprecedidos de # implicam em comandos que necessitam de permissões administrativasenquanto comandos precedidos por $ podem ser efetuados por qualquer usuário.

Tabela 1 – Comandos para atualização do banco de dados dos gerenciadores de repositó-rios mais populares.

Gerenciador de Repositórios CommandoAPT # apt-get updateYUM # yum updateEmerge # emerge –sync

Pressupondo que os repositórios já estejam sincronizados na maquina local, é pos-sível realizar os comandos básicos de instalação, remoção ou busca por pacotes sem riscosde que um pacote não seja encontrado ou tenha sua referência incompleta ou inválida.Estes comandos devem ser passados também via terminal. Os comandos de instalação e re-moção de pacotes precisam de permissão administrativa. A Tabela 2 lista estes comandos

3.2. Algoritmos de comparação de string 31

para os gerenciadores de repositórios mais populares, onde <pacote> é o nome do pacotecom o qual se deseja operar. É importante frisar que tem-se por padrão a nomeação dospacotes sem caracteres especiais ou espaços. Apesar de existir uma padronização quantoao versionamento dos pacotes e suas arquiteturas, não é necessário a caracterização destasinformações. Para operações de instalação de pacotes, serão priorizados os pacotes maisrecentes com arquitetura compatível com a máquina, sendo necessário a descriminaçãoda arquitetura x86 para a instalação de pacotes 32 bits em sistemas 64 bits.

Tabela 2 – Principais comandos dos gerenciadores de repositórios mais populares.

Gerenciador Instalar Remover ProcurarAPT # apt-get install <pacote> # apt-get purge <pacote> $ apt-cache search <pacote>YUM # yum install <pacote> # yum purge <pacote> $ yum search <pacote>Emerge # emerge <pacote> # emerge remove <pacote> $ emerge search <pacote>

3.2 Algoritmos de comparação de string

3.2.1 Levenshtein

Duas das abordagens propostas neste trabalho são baseadas nos trabalhos de Vla-dimir Levenshtein. Atuante na área de teoria da informação, código de correção de errose analise combinatória, Levenshtein publicou 1965 na Problemy Peredachi Informatsii otrabalho pelo qual seria reconhecido desde então: Binary codes with correction of droo-ping and insertion of the symbol 1 (LEVENSHTEIN, 1965). Republicado num resumo em1966 com o título de Binary codes capable of correcting deletions, insertions and reversals(LEVENSHTEIN, 1966), a obra tratava do cálculo da distância entre duas strings, ouseja, dada as strings A e B, determinar a quantidade mínima de operações necessáriaspara que, partindo da string A, seja possível obter a string B. Entende-se por operaçõesa inserção, remoção e substituição de um caractere.

3.2.1.1 Exemplo de cálculo de distância entre strings

Para uma maior compreensão do que se trata uma operação e a distância entrestrings, tomemos como exemplos duas palavras, cantar e dançar. Vamos aplicar algumasoperações para, a partir da primeira, alcançar a segunda palavra.

0. cantar

1. dantar (Substituição de “c” por “d”)

2. dançar (Substituição de “t” por “ç”)

32 Capítulo 3. Fundamentação Teórica

Como podemos observar, foram necessárias duas operações para alcançar a palavradançar. Como este é o número mínimo de operações para se obter o resultado desejado,a distância entre elas é 2. É importante observar observar que, mesmo que duas letrasiguais e consecutivas sejam substituídas por outras duas letras idênticas, serão creditadasduas operações, por exemplo as palavras correr e Potter:

0. correr

1. Porrer (Substituição de “c” por “P”)

2. Potrer (Substituição do primeiro “r” por “t”)

3. Potter (Substituição do segundo “r” por “t”)

Precisamos então de 3 operações para alcançar Potter partindo de correr. É dopressuposto que o algoritmo é case-sensitive e sua ordenação é baseada na Tabela AS-CII (American Standard Code for Information Interchange), tabela inicialmente baseadano alfabeto inglês com codificação de 7-bits por caractere em um intervalo de até 128caracteres - imprimíveis ou não (SHIREY, 2007).

3.2.1.2 Distância de Levenshtein

Nos trabalhos de Levenshtein de 1965 e 1966, são apesentadas apenas as possibi-lidades de localização de um caractere perdido, ou do bit perdido na sequência binária.Porém a descrição apresentada para a identificação do caractere no trabalho de 1966 (LE-VENSHTEIN, 1966) possibilitou a implementação do algoritmo no decorrer da história,tendo uma das sua representações mostrada no Código 3.2.

Código 3.1 − Implementação da distância de Levenshtein1 def calculate_distance(s1,s2):2 d = {}3 lenstr1 = len(s1)4 lenstr2 = len(s2)5 for i in xrange(-1,lenstr1+1):6 d[(i,-1)] = i+17 for j in xrange(-1,lenstr2+1):8 d[(-1,j)] = j+19

10 for i in xrange(lenstr1):11 for j in xrange(lenstr2):12 if s1[i] == s2[j]:13 cost = 014 else:

3.2. Algoritmos de comparação de string 33

15 cost = 116 d[(i,j)] = min(17 d[(i-1,j)] + 1, # deletion18 d[(i,j-1)] + 1, # insertion19 d[(i-1,j-1)] + cost, # substitution20 )2122 return d[lenstr1-1,lenstr2-1]

Como pode-se observar, a implementação do cálculo da distância utiliza progra-mação dinâmica a partir de operações de inserção, remoção e substituição. Tal abordagemfacilita a inserção de novas operações, conforme apresentado na próxima subseção.

3.2.2 Damerau-Levenshtein

A distância de Damerau-Levenshtein é uma variação da distância de Levenshtein(LEVENSHTEIN, 1965), havendo ainda a adição da transposição no set de operaçõesbásicas. Em seus estudos, Damerau apresentou que mais de 80% dos erros de escritaoriundo de humanos estavam relacionados às operações de falta de caractere, excesso decaracteres, substituição de caracteres ou transposição de caracteres (DAMERAU, 1964).

Por considerar a transposição de dois caracteres adjacentes, a distância de Damerau-Levenshtein abriu portas para um novo padrão de métricas, as biológicas, no campo demensurar a variação entre moléculas de DNA. Esta seria a brecha necessária para quesurgissem outros métodos de analise de moléculas de DNA baseadas na comparação destrings, tais como o algoritmo de Needleman–Wunsch (NEEDLEMAN; WUNSCH, 1970)e o de Smith-Waterman (SMITH; WATERMAN, 1981), apresentado na Seção 3.2.3.

3.2.2.1 Implementação

Para melhor contextualização da diferença entre o método tradicional de cálculo dedistância e o modelo de Damerau-Levenshtein, consideremos a seguir uma visão atômicade como seria o procedimento do cálculo da distância de Levenshtein, conforme mostradono Código 3.2.

Código 3.2 − Visão atômica do cálculo da distância de Levenshtein1 def levenshtein_distance(s1, s2):2 lenstr1 = len(s1)3 lenstr2 = len(s2)4 d = initialize_distance(lenstr1,lenstr2)56 d = calculate_distance(lenstr1,lenstr2,d)7

34 Capítulo 3. Fundamentação Teórica

8 return d[lenstr1-1,lenstr2-1]

O Código 3.2 serviria tanto para o modelo tradicional como para o de Damerau-Levenshtein, necessitando apenas implementar o método calculate_distance() de formadistinta. O Código 3.3 representa como seria a implementação para o modelo de Damerau-Levenshtein.

Código 3.3 − Implementação da distância de Damerau-Levenshtein1 def calculate_distance(lenstr1,lenstr2,d):2 for i in xrange(lenstr1):3 for j in xrange(lenstr2):4 if s1[i] == s2[j]:5 cost = 06 else:7 cost = 18 d[(i,j)] = min(9 d[(i-1,j)] + 1, # deletion

10 d[(i,j-1)] + 1, # insertion11 d[(i-1,j-1)] + cost, # substitution12 )13 if i and j and s1[i]==s2[j-1] and s1[i-1] == s2[j]:14 d[(i,j)] = min (d[(i,j)], d[i-2,j-2] + cost) # transposition1516 return d

A distinção do método de Damerau-Levenshtein para o modelo tradicional é apenasa inserção das linhas 13 e 14 do Código 3.3, que realiza a transposição dos caracteres,quando for o caso, ao custo de uma única operação.

3.2.3 Smith-Waterman

Proposto em 1981 por Temple F. Smith e Michael S. Waterman (SMITH; WA-TERMAN, 1981) com o intuito de localizar sequências moleculares semelhantes, estealgoritmo de programação dinâmica é hoje amplamente utilizado para a localização deregiões similares entre strings e nas sequências de proteínas ou nucleotídeos.

O algoritmo trabalha com o alinhamento de strings no intuito de buscar a maiorsemelhança entre elas. Considerando este fator, é interessante que as duas strings con-tenham uma quantidade de caracteres igual ou próxima, visto que a string com maiorquantidade de caracteres provavelmente terá suas bordas ignoradas no final. Como resul-tado, podemos obter melhores resultados com comparações de strings que os algoritmosde Leveinstein quando tratamos de busca por radicais. Todavia uma comparação usandopalavras com uma diferença significativa na quantidade de caracteres poderá resultar em

3.2. Algoritmos de comparação de string 35

uma perda de desempenho devido ao número de permutações necessárias para localizar omelhor alinhamento.

3.2.3.1 Algoritmo

De acordo com o artigo de Smith e Waterman (SMITH; WATERMAN, 1981),o algoritmo pode ser apresentado da seguinte forma: Considerando as strings 𝑎 e 𝑏 detamanhos 𝑛, 𝑚 respectivamente e 𝑠(𝑎, 𝑏) a função de similaridade do universo a ser con-siderado2, é montada uma matriz 𝐻 para encontrar os dois pares com maior grau desimilaridade sendo 𝑊𝑖 a nota de lacuna3.

Valores preliminares de 𝐻 tem a interpretação de que 𝐻(𝑖, 𝑗) tem a máxima simi-laridade de duas strings que possuem final 𝑎𝑖 e 𝑏𝑗 respectivamente. Os valores de 𝐻(𝑖, 𝑗)podem ser obtidos através das Equações 3.1 e 3.4:

𝐻(𝑖, 0) = 0, 0 ≤ 𝑖 ≤ 𝑚 (3.1)

𝐻(0, 𝑗) = 0, 0 ≤ 𝑗 ≤ 𝑛 (3.2)

𝐻(𝑖, 𝑗) = max{𝐴(𝑖, 𝑗), 𝐵(𝑖, 𝑗), 𝐶(𝑖, 𝑗), 0}, 1 ≤ 𝑖 ≤ 𝑛 e 1 ≤ 𝑗 ≤ 𝑚 (3.3)

onde

𝐴(𝑖, 𝑗) = 𝐻(𝑖 − 1, 𝑗 − 1) + 𝑠(𝑎𝑖, 𝑏𝑗) (3.4)

𝐵(𝑖, 𝑗) = max𝑘≥1

{𝐻(𝑖 − 𝑘, 𝑗) − 𝑊𝑘} (3.5)

𝐶(𝑖, 𝑗) = max𝑙≥1

{𝐻(𝑖, 𝑗 − 𝑙) − 𝑊𝑙} (3.6)

Montada a matriz 𝐻, para obter o melhor alinhamento, o algoritmo começa como maior valor na matriz com índice (𝑖, 𝑗), retornando em sentido a célula (0, 0), seguindopelos pontos (𝑖 − 1, 𝑗), (𝑖, 𝑗 − 1), ou (𝑖 − 1, 𝑗 − 1).

A fórmula para 𝐻(𝑖, 𝑗) considera as possibilidades de fim da string para qualquer𝑎𝑖 ou 𝑏𝑗, tal que:

1. Se 𝑎𝑖 e 𝑏𝑗 forem associados, a similaridade será dada pela Equação 3.7:

𝐻𝑖−1,𝑗−1 + 𝑠(𝑎𝑖, 𝑏𝑗) (3.7)

2. Se 𝑎𝑖 está ao fim de uma remoção de largura 𝑘, a similaridade será dada pela Equação3.8:

𝐻𝑖−𝑘,𝑗 − 𝑊𝑘 (3.8)2 Smith considerava apenas as letras A,C,U,G devido ao algoritmo ser voltado para identificação de

similidades genéticas, todavia a generalização para as demais letras do alfabeto não invalida o algo-ritmo.

3 Também conhecida como gap-scoring ou gap-penalty.

36 Capítulo 3. Fundamentação Teórica

3. Se 𝑏𝑖 está ao fim de uma remoção de largura 𝑙, a similaridade será dada pela Equação3.9:

𝐻𝑖,𝑗−𝑙 − 𝑊𝑙 (3.9)

4. Por fim são incluídos sentinelas a fim de evitar o cálculo de similaridades negativas.

3.2.3.2 Implementação do algoritmo

Conforme citado no Capítulo 2, este trabalho tem por objetivo propôr uma melhorqualificação das saídas das buscas, e não a implementação dos algoritmos de comparaçãode strings. Sendo assim, estão sendo utilizadas bibliotecas já desenvolvidas e que estão dis-poníveis para uso. Para o algoritmo de Smith-Waterman não foi diferente, sendo utilizadauma das bibliotecas disponíveis para Python chamada swalign4.

4 A biblioteca pode ser encontrada em <https://pypi.python.org/pypi/swalign/>, tendo seu códigodisponibilizado em <https://github.com/mbreese/swalign>.

37

4 Delimitação do Assunto

Este trabalho visa apresentar métodos de qualificação dos resultados de buscapor pacotes de repositórios. Tendo em vista a proximidade dos resultados atualmenteapresentados pelos gerenciadores de repositórios, o universo de estudo de gerenciadoresserá restringido para apenas um, a fim de manter o foco na busca de melhores qualifica-ções e assim apresentar propostas que possam ser utilizadas nos distintos gerenciadoresdisponíveis.

Para tal, será usado como base de estudo o gerenciador APT, devido a sua maiorpopularidade. A disponibilidade de interfaces em Python para o gerenciador é interessantetambém. Devido a simplicidade da linguagem para a prototipação de código, a disponibili-dade de algoritmos de comparação de strings já existentes e simplicidade na manipulaçãode strings faz da linguagem Python uma escolha interessante para o desenvolvimento desteestudo.

Mesmo havendo um interesse em contribuir com a comunidade livre e com a evo-lução do sistema Linux para um estado mais próximo dos usuários leigos da plataforma,no primeiro momento o foco do trabalho não é apresentar alternativas otimizadas e comgrande performance. Tendo em vista haver um interesse em avaliação dos algoritmos decomparação de strings, os primeiros protótipos apresentam soluções que podem levar maisde 50 segundos para a apresentação de resultados.

Outro ponto a se frisar é que, mesmo o APT sendo hoje um conjunto de aplicações,ele é predominantemente escrito em linguagem C++. A apresentação de resultados destetrabalho, sendo escrita em Python, apresenta uma performance inferior se comparada comtodo o resto da aplicação a qual o APT representa.

39

5 Metodologia

5.1 Levantamento bibliográfico

Com o auxílio de portais como o Periódicos Capes1, ebrary2 e Google Acadêmico3,foram levantado estudos em string matching que pudessem vir a ser interessantes paraa qualificação das saídas das buscas. Por ser uma área estudada até mesmo antes damodernização e popularização de computadores, sejam por fins militares ou puramentecientíficos, este foi um dos pontos de difícil escolha, devido a vasta diversidade de métodosque é possível encontrar. Em estudos recentes como o de Xu (XU et al., 2013) comprocessamento usando GPUs ou mais antigos como o de Galil (GALIL; GIANCARLO,1988), um dos nomes que normalmente eram citados era o de Levenshtein e seu trabalho de1966 (LEVENSHTEIN, 1966). Este algoritmo por si só apontou outras duas alternativas,sendo uma delas uma variação do primeiro para maior exatidão de resultados. Assim,o levantamento indicava três algoritmos como candidatos para a solução do trabalhoproposto. O algoritmo de Smith-Waterman, a distância de Levenshtein e sua variação, adistância de Damerau-Levenshtein.

5.2 Ferramentas

Tendo como meta abordagens que apresentassem resultados mais intuitivos aousuário, duas escolhas deviam ser tomadas para objetividade do estudo: a escolha daplataforma e gerenciador a ser adotado como base do estudo e a linguagem de desenvol-vimento do trabalho.

Dentre os grandes grupos que a comunidade Linux se divide, distribuições oriundasdo Debian e do Slackware são as predominantes. Dentre estas duas e suas ramificações, oUbuntu é uma das distribuições mais indicadas e adotadas por pessoas que estão aden-trando no mundo Linux. Desta forma o APT tornou-se o candidato escolhido dentre ogrupo de gerenciadores de repositórios de pacotes. Como distribuição para desenvolvi-mento e teste no estudo, foi adotada o Ubuntu 14.04.

Como intuito de agilizar os ensaios e protótipos, foi adotada a linguagem Pythonpor apresentar uma interface de interação com o gerenciador de pacote escolhido para usoneste trabalho, o APT e por ser de fácil prototipagem. Para a edição de texto foi utilizado

1 Disponível em <www.periodicos.capes.gov.br>2 Disponível em <www.ebrary.com>3 Disponível em <scholar.google.com.br>

40 Capítulo 5. Metodologia

o Sublime-Text 2 com plugins do pylint e PEP8 na tentativa de manter a padronizaçãode código, documentação, coesão e coerência do protótipo.

Como forma de controle do tempo e no intuito de manter o desenvolvimento maispróximo do planejado, foi utilizado o Trello para lançar as atividade e definir as dataslimites para entregas, fazendo com que a metodologia aproximasse à programação extrema(eXtreme Programming) ao apresentar contextos como fases pequenas (uma ou duassemanas), design simples, padronização e refatoração de código.

5.3 Algoritmos PropostosSendo o interesse do estudo apresentar alternativas para a qualificação dos resulta-

dos de uma busca apresentado hoje no gerenciador e não novos algoritmos de aproximaçãode string, foram priorizados algoritmos de implementação pouco rebuscada, que apresen-tassem bons resultados de comparação de strings e que já estivessem implementadosem linguagem Python. Desta forma, foram escolhidos três algoritmos disponibilizados noPyPI. São eles:

swalign Pacote que oferece o algoritmo de comparação de Smith-Waterman. Utilizada aversão 0.3.1.

python-Levenshtein Pacote que oferece o algoritmo de comparação de Levenshtein.Utilizada a versão 0.11.2.

pyxDamerauLevenshtein Pacote que oferece o algoritmo de comparação de Damerau-Levenshtein. Utilizada a versão 1.2.

Também foi utilizado o algoritmo de match exato, no qual deve-se encontrar astring procurada na íntegra no nome do pacote. Esta busca já é implementada no processode search do APT, porém ela aparece em um segundo patamar de ordenação. Assim, foiimplementado também um método de comparação baseada apenas no match exato dastring de entrada em relação ao nome do pacote.

5.4 Execução dos experimentosDefinido os algoritmos que seriam utilizados no estudo, iniciou-se então a fase de

prototipagem de código. O primeiro passo foi a familiarização com o pacote apt, dis-ponibilizado por padrão na instalação do python2.7 nas distribuições Debian-like. Estepacote possibilita a busca, instalação e remoção de pacotes. Para tal foi utilizada a classeapt.cache.Cache que nos possibilita verificar a existência de um pacote na lista de can-didatos por meio da interface __getitem__ padrão do Python. O Código A.1 apresenta

5.4. Execução dos experimentos 41

a versão final deste protótipo, onde se era testado por padrão no método a procura einstalação do pacote git enquanto no método principal se testava as mesmas rotinas parao inexistente pacote gito.

O estudo deste pacote possibilitou a evolução de um esqueleto de código quepermitiria o teste dos distintos algoritmos de string-matching. O primeiro a ser escrito foio de match exato, apresentado no Código A.2. Este esqueleto oferecia elementos básicosdos protótipos que seriam criados a seguir. São eles:

Classe Pack Classe básica construída para armazenar os resultados obtidos dos algorit-mos e posteriormente ordená-los. É formada basicamente pelo método de formataçãode impressão do pacote, o nome do pacote, o ratio do pacote (usado para classifi-cação) e os métodos que podem vir a ser utilizados pelas rotinas de ordenação delistas.

_parser Objeto responsável por realizar o parser das aplicações, oferecendo flags decontrole, como quantidade máxima a ser listada no resultado, ratio mínimo a serimpresso, inclusão de prefixos e sufixos comuns ao nome do pacote procurado paraclassificação e a opção de executar um pool de threads na rotina a fim de reduziro tempo de execução. Esta última opção foi classificada como depreciada devido ainstabilidade que gerava no momento da ordenação dos pacotes.

Este modelo foi fundamental para a escrita dos outros três protótipos deste tra-balho, apresentados nos Código A.3, Código A.4 e Código A.5 do Apêndice A destedocumento. Como a estrutura do protótipo era mantida para os demais algoritmos, oúnico momento de retrabalho foi com o algoritmo de Smith-Waterman, onde o pacoteretornava uma lista de valores que deviam ser classificados, o que necessitou a reescritade um método de ordenação dos pacotes, já que para o algoritmo oferecido pelo pacoteem especial não havia um retorno de uma simples distância ou ratio de aproximação.

Para a obtenção dos resultados, foi utilizado um CoreTM i7 CPU 870 (2.93GHz) e3.8𝐺𝐵 de RAM rodando sistema Ubuntu 14.04 LTS 64-bits. Os comandos foram todosexecutados em primeiro plano sem outra aplicação rodando em conjunto e foram-se efe-tuados cinco medidas consecutivas do tempo e retirada a média entre elas. A medida detempo foi obtida executando a chamada das aplicações precedidas do comando time etomado como resultado o valor retornado para o usuário. Na Figura 3 é possível observarum exemplo da procura pelo pacote xpto no apt. Neste exemplo, o valor considerado foio de 890 ms.

42 Capítulo 5. Metodologia

Figura 3 – Exemplo do uso do comando time

5.5 Funcionalidades descartadasTambém foi implementada a possibilidade de uso do padrão thread pool para re-

duzir o tempo de execução até a obtenção dos resultados. Todavia, foi encontrada adificuldade em manter a ordenação das listas, fazendo com que a opção fosse descontinu-ada até segundo momento, porém não totalmente descartada, visto que em alguns testeshouve redução de aproximadamente um terço do tempo gasto sem o uso de threads.

43

6 Resultados

Para validação dos protótipos, foram escolhidos 7 (sete) dentre os 30 (trinta) pa-cotes mais instalados segundo o Popcorn-Ubuntu e realizado o teste de busca com cadaum destes e os protótipos. Para efeito de comparação, os testes foram realizados tambémcom o apt e o apt-cache. Os tempos obtidos foram apresentados na Tabela 3. Para umamelhor apresentação dos dados, buscas com mais de 100 resultados foram desconsideradose identificadas no final da tabela. As opções de uso de pool de threads não foram utilizadasdevido a sua instabilidade no momento de ordenação dos resultados.

Tabela 3 – Comparação de resultados

Pacote apt apt-cache Exact Match Levenshtein Smith-Watermanposição 27 3 1 1 1

ncurses-base dimensão 37 37 1 − −tempo [s] 0.874 0.349 1.146 9.539 52.212posição *** *** 48 1 1

sed dimensão *** *** * − −tempo [s] 0.968 0.358 1.102 9.125 16.421posição 6 1 1 2 1

bash dimensão * * 13 − −tempo [s] 0.901 0.335 1.142 9.343 20.518posição *** * * 2 1

tar dimensão * * * − −tempo [s] 0.923 0.373 1.137 9.028 16.02posição 13 2 1 1 1

perl-base dimensão 16 16 2 − −tempo [s] 0.936 0.311 1.116 9.36 41.548posição * 52 23 1 1

mount dimensão * * 37 − −tempo [s] 0.895 0.338 1.121 9.082 24.848posição 23 5 1 1 1

gzip dimensão * * 5 − −tempo [s] 0.876 0.324 1.103 9.482 20.163

* Acima de 100 pacotes.

** Acima de 1000 pacotes.

*** Acima de 10000 pacotes.

− Quantidade desconsiderada

O que podemos observar segundo a Tabela 3 é um certa deficiência em apresentaros pacotes realmente desejados no topo da lista de possibilidades quando se trata dosmétodos padrões de busca, apt e apt-cache. Com a busca realizada no apt, a busca pelopacote bash foi a mais bem sucedida, posicionando o pacote desejado na 6a posição, porémteve resultados terríveis quando observado a busca pelos pacotes sed e tar, onde ambos

44 Capítulo 6. Resultados

apareciam na lista, após a 10.000a posição

Devido o formato como os protótipos de Levenshtein e Smith estão escritos, épossível se imprimir uma comparação com toda a lista de pacotes disponíveis na cache.Assim, apenas os 50 primeiros pacotes eram impressos para verificação. Assim, a linhadimensão da tabela para estes algoritmos foi desconsiderada.

Figura 4 – Amostra de comparação dos resultados

A Figura 4 apresenta um gráfico representativo da Tabela 3 com a supressão dosvalores acima de 100 para melhor visualização.

O que podemos observar deste trabalho é um resultado proporcional ao que seesperava, de quanto maior o trabalho ou a complexidade do algoritmo para a comparaçãode strings e qualificação dos resultados, maior será o tempo necessário para a pesquisa,porém melhor serão os resultados obtidos na qualificação.

Podemos compreender também por que o apt-cache é mais utilizado que o próprioapt. Por ordenar todos os pacotes que retornam da pesquisa sem considerar a string deentrada, o apt em momento algum apresentou resultados melhores que o apt-cache eainda obteve um tempo de resposta aproximadamente 3 vezes maior. Se o algoritmode busca atual do apt fosse substituído pelo modelo do Exact Match, ele apresentariaresultados melhores que o do apt-cache gastando cerca de 300 ms a mais que gastaatualmente. Porém, ambos algoritmos deixariam a desejar na apresentação de pacotesquando ocorresse uma escrita errada do pacote, visto que nenhum deles trata o caso deerros ortográficos.

Uma situação ideal seria obter os resultados alcançados com o algoritmo de Smith-Waterman com o tempo de resposta que o apt-cache leva atualmente. Porém a realidadeé que o tempo gasto pelo algoritmo de Smith-Waterman é hoje impraticável, visto quequanto maior o tamanho do nome do pacote, maior é o tempo de resposta, levando a

45

gastar quase 1 (um) minuto para uma busca pelo pacote ncurses-base. Porém o tempogasto pelo algoritmo de Levenshtein se mostra válido para futuros estudos de otimizaçãoe inclusão nas rotinas de busca quando retornar poucos pacotes ou nenhum pacote, consi-derando assim que possa ter acontecido um erro de digitação. Neste caso seria importanteapresentar ao usuário que existe a possibilidade de escrita incorreta de pacote antes daapresentação dos resultados.

Tabela 4 – Comparação de resultados com entradas contendo erros de ortografia

Pacote apt apt-cache Exact Match Levenshtein Smith-Watermanpitom-dev posição 0 0 0 15 11

[python-dev] dimensão 0 0 0 − −tempo [s] 0.894 0.325 1.1 9.443 45.148

gyth-core posição 0 0 0 1 16[git-core] dimensão 0 0 0 − −

tempo [s] 0.872 0.316 1.124 9.757 40.694libbesh posição 0 0 0 4 2

[libbash] dimensão 0 0 0 − −tempo [s] 0.816 0.331 1.121 9.481 32.686

g-zip posição 0 0 0 1 1[gzip] dimensão 0 0 0 − −

tempo [s] 0.881 0.312 1.118 9.237 24.224

− Quantidade desconsiderada

Também foi verificado uma busca apenas com a escrita errada de pacotes parasimular o desconhecimento do nome do pacote pelo usuário, fazendo com que fosse influ-enciado apenas pela fonética do pacote, tanto para simular um casual erro de digitaçãoque se passa despercebido. A Tabela 4 apresenta estes resultados para alguns pacotes- contendo entre colchetes o nome correto do pacote. Como já é de conhecimento, asaplicações apt e apt-cache não possuem algoritmo que possa buscar por pacotes com onome semelhante ao digitado quando não há resultados. Desta forma, as saídas para estasaplicações foram nulas devido a não existir um pacote com o nome fornecido na busca.Por fazer um processo de busca exata, o algoritmo de nome exato também não conseguiuencontrar nenhum pacote para apresentar de resultado quando era fornecido um nomeinexistente dentre os pacotes disponíveis.

Para os algoritmos de Levenshtein e Smith-Waterman os resultados já são bemdiferentes, já que ambos apresentam resultados baseados em aproximação de nomes. Oalgoritmo de Levenshtein conseguiu manter três dos quatro testes entre os cinco primeirosresultados. Já o de Smith-Waterman conseguiu manter apenas em metade dos casos opacote desejado entre os cinco primeiros - mesmo tendo um melhor resultado na procurapelo pacote pithom-dev onde foram inseridos dois erros ortográficos.

O provável motivo pelo qual os resultados no algoritmo de Levenshtein tenha sesaído melhor nestes teste decorre do fato de apenas este protótipo estava preparado para

46 Capítulo 6. Resultados

melhor classificar os pacotes que tivessem alguns prefixos ou sufixos predefinidos (lib, -core, -dev, -commom e -devel). Todavia, podemos observar um aumento acentuado notempo necessário para a realização da busca do algoritmo de Smith-Waterman. Este semanteve pouco acima da média de tempo anterior, subindo da média de 27.39 segundosda Tabela 3 para 35.688 segundos na Tabela 4, implicando em um aumento de quase 70%da média do tempo dos pacotes.

47

7 Cronograma

Abaixo segue o gráfico de gantt de evolução do trabalho contabilizadas em semanas,com evolução de tarefas estimadas, tendo a primeira semana em 21 de Agosto de 2013.

17 de novembro

Semanas

1 2 3 4 5 6 7 8 9 10 11 12 13 14

Fundamentação

1

2

3

4

Prototipagem

5

6

7

8

Documentação

9

10

11

12

13

14

48 Capítulo 7. Cronograma

Legenda dos índices do gráfico:

1 Levantar documentação oficial das distribuições.

2 Levantar gerenciadores das principais distribuições Linux.

3 Configurar máquinas com o Vagrant.

4 Estudar documentação de String Matching.

5 Escrever primeiro protótipo.

6 Testar com 5 pacotes.

7 Escrever segundo protótipo.

8 Escrever terceiro protótipo.

9 Estruturar documento do Trabalho de Conclusão de Curso.

10 Escrever fundamentação teórica.

11 Escrita do Trabalho de Conclusão de Curso.

12 Revisão do Trabalho de Conclusão de Curso.

13 Planejamento da Apresentação.

14 Entrega.

Este trabalho foi planejado com entregas semanais com três grandes frentes: estudoda fundamentação teórica, prototipagem e documentação. O gráfico de gantt a seguirapresenta uma aproximação do desenvolvimento deste trabalho, tendo ocorrido algumasadaptações durante o período da fundamentação1.

7.1 Planejamentos futurosPara a continuação do estudo, algumas atividades já estão planejadas. São elas:

1. Fork do repositório APT e configurações de ambiente necessárias.

2. Revisão e estudo do código APT.

3. Busca por bibliotecas contendo o algoritmo escolhido implementadas em C/C++2.1 Até o desenvolvimento desta seção, o período de entrega ainda não havia ocorrido, fazendo com que

a parte final do gráfico ainda seja estimada.2 Preferência por bibliotecas em C++ por melhor compatibilidade e mais opções de funcionalidades ou

recursos

7.1. Planejamentos futuros 49

4. Tradução do código Python para C++3.

5. Fusão do algoritmo ao APT.

Implementadas estas atividades, o objetivo do trabalho já estaria alcançado, poréma possibilidade de sobra de tempo permitiria que algumas funcionalidades pudessem vira serem estudadas e planejadas para a implementação, tais como:

Novas opções de saída/ ordenação dos pacotes Pacotes poderiam ser ordenados al-fabeticamente, por proximidade com a string de entrada, por ordem de apresentaçãono repositório ou outras, sendo esta ordenação ser escolhida por flags passadas du-rante a pesquisa.

Otimização do algoritmo Um estudo para que o algoritmo fizesse uso de threads oumultiprocessos para obter um ganho de performance. Talvez um estudo de tecno-logias ainda mais alternativas como o uso de frameworks como CUDA ou OpenCLpara fazer de uso de recursos de GPU para ganho de desempenho.

Inclusão de possibilidade de prefixos e/ ou sufixos A possibilidade de escolher comflags o uso de prefixos ou sufixos para um melhor refinamento e classificação dospacotes de maior interesse.

Devido ao resultado obtido na primeira parte do estudo, a adoção de uma médiade duas semanas no máximo para cada atividade viria a ser uma escolha interessantepara a segunda etapa do estudo, porém seriam necessários ao menos dez semanas paraa obtenção dos resultados mínimos desejados para objetivo e até dezesseis semanas paraa elaboração com todos os recursos desejados. É de interesse que as alterações sejamrealmente adotadas pela comunidade, de forma que a consideração de ao menos umasemana para que a equipe do APT pudesse estudar o pull request gerado pelo estudo deveser considerado no cálculo do tempo disponível.

3 Existe a possibilidade de se considerar outras linguagens além do C++ para implementação final,porém devido o APT estar em C++, uma tradução para esta linguagem proporcionaria uma melhorcompatibilidade, oferecendo talvez tempo para a implementação de recursos sobressalentes para aaplicação.

51

Referências

BAILEY, E. C. Maximum RPM: Taking the red hat package manager to the limit. [S.l.]:Red Hat Software, 1997. Citado na página 27.

BECK, M.; MAGNUS, R.; KUNITZ, U. Linux Kernel Internals with Cdrom. [S.l.]:Addison-Wesley Longman Publishing Co., Inc., 2002. Citado na página 27.

BRETTHAUER, D. Open source software: A history. 2001. Citado na página 27.

BROWN, R.; PICKARD, J. Yum (Yellowdog Updater, Modified) HOWTO. 2003.Disponível em: <http://www.phy.duke.edu/~rgb/General/yum_HOWTO/yum_HOWTO.pdf>. Acesso em: 6 de Novembro de 2014. Citado na página 29.

BROWN, R. G. Yum: Yellowdog updater, modied. Dezembro 2003. Disponível em:<http://www.phy.duke.edu/~rgb/General/yum_article/yum_article.pdf>. Acesso em:6 de Novembro de 2014. Citado na página 29.

DAMERAU, F. J. A technique for computer detection and correction of spelling errors.Communications of the ACM, ACM, v. 7, n. 3, p. 171–176, 1964. Citado na página 33.

DEBIAN GNU/LINUX. The Debian GNU/Linux FAQ. [S.l.], 2013. Citado na página28.

FUSCO, J. The Linux programmer’s toolbox. [S.l.]: Pearson Education, 2007. Citado napágina 29.

GALIL, Z.; GIANCARLO, R. Data structures and algorithms for approximate stringmatching. Journal of Complexity, Elsevier, v. 4, n. 1, p. 33–72, 1988. Citado na página39.

GARBEE, B. et al. A brief history of debian. the package: Debian-history, 2008. Citadona página 28.

GENTOO FOUNDATION, INC. Gentoo Linux Documentation – Portage Features.[S.l.], 2001. Disponível em: <http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=3>. Acesso em: 7 de Novembro de 2014. Citado na página 30.

GUO, H.; WU, Y. Integrated embedded solution for vehicle communication & control.Institute for Infocomm Research, Connexis Singapore, 2009. Citado na página 30.

HEKMAN, J. P.; ORAM, A. Linux in a Nutshell. [S.l.]: O’Reilly & Associates, Inc.,1996. Citado na página 30.

LEVENSHTEIN, V. I. Binary codes with correction of drooping and insertion of thesymbol 1. In: Problemy Peredachi Informatsii. [S.l.: s.n.], 1965. v. 1, p. 12–25. Citado 2vezes nas páginas 31 e 33.

LEVENSHTEIN, V. I. Binary codes capable of correcting deletions, insertions andreversals. In: Soviet physics doklady. [S.l.: s.n.], 1966. v. 10, p. 707. Citado 3 vezes naspáginas 31, 32 e 39.

52 Referências

NEEDLEMAN, S. B.; WUNSCH, C. D. A general method applicable to the search forsimilarities in the amino acid sequence of two proteins. Journal of molecular biology,Elsevier, v. 48, n. 3, p. 443–453, 1970. Citado na página 33.

RYAN, J. Linux distribution chart. Linux Journal, Belltown Media, v. 2010, n. 194, p. 4,2010. Citado na página 30.

SHIREY, R. RFC 4949–Internet Security Glossary. [S.l.]: Version, 2007. Citado napágina 32.

SMITH, T. F.; WATERMAN, M. S. Identification of common molecular subsequences.Journal of molecular biology, Elsevier, v. 147, n. 1, p. 195–197, 1981. Citado 3 vezes naspáginas 33, 34 e 35.

VERMEULEN, S. et al. Gentoo linux x86 handbook. URL: http://www. gentoo.org/doc/en/handbook/handbook-x86. xml, 2005. Citado na página 29.

XU, K. et al. Bit-parallel multiple approximate string matching based on gpu. ProcediaComputer Science, Elsevier, v. 17, p. 523–529, 2013. Citado na página 39.

Apêndices

55

APÊNDICE A – Protótipos elaborados notrabalho

Código A.1 − Protótipo em Python para estudo do pacote apt.1 # -*- coding: utf-8 -*-2 """3 Prototype code45 Prototype code to teste apk API6 """789 def test_install(package_name="git"):

10 """11 function to test a package installation12 """13 try:14 # from apt.cache import Cache as _15 import apt16 # from apt.cache import LockFailedException17 from apt import progress18 except ImportError as error:19 raise error2021 cache = apt.cache.Cache(progress.text.OpProgress())2223 try:24 cache.update(progress.base.AcquireProgress())25 cache.open(progress.text.OpProgress())26 pkg = cache[package_name]27 except KeyError:28 print "{pkg_name} not found".format(pkg_name=package_name)29 return30 except apt.cache.LockFailedException as arg:31 print "Error: {err}".format(err=str(arg))32 return3334 if pkg.is_installed:35 print "{pkg_name} already installed".format(pkg_name=package_name)36 else:37 # select to be installed

56 APÊNDICE A. Protótipos elaborados no trabalho

38 pkg.mark_install()3940 print "Dependeces from %s to be installed:" % package_name41 print cache.get_changes()[0].name,42 for i in cache.get_changes():43 print i.name,4445 if raw_input("\nDo you want to continue? (y/n) ") == ’y’:46 try:47 cache.commit(install_progress=progress.base.InstallProgress())48 except apt.cache.LockFailedException as arg:49 print "Error: {err}".format(err=str(arg))50 else:51 cache.clear()5253 # library compatibility54 try:55 cache.close()56 except AttributeError as error:57 pass58 print "Leaving"5960 if __name__ == ’__main__’:61 test_install(’gito’)

57

Código A.2 − Protótipo do algoritmo de match exato.1 # -*- coding: utf-8 -*-2 """3 Code to rank packages from a search in APT using exact match4 """56 from apt import Cache7 import optparse8 from multiprocessing.pool import ThreadPool as Pool9 _MAX_PEERS = 20

101112 class Pack(object):1314 """Class to handle the package object"""15 name = ’’16 ratio = 01718 def __init__(self):19 super(Pack, self).__init__()2021 def __str__(self):22 return self.name.ljust(50) + ’ ’ + str(self.ratio)2324 def __gt__(self, other):25 return self.ratio > other.ratio2627 def __lt__(self, other):28 return self.ratio < other.ratio2930 def __eq__(self, other):31 return self.ratio == other.ratio3233 def __le__(self, other):34 return self.ratio <= other.ratio3536 def __ge__(self, other):37 return self.ratio >= other.ratio3839 def __ne__(self, other):40 return self.ratio != other.ratio4142 def __hash__(self):43 # return self.ratio44 return hash(self.__str__())

58 APÊNDICE A. Protótipos elaborados no trabalho

4546 def __len__(self):47 return len(self.name)4849 _parser = optparse.OptionParser(50 usage="Use with care",51 description="Search packages"52 )5354 _parser.add_option("--no-suffix",55 dest="suffix",56 action="store_false",57 help="suppres search for suffixes",58 default=True59 )60 _parser.add_option("--no-prefix",61 dest="prefix",62 action="store_false",63 help="suppres search for prefix",64 default=True65 )6667 _parser.add_option("--amount",68 dest="amount",69 type=’int’,70 help="How many print",71 default=5072 )7374 _parser.add_option("--ratio",75 dest="ratio",76 type=’float’,77 help="Minimal ratio to print",78 default=0.079 )8081 _parser.add_option("--multi",82 dest="single",83 action="store_false",84 help="Depraced",85 default=True86 )878889 def _cmp(pack, other):90 """ Ovewriting for compare method"""91 return pack.name < other.name

59

929394 def Thread_Exact(k):95 """ Method to be done by a thread from the pool"""96 pack = args[0]97 if pack in k:98 item = Pack()99 item.name = k

100 item.ratio = 0101 return item102 return None103104105 def Exact_Match(pack):106 """ Method to execute the exact matching """107 cache = Cache()108 if _options.single:109 list_app = []110 for k in cache:111 if pack in k.name:112 item = Pack()113 item.name = k.name114 item.ratio = 0115 list_app.append(item)116 return list_app117 else:118 _pool = Pool(processes=_MAX_PEERS)119 result = _pool.map(Thread_Exact, cache._set)120 return result121122 if __name__ == ’__main__’:123 (_options, args) = _parser.parse_args()124 package_name = args[0]125 suffixes = [’core’, ’dev’, ’commom’, ’devel’]126 prefixes = [’lib’]127128 _options.suffix = _options.prefix = False129130 lista = Exact_Match(package_name)131 if _options.suffix:132 for suffix in suffixes:133 matches = Exact_Match(’{}-{}’.format(package_name, suffix))134 lista.extend(matches)135 if _options.prefix:136 for prefix in prefixes:137 matches = Exact_Match(’{}{}’.format(prefix, package_name))138 lista.extend(matches)

60 APÊNDICE A. Protótipos elaborados no trabalho

139 if _options.suffix and _options.prefix:140 for suffix in suffixes:141 for prefix in prefixes:142 matches = Exact_Match(143 ’{}{}-{}’.format(prefix, package_name, suffix))144 lista.extend(matches)145146 lista = filter(None, lista)147 lista = sorted(lista, cmp=_cmp)148 _options.amount = 300149 for i in lista[:_options.amount]:150 print i151152 print ’%d itens’ % len(lista)

61

Código A.3 − Protótipo do algoritmo de Levenshtein.1 # -*- coding: utf-8 -*-2 """3 Code to rank packages from a search in APT using Levenshtein4 """5 from apt import Cache6 from Levenshtein import ratio7 from exact import Pack, _parser8 from multiprocessing.pool import ThreadPool as Pool9

10 _MAX_PEERS = 20111213 def Thread_Rank(k):14 pack = _args[0]15 item = Pack()16 item.name = k17 item.ratio = ratio(pack, k)18 return item192021 def Rankilist(pack):22 cache = Cache()23 if _options.single:24 list_app = []25 for k in cache:26 item = Pack()27 item.name = k.name28 item.ratio = ratio(pack, k.name)29 list_app.append(item)30 return list_app31 else:32 _pool = Pool(processes=_MAX_PEERS)33 result = _pool.map(Thread_Rank, cache._set)34 return result3536 if __name__ == ’__main__’:37 (_options, _args) = _parser.parse_args()38 package_name = _args[0]39 suffixes = [’core’, ’dev’, ’commom’, ’devel’]40 prefixes = [’lib’]4142 lista = Rankilist(package_name)43 if _options.suffix:44 for suffix in suffixes:

62 APÊNDICE A. Protótipos elaborados no trabalho

45 matches = Rankilist(’{}-{}’.format(package_name, suffix))46 lista.extend(matches)47 if _options.prefix:48 for prefix in prefixes:49 matches = Rankilist(’{}{}’.format(prefix, package_name))50 lista.extend(matches)51 if _options.suffix and _options.prefix:52 for suffix in suffixes:53 for prefix in prefixes:54 matches = Rankilist(55 ’{}{}-{}’.format(prefix, package_name, suffix))56 lista.extend(matches)5758 # ultimo = time.time()59 lista = list(set(lista))60 lista = sorted(lista, reverse=True)61 for i in lista[:_options.amount]:62 print i

63

Código A.4 − Protótipo do algoritmo de Damerau-Levenshtein.1 # -*- coding: utf-8 -*-2 """3 Code to rank packages from a search in APT using Damerau Levenshtein4 """5 from apt import Cache6 from pyxdameraulevenshtein import damerau_levenshtein_distance as ratio7 from exact import Pack, _parser8 from multiprocessing.pool import ThreadPool as Pool9

10 _MAX_PEERS = 20111213 def Thread_Rank(k):14 """ Method to be done by a thread from the pool"""15 pack = _args[0]16 item = Pack()17 item.name = k18 item.ratio = ratio(pack, k)19 return item202122 def Rankilist(pack):23 """ Method to execute the algorithm """24 cache = Cache()25 if _options.single:26 list_app = []27 for k in cache:28 item = Pack()29 item.name = k.name30 item.ratio = ratio(pack, k.name)31 list_app.append(item)32 return list_app33 else:34 _pool = Pool(processes=_MAX_PEERS)35 result = _pool.map(Thread_Rank, cache._set)36 return result3738 if __name__ == ’__main__’:39 (_options, _args) = _parser.parse_args()40 package_name = _args[0]41 suffixes = [’core’, ’dev’, ’commom’, ’devel’]42 prefixes = [’lib’]4344 lista = Rankilist(package_name)

64 APÊNDICE A. Protótipos elaborados no trabalho

45 if _options.suffix:46 for suffix in suffixes:47 matches = Rankilist(’{}-{}’.format(package_name, suffix))48 lista.extend(matches)49 if _options.prefix:50 for prefix in prefixes:51 matches = Rankilist(’{}{}’.format(prefix, package_name))52 lista.extend(matches)53 if _options.suffix and _options.prefix:54 for suffix in suffixes:55 for prefix in prefixes:56 matches = Rankilist(57 ’{}{}-{}’.format(prefix, package_name, suffix))58 lista.extend(matches)5960 # ultimo = time.time()61 lista = list(set(lista))62 lista = sorted(lista)63 for i in lista[:_options.amount]:64 print i

65

Código A.5 − Protótipo do algoritmo de Smith-Waterman.1 # -*- coding: utf-8 -*-2 from apt import Cache3 import swalign4 from exact import Pack, _parser5 from math import fabs6 from multiprocessing.pool import ThreadPool as Pool7 _MAX_PEERS = 2089

10 def _cmp(x, y):11 """ Ovewriting for compare method"""12 if x.ratio[0] == y.ratio[0]:13 if x.ratio[1] == y.ratio[1]:14 if x.ratio[2] == y.ratio[2]:15 if x.ratio[3] == y.ratio[3]:16 return 017 elif x.ratio[3] < y.ratio[3]:18 return -119 else:20 return 121 elif x.ratio[2] < y.ratio[2]:22 return -123 else:24 return 125 elif x.ratio[1] < y.ratio[1]:26 return 127 else:28 return -129 elif x.ratio[0] < y.ratio[0]:30 return -131 else:32 return 1333435 def Thread_Align(k):36 """ Method to be done by a thread from the pool"""37 pack = _args[0]38 item = Pack()39 item.name = k40 alinhamento = sw.align(pack, k)41 item.ratio = (alinhamento.mismatches +42 fabs(len(pack) - len(k)) - alinhamento.matches) + len(pack)43 return item44

66 APÊNDICE A. Protótipos elaborados no trabalho

4546 def SmithWaterman(pack):47 """ Method to execute the algorithm """48 cache = Cache()49 if _options.single:50 list_app = []51 for k in cache:52 item = Pack()53 item.name = k.name54 alinhamento = sw.align(pack, k.name)55 item.ratio = [alinhamento.matches, fabs(len(pack) - len(k.name)),56 alinhamento.score, alinhamento.mismatches]57 list_app.append(item)58 return list_app59 else:60 _pool = Pool(processes=_MAX_PEERS)61 result = _pool.map(Thread_Align, cache._set)62 return result6364 if __name__ == ’__main__’:65 (_options, _args) = _parser.parse_args()66 package_name = _args[0]67 suffixes = [’core’, ’dev’, ’commom’, ’devel’]68 prefixes = [’lib’]6970 match = 271 mismatch = -172 scoring = swalign.NucleotideScoringMatrix(match, mismatch)73 sw = swalign.LocalAlignment(scoring)7475 _options.suffix = _options.prefix = False7677 lista = SmithWaterman(package_name)78 if _options.suffix:79 for suffix in suffixes:80 matches = SmithWaterman(’{}-{}’.format(package_name, suffix))81 lista.extend(matches)82 if _options.prefix:83 for prefix in prefixes:84 matches = SmithWaterman(’{}{}’.format(prefix, package_name))85 lista.extend(matches)86 if _options.suffix and _options.prefix:87 for suffix in suffixes:88 for prefix in prefixes:89 matches = SmithWaterman(90 ’{}{}-{}’.format(prefix, package_name, suffix))91 lista.extend(matches)

67

9293 # ultimo = time.time()94 lista = list(set(lista))95 lista = sorted(lista, reverse=True, cmp=_cmp)96 for i in lista[:_options.amount]:97 print i

Anexos

71

ANEXO A – Figuras

Figura 5 – Heranças de algumas das distribuições Linux existentes hoje1.

1 Fote: www.linux-es.org

72 ANEXO A. Figuras

A Figura 5 apresenta uma visualização de algumas das ramificações que surgi-ram cronologicamente nas distribuições Linux, dando um foco para as três distribuiçõescomentadas neste estudo: Debian, Slackware e Red Hat. A linha na horizontal indica atimeline da distribuição. As reticencias ao final da linha indicam que a distribuição foidescontinuada. As linhas na vertical podem indicar uma ramificação (nova distribuiçãocriada a partir de uma antiga) ou a fusão de distribuições. Linhas na horizontal contendoum circulo no meio do tracejado indicam que alguma distribuição alterou o seu nome(como foi o caso do S.u.S.E para SuSE no ano de 1998). Mesmo que de dificil visualiza-ção do nome das distribuições na imagem, o objetivo dela no trabalho é contextualizar ainfluencia que as distribuições Debian, Slackware e Red Hat tem entre diversas distribui-ções e que novas funcionalidades nelas serão eventualmente adotadas nas suas herdeiras,aumentando a propagação de funcionalidades. Assim, uma nova funcionalidade no De-bian certamente seria adotada na distribuição Ubuntu e suas ramificações, porém novasfuncionalidades no Ubuntu demoram a serem copiadas para o Debian, quando são. Umaadaptação da imagem Linea del tiempo Distribuciones Linux, a imagem pode ser melhorvizualizada em <http://www.linux-es.org/files/distribuciones_en_el_tiempo.png>.