注意:

The Funtoo Linux project has transitioned to "Hobby Mode" and this wiki is now read-only.

Difference between revisions of "Funtoo:About/pt-br"

From Funtoo
Jump to navigation Jump to search
 
(12 intermediate revisions by the same user not shown)
Line 1: Line 1:
= Visão do Projeto =
= Visão do Projeto =


Daniel Robbins originalmente escreveu a [[ Gentoo Linux Philosophy|Filosofia Gentoo Linux]], e nisso definiu o conceito de uma ferramenta ideal assim sendo algo que "simplesmente funciona", não fica no caminho do usuário, e responde a vontade do usuário ao invés de forçar o usuário a trabalhar de um jeito particular.
Daniel Robbins originalmente escreveu a [[Gentoo_Linux_Philosophy/pt-br|Filosofia Gentoo Linux]], e nisso definiu o conceito de uma ferramenta ideal assim sendo algo que "simplesmente funciona", não fica no caminho do usuário, e responde a vontade do usuário ao invés de forçar o usuário a trabalhar de um jeito particular.


Funtoo Linux é um projeto de pessoas que concordam filosofia da ferramenta ideal, e que são ''apaixonados'' pelo nosso desejo de melhorar a tecnologia de ser tão próximo desse ideial quanto possível. O foco de nossos esforços é o melhoramento contínuo da distribuição Gentoo Linux.  
Funtoo Linux é um projeto de pessoas que concordam filosofia da ferramenta ideal, e que são ''apaixonadas'' pelo nosso desejo de melhorar a tecnologia de ser tão próximo desse ideal quanto possível. O foco de nossos esforços é o melhoramento contínuo da distribuição Gentoo Linux.  


O foco do desenvolvimento do Funtoo Linux é atualmente direcionado ao sistema central, significando qualquer coisa em um stage3, portage, core languages, kernels, aplicações de servidor, e em cima do X11 e gerenciadores de janelas simples, e incluindo ambientes desktop como o GNOME e o KDE.
O foco do desenvolvimento do Funtoo Linux é atualmente direcionado ao sistema central (core system), significando qualquer coisa em um stage3, portage, core languages, kernels, aplicações de servidor, e em cima do X11 e gerenciadores de janelas simples, e incluindo ambientes desktop como o GNOME e o KDE.


== Foco, Foco, Foco ==
== Foco, Foco, Foco ==


Desenvolvedores deveriam utilizar esses princípios gerais para determinar em quais prioridades focar primeiro. -Essas areas abaixo estão listadas em ordem de prioridade, então o próximo parágrafo é a principal prioridade (top priority), seguido pela próxima prioridade, etc. Só por que algo é prioridade mais baixa não significa que é "menos importante" - somente significa tratar as coisas de prioridades mais altas (higher-priority) antes.
Os desenvolvedores devem utilizar esses princípios gerais para determinar em quais prioridades focar primeiro. -Essas áreas abaixo estão listadas em ordem de prioridade, então o próximo parágrafo é a mais alta prioridade (top priority), seguido pela próxima prioridade, etc. Só por que algo é prioridade mais baixa não significa que é "menos importante" - somente significa tratar as coisas de prioridades mais altas (higher-priority) primeiro.


=== Ele controe? ===
=== Constrói? ===


* '''Ele constrói confiavelmente?'''
* '''Constrói confiavelmente?'''


O primeiro teste - o software constrói a partir do código fonte corretamente? Isso não se trata somente de emergir ebuilds no seu sistema -- do stage builds work with no issues using Metro? If not, this needs to be fixed first. Funtoo Linux continually builds updated operating system releases, and these must build reliably at all times. The focus here is for 100% correct and efficient builds using Metro, and then emerging initial applications on a Funtoo Linux system.
O primeiro teste - o software constrói a partir do código fonte corretamente? Isso não se trata somente de emergir ebuilds no seu sistema -- OS builds do stage funcionam sem problemas utilizando o Metro? Se não, isso precisa ser corrigido primeiro. O Funtoo Linux continuamente constrói lançamentos do sistema operacional atualizados, e essas devem ser construídas confiavelmente em todos os momentos. O foco aqui é para builds 100% corretos e eficientes utilizando o Metro, e depois emergindo aplicações iniciais em um sistema Funtoo Linux.


=== Does It Run? ===
=== Ele executa? ===


* '''Does it Run Well?'''
* '''Ele executa bem?'''


OK, it builds. Does it run properly? Does it work? This is pretty vague, so let's put some specifics here. When installing Funtoo Linux from a stage3, does everything work? What complications or failures were encountered on initial install? These should be fixed, or work-arounds should be put in place, and long-term fixes should be worked on to improve the user experience. Remember that the focus of Funtoo Linux is on the core system - this is the stuff you touch when you first install Funtoo Linux. You should regularly re-install Funtoo Linux to check for any issues and prioritize user install issues and the initial user experience.
OK, ele constrói. Ele executa corretamente? Ele funciona? Isso é bem vago, então vamos colocar algumas especificações aqui. Quando instalar o Funtoo Linux a partir do stage3, tudo funciona? Quais complicações ou falhas foram  encontradas na instalação inicial? Essas devem ser corrigidas, ou soluções devem ser colocadas no lugar, e correções a longo prazo devem ser trabalhadas para melhorar a experiência do usuário. Lembre-se de que o foco do Funtoo Linux é no sistema central - Essa é a coisa que você toca quando você instala o Funtoo Linux pela primeira vez. Você deve reinstalar o Funtoo Linux regularmente para verificar por quaisquer questões e priorizar as questões de instalação do usuário e a experiência inicial do usuário.


=== Can I Use It? ===
=== Consigo Usá-lo? ===


* '''Easily?'''
* '''Facilmente?'''
* '''For Real Work?'''
* '''Para Trabalho de Verdade?'''


OK, it builds, and it runs. But can I actually perform tasks with the tool? How easy or hard is it to perform these tasks? The technology (and documentation) must be designed to support the user in performing these tasks, rather than forcing the user to jump through hoops to get something set up correctly. Things should be automated as much as possible without taking control away from the user. Reasonable, secure defaults that are suitable for production workloads must be used for all applications. Things should emerge without blockers or missing features that must be enabled manually by the user. And a pet peeve - if emerge stops to tell the user that they must define a USE variable to continue, this is something that should be fixed one way or another. Then, when everything is said and done, it should work.
OK, ele constrói, e executa. Mas eu posso realizar tarefas de verdade com a ferramenta? Qual é a facilidade ou dificuldade  de realizar essas tarefas? A tecnologia (e documentação) devem ser projetadas para oferecer suporte ao usuário na questão de realizar estas tarefas, ao invés de forçar o usuário a saltar por arcos para obter algo configurado corretamente. As coisas devem ser automatizadas o tanto o quanto possível sem assumir controle distante do usuário. Padrões seguros, razoáveis que são adequados para a cargas produtivas devem ser utilizadas por todas as aplicações. As coisas devem emergir sem bloqueadores ou ausência de recursos que devem ser habilitadas manualmente pelo usuário. E uma implicância - se o emerge parar para dizer ao usuário que ele deve definir uma variável USE para que continue, isso é algo que deve ser corrigido de um jeito ou de outro. Então, quando tudo é dito e feito, ele deve funcionar.


=== Is It Documented? ===
=== É Documentado? ===


* '''For free software projects, documentation is key.'''
* '''Para projetos de software livre, documentação é a chave.'''


If software builds, runs and works, others still may not be able to use it until proper documentation is available. Upstream documentation isn't always complete or easy to understand, so often additional user documentation is required. If manual steps are required, they should be documented clearly and correctly. The documentation option of choice is the Funtoo wiki as well as man pages.
Se o software, executa e funciona, outros ainda podem ainda não ser capaz de utilizá-lo até que documentação adequada esteja disponível. Documentação montante nem sempre é completa ou fácil de entender, então frequente documentação adicional para usuário é necessária. Se etapas do manual são necessárias, elas devem ser documentadas claramente e corretamente. A opção de escolha da documentação é a Funtoo wiki tão bem quanto as man pages.


For source code, verbose comments should be used. You may be working on the code now, but someone else might be working on it six months from now. Developers are expected to write clear comments that are sufficiently non-technical and provide the necessary context to allow less experienced developers to understand critical parts of code, and ideally '''all''' parts of the code. Please see [[Coding Standards]].
Para o código fonte, comentários bem detalhados devem ser utilizados. Você pode estar trabalhando no código agora, mas outra pessoa poderá estar trabalhando nele daqui a seis meses. É esperado que desenvolvedores escrevam comentários claros que sejam suficientemente não-técnicos e forneça o contexto necessário para permitir que desenvolvedores menos experiente entendam partes criticas do código, e idealmente ''''todas'''' as partes do código. Por favor veja [[Coding_Standards/pt-br|Padrões de Código]].


=== Is It Well-Designed? ===
=== É bem projetado? ===


* '''Optimized?'''
* '''Otimizado?'''
* '''Maintainable?'''
* '''Sustentável?'''


It builds and runs, and I can use it to perform real work. But is the system well-designed? Does it work reliably? Are all available patches and fixes in place to ensure a reliable computing experience? Is Funtoo Linux providing the best technology possible to users? And is this technology easy to maintain? Remember, all things being equal, less code is better than more code because it is easier to maintain. Are there verbose comments in code where necessary?
Ele constrói e executa, e eu posso utilizá-lo para realizar trabalho de verdade. Mas o sistema é bem projetado? Ele funciona confiavelmente? Todos os patches estão disponíveis e corrige o lugar para assegurar uma experiencia computacional confiável? O Funtoo Linux está fornecendo a melhor tecnologia possível aos usuários? E essa tecnologia é fácil de manter? lembre-se, todas as coisas sendo iguais, menos código é melhor que mais código por que é mais fácil de manter. Há comentários detalhados no código aonde é necessário?


=== Are We Getting Better? ===
=== Estamos melhorando? ===


OK, we're doing all of the above steps. Here is the next test - are we getting better? Is the quality, security, usability and maintainability of the distribution improving over time, or is it going up, and then going down, and we're not really making any forward progress? The ultimate goal at the end of the day is to make forward progress in the quality of the distribution. This requires better automation, better tools, better processes, and investment in research and development and new ways of doing things. It also requires the right attitude. If we are doing a lot of work and the overall quality of the distribution is not improving, then our efforts are not making a long-term difference, even though they may be addressing immediate bugs and issues. We must ensure that our efforts are worthwhile, and they are making a positive long-term difference in the quality of the distribution.
OK, estamos fazendo todas as etapas acima. Aqui está o próximo teste - estamos melhorando? A qualidade, segurança, usabilidade e a manutenção da distribuição está melhorando com o tempo, ou ela está subindo, e depois descendo, e não estamos mesmo tendo nenhum progresso? O objetivo no final do dia é obter progresso avançado no qualidade da distribuição. Isso requer automação melhor, ferramentas melhores, processos melhores, e investimento em pesquisa e desenvolvimento e novos métodos de fazer coisas. Isso também requer a atitude correta. Se estivermos fazendo um monte de trabalho e a qualidade global da distribuição não estiver melhorando, então nossos esforços não estão fazendo diferença a longo prazo, mesmo que eles possam estar tratando bugs e problemas imediatos. Temos que garantir que nossos esforços venham valer a pena, e que eles estão fazendo uma diferença positiva a longo prazo na qualidade da distribuição.


=== What is The Real Problem? ===
=== Qual o verdadeiro problema? ===


Building on this theme - when a bug is encountered, what is the ''real'' problem, or ''root cause''? Strategic thinking as well as in-depth troubleshooting is required to identify the root cause of a problem. Should we just fix root causes? No, this is impractical, because doing this takes a lot of time. Instead, workarounds are often used to quickly restore quality to acceptable levels. However, just implementing workarounds is dangerous, because bugs tend to multiply while the underlying issue goes unresolved. The proper solution is to implement workarounds but to not lose focus on the need to address the underlying issues, or root causes, of the problem. In fact, much of the focus of Funtoo Linux is on this last step - aggressively fixing a bunch of immediate issues so we can start to address the deeper problems once and for all...
Construindo nesse tema - quando um bug é encontrado, qual é o ''verdadeiro'' problema, ou a ''raiz (root cause)''? Pensamento estratégico tão bem quanto uma resolução profunda (in-depth troubleshooting) é necessária para identificar a raiz do problema. Devemos somente corrigir as raízes? Não, isso é impraticável, por que fazer isso leva muito tempo. Ao invés disso, soluções alternativas são com frequência utilizadas para restauras rapidamente a qualidade à níveis aceitáveis. No entanto, somente implementar soluções alternativas é perigoso, por que os bugs tendem a multiplicar-se enquanto a questão subjacente não for solucionada. A solução adequada é implementar soluções alternativas mas não perder o foco no necessário para tratar as questões subjacentes, ou raízes, do problema. De fato, muito do foco do Funtoo Linux está nessa ultima etapa - agressivamente corrigindo um monte de questões imediatas assim nós podemos começar a tratar os problemas mais profundos de uma vez por todas...


=== Architecture ===
=== Arquitetura ===


...and addressing root causes of problems often requires a significant change in software architecture. Funtoo Linux is a project that is not afraid of making significant, even aggressive, architectural changes in order to fix problems. This is what our users expect us to do, and ''as long as these changes are properly tested, managed, planned, automated and communicated to users'', they will not get upset. As stated in the previous paragraph, the Funtoo Linux project is zealous about addressing these core architectural issues -- but we need to get a handle on the more fundamental challenges first. Once workarounds are in place, we'll take a stab at some core system change that will pay dividends well into the future.
...e tratar da raiz de problemas com frequência requer uma mudança significativa na arquitetura de software. Funtoo Linux é um projeto que não tem medo de fazer alterações arquitetônicas significantes, e mesmo agressivas, a fim de corrigir problemas. Isso é o que os nossos usuários esperam que façamos, e ''desde que essas alterações sejam propriamente testadas, gerenciadas, planejadas, automatizadas e comunicadas aos usuários'', eles não irão se chatear. Conforme declarado no parágrafo anterior, o projeto Funtoo Linux é zeloso a respeito de tratar esses problemas centrais de arquitetura -- mas nós precisamos controlar os desafios mais fundamentais primeiro. Uma vez soluções alternativas estão no lugar, levaremos uma punhalada em alguma alteração no sistema central que pagarão dividendos bem no futuro.


== Examples ==
== Exemplos ==


Below, you will find examples of existing efforts that have aligned with these goals. This section will give you a feel for how real projects can be started that align with the Funtoo Linux vision defined above.
Abaixo, você encontrará exemplos de esforços que tem alinhados a esses objetivos. Essa seção lhe dará uma sensação do quanto projetos reais podem ser iniciados que se alinham com a visão do Funtoo Linux definida acima.


=== Boot-Update ===
=== Boot-Update ===


[[Boot-Update]] was designed by Daniel Robbins to provide a more elegant way to configure boot loaders under Funtoo Linux. This project was prioritized for several reasons. For one, it had to do with the initial installation experience (see [[#Does it Run?]]) Also, lack of GRUB2 support, as well as GPT/GUID support, was identified as a critical weakness in current Gentoo Linux functionality (see [[#Is it Well-Designed?]]) Because of this, a new unified configurator was written which uses <tt>/etc/boot.conf</tt> as the global boot loader configuration file. This represented a change in boot loader architecture (see [[#Architecture]]) under Funtoo Linux, in order to improve usability and flexibilty over existing solutions, and to attempt to reduce or eliminate a class of problems related to boot loader configuration, which is especially troublesome with GRUB2.
[[Boot-Update/pt-br|Boot-Update]] foi projetado por Daniel Robbins para prover um jeito mais elegante de configurar o carregador de boot sob o Funtoo Linux. Esse projeto foi priorizado por várias rasões. Uma, esse projeto tinha que fazer com que a experiência da instalação inicial (veja [[#Ele executa?]]) Também, ausência do suporte ao GRUB2, tão bem quanto o suporte ao GPT/GUID, foi definido como um ponto fraco crítica na funcionalidade atual do Gentoo Linux (veja [[#É bem projetado?]]) Por isso, um novo configurador unificado foi escrito que utiliza <tt>/etc/boot.conf</tt> como arquivo de configuração para o carregador de boot global. Isso representa a mudança na arquitetura do carregador de boot (veja [[#Arquitetura]]) sob o  Funtoo Linux, a fim de melhorar a usabilidade e a flexibilidade em soluções existentes, e tentar reduzir ou eliminar uma classe de problemas relacionadas a configuração do carregador de boot, que é especialmente problemático no GRUB2.


=== Metro ===
=== Metro ===


[[Metro]] was designed by Daniel Robbins and is used to address the "[[#Does It Build?]]" question. The existing solution, catalyst, was difficult to maintain (see [[#Is It Well-Designed?]]), so Metro was developed to provide a new mechanism for building OS releases.
[[Metro/pt-br|Metro]] foi projetado por Daniel Robbins e é utilizado para tratar a questão do "[[#Constrói?]]". A solução existente, catalyst, foi difícil de manter (veja [[#É bem projetado?]]), então  Metro foi desenvolvido para prover um  novo mecanismo para a construção de lançamentos de sistema operacional (OS releases).


=== Forked Ebuilds ===
=== Forked Ebuilds ===


Not all improvements involve large software development efforts. In fact, the majority of fixes involve relatively small fixes to ebuilds. These fixes are often made to fix a Metro build failure (see [[#Does it Build?]]) or address some quality issue (see [[#Is It Well-Designed?]]). The <tt>www-servers/nginx</tt> ebuild was improved to provide better default settings for production systems, with corresponding changes made to <tt>sys-libs/pam</tt> to allow this to work. <tt>dev-lang/python</tt> contains fixes to ensure that Metro builds complete properly and a valid <tt>/usr/bin/python</tt> symlink always exists.
Nem todas as melhoras envolvem grandes esforços no desenvolvimento de software. De fato, a maioria das correções envolvem correções relativamente pequenas para os ebuilds. Essas correções são com frequência feitas para corrigir uma falha no Metro build (veja [[#Constrói?]]) ou tratar de alguma questão de qualidade (veja [[#É bem projetado?]]). O ebuild <tt>www-servers/nginx</tt> foi melhorado para prover melhores configurações padrões para sistemas de produção, com alterações correspondentes feitas ao <tt>sys-libs/pam</tt> para permitir que isso funcione. <tt>dev-lang/python</tt> contem correções para assegurar que o contem correções para assegurar que Metro builds complete corretamente e um symlink <tt>/usr/bin/python</tt> válido sempre exista.


=== OpenVZ ===
=== OpenVZ ===


OpenVZ support is a specific priority of Funtoo Linux. Funtoo Linux maintains a patched <tt>sys-cluster/vzctl</tt> with various patches to fix a variety of problems. In addition, <tt>openvz-rhel6-stable</tt> and <tt>openvz-rhel5-stable</tt> ebuilds have been created to ease installation of production-quality OpenVZ kernels (see [[#Can I Use It?]]) In addition, [[OpenVZ]] documentation exists on the wiki (see [[#Can I Use It?]])
Suporte a OpenVZ é uma prioridade específica do Funtoo Linux. Funtoo Linux mantem um patched <tt>sys-cluster/vzctl</tt> com vários patches para corrigir uma variedade de  problemas. Em adição, <tt>openvz-rhel6-stable</tt> e <tt>openvz-rhel5-stable</tt> ebuilds tem sido criados para facilitar a instalação de kernels OpenVZ de qualidade para produção (veja [[#Consigo Usá-lo?]]) em adição, documentação [[OpenVZ]] existe no wiki (veja [[#Consigo Usá-lo?]])


[[Category:QA]]
[[Category:QA]]

Latest revision as of 14:55, January 10, 2015

Visão do Projeto

Daniel Robbins originalmente escreveu a Filosofia Gentoo Linux, e nisso definiu o conceito de uma ferramenta ideal assim sendo algo que "simplesmente funciona", não fica no caminho do usuário, e responde a vontade do usuário ao invés de forçar o usuário a trabalhar de um jeito particular.

Funtoo Linux é um projeto de pessoas que concordam filosofia da ferramenta ideal, e que são apaixonadas pelo nosso desejo de melhorar a tecnologia de ser tão próximo desse ideal quanto possível. O foco de nossos esforços é o melhoramento contínuo da distribuição Gentoo Linux.

O foco do desenvolvimento do Funtoo Linux é atualmente direcionado ao sistema central (core system), significando qualquer coisa em um stage3, portage, core languages, kernels, aplicações de servidor, e em cima do X11 e gerenciadores de janelas simples, e incluindo ambientes desktop como o GNOME e o KDE.

Foco, Foco, Foco

Os desenvolvedores devem utilizar esses princípios gerais para determinar em quais prioridades focar primeiro. -Essas áreas abaixo estão listadas em ordem de prioridade, então o próximo parágrafo é a mais alta prioridade (top priority), seguido pela próxima prioridade, etc. Só por que algo é prioridade mais baixa não significa que é "menos importante" - somente significa tratar as coisas de prioridades mais altas (higher-priority) primeiro.

Constrói?

  • Constrói confiavelmente?

O primeiro teste - o software constrói a partir do código fonte corretamente? Isso não se trata somente de emergir ebuilds no seu sistema -- OS builds do stage funcionam sem problemas utilizando o Metro? Se não, isso precisa ser corrigido primeiro. O Funtoo Linux continuamente constrói lançamentos do sistema operacional atualizados, e essas devem ser construídas confiavelmente em todos os momentos. O foco aqui é para builds 100% corretos e eficientes utilizando o Metro, e depois emergindo aplicações iniciais em um sistema Funtoo Linux.

Ele executa?

  • Ele executa bem?

OK, ele constrói. Ele executa corretamente? Ele funciona? Isso é bem vago, então vamos colocar algumas especificações aqui. Quando instalar o Funtoo Linux a partir do stage3, tudo funciona? Quais complicações ou falhas foram encontradas na instalação inicial? Essas devem ser corrigidas, ou soluções devem ser colocadas no lugar, e correções a longo prazo devem ser trabalhadas para melhorar a experiência do usuário. Lembre-se de que o foco do Funtoo Linux é no sistema central - Essa é a coisa que você toca quando você instala o Funtoo Linux pela primeira vez. Você deve reinstalar o Funtoo Linux regularmente para verificar por quaisquer questões e priorizar as questões de instalação do usuário e a experiência inicial do usuário.

Consigo Usá-lo?

  • Facilmente?
  • Para Trabalho de Verdade?

OK, ele constrói, e executa. Mas eu posso realizar tarefas de verdade com a ferramenta? Qual é a facilidade ou dificuldade de realizar essas tarefas? A tecnologia (e documentação) devem ser projetadas para oferecer suporte ao usuário na questão de realizar estas tarefas, ao invés de forçar o usuário a saltar por arcos para obter algo configurado corretamente. As coisas devem ser automatizadas o tanto o quanto possível sem assumir controle distante do usuário. Padrões seguros, razoáveis que são adequados para a cargas produtivas devem ser utilizadas por todas as aplicações. As coisas devem emergir sem bloqueadores ou ausência de recursos que devem ser habilitadas manualmente pelo usuário. E uma implicância - se o emerge parar para dizer ao usuário que ele deve definir uma variável USE para que continue, isso é algo que deve ser corrigido de um jeito ou de outro. Então, quando tudo é dito e feito, ele deve funcionar.

É Documentado?

  • Para projetos de software livre, documentação é a chave.

Se o software, executa e funciona, outros ainda podem ainda não ser capaz de utilizá-lo até que documentação adequada esteja disponível. Documentação montante nem sempre é completa ou fácil de entender, então frequente documentação adicional para usuário é necessária. Se etapas do manual são necessárias, elas devem ser documentadas claramente e corretamente. A opção de escolha da documentação é a Funtoo wiki tão bem quanto as man pages.

Para o código fonte, comentários bem detalhados devem ser utilizados. Você pode estar trabalhando no código agora, mas outra pessoa poderá estar trabalhando nele daqui a seis meses. É esperado que desenvolvedores escrevam comentários claros que sejam suficientemente não-técnicos e forneça o contexto necessário para permitir que desenvolvedores menos experiente entendam partes criticas do código, e idealmente 'todas' as partes do código. Por favor veja Padrões de Código.

É bem projetado?

  • Otimizado?
  • Sustentável?

Ele constrói e executa, e eu posso utilizá-lo para realizar trabalho de verdade. Mas o sistema é bem projetado? Ele funciona confiavelmente? Todos os patches estão disponíveis e corrige o lugar para assegurar uma experiencia computacional confiável? O Funtoo Linux está fornecendo a melhor tecnologia possível aos usuários? E essa tecnologia é fácil de manter? lembre-se, todas as coisas sendo iguais, menos código é melhor que mais código por que é mais fácil de manter. Há comentários detalhados no código aonde é necessário?

Estamos melhorando?

OK, estamos fazendo todas as etapas acima. Aqui está o próximo teste - estamos melhorando? A qualidade, segurança, usabilidade e a manutenção da distribuição está melhorando com o tempo, ou ela está subindo, e depois descendo, e não estamos mesmo tendo nenhum progresso? O objetivo no final do dia é obter progresso avançado no qualidade da distribuição. Isso requer automação melhor, ferramentas melhores, processos melhores, e investimento em pesquisa e desenvolvimento e novos métodos de fazer coisas. Isso também requer a atitude correta. Se estivermos fazendo um monte de trabalho e a qualidade global da distribuição não estiver melhorando, então nossos esforços não estão fazendo diferença a longo prazo, mesmo que eles possam estar tratando bugs e problemas imediatos. Temos que garantir que nossos esforços venham valer a pena, e que eles estão fazendo uma diferença positiva a longo prazo na qualidade da distribuição.

Qual o verdadeiro problema?

Construindo nesse tema - quando um bug é encontrado, qual é o verdadeiro problema, ou a raiz (root cause)? Pensamento estratégico tão bem quanto uma resolução profunda (in-depth troubleshooting) é necessária para identificar a raiz do problema. Devemos somente corrigir as raízes? Não, isso é impraticável, por que fazer isso leva muito tempo. Ao invés disso, soluções alternativas são com frequência utilizadas para restauras rapidamente a qualidade à níveis aceitáveis. No entanto, somente implementar soluções alternativas é perigoso, por que os bugs tendem a multiplicar-se enquanto a questão subjacente não for solucionada. A solução adequada é implementar soluções alternativas mas não perder o foco no necessário para tratar as questões subjacentes, ou raízes, do problema. De fato, muito do foco do Funtoo Linux está nessa ultima etapa - agressivamente corrigindo um monte de questões imediatas assim nós podemos começar a tratar os problemas mais profundos de uma vez por todas...

Arquitetura

...e tratar da raiz de problemas com frequência requer uma mudança significativa na arquitetura de software. Funtoo Linux é um projeto que não tem medo de fazer alterações arquitetônicas significantes, e mesmo agressivas, a fim de corrigir problemas. Isso é o que os nossos usuários esperam que façamos, e desde que essas alterações sejam propriamente testadas, gerenciadas, planejadas, automatizadas e comunicadas aos usuários, eles não irão se chatear. Conforme declarado no parágrafo anterior, o projeto Funtoo Linux é zeloso a respeito de tratar esses problemas centrais de arquitetura -- mas nós precisamos controlar os desafios mais fundamentais primeiro. Uma vez soluções alternativas estão no lugar, levaremos uma punhalada em alguma alteração no sistema central que pagarão dividendos bem no futuro.

Exemplos

Abaixo, você encontrará exemplos de esforços que tem alinhados a esses objetivos. Essa seção lhe dará uma sensação do quanto projetos reais podem ser iniciados que se alinham com a visão do Funtoo Linux definida acima.

Boot-Update

Boot-Update foi projetado por Daniel Robbins para prover um jeito mais elegante de configurar o carregador de boot sob o Funtoo Linux. Esse projeto foi priorizado por várias rasões. Uma, esse projeto tinha que fazer com que a experiência da instalação inicial (veja #Ele executa?) Também, ausência do suporte ao GRUB2, tão bem quanto o suporte ao GPT/GUID, foi definido como um ponto fraco crítica na funcionalidade atual do Gentoo Linux (veja #É bem projetado?) Por isso, um novo configurador unificado foi escrito que utiliza /etc/boot.conf como arquivo de configuração para o carregador de boot global. Isso representa a mudança na arquitetura do carregador de boot (veja #Arquitetura) sob o Funtoo Linux, a fim de melhorar a usabilidade e a flexibilidade em soluções existentes, e tentar reduzir ou eliminar uma classe de problemas relacionadas a configuração do carregador de boot, que é especialmente problemático no GRUB2.

Metro

Metro foi projetado por Daniel Robbins e é utilizado para tratar a questão do "#Constrói?". A solução existente, catalyst, foi difícil de manter (veja #É bem projetado?), então Metro foi desenvolvido para prover um novo mecanismo para a construção de lançamentos de sistema operacional (OS releases).

Forked Ebuilds

Nem todas as melhoras envolvem grandes esforços no desenvolvimento de software. De fato, a maioria das correções envolvem correções relativamente pequenas para os ebuilds. Essas correções são com frequência feitas para corrigir uma falha no Metro build (veja #Constrói?) ou tratar de alguma questão de qualidade (veja #É bem projetado?). O ebuild www-servers/nginx foi melhorado para prover melhores configurações padrões para sistemas de produção, com alterações correspondentes feitas ao sys-libs/pam para permitir que isso funcione. dev-lang/python contem correções para assegurar que o contem correções para assegurar que Metro builds complete corretamente e um symlink /usr/bin/python válido sempre exista.

OpenVZ

Suporte a OpenVZ é uma prioridade específica do Funtoo Linux. Funtoo Linux mantem um patched sys-cluster/vzctl com vários patches para corrigir uma variedade de problemas. Em adição, openvz-rhel6-stable e openvz-rhel5-stable ebuilds tem sido criados para facilitar a instalação de kernels OpenVZ de qualidade para produção (veja #Consigo Usá-lo?) em adição, documentação OpenVZ existe no wiki (veja #Consigo Usá-lo?)