Aqui mais uma referência ao GNOME 3.0. Desta vez no Guia do Hardware, traduzida por Roberto Bechtlufft e agora falando um pouco mais sobre o Shell e o Zeitgeist, duas tecnologias chave do novo GNOME.
Deixo aqui uma referência a uma excelente introdução ao Arch Linux feita pelo Carlos Morimoto, no GDH Press Blog.
Complementando minha tradução do artigo sobre os planos para o GNOME 3, deixo esta referência para o artigo “A Estrada para o GNOME 3″ postado no Guia do Hardware e traduzido pelo Roberto Bechtlufft.
Até a próxima!
Material original: The GNOME Release Team (3 de Abril de 2009)
Traduzido por: Tiago Paranhos Lima (8 de abril de 2009)
Durante os primeiros meses de 2008, alguns membros do Time de Lançamento discutiram sobre o estado do GNOME. Não foi nada oficial, e isto poderia de fato ser considerado como alguns amigos falando sobre coisas com as quais se importam muito. Alguns achavam que o GNOME deveria continuar no branch 2.x por muito tempo dado nossos sólidos métodos de desenvolvimento, mas este não era o futuro que a nossa comunidade deseja ver acontecer. Por motivo da falta de excitação. Devido à falta de visão. Lentamente, um plano começou a emergir. Ele evoluiu, mudou, foi se tornando mais sólido. Começamos discutindo com mais algumas pessoas, conseguimos mais feedback. E assim, na GUADEC, o Time de Lançamento propôs um plano inicial para a comunidade que levaria o projeto ao GNOME 3.0. Mais algum tempo se passou; na verdade, muito tempo se passou porque muitas pessoas estavam ocupadas com outras coisas. Mas nunca é muito tarde para fazer a coisa certa, então vamos levar a sério o GNOME 3.0 agora!
Primeiro vamos divergir um pouco e discutir sobre a impressão geral de que o GNOME está precisando de “visão”. Se você observar nossa comunidade de perto, seria errado dizer que as pessoas estão sem visão; mas o projeto como um todo parece ter esse problema. O que nos falta são pessoas “abençoando” uma visão específica e tornando-a oficial, oferecendo objetivos à comunidade para que possamos todos trabalhar juntos na mesma direção. Nos dias pré-2.x, a comunidade como um todo aceitava uma visão específica, e esta “benção” não era necessária. Mas durante o ciclo 2.x, com nossos calendários de 6 meses, parecia que tudo (comunidade, processo de desenvolvimento, etc.) estava funcionando tão bem, e como a visão foi cada vez mais sendo atingida, os termos de longo prazo tornaram-se menos importantes e nos focamos em polir nosso desktop. Mas agora alcançamos um ponto onde nossos próximos passos devem nos levar a um outro nível, e estes próximos passos requerem decisões importantes. Isto é parte do que um Time de Lançamento deve fazer. Observe que os membros do Time de Lançamento não tem que ser aqueles que possuem a visão; “apenas” temos que ser a voz da comunidade.
(Para efeito de nota, o processo de roadmap que tentamos reestabelecer a 2 anos atrás foi uma primeira tentativa de consertar isto. Infelizmente, o que aconteceu foi que nos faltava o mais importante: um roadmap para o projeto como um todo. Isto porque uma coleção de roadmaps individuais não é o suficiente para criar um roadmap para o projeto como um todo.)
Então vamos para o tópico principal, discutir o que o esforço do lançamento do GNOME 3.0 deveria ser. Propomos a seguinte lista de áreas nas quais devemos focar nossos esforços:
* Renovar nossa Experiência de usuário
* Simplificação da Plataforma
* Promoção do GNOME
Existem também outras áreas potenciais que são dignas de exploração se houver interesse suficiente da comunidade.
A partir de uma perspectiva de gerenciamento de lançamento, existem várias questões que são levantadas no contexto do GNOME 3.0. Definitivamente precisamos de um plano para organizar o desenvolvimento (veja abaixo mais detalhes sobre isso), mas também precisamos aproveitar esta oportunidade para pensar em como nós entregamos o GNOME: os conjuntos de módulos ainda são a melhor maneira de entregar o GNOME? Não existe uma resposta óbvia para isto, mas a forma na qual iremos apresentar o GNOME no futuro certamente terá um impacto nisso.
MUDANDO NOSSA EXPERIÊNCIA DE USUÁRIO
Quando falamos com algumas pessoas na GUADEC sobre o GNOME 3.0, uma preocupação recorrente foi a de que seria um erro fazer o GNOME chegar à versão 3.0 sem alguma grande mudança visível aos usuários. Embora alguns de nós não necessariamente entrem em consenso sobre isso, ainda assim isso era uma preocupação válida. Mas parece que se você diz à comunidade que haverá algo após o 2.x, então a comunidade irá parar de pensar vagamente sobre idéias futuras e irá começar a trabalhar em planos concretos.
Parece bem claro agora que existem 2 idéias importantes que podem ter um impacto realmente positivo na experiência de usuário:
* GNOME Shell: a idéia do shell não é apenas sobre mudanças no painel e no gerenciador de janelas. É sobre mudar a forma através da qual você inicia uma atividade e como você alterna entre 2 atividades diferentes. Ou de forma mais geral, em como você gerencia atividades diferentes no desktop.
* Mudar a forma através da qual acessamos documentos (através de um journal, como o GNOME Zeitgeist): ter que lidar com um sistema de arquivos em seu trabalho diário não é o que torna os usuários felizes — pelo contrário, eles geralmente querem apenas acessar seus documentos e não navegar em seu disco rígido. Prover novas soluções para este problema (usando linhas de tempo, tags, bookmarks, etc.) é algo que tem sido de interesse da nossa comunidade por um longo tempo, mas nunca imergimos completamente nisso. E deveríamos.
Estas 2 idéias podem formar a base para uma experiência GNOME revisada; e não são as únicas mudanças que podemos e iremos fazer, mas elas definitivamente são os projetos mais avançados para nos ajudar a dar o próximo passo em termos de experiência de usuário. Os projetos GNOME Shell e GNOME Zeitgeist na verdade já estão progredindo, com código em andamento e um forte desenvolvimento já acontecendo há aproximadamente 6 meses. Isso quer dizer que o esforço não é sobre iniciar estes projetos, mas sobre primeiro completá-los para que as pessoas possam trabalhar diariamente com eles, e então melhorá-los.
Existe uma questão óbvia relacionada a estas mudanças potenciais: o que irá acontecer com a velha maneira de fazer as coisas? Por exemplo, ainda iremos deixar o Painel GNOME disponível se, por alguma razão, as pessoas não estiverem imediatamente felizes com o GNOME Shell? Não há uma resposta óbvia para isto, que terá que ser discutido. Alguns de nós acreditam que pode ser algo bom continuar provendo os elementos antigos por um tempo limitado, para facilitar a migração. Isto sendo dito, tornar isto realidade obviamente irá demandar recursos de desenvolvimento e desacelerar o trabalho no que deveria ser o futuro. Não é uma escolha fácil, claro. Todavia, é válido observar que as distribuições e outros membros da comunidade usando o GNOME para construir produtos enterprise irão certamente ajudar a manter o shell GNOME 2.x ainda por algum tmepo, e que o projeto irá suportar isto da melhor maneira possível.
SIMPLIFICAÇÃO DA PLATAFORMA
Uma vez que o GNOME 2.0 foi lançado em 2002, tem havido algumas mudanças em nossa plataforma de desenvolvimento: novas APIs foram criadas e outras tornaram-se obsoletas. Existem ainda algumas bibliotecas da plataforma que agora são muito pouco utilizadas. Isso cria alguma confusão e não facilita a vida dos desenvolvedores. Uma vez que desejamos que as aplicações sejam desenvolvidas para o GNOME, isto é um problema que precisamos consertar.
Além disso, faz perfeito sentido retrabalhar nossa plataforma e tentar torná-la mais clara para recém-chegados. Aqui existem alguns passos que devem ser considerados:
* mover todas as bibliotecas obsoletas para fora da plataforma, para que as pessoas parem de utilizá-las em novos códigos;
* criar uma área de “estágio” na plataforma para bibliotecas que desejam estar em nossa plataforma mas não oferecem garantias suficientes no momento (como o GStreamer): isto irá tornar claro o que deve ser usado;
* incluir novas e excitantes tecnologias que estão começando a se utilizadas em nosso desktop. Exemplos óbvios são efeitos 3D (com o Clutter) e geolocalização (com GeoClue e libchamplain).
* retrabalhar a forma em que apresentamos a plataforma para integrar também algumas dependências externas: como, digamos, D-Bus ou Avahi são dependências externas, elas são definitivamente o que desejamos que os desenvolvedores usem. E é fácil ser mais explícito sobre isso.
* mover os bindings para mais perto da plataforma quando falamos sobre bindings, para torná-los ainda mais visíveis e atrair desenvolvedores de todas as linguagens.
O trabalho que tem sido feito na introspecção GObject também irá mudar profundamente a forma em que desenvolvimento GNOME pode ser feito; já começamos a ver como isso pode ser alavancado no GNOME Shell, e o fato de que ela pode trazer novas linguagens populares como Javascript para o GNOME é um enorme benefício.
Tudo isto tem, é claro, impacto em nossas aplicações: teremos que portar novo código das APIs pbs, mas também preparar nossas aplicações para as mudanças vindouras, como o GTK+ 3.0. Por sorte esta é uma tarefa que pode ser mensurada facilmente e seu progresso pode ser acompanhado em uma simples web page.
PROMOÇÃO DO GNOME
Nossa comunidade tem historicamente sido forte no lado do desenvolvimento, mas temos sempre lutado para promover o GNOME. Porque isto certamente não é uma tarefa fácil. Nossa base de usuários tem todavia crescido significativamente desde que nosso projeto começou, e falhamos em recrutar pessoas que poderiam ter ajudado aqui. O GNOME 3.0 é uma oportunidade de mudar isto e atrair colaboradores que possam ajudar a forjar a comunicação em torno do projeto GNOME. A promoção do projeto é definitivamente parte do que faz um bom lançamento, e o Time de Marketing pode contribuir muito para o sucesso do 3.0.
Claro que um objetivo óbvio da promoção do GNOME neste contexto seria preparar o lançamento 3.0 e a comunicação em torno deste release. Depois de destacar as mudanças feitas especificamente para o 3.0, outra idéia imediata é simplesmente mostrar o progresso que o projeto GNOME tem feito desde o GNOME 2.0: O GNOME 2.10 poderia ter sido nomeado como 3.0 se comparado ao 2.0, e o mesmo pode-se dizer do 2.20. Isto poderia servir como uma base para o trabalho de explicar porque nossa abordagem evolucionária no desenvolvimento funciona bem.
Um ponto comum que geralmente vinha à tona quando discutíamos sobre como promover o GNOME era que promover o desktop como um todo é difícil. Mas não há necessidade de fazer isso. Podemos ao invés disso focar nossa comunicação em torno da experiência GNOME: a experiência GNOME básica é simplesmente o GNOME Shell; mas os usuários não querem só um desktop básico, eles usam aplicações. Nunca explicamos porque as aplicações desenvolvidas para o GNOME são boas; nunca realmente colocamos estas aplicações sob os holofotes. Por exemplo, porque não poderíamos por na página principal do website do GNOME uma mensagem clara sobre um bom gerenciador de músicas? Não deveríamos ter que escolher entre o Rhythmbox ou o Banshee: podemos promover ambos, uma vez que ambos são bons de formas diferentes, e ambos são bons exemplos da experiência GNOME.
Isto nos leva a um terceiro item: relançar nosso website. Enquanto nosso website atual é conhecido por ser defasado de várias formas diferentes sob o ponto de vista da comunicação, não temos sido capazes de liberar uma nova versão que pudesse consertar estas coisas. Consertar o website é uma grande tarefa, mas não deveríamos desistir disso: o website GNOME é parte principal da identidade GNOME, e não podemos ignorar os problemas atuais. Isto aconteceu por falta de mão-de-obra, mas a boa notícia é que existem desenvolvedores web que são apaixonados pelo GNOME e apenas não sabem como ajudar o projeto.
E o fato de que desenvolvedores web podem ter um importante papel também é válido para todos os nossos usuários. Atualmente, não estamos realmente dando poder aos nossos usuários para promoverem o GNOME: o que um usuário deveria fazer se ele quisesse fazer isso? Sabemos todos como alguma comunicação viral pode beneficiar um projeto como o nosso, então a solução é simples: vamos dar a nós mesmos a chance de isso acontecer!
OUTRAS ÁREAS POTENCIAIS
As áreas apresentadas acima não são uma grande surpresa para aqueles que acompanham o desenvolvimento do GNOME e são escolhas óbvias. Todavia existem outros candidatos que podem tornar o GNOME 3.0 um sucesso. Esta áreas de foco potencial apenas precisam de pessoas que deem um passo a frente para que as expectativas possam ser cumpridas.
* Testes do Desktop: com a criação recente do Time de Teste do Desktop, este tópico se torna mais e mais visível. Podemos inovar lá, e realmente deveríamos: ajudamos a mostrar o caminho no mundo do software livre quando se fala de usabilidade e acessibilidade, e não há motivos para não focarmos em uma experiência similar para os testes de desktop.
* Arte: Uma hackfest sobre a API GTK+ Theming aconteceu em fevereiro, quando algum consenso foi atingido sobre como os temas devem ser feitos no futuro. Isso nos dá uma nova oportunidade para um look and feel mais atualizado. Isto pode acontecer com a ajuda de artistas: se tivermos artistas e programadores trabalhando juntos, com os programadores sabendo das necessidades dos artistas, então não há dúvidas de que os resultados simplesmente vão arrasar.
* Pessoas: o framework telepathy tem progredido muito bem durante os últimos anos e está oferecendo grandes perspectivas para integrar mensagens instantâneas e, de forma mais geral, a interação com pessoas em outras aplicações. Com algum foco, ele poderia contribuir para tornar o GNOME um desktop social onde você não apenas trabalha em documentos, mas também interage com seus amigos.
* Mobile: A plataforma GNOME Mobile foi introduzida pela primeira vez no GNOME 2.24, e ajudou a tornar visível nossa presença no mundo mobile. Muitas das mudanças que estão planejadas sobre a plataforma são de interesse direto do Time Mobile.
ORGANIZANDO O DESENVOLVIMENTO
Precisamos definir um timeline claro para o desenvolvimento, com um calendário que nos permita checar se ele está no caminho certo. O objetivo final é simples: queremos entregar o GNOME 3.0 a tempo do release 2.30. Isto faz sentido por vários motivos: de uma perspectiva técnica, o timing é bom para a integração de novas tecnologias ou projetos (o GNOME Shell, por exemplo); sob um ponto de vista de comunicação, a evolução do 2.30 para o 3.0 é lógica e fácil de entender. É válido apontar para o fato de que se você comparar o GNOME 2.26 com o GNOME 2.0, é realmente surpreendente ver que ainda tenhamos mantido a numeração 2.x enquanto poderíamos estar no 3.x, ou até mesmo no 4.x. Tornar o GNOME 2.30 3.0 é, claro, um objetivo ambicioso, mas podemos fazer isso graças ao que aprendemos no passado.
Os métodos de desenvolvimento que adotamos durante o GNOME 2.x são métodos bons no geral e a comunidade tem estado acostumada a eles. Por exemplo, os colaboradores entendem as razões dos freezes que possuímos e fazem o seu melhor para respeitar estes freezes. Isto não é algo que deve ser mudado porque agora temos a oportunidde de tentar de outra forma; pelo contrário, estes métodos irão tornar o caminho para o 3.0 mais fácil. Algumas regressões foram apontadas durante os últimos ciclos: isto não deve ser ignorado e acreditamos que parte das razões pelas quais elas aconteceram é que apenas uma pequena parte de nossa comunidade estava tentando seguir adiante, o que criou alguma controvérsia; possuir um foco como comunidade deveria limitar estas controvérsias, e desta forma também as regressões como sentidas pela comunidade.
O ciclo de 6 meses é agora parte de nossa cultura e tem um impacto no ecossistema do software livre, com distribuições baseando seus calendários no nosso. Tentar mudar este elemento crucial do gerenciamento de nosso lançamento, que funciona muito bem, certamente não iria nos ajudar de forma alguma. Logo, iremos manter nossos calendários de 6 meses. Mas possuir objetivos como projeto e a longo prazo requer alguma adaptação. O GNOME 2.28 não será um lançamento independente ou um destino em si mesmo, mas será um passo lógico em direção do GNOME 2.30, e portanto para o GNOME 3.0.
Claro, deveríamos estar preparados para considerar o fato de que o GNOME 2.30 pode não estar bom o suficiente para o chamarmos de 3.0. Todos os nossos lançamentos agendados são também baseados em qualidade: se o Time de Garantia de Qualidade sentir que um release deva ser adiado, então ele será adiado. No contexto do 3.0, isto é algo que devemos estar preparados para diagnosticar durante o ciclo de desenvolvimento do 2.29 e não devemos ter medo de manter o GNOME 2.30 como 2.30 e esperar o GNOME 2.32 para o lançamento do 3.0, por exemplo. Isto estando dito, queremos que a comunidade tente o mais arduamente possível tornar um sucesso “GNOME 2.30 = GNOME 3.0″.
Em uma nota mais geral, sobrepor um ciclo de desenvolvimento de longo prazo (3 anos por exemplo) com metas em nível de projeto no topo de nossos agendamentos de desenvolvimento de 6 meses é algo que queremos manter após o GNOME 3.0.
CONCLUSÃO
Você já pode checar o agendamento dos ciclos de desenvolvimento das versões 2.27 e 2.29. Eles contem alguns passos concretos e deadlines que irão manter nosso projeto focado para tornar o GNOME 3.0 uma realidade.
Como já mencionado, isto é um plano ambicioso e irá somente ser concretizado se todos ajudarem. Companhias podem contribuir muito — por exemplo, o esforço GNOME Shell está indo bem graças ao envolvimento da Red Hat. Mas o GNOME sequer existiria sem todos os voluntários que são apaixonados pelo projeto. E é porque esta paixão é tão forte que podemos constuir um plano como este!
Estamos chegando lá. Acreditamos fortemente que tudo isto pode ser um bom plano para o GNOME. Claro, não é perfeito. E haverão controvérsias e problemas ao longo do caminho. Mas este é o caminho a seguir.
Time de Lançamento do GNOME
***
Material originalmente publicado no seguinte endereço: http://live.gnome.org/ThreePointZero/Plan. Esta é uma tradução livre com o único intuito de disseminar conhecimento entre a comunidade de usuários linux do Brasil. Todos os direitos e idéias divulgados aqui são de propriedade dos autores originais. Para sugestões/críticas/errata, utilize o espaço para comentários desse tópico ou envie um e-mail para tiagoprn@gmail.com.
***
Artigo original: Caitlyn Martin (9 de Março de 2009)
Traduzido por: Tiago Paranhos Lima (24 de março de 2009)
Quando escrevo análises de várias distribuições linux e descrevo as diferenças na performance quase invariavelmente ouço que todas as distribuições linux são essencialmente as mesmas: rodam sob o mesmo kernel, as mesmas bibliotecas e os mesmos sistemas de arquivos. A performance deveria ser essencialmente a mesma, certo? A resposta é não. Os resultados de performance de diferentes distribuições, mesmo aquelas rodando sob a mesma versão do kernel, as mesmas bibliotecas core e o mesmo sistema de arquivos podem ser muito, muito diferentes.
Vejo esta questão debatida em incontáveis fórums sobre o linux geralmente sem quaisquer fatos concretos. “É mais rápida para mim” não irá convencer ninguém. Em uma discussão em LXer.com <http://lxer.com/module/forums/t/28639/> um usuário chamado herzeleid perguntou: “Qual a razão desta diferença?”. Este pequeno artigo nasceu de minha resposta.
Diferentes distribuições são mais adequadas para determinados tipos de hardware. O exemplo mais óbvio disso é que entre um Desktop de um usuário doméstico e um servidor corporativo existem diferenças na arquitetura do processador. Para muitos usuários desktop isto se resume a se você está executando uma CPU 32 ou 64-bit. (Máquinas dual e quad core são geralmente múltiplas CPUs 64-bit hoje em dia). Sim, uma distribuição 32-bit irá executar bem em uma máquina 64-bit e para as tarefas mais comuns, onde realmente não haverá qualquer diferença na performance. Mas para tarefas que requerem uso intensivo da CPU e que utilizam por completo as vantagens de um processador 64-bit um SO de 32-bit não irá ter uma boa performance. Uma amiga minha que é artista executa muita renderização de gráficos em 3D. Para ela uma distribuição 32-bit leva muito mais tempo para executar essa tarefa do que uma distribuição 64-bit nativa. Qualquer coisa que envolva muitos números também irá ter degradação de performance, bem como tarefas multimídia e games high-end. Uma distribuição 64-bit também consegue endereçar e utilizar corretamente grandes quantidades de RAM.
Diferenças na performance são mais evidentes quando um sistema é levado aos seus limites. Você vê isso acontecendo todo o tempo em uma máquina com especificações modestas. Isso envolve qualquer coisa desde os cada vez mais populares netbooks até hardware antigo legado. Em tempos econômicos difíceis isto se aplica tanto ao usuário doméstico quanto ao usuário corporativo. Conheço um grande número de empresas que agora compram netbooks ao invés dos convencionais laptops, a fim de cortar custos. Muitas outras estão tentando extrair o máximo de hardware antigo, muito dele muito antigo, a fim de evitar gastos com equipamento em tempos de economia instável. O Linux serve como uma luva para estender a vida de sistemas antigos, incluindo sistemas que sequer atingem as especificações mínimas para uma versão atual do Windows. Nestes casos estamos geralmente falando de processadores 32-bit e distribuições linux de 32-bit, então a arquitetura do processador não está em questão. Diferenças de performance entre distribuições de 32-bit podem ser enormes.
Na discussão em LXer.com mencionei um usuário chamado azerthoth que fez este comentário com referência ao kernel do Ubuntu <http://www.ubuntu.com>:
“Quanto ao seu kernel, aqueles caram realmente precisam explorar como carregar módulos sob demanda. Na última vez que coloquei minhas mãos em uma máquina ubuntu e imprimi o lsmod, por default ele tinha o comprimento de 3 páginas.”
Diferenças quanto à forma através da qual o kernel é construído e compilado podem fazer uma grande diferença. E também o grau no qual os desenvolvedores fazem a “tunagem” do kernel, dos sistemas de arquivos, e outros aspectos do SO para o nicho ao qual a distribuição se aplica. De fato, a O’Reilly possui um livro inteiro sobre “tunagem” de performance de sistemas UNIX/Linux <http://oreilly.com/catalog/9780596002848/index.html#top>, o que torna claro que existem muitos aspectos do SO que podem ser ajustados para uma melhor performance. Grandes distribuições como Fedora <http://www.fedoraproject.org>, Ubuntu, SUSE <http://www.novell.com/linux/> e Mandriva <http://www.mandriva.com/> são adeptas à filosofia de atender o maior número de nichos de usuários possível. Consequentemente, não são otimizadas para nenhum deles. Em 2006 Fernando Apesteguia escreveu um excelente artigo <http://www.linuxforums.org/desktop/linux_performance_tuning.html> sobre como otimizar um sistema linux para aumentar a performance. Todas as “grandes” distribuições podem ser otimizadas e a performance pode ser muito melhorada.
Muitas distribuições pequenas ou especializadas buscam um alvo ou parte específica da comunidade de usuários linux ao invés de procurar um denominador comum para todos. O resultado pode ser um sistema muito mais rápido e já otimizado se você escolhe uma distribuição que se adequa ao seu perfil. A Intel está seguindo essa linha no desenvolvimento do Moblin <http://moblin.org/>, uma distribuição otimizada para netbooks que usam processadores da série Intel Atom. Uma distribuição mais focada oferece a usuários menos inclinados tecnicamente a oportunidade de aproveitar uma performance superior sem que os mesmos tenham que se aprofundar em aspectos técnicos.
No desktop meus leitores regulares sabem que tenho estado muito impressionada com o Vector Linux <http://www.vectorlinux.com> e o Wolvix <http://www.wolvix.org>, duas das distribuições que parecem fazer o melhor trabalho a fim de entregar uma experiência em desktop rica e rápida, mesmo em hardware com potência limitada. Ambas as distribuições tem como foco usuários domésticos ou de pequenos escritórios/laptops e não são muito adequadas para um servidor. O Vector Linux possui alguns desenvolvedores habilidosos em otimizar quase tudo que pode produzir um desktop muito rápido. Eles até mesmo reescreveram os scripts init a fim de acelerar um pouco o processo de boot. Não sei muito sobre os desenvolvedores Wolvix mas eles também parecer ter feito coisas similares para atingir os resultados que conseguiram com a versão 1.1.0. Ambas as distribuições são derivadas 32-bit do Slackware <http://www.slackware.com>. (Uma versão 64-bit do Vector Linux atualmente está em fase alpha.)
A forma de construir os pacotes também é importante. O Vector Linux constrói pacotes para i586 e os “tuna” para i686. Ele não irá rodar em hardware i486 (como sistemas baseados no AMD K5) que pode executar uma versão atual do Slackware. Outras flags/opções de compilação também importam em alguns casos.
Algumas distribuições como o Ubuntu carregam muitas coisas por default que podem não ser necessárias. Sim, você pode simplesmente desligá-las se você souber o que está fazendo. Quantos usuários realmente não sabem como desabilitar serviços e daemons que não necesstam? O Slackware e muitas distribuições derivadas do Slackware tomam um princípio contrário: se o usuário precisa de algo ele pode habilitá-lo. Inicie apenas com o que quase todos precisam por default. Por exemplo, alguns usuários possuem sistemas Windows com o qual precisam se comunicar, compartilhar arquivos e talvez uma impressora. Outros não. O Vector Linux 6.0 não habilita o samba <http://us6.samba.org/samba/> por default, enquanto muitas outras distribuições o fazem. O resultado de escolhas como esta é uma experiência default mais rápida.
O Slackware possui a filosofia “Quanto mais simples melhor”. No Slackware são deixadas de lado coisas que outras distribuições geralmente incluem. Por exemplo, o Slackware não implementa PAM <http://www.kernel.org/pub/linux/libs/pam/index.html>. Alguns derivativos populares do Slackware (por ex.: Zenwalk <http://www.zenwalk.org>) incluem o PAM mas o Vector Linux e o Wolvix não o fazem. Poderia a camada extra de segurança requerida para autenticação fazer diferença, particularmente em hardware antigo? Claro que sim. O propósito do PAM é permitir e gerenciar diferentes métodos de autenticação em uma rede. Em um sistema mono-usuário ou em um escritório pequeno o antigo gerenciamento de senhas baseado em arquivo é mais simples e o PAM não é necessário. Eu certamente não me importo de ter o PAM em um laptop antigo. Para a segurança de um servidor enterprise com certeza ele é uma boa pedida. Esta é uma das razões pela qual eu não considero o Slackware apropriado para um servidor enterprise. Por outro lado, se você busca velocidade não habilitar o PAM pode ser de grande ajuda.
Ainda quanto à segurança, o Slackware também não inclui o SELINUX <http://en.wikipedia.org/wiki/Selinux>. A menos que você trabalhe pra uma agência do governo ou uma organização/empresa paranóica por segurança você provavelmente não precisa se preocupar com isso, uma vez que ele também causa overhead. No Fedora, por exemplo, ele está habilitado por default.
É uma escolha entre funcionalidade e velocidade. Qual é o mais importante? Depende do que você irá fazer, não? Alguns irão argumentar que a filosofia “mais simples possível” do Slackware ajuda em termos de estabilidade e confiabilidade. Eu concordo em princípio mas diria que os caras da Red Hat <http://www.redhat.com/rhel/> fizeram um maravilhoso trabalho ao criar um SO estável com muitas ferramentas extras para o mercado enterprise. Mas ele não é particularmente rápido, principalmente se comparado ao Slackware e alguns derivativos altamente otimizados deste último, como o Vector Linux.
Existem muitas variáveis que definem como uma distribuição é construída. O Slackware inicia simples e rápido sem muita “poluição”. As distribuições derivativas podem acrescentar, ajustar-se a um nicho específico, etc… e possuírem resultados totalmente diferentes. Uma vez que possuo um netbook e alguns sistemas antigos tendo a preferir distribuições que privilegiam a performance sobre todos os demais aspectos.
NOTA DO TRADUTOR: Também possuo um netbook (Asus EEE PC 900). Possuo nele instalado o Arch Linux, justamente por ele seguir o princípio “Mais simples possível” (popular “KISS”) mas, diferentemente do Slackware, um sistema de pacotes e as principais configurações centralizadas em um único arquivo onde defino manualmente, dentre outras coisas, os módulos do kernel e os daemons que desejo subir na inicialização do sistema. Além disso, é otimizado para a plataforma i686 e, pelo fato de ser uma distribuição rolling release, possuo sempre a versão mais atualizada de todos os pacotes que possuo instalados, sem haver necessidade de reinstalar o sistema a cada nova versão do kernel/Gnome/KDE/X.org etc…, como as distribuições “newbie-friendly”. Para usuários com estas necessidades, recomendo. 
***
Artigo originalmente publicado no seguinte endereço: http://broadcast.oreilly.com/2009/03/linux-performance-different-di.html. Esta é uma tradução livre com o único intuito de disseminar conhecimento entre a comunidade de usuários linux do Brasil. Todos os direitos e idéias divulgados aqui (com exceção da nota do tradutor) são de propriedade do autor original. Para sugestões/críticas/errata, utilize o espaço para comentários desse tópico ou envie um e-mail para tiagoprn@gmail.com.
***
Essa é pra descontrair. Um pouco comprido…. mas muito engraçado.
O final é surpreendente…
Curioso?
Acesse o link:
A criação do mundo segundo o root
Até a próxima!
Salve galera!
Então, acabei de instalar o VirtualBox 2.0.2 no meu Arch Linux, que resolve o problema da acentuação em máquinas virtuais Windows… mas me deparei com outros 2 problemas:
1 - Se executo como usuário normal recebo erro nas permissões
2 - Se logo como root diz que o arquivo “VirtualBox.so” está faltando.
Eis a minha solução :
(para repetir os procedimentos abaixo, logue como root)
cp -farv /usr/bin/VirtualBox /usr/bin/VirtualBox.old
chmod 4511 /usr/bin/VirtualBox
cd /usr/lib/virtualbox
ln -s ../VirtualBox.so VirtualBox.so
Como não consegui mais usá-lo como usuário comum, adicionei a mim mesmo no arquivo /etc/sudoers
e segui adiante:
cp -farv /home/meuUsuario/.VirtualBox /root
chown -R root.root /root/.VirtualBox
Após reiniciar a máquina (para subir o novo módulo do kernel do virtualbox), loguei novamente como usuário normal e testei com o sudo:
sudo VirtualBox
Informei a senha e… surpresa: TUDO FUNCIONANDO DIREITINHO!
Inclusive a acentuação. 
PS: para me certificar de que a configuração de acentuação estaria correta, fui no menu File -> Preferences -> Input (do VirtualBox mesmo, não da máquina virtual), e marquei a opção “Auto Capture Keyboard”.
Esta dica deve funcionar também com outras distros.
Esta versão do VirtualBox, além de corrigir o problema da acentuação, também fica muito mais bonita no KDE 4.1. Isso tudo porque agora o Virtualbox também usa o toolkit QT4, mesmo toolkit gráfico base do KDE 4.
É isso aí, até a próxima! 
Andava pesquisando sobre o Android (uma espécie de “sistema operacional open-source” para celulares, criado pelo Google - algo como o “Linux” dos celulares). Então me deparei com uma distribuição LiveCD prontinha, com SDK, Eclipse, emuladores e todo o aparato necessário para quem quiser se aventurar na nova plataforma.
Confesso que fiquei bastante surpreso com o que encontrei, mais ainda porque esta distro (baseada no Debian Lenny) está mais para meta-distro. Existem versões customizadas para desenvolvimento web, jogos, programação em geral e até mesmo para quem gosta de trabalhar com áudio/música.
O link para o site do “perfil Android” da distro é este. Os outros links valem, no mínimo… uma visita.
Este é o meu blog pessoal. Pretendo mantê-lo atualizado com artigos sobre programação, linux, RPGs, Saint Seiya… etc…
Sejam bem-vindos!