Entrevista com Robert Shingledecker, criador do Tiny Core

RS: Olá Chris, obrigado pela oportunidade. Sou fã do DistroWatch há muitos anos e sempre fico na expectativa pela nova edição do DistroWatch Weekly às segundas-feiras.

Tenho 60 anos, estou aposentado e moro em Fullerton, na Califórnia. Obtive meu bacharelado em matemática em 1971, pela Universidade do Estado da Califórnia. Sou deficiente e estou nos estágios mais avançados da Distrofia Muscular Oculofaríngea. Ela afeta meus olhos, minha fala e eu tenho dificuldade para engolir. Essa distrofia é genética. Eu sei o que me aguarda. Quando estou bem, gosto de escrever e compartilhar código com os outros. Isso mantém a minha mente afiada e longe de pensamentos depressivos sobre meus problemas de saúde. Foi por causa da distrofia que não enviei uma foto recente minha. Espero que compreenda.

RS: Brincar com computadores e linguagens tem sido meu trabalho e meu hobby.

Minha primeira experiência com computadores foi na Burroughs Corp. em 1971. Eu fazia programas de contabilidade com código de máquina (sim, hexadecimal) manualmente em fitas perfuradas. um ano depois eu tive o luxo de ter acesso a um assembler. Por boa parte dos anos 70 eu escrevi grandes pacotes integrados de contabilidade, todos em assembler. Eu tinha clientes por toda a Califórnia, de San Diego a Fresno. Pouco anos depois me pediram que escrevesse em COBOL. Eu era um freelancer que trabalhava à base de contratos, principalmente para as filiais da Burroughs na Califórnia do Sul. O microcomputador Burroughs B20 estava entrando em cena quando fechei meu negócio. O primeiro computador que eu tive foi um Burroughs B80 mini com meu próprio compilador COBOL!

Eu me envolvi com microcomputadores escrevendo assembly 6502 em um Ohio Scientific. Eu odiava Basic. Eu escolhi a linguagem COMAL e fiquei bastante envolvido na promoção dela. Publiquei vários artigos em uma pequena revista chamada COMAL TODAY. Eu tenho um raro IBM COMAL oficial em alemão para IBM PCs. Conheci pessoalmente Børge Christensen, criador do COMAL, e promovia ativamente o COMAL na Califórnia do Sul.

Eu rodava o Minix quando ele era apenas um sistema em disquete e desenvolvi o suporte a discos rígidos. Curti o Coherent OS e fui membro de uma rede UUCP.

Quando optei por um emprego comum de expediente de 9 às 17, fui para a cidade de Garden Grove, na Califórnia, onde apresentei a cidade ao Samba (e depois ao Linux), hospedando uma rede Windows 3.11. Foi a primeira implantação em larga escala do Linux nos Estados Unidos. Eu recebia visitantes de todo o mundo interessados no desenvolvimento. Conheci muitos nomes famosos do software livre, como Linus, Stallman, Maddog, Bob Young e Gaël Duval, e fui convidado para discursar em um painel na primeira Linux World Expo em San Jose sobre a exposição que nossa implantação trouxe ao Linux. Discursei em vários outros eventos depois desse. Geralmente eu era chamado para falar sobre redes da Novell. O maior evento no qual discursei foi a COMDEX.

Deixei a cidade em janeiro de 2000 para me tornar CTO de uma dot-com. Na verdade, fui CTO de várias dot-coms. Foi nela que eu e outro programador criamos appliances em live CD-ROMs com o Linux, incluindo um desktop em live-CD.

Você pode visitar meu site para mais detalhes sobre meus projetos com o Linux.

RS: Eu anoto tudo. O que eu quero dizer é que sempre tenho um caderno para fazer anotações sobre as coisas nas quais estou trabalhando. Cara, eu tenho uma coleção deles só sobre o DSL!

Minhas primeiras anotações sobre o DSL datam de 3 de setembro de 2003. Eu tinha encontrado o DSL na lista do DistroWatch e, como suponho que muitos tenham feito, remasterizei o CD. Talvez muitos não saibam, mas o fundador do DSL, John Andrews, começou a distribuição usando o miniCD de recuperação de 50 MB do KNOPPIX. Ele removeu os aplicativos de recuperação e os substituiu por um desktop, pelo GTK+ e por aplicativos, alguns dos quais eram do DeLI Linux.

Eu me cadastrei no fórum do DSL em setembro de 2003 e mandei um email para o John com alguns patches e sugestões. A princípio, eles eram para pendrives USB e para o cliente NFS. Nos meses seguintes eu contribuí com uma alternativa de backup e restauração, um bash_profile funcional, o bootlocal.sh e um diretório /opt com suporte a escrita. Em janeiro de 2004 recebi a tarefa de criar e manter a imagem ISO do DSL. Depois disso, criei pessoalmente todas as versões a partir da 0.5.3.1 de 15 de janeiro de 2004. Todas as grandes melhorias estruturais do DSL foram criações minhas. Eu estava tentando incluir novos recursos em um live-CD para que houvesse pouca ou nenhuma vantagem em realizar uma instalação tradicional no disco rígido (isso tudo bem antes do Unionfs). Escrevi um artigo com o título “Não é o sistema operacional do seu pai”, no qual eu explicava muito da minha filosofia.

Segui com a criação da instalação frugal, substituí o BusyBox pelas Coreutils do GNU, escrevi a documentação do “Guia de introdução”, criei e introduzi o sistema de extensão MyDSL, bem como as extensões compactadas montáveis em loop, que depois se tornariam a UCI. Introduzi o Lua/FLTK (Flua) para criar umas 50 interfaces gráficas para o DSL. Também integrei o QEMU ao DSL e criei uma versão separada do SYSLINUX. Adicionei os ícones de clique único ou duplo, um gerenciador de layout dos ícones e um desktop com suporte a arrastar e soltar. Adicionei o suporte aos populares Winmodems da Lucent, suporte para inclusão de usuários, implementei o Unionfs e o tipo de extensão UNC, configurei os repositórios, criei a versão PXE, criei os disquetes de inicialização com suporte a USB e incluí o suporte a PCMCIA. Fiz e implementei vários códigos de inicialização novos, como secure, protect, legacy, desktop, icons e waitusb. Criei as bibliotecas usadas pelos scripts do Bash e pela linguagem Lua, bem como os scripts para instalação em pendrives, tanto ZIP quanto HDD. Criei o recurso dpkg-restore, o suporte multiusuário para a instalação no disco rígido e o backup e a restauração via web. Eu também desmontei o KNOPPIX duas vezes (a versão 3.3 para o DSL 0.6 e a versão 3.4 para o DSL 2.0) e compilei o kernel 2.4.31 e todos os módulos para manter o DSL atualizado.

O DSL que você está usando hoje, seja ele 0.6+, 1.x, 2.x, 3.x ou 4.x, é basicamente o resultado dos meus esforços, com a condição de trazer para o DSL os aplicativos em GTK+ do John. Isso para que o DSL continuasse parecendo com o DSL. Eu outras palavras, não era para eu mexer com os aplicativos.

RS: Eu não trabalho mais no DSL por vários motivos, numa soma de ataques e acusações pessoais contra mim, desavenças e diferenças inconciliáveis. Na verdade eu não saí do projeto, eu fui exilado e trancado do lado de fora por John Andrews. Meus posts no blog do DSL, que consistiam de tudo o que eu escrevi, foram apagados. Uma lista que estava sendo montada por terceiros com todas as personalizações do DSL, mostrando principalmente o meu nome como criador dessa inovação, também foi excluída. Foi uma confusão.

A ideia de uma distribuição de núcleo pequeno, que John rejeitou por muitas vezes, era no que eu estava trabalhando enquanto continuava a desenvolver o DSL. John não ficou feliz por eu ter hospedado meu novo trabalho em outro lugar, e desativou todo o acesso que eu tinha. Sendo assim, eu não tinha mais como dar suporte ao projeto.

Então agora a pergunta é, por que eu decidi hospedar meu novo projeto em outro lugar?

Por muitos motivos. Foi a gota d’água. Tanta discórdia, falta de feedback e participação, basicamente o abandono do projeto.

Kent Porter era membro da equipe do DSL. As contribuições dele para as extensões MyDSL foram enormes. Nós lidávamos com centenas de contribuições, recompilávamos todas de acordo com as especificações e ajudávamos os novos usuários com os novos conceitos que eu havia trazido para o DSL. A ajuda e a participação dele ajudaram a dar impulso ao DSL. Chris Livesay também era membro da equipe do DSL. Em 2005, Kent e Chris estavam tentando ajudar na realização de tarefas para liberar John da “Loja do DSL”, de modo que eu talvez obtivesse alguma ajuda no desenvolvimento. Houve um forte desentendimento quanto ao uso das doações para o benefício do DSL, e Kent e Chris foram demitidos imediatamente. Para meu desalento, além de não conseguir a ajuda de que precisava eu ainda acabei encarregado das tarefas do Kent. Mas isso foi só o começo. Quando escrevi o “Livro oficial do Damn Small Linux”, eu incluí uma seção listando as contribuições de Kent. John exigiu que eu removesse o nome de Kent do livro. Eu não pude aceitar, e queria que o nome do Kent aparecesse no livro de qualquer jeito, então usei de propósito uma foto da tela que tinha o nome dele.

O tempo foi passando, e John ia ficando cada vez menos disponível. Ele já não revisava mais o meu trabalho. Quando pedi a ajuda dele com as extensões, não houve resposta. Ele não dizia “não”, ele simplesmente me ignorava. Como meus problemas de saúde têm um impacto sobre o que eu posso fazer, pedi ajuda novamente. Nunca recebi ajuda alguma em tarefas como o gerenciamento das extensões, como para movê-las da seção de testes para a categoria adequada. John parou de atualizar a seção de “marcos” do site. Ele apagou o blog do DSL e postou que ele voltaria. Um ano depois… nada. Ele parou de atualizar o site, e também de atualizar a seção de notas. Ao invés de conseguir a ajuda que eu pedi, fiquei cada vez mais carregado, tendo que fazer tudo, não apenas cuidando do desenvolvimento, mas também administrando o site e processando as extensões. Eu não tinha como dar conta de tudo aquilo.

Num dado momento, o fórum do DSL começou a receber spams pornográficos. O John configurou um sistema de aprovação de novos usuários, mas ele raramente aprovava as contas novas. Enquanto isso, eu via crescer o número de usuários aguardando aprovação. Comecei a ver usuários criando tópicos em outros sites reclamando, perguntando como fazer para serem aprovados e poderem postar. A lista chegou a 23.000 usuários. Alguns esperaram mais de um ano para serem aprovados.

Nessa época o John já não me dava nenhuma reposta. E ficou pior. Postei um tópico, mas John não respondeu. Deixei recados pelo telefone e mandei vários emails. Como muitos no fórum, achei que ele estava de férias. Depois, até o registro do domínio venceu.

E ainda havia a loja do DSL. Eu já havia saído desse setor e não recebia mais os lucros das operações da loja, mas ainda recebia emails com reclamações sobre produtos que não eram entregues. Eu respondia a esses emails encaminhando-os para o John e informando ao usuário que eu era um desenvolvedor, e não era afiliado às operações da loja. Eu nunca havia sido um empregado na operação do John. Originalmente tínhamos um acordo de divisão dos lucros, mas na maioria das vezes ele dizia que não havia lucro depois de pagar aos empregados da loja. Mais tarde eu pedi e me foi concedido um acordo baseado em anúncios do Google e doações.

Bom, você já deve ter entendido a situação. É bastante óbvia. Por que eu iria querer continuar incluindo meus esforços solitários em um ambiente desses? É óbvio que muitos outros também estavam sendo ignorados pelo John. Eu queria desesperadamente encontrar um novo lar para o meu trabalho. Até postei sobre o assunto no fórum. Kent Porter e Chris Livesay tiveram a gentileza de me oferecer a hospedagem, e pediram que eu selecionasse uma equipe de desenvolvimento. Aceitei a oferta deles e montei meu “time dos sonhos” de desenvolvimento.

Finalmente eu via uma luz no fim do túnel. Finalmente eu teria ajuda. Finalmente uma equipe que apreciava o meu trabalho, que entendia a minha filosofia de como o Linux podia funcionar. Finalmente uma equipe que poderia levar adiante o meu design, melhorar o tempo de inicialização, trazer avanços para meus conceitos de extensão.

A melhor decisão que tomei foi a de hospedar meu novo projeto em outro lugar. Quanto ao DSL, foi pena acabar como acabou, mas acho que foi melhor assim.

RS: Quando me perguntam “por que outra distribuição”?, eu me lembro da Linux World 2005. Foi lá que, ao tentar apresentar o DSL, fui logo desprezado com um comentário do tipo “tá bom, você e um monte de moleques de treze anos fazem ‘suas próprias’ distribuições Linux”. Mas quando esse fornecedor viu o que eu tinha nas mãos, percebeu que se destacava naquele mar de marasmo. A minha filosofia é a de oferecer uma maneira única de rodar o Linux. Eu não promovo instalações tradicionais no disco rígido. Chamo esse método de instalação de “modo espalhado”. Você não o encontrará na lista de métodos básicos de operação do Tiny Core.

Ao longo dos anos, vi todo tipo de sistema operacional sofrer uma “decomposição do sistema”. Com o tempo o desempenho vai sendo afetado ou é corrompido. Seja devido ao mal funcionamento do software ou do hardware, erro do usuário/operador, explosões solares, o que quer que seja. Eu acredito que a inicialização do computador deva ser rápida. Ele sempre deve iniciar a partir de um estado puro. Acredito que o usuário deva ter o controle dos processos em execução na inicialização e sobre a coleção de aplicativos que deseja usar. Enquanto isso, as outras distribuições vão ficando cada vez maiores. A maioria delas dá prioridade a um visual atraente e não à funcionalidade, e dita o ambiente de execução e a seleção de aplicativos. Eu acho que elas são muito lentas, têm muitos processos desnecessários e não trazem os aplicativos que eu quero. As outras distribuições pequenas também ditam uma coleção de aplicativos. Eu nunca uso a maioria deles.

A gênese do Tiny Core foi um encontro que tive na Linux World 2005 com Kent Porter e Chis Livesay. Conversamos sobre o que nós pensávamos que seria um ambiente ideal. Um que suportasse facilmente os conceitos e a filosofia que eu havia apresentado ao Damn Small Linux, mas sem o fardo dos aplicativos em GTK+. Deixe o usuário decidir: GTK+ ou GTK+ 2, linha de comando para o servidor, desktop minimalista ou appliance especializada. Quando apresentei ao John esse conceito de um núcleo pequeno, ele o rejeitou. Então eu desmontei o KNOPPIX 4 e montei um pequeno núcleo, chamado DSL-N. John o rejeitou outra vez. Mais uma vez ele cuidou da parte dos aplicativos do DSL-N, e o núcleo não foi lançado. John logo abandonou o DSL-N, e eu fiz o mesmo.

Se poder fazer muita coisa nova com um velho kernel 2.4, mais uma vez tentei encontrar uma nova base. Só quando vi o SliTaz é que eu me lembrei da palestra de Rob Landley na OLS 2006 sobre como popular o initramfs com o BusyBox. Estudei o assunto com os logs de desenvolvimento do kernel e vi como um disco inicial de RAM simples e o BusyBox poderiam funcionar com minhas ideias e conceitos originais para as extensões. Botei para rodar o Finnix, uma distribuição pequena e poderosa baseada no Debian, e segui a documentação de Rob Landley sobre o kernel e o BusyBox para criar o primeiro protótipo, e então comecei a trabalhar no código que eu havia criado nos últimos cinco anos para fazer o primeiro desktop. A próxima iteração foi uma conversão do murgaLua para C++/FLTK para chegar a um protótipo funcional do Tiny Core.

O Tiny Core não é um fork do DSL. Ele tem uma base completamente diferente e não baseado nem no Debian nem no KNOPPIX. O Tiny Core também não é um SliTaz remasterizado, e foi feito com base nos novos recursos do kernel 2.6 somados aos recursos oferecidos pelo BusyBox. Embora seja pequeno (10 MB), o Tiny Core não é focado no hardware de nenhuma geração específica. Seria injusto dizer que devido ao tamanho reduzido o Tiny Core é para hardware antigo. Podem dizer que o Tiny Core é para usuários avançados. Mas eu me esforcei para apresentar uma interface fácil de usar para adicionar aplicativos, módulos e bibliotecas. Experimente!

Como trata-se apenas de um núcleo, o usuário se vê diante de muitas escolhas. Muitas escolhas levam a muitas decisões. Tomar decisões efetivas significa passar algum tempo entendendo qual é a ideia do Tiny Core.

RS: O Tiny Core está completamente contido em um arquivo cpio compactado que popula o disco de RAM inicial na inicialização do kernel Linux. Basicamente, o Tiny Core consiste de dois arquivos: bzImage (o kernel Linux) e tinycore.gz. Como o Tiny Core é todo carregado na RAM, ele é muito rápido e também nos permite oferecer várias opções de persistência. Todas elas estão documentadas online na seção core concepts (conceitos básicos) de nosso site.

A ideia é separar os dados estáticos dos dinâmicos. Todos os dados estáticos, geralmente na forma de aplicativos, são empacotados em um arquivo TAR (TCE) ou em imagens compactadas para montagem em loop (TCZ). Esses pacotes – vamos chamá-los de extensões – estão disponíveis em nossos repositórios online. Agora some a esses dois arquivos bzImage e tinycore.gz um diretório chamado “tce” e o Tiny Core vai mesclar ou montar um diretório inteiro de extensões durante a inicialização. O resultado é um desktop personalizado com base nos aplicativos que você escolher. A persistência dos dados dinâmicos, que de modo geral consistem em seus dados pessoais localizados em sua pasta home, se dá por meio de backup e restauração. Isso também pode ser automático e é gerido por dois arquivos, .filetool.lst e .xfiletool.lst. Os que estiverem familiarizados com o comando de arquivamento tar vão perceber que o arquivo .filetool.lst é para a opção “T” e que o .xfiletool.lst é para a opção “X”. Esses dois arquivos são populados previamente para facilitar o uso, mas podem ser editados sem dificuldades para que você obtenha um controle bem detalhado.

Esse é apenas um dos modos de operação do Tiny Core. Nós oferecemos vários outros, cada um consistindo de níveis diferentes de persistência. Um exemplo seria a instalação de extensões em um arquivo ou diretório de loop, eliminando o carregamento durante a inicialização. Ou o uso de um diretório home persistente para evitar o backup e a restauração.

RS: O Tiny Core sempre inicia a partir de uma imagem cpio compactada. Cada inicialização é como a primeira de um CD-ROM. Na verdade, nós sugerimos que os arquivos do Tiny Core sejam armazenados em um disco rígido, numa instalação frugal. A instalação frugal é bem pequena e organizada. O Tiny Core pode coexistir facilmente com uma distribuição Linux que já esteja instalada. É só copiar os arquivos bzImage e tinycore.gz para o disco rígido e configurar o GRUB. Crie um diretório tce e está tudo pronto. Mesmo ao usar uma home persistente, ele vai usar um diretório home já existente, simplesmente adicionando uma pasta “tc” a ele. Por isso a cada inicialização o sistema está em um estado puro. Não promovemos uma instalação tradicional no disco rígido. Chamo isso de “modo espalhado” porque não é pequeno e organizado, e você acaba ficando com arquivos espalhados pelo disco rígido. Isso significa que você tem que alocar uma partição para a instalação. Isso significa que ela não pode coexistir com outra distribuição Linux instalada. Isso significa que esses arquivos espalhados não são carregados “do zero” a cada inicialização e estão suscetíveis à “decomposição do sistema”.

RS: Não conheço ninguém que tenha feito o que eu fiz ao montar o Tiny Core. Tanto a inicialização quanto o carregamento das extensões são muito rápidos. O Tiny Core é muito dinâmico e extensível, tanto em aplicativos quanto em módulos e bibliotecas. Começar com uma instalação básica do Debian significa alocar espaço em disco, não ser capaz de coexistir e adicionar pacotes que serão espalhados pelo sistema de arquivos. É muito diferente. Considere também que as dependências do Debian ditariam um tamanho bem maior do que o do Tiny Core com seu modelo otimizado de extensões. Uma instalação básica do Debian levaria ao carregamento de mais recursos, e não foi feita para ser dinâmica a cada inicialização.

O Tiny Core, em qualquer um de seus modos de execução, pode facilmente ser o seu desktop. Eu levanto a minha bandeira. O meu desktop é o Tiny Core. Eu o rodo com umas 60 extensões. Pessoalmente, prefiro o tipo de montagem com o tcz. Tenho dois netbooks, ambos com SSDs pequenos. Eu uso a instalação frugal para coexistir com o Xandros do Eee PC 900A e com o Ubuntu do Dell Mini 9. Sempre entro pelo Tiny Core. A inicialização, mesmo com o carregamento das extensões, me oferece um netbook com rede sem fio bem mais responsivo do que o SO instalado nativamente. O Tiny Core também funciona bem em computadores antigos, é claro, recursos modernos como o GTK+ ou o Flash mais recente têm requisitos enormes. Na conferência Scale 7x ocorrida recentemente, eu demostrei o Tiny Core em alguns netbooks novos e também em laptops antigos com 300 MHz e 128 MB em modo de framebuffer. Todos com rede sem fio.

No momento, o Tiny Core tem suporte à adição de usuários, mas principalmente para o propósito de permitir o acesso SSH. O Tiny Core acabou de nascer. A primeira versão pública dele saiu no dia 1º de dezembro de 2008, e só faz duas semanas que ele foi incluído no DistroWatch. Muitos recursos ainda estão por vir.

RS: Nosso grupo de desenvolvimento é fabuloso. A equipe não só me ajuda no desenvolvimento básico, como também é muito ativa na criação de extensões e me ajuda com a comunidade de usuários. A comunidade de usuários pode solicitar que uma extensão seja compilada. As extensões podem ser facilmente compiladas a partir dos fontes usando as ferramentas que disponibilizamos. O fato é que a equipe de desenvolvimento usa essas mesmas ferramentas em todo o nosso desenvolvimento. Observe também que todos os fontes, tanto do núcleo quanto das extensões, estão disponíveis no nosso site. Os usuários podem contribuir com extensões para que nós as hospedemos. Nós exigimos os fontes. Não distribuímos os binários sozinhos.

RS: O Tiny Core já possui ótimos recursos, como a capacidade de inicialização pela rede (consulte “TC Terminal Server” em nosso menu “Tools” e “Netbooting” para instruções). O Tiny Core é perfeito para o projeto XAMPP. Com nosso diretório /opt persistente, o ambiente LAMP do projeto XAMPP funciona muito bem. Eu também fiz uma demonstração disso recentemente na conferência Scale 7x. O que é empolgante no Tiny Core é o modelo de extensões. Pelas extensões, podemos seguir qualquer direção. Vamos manter o núcleo atualizado e nos esforçar para mantê-lo pequeno. Vamos adicionar a infraestrutura necessária para melhorar o suporte e a interação com nosso modelo de extensões. Somos uma distribuição jovem e acabamos de começar.

O Tiny Core é divertido. É desafiador. Oferece muitas possibilidade que eu espero que você conheça e explore.

RS: De nada. E mais uma vez, obrigado pela oportunidade.