Frequently asked questions (Português)

Status de tradução:
Esse artigo é uma tradução de
Frequently asked questions
. Data da última tradução: 2024-10-23. Você pode ajudar a sincronizar a tradução, se houver
alterações
na versão em inglês.
Artigos relacionados
Terminologia do Arch
Arch comparado a outras distribuições
Repositório de usuário do Arch#Perguntas frequentes
Solução de problemas gerais
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
(
l
ong
m
ode
) 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.