Frequently asked questions (Português)
Geral
O que é o Arch Linux?
Veja o artigo Arch Linux.
Por que eu não iria querer usar o Arch?
Você pode não querer usar o Arch, se:
- você não tem habilidade/tempo/desejo para uma distribuição GNU/Linux do tipo faça você mesmo.
- você precisa de suporte a uma arquitetura diferente de x86_64.
- você insiste em usar uma distribuição que só fornece software livre conforme definido pela GNU.
- você acredita que um sistema operacional deve se autoconfigurar, vir pronto para usar e incluir um conjunto padrão completo de softwares e ambiente de área de trabalho na mídia de instalação.
- você não deseja uma distribuição GNU/Linux de lançamento contínuo (rolling release).
- você está satisfeito com seu SO atual.
Por que eu iria querer usar o Arch?
Porque o Arch é o melhor.
A quais arquiteturas o Arch dá suporte?
O Arch suporta apenas a arquitetura x86_64 (às vezes chamada de amd64). O suporte para i686 foi abandonado em novembro de 2017 [1].
Há portes não oficiais para as CPUs da arquitetura i686 [2] e da ARM [3], cada um com seus próprios canais comunitários.
O Arch segue o Filesystem Hierarchy Standard (FHS) da Linux Foundation?
O Arch Linux segue FHS (em português, hierarquia de sistema de arquivos) para sistemas de arquivos usando o gerenciador de serviço systemd. Veja file-hierarchy(7) para uma explicação de cada diretório junto com suas designações. Em especial, /bin, /sbin e /usr/sbin são links simbólicos para /usr/bin, e /lib e /lib64 são links simbólicos para /usr/lib.
Eu sou um completo iniciante no GNU/Linux. Eu deveria usar o Arch?
Se você é um iniciante e deseja usar o Arch, você deve estar disposto a investir tempo para aprender um novo sistema, e aceitar que o Arch é projetado como uma distribuição de faça você mesmo; é o usuário que monta o sistema.
Antes de pedir ajuda, faça sua própria pesquisa em mecanismos de pesquisa, em fóruns e nas várias fantásticas documentações fornecidas pelo Arch Wiki. Há uma razão para que estes recursos tenham sido disponibilizados. Muitos milhares de horas de voluntários foram gastos compilando essas informações excelentes.
Veja também Terminologia do Arch#RTFM e o Guia de instalação.
O Arch é projetado para ser usado como um servidor? Um desktop? Uma estação de trabalho?
O Arch não foi projetado para nenhum tipo de uso específico. Em vez disso, ele é projetado para um determinado tipo de usuário. O Arch visa usuários competentes que gostam de sua natureza faça você mesmo e que a exploram ainda para moldar o sistema para atender às suas necessidades exclusivas. Portanto, nas mãos de sua base de usuários alvo, o Arch pode ser usado praticamente qualquer propósito. Muitos usam o Arch em seus desktops e estações de trabalho. E, claro, o archlinux.org, aur.archlinux.org e quase toda a infraestrutura do Arch funciona no Arch.
Eu realmente gosto do Arch, exceto que a equipe de desenvolvimento precisa implementar o recurso X
Participe, contribua seu código/solução para a comunidade. Se for bem aceito pela comunidade e pela equipe de desenvolvimento, talvez seja incorporado. A comunidade do Arch prospera em contribuição e compartilhamento de código e ferramentas.
Quando o novo lançamento estará disponível?
Os lançamentos do Arch Linux são apenas um ambiente live para instalação ou resgate, que inclui o metapacote base e alguns outros pacotes. Os lançamentos são geralmente emitidos na primeira metade de cada mês.
O Arch Linux é uma distribuição estável? Vou presenciar frequentes quebras?
O usuário é o responsável pela estabilidade de seu próprio sistema de lançamento contínuo. O usuário é quem decide quando atualizar e mesclar alterações necessárias, quando necessário. Se o usuário buscar na comunidade por ajuda, geralmente consegue em pouco tempo. A diferença entre o Arch e outras distribuições está realmente no fato do Arch ser uma distribuição "faça você mesmo"; reclamações sobre quebras e travamentos são equivocadas e contraproducentes, já que alterações no upstream não são responsabilidade dos desenvolvedores do Arch.
Veja o artigo Manutenção do sistema para dicas sobre como tornar um sistema Arch Linux o mais estável possível.
O Arch precisa de mais divulgação (isto é, propaganda)
O Arch já recebe bastante cobertura da imprensa. O objetivo do Arch Linux não é ser grande; em vez disso, o crescimento orgânico e sustentável ocorre naturalmente entre a base de usuários alvo.
O Arch precisa de mais desenvolvedores
Possivelmente. Sinta-se à vontade para se voluntariar! Visite os fóruns, canais IRC, listas de discussão e veja o que precisa ser feito. Veja também como Participar para mais detalhes.
Instalação
Arch precisa de um instalador. Talvez um instalador de interface gráfica?
O Arch costumava ter um instalador com uma interface de usuário baseada em texto chamada de Arch Installation Framework (AIF). Depois que seu último mantenedor saiu, o projeto foi descontinuado em favor dos arch-install-scripts.
Desde 01/04/2021, o Arch tem um instalador novamente. Veja archinstall para mais detalhes.
Instalei o Arch e agora estou em um shell! E agora?
Veja Recomendações gerais.
Qual ambiente de desktop ou gerenciador de janelas devo usar?
Como muitos estão disponíveis para você, use aquele que melhor se adapta às suas necessidades. Dê uma olhada nos artigos Ambiente de desktop e Gerenciador de janela.
O que torna o Arch único entre outras distribuições "mínimas"?
Veja Arch em comparação com outras distribuições.
Manutenção do sistema
Veja também Manutenção do sistema.
Por que a minha internet está tão mais lenta em comparação com outros sistemas operacionais?
Sua rede está configurada corretamente? Dê uma olhada no artigo Configuração de rede. Para configurações avançadas, você também pode querer dar uma olhada em traffic shaping.
Um dos kernels mais comumente usados, linux, tende a ser mais novo que o kernel de outras distribuições Linux mais estáveis. Por isso, você raramente pode experimentar uma regressão do kernel ou bug de driver, especialmente se estiver usando Wi-Fi. Observe que a grande maioria desses bugs não são específicos do Arch Linux, pois o Arch Linux aplica apenas os patches mais básicos. Isso precisa ser feito ao upstream. Veja #Eu encontrei um erro no pacote X. O que eu devo fazer?.
Por que o Arch está usando toda minha RAM?
Essencialmente, RAM não usada é RAM desperdiçada.
Muitos novos usuários podem notar como que o kernel do Linux trata memória diferentemente de como era usado antes. Considerando que o acesso a dados da RAM é muito mais rápido do que de uma unidade de armazenamento, o cache do kernel de dados recentemente acessados na memória. Os dados em cache são apagados apenas quando o sistema começa a ficar sem memória disponível e novos dados precisam ser carregados.
Nós poderíamos fazer a distinção pelo comando free:
$ free -h
total usada livre compart. buff/cache disponível Mem.: 2.8Gi 1.1Gi 283Mi 224Mi 1.4Gi 1.2Gi Swap: 3.0Gi 881Mi 2.1Gi
É importante notar a diferença entre memória "livre" e "disponível". No exemplo acima, um laptop com 2.8Gi de RAM total parece estar usando a maioria dela, com apenas 283Mi como memória livre. Porém, 1.4Gi disto é "buff/cache". Há ainda 1.2Gi disponível para iniciar aplicativos, sem fazer swap. Veja free(1) para detalhes. O resultado de tudo isso? Desempenho!
Veja esse maravilhoso artigo se você ficou curioso. Há também um site dedicado a esclarecer essa confusão: https://www.linuxatemyram.com/.
Para onde foi todo meu espaço livre?
A resposta para essa pergunta depende do seu sistema. Existem alguns ótimos utilitários que podem ajudar você a encontrar a resposta.
Por que não consigo fazer login?
Você digitou sua senha ou cancelou um comando sudo três vezes em quinze minutos? Se sim, você acionou um mecanismo de prevenção contra ataques de força bruta: veja Segurança#Bloquear usuário após três tentativas de login com falha para mais detalhes.
Arch faz "phone home"?
- os usuários do NetworkManager devem saber que ele faz verificações automáticas de conectividade: a URL de conectividade padrão é fornecida pelo Arch e comprometida em não registrar nenhum acesso;
- Clientes do Network Time Protocol em sua configuração padrão usam um pool de fornecedores de servidores NTP fornecido pelo NTP Pool Project (conforme suas regras);
- conforme explicado pela nota em Pacman/Assinatura de pacote#Atualize o sistema regularmente, uma vez por semana um timer systemd é executado para atualizar as novas assinaturas de chaves já confiáveis: não há registro de nenhum acesso lá também.
Você pode querer fazer "phone home" ("enviar seua dados para um servidor") voluntariamente contribuindo para o projeto pkgstats que coleta dados anônimos de popularidade de pacotes para ajudar os desenvolvedores do Arch a priorizar seus esforços.
Gerenciamento de pacote
Veja as páginas pacman, pacman/Dicas e truques e Repositórios oficiais para mais respostas.
Eu encontrei um erro no pacote X. O que eu devo fazer?
Primeiro, você precisa descobrir se esse erro é algo que a equipe do Arch pode consertar. Frequentemente não é (por exemplo, travamentos do Firefox podem ser culpa da equipe do Mozilla); isso é chamado de erro upstream, veja Bug reporting guidelines (Português)#Upstream ou Arch?. Se for um problema do Arch, há uma série de etapas que você pode seguir:
- Procurar informações no fórum. Veja se alguém teve o mesmo problema.
- Publique um relatório de erro com informações detalhadas sobre o rastreador de bugs do Arch Linux no Gitlab.
- Se desejar, você pode criar um tópico no fórum descrevendo o problema e informando que você já relatou o mesmo. Isto ajuda a prevenir que várias pessoas relatem o mesmo erro.
Os pacotes do Arch precisam usar uma nomenclatura única. ".pkg.tar.zst" é muito longo e/ou confuso
Isto foi discutido na lista de discussão do Arch. Alguns propuseram uma extensão de arquivo .pac, mas não há nenhum plano para modificar a extensão de pacote. Como Tobias Kieslich, um dos desenvolvedores do Arch, colocou, "Um pacote é um tarball [comprimido] !! E ele pode ser aberto, verificado e manipulado por qualquer aplicação tar. Além disso, o tipo mime é automaticamente detectado pela maioria dos aplicativos".
O pacman precisa de uma biblioteca para que outros aplicativos possam acessar facilmente informações dos pacotes
Pacman é um front-end para libalpm(3), acrônimo para "Arch Linux Package Management" ("Gerenciamento de Pacote do Arch Linux"), que permite front-ends alternativos, como um front-end gráfico, serem escritos.
O pacman precisa do recurso X!
Se você acha que sua ideia tem fundamento, então você pode discuti-la na pacman-dev. Verifique também https://gitlab.archlinux.org/pacman/pacman/-/issues e https://bugs.archlinux.org por requisições existentes por recursos.
Porém, a melhor forma de ter um recurso adicionado ao pacman ou Arch Linux é implementá-lo você mesmo. O patch ou código pode ou não ser aceito oficialmente, mas talvez outros vão apreciar, testar e contribuir para seu esforço.
Eu acabei de instalar o pacote X. Como eu o inicio?
Se você está usando um ambiente desktop como KDE ou GNOME, o programa deve ser automaticamente mostrado em seu menu se vier com uma Desktop entries. Se você está tentando executar o programa de um terminal e não mostrar o nome do binário, use:
$ pacman -Qlq nome-pacote | grep /usr/bin/
Por que há uma única versão de cada biblioteca compartilhada nos repositórios oficiais?
Diversas distribuições, como o Debian, possuem diferentes versões de bibliotecas compartilhadas empacotadas como pacotes diferentes: libfoo1, libfoo2, libfoo3 e por aí vai. Nesta forma, é possível ter aplicativos compilados com diferentes versões de libfoo instaladas no mesmo sistema.
No caso de uma distribuição como o Arch, apenas as últimas versões empacotadas são oficialmente suportadas. Ao descartar suporte a um software desatualizado, mantenedores de pacote conseguem gastar mais tempo assegurando que as versões mais novas funcionam conforme esperado. Assim que uma nova versão de uma biblioteca compartilhada é disponibilizada pelo upstream, ela é adicionada aos repositórios e pacotes afetados são recompilados para usar a nova versão.
E se eu executar uma atualização completa do sistema e houver uma atualização para uma biblioteca compartilhada, mas não para os aplicativos que dependem dela?
Esse cenário não deve acontecer. Presumindo que um aplicativo chamado foobaz está em um dos repositórios oficiais e compila com sucesso com a nova versão da biblioteca compartilhada chamada libbaz, ele será atualizado junto com libbaz. Se, porém, ele não compilar com sucesso, o pacote foobaz terá uma dependência versionada (p.ex.: libbaz 1.5) e será removido pelo pacman durante a atualização de libbaz, por causa de um conflito.
Se foobaz é um pacote que você mesmo compilou e instalou do AUR, você deve recompilar foobaz com a nova versão de libbaz. Se a compilação falhar, relate o erro aos desenvolvedores do foobaz.
É possível haver uma atualização de versão maior do kernel no repositório e que alguns dos pacotes de driver não tenham sido atualizados?
Não, não é possível. Atualizações de versões maiores do kernel (p.ex. linux 3.5.0-1 para linux 3.6.0-1) são sempre acompanhadas por recompilações de todos os pacotes de drivers de kernel. Por outro lado, se você tiver um pacote de driver sem suporte em seu sistema (por exemplo, do AUR) então a atualização de kernel pode quebrar coisas se você não recompilá-lo para o novo kernel. Os usuários são responsáveis por atualizar quaisquer pacotes de driver sem suporte que eles tenham instalado.
O que fazer antes de atualizar?
Siga a seção Manutenção do sistema#Atualizando o sistema.
Uma atualização de pacote foi lançada, mas o pacman diz que o sistema está atualizado
Mirrors do pacman não são sincronizados imediatamente. Leva cerca de 24 horas antes que uma atualização esteja disponível para você. As únicas opções são ser paciente ou usar um outro mirror. MirrorStatus pode lhe ajudar a identificar um mirror atualizado.
Upstream do projeto X lançou uma nova versão. Quanto tempo vai levar para o pacote do Arch ser atualizado para essa nova versão?
Atualizações de pacotes serão lançadas quando elas estiverem prontas. A quantidade específica de tempo pode ser tão curta quanto algumas horas após o upstream lançar uma atualização menor de correção de erros e tão longa quanto várias semanas após a atualização de versão maior de um grupo grande de pacotes. A quantidade de tempo de uma nova versão do upstream até o Arch lançar um novo pacote depende dos pacotes específicos e da disponibilidade dos mantenedores de pacote. Adicionalmente, alguns pacotes ficam algum tempo no repositório testing, então isso pode prolongar o tempo antes de um pacote ser atualizado. Cada mantenedor de pacote tenta trabalhar rapidamente para trazer atualizações estáveis para os repositórios. Se você encontrar um pacote nos repositórios oficiais que está desatualizado, vá até a página do pacote no site de pacotes e sinalize-o como tal.
Se eu precisar de uma versão mais antiga de uma biblioteca instalada, posso simplesmente fazer um link simbólico para a versão mais recente?
Se você tiver sorte, pode funcionar por um tempo. Independentemente disso, não é uma solução adequada, porque:
- As bibliotecas não alteram versões aleatoriamente - a API/ABI provavelmente terá mudado (possivelmente com partes removidas) e se essas mudanças afetam ou não o uso é apenas uma questão de sorte.
- O link simbólico não seria rastreado por um gerenciador de pacotes. Novatos que tentam imediatamente hackear arquivos da biblioteca do sistema correm o maior risco de fazer uma alteração indesejada que eles não podem diagnosticar/consertar, algo que um gerenciador de pacotes ajuda a evitar.
- Uma alternativa de colocar o arquivo da antigo biblioteca no sistema de arquivos, sem rastreamento, poderia ser esquecida e potenciais bugs de segurança não seriam notados/corrigidos.
Em vez disso, prefira algo como, por exemplo, usar/escrever um compat (compatibility) pacote, que fornece a versão necessária da biblioteca.
64 bits
Como eu determino se meu processador é compatível com x86_64?
Se seu processador é compatível com x86_64, você terá a flag lm (long mode) no /proc/cpuinfo. Por exemplo,
$ grep -w lm /proc/cpuinfo
No Windows, usar o freeware CPU-Z ajuda a determinar se seu CPU é compatível com 64-bit. CPUs com conjunto de instruções da AMD "AMD64" ou a solução da Intel "EM64T" devem ser compatíveis com os pacotes binários e lançamentos de x86_64.
Por que 64 bits?
É mais rápido na maioria das circunstâncias e, como um bônus adicional, inerentemente mais seguro devido à natureza de Aleatorização do layout de espaço do endereço (ASLR) em combinação com Código independente de posição (PIC) e Bit NX que não está disponível no kernel i686 devido à Extensão de Endereço Físico (PAE) desabilitada. Se seu computador tem mais de 4GiB de RAM, somente um sistema operacional de 64 bits poderá utilizá-lo totalmente.
Os programadores também têm se preocupado cada vez menos em relação a 32 bits ("legado"), pois as "novas" CPUs x86 geralmente oferecem suporte às extensões de 64 bits.
Há muitas outras razões que podemos listar aqui para dizer-lhe para evitar 32 bits, mas entre o kernel, o espaço de usuários e os programas individuais, simplesmente não é viável listar todas as últimas coisas que o 64 bits faz muito melhor nos dias de hoje.