Você provavelmente aprendeu Linux errado (assim como eu)

Linux
,
1

Esse post serve como um pedido de desculpas por coisas que eu fiz errado, vamos lá:

Você não precisa do /usr/bin

Mas calma, não é pra excluir, é pra não mexer, o Linux no desktop possui algumas variáveis ambientes que ditam como o sistema vai se comportar, a variável PATH diz ao sistema onde buscar executáveis, tipicamente ela tem os diretórios:

  • /usr/local/sbin
  • /usr/local/bin
  • /bin
  • /sbin
  • /usr/sbin
  • /usr/bin
  • /usr/games
  • /usr/local/games

Isso significa que quando você executa um comando primeiro o sistema procura em /usr/local/sbin, se não achar em /usr/local/bin e assim sucessivamente, o ponto aqui é que isso não é estático, editando o arquivo .profile na sua HOME ou em /etc/profile caso queira fazer isso globalmente então você pode fazer o sistema buscar executáveis onde você quiser

Você não precisa do /usr/share

Quando você instala/modifica um tema, fonte, ou lançador no menu você provalvelmente escreve em alguma pasta em /usr/share a verdade é que você não precisa dela, a lógica aqui é exatamente a mesma que o PATH, mas com a variável XDG_DATA_DIRS:

  • /usr/local/share
  • /usr/share

Vamos supor que eu queira por um tema, usualmente eu faria em /usr/share/themes, mas se eu quiser eu posso fazer isso em /var/natanael/themes basta colocar /var/natanael no início da variável XDG_DATA_DIRS

Conclusão

Não precisa ter medo de perder a liberdade de modificar o sistema com a onda dos sistemas imutáveis, desde que você ainda possa escrever em /etc/profile nada está perdido, os caminhos são separado por : e tem outras mais avançadas:

  • LD_LIBRARY_PATH
  • GSETTINGS_SCHEMA_DIR
  • QTPATH
  • QT_PLUGIN_PATH
  • QT_PLUGIN_PATH
  • GDK_PIXBUF_MODULEDIR
  • GDK_PIXBUF_MODULE_FILE
  • …

Elas permitem ter um sistema extremamente customizado onde não importa se a base é imutável ou não, e o melhor de tudo: se você fizer besteira, simplesmente apague e reinicie o sistema volta exatamente como antes, espero que esse post acalme a animosidade sobre sistema imutáveis: nada mudou, você só fazia as coisas no lugar errado

13 curtidas
2

Legal!

Eu não sabia disso. Costumo adicionar as configurações personalizadas dentro da pasta de usuário em .local, onde geralmente os aplicativos procuram as configurações personalizadas (como pulse.pa). A solução de guardar os arquivos em nova pasta é bem interessante para computadores com vários usuários, evitando-se mexer nos arquivos de sistema, bem como duplicar a informação para cada usuário.

2 curtidas
3

Bom, fazendo isso, se você cometer algum erro mexendo nos temas ou variáveis do sistema, basta limpar algumas das pastas na home e você terá um sistema novo em folha, evitando dores de cabeça por conta de uma bobeira assim :joy:

1 curtida
4

Obrigado pela dica, @Natanael.755

Acabo de descobri que “não aprendi errado”… porque nunca aprendi a fazer nada disso – nem do modo certo, nem do modo errado. :joy:

A dor e a delícia de ser um mero “usuário médio”.

Mas, anotei, pois nunca se sabe o que o amanhã nos reserva!

3 curtidas
5

Também é uma maneira, mas aí só funciona para o seu usuário. Quando vc quer ter uma personalização de toda a instalação para todos os usuários deve seguir o fluxo proposto pelo amigo aí em cima.

Perfeito o post! Parabéns.

A coisa fica mais emocionante usando os links simbólicos, respeitando essa estrutura.

Sistemas quebram muito quando manipulamos partes de que não deveríamos. Se você aprende a moda dos imutáveis não faz diferença nenhuma, só complica rsss

1 curtida
6

Há problemas de usar temas só para usuários. Quando você tentar usar um app gráfico como outro usuário (yast, synaptic e outros que rodam como root) ele não vai encontrar seu tema.

1 curtida
7

É bom que existam opções, mas acho que para a grande maioria dos casos onde haja 1 usuário é mais simples fazer as alterações na raiz.

1 curtida
8

É só definir no /etc/profile, na variável XDG_DATA_DIRS para que o sistema busque globalmente temas, executáveis, etc, na sua pasta home, por exemplo. Você não vai estar bagunçando as pastas importantes do sistema com customizações, mas vai funcionar direitinho.

3 curtidas
9

A alteração é feita na raiz, só não deve ser feita em /usr

1 curtida
10

A bronca é que “um usuário” que aprende errado fica replicando de forma errada em todo sentido. Costumo dizer que obedecer padrões te liberta de erros futuros.

A coisa mais deseducativa que acho são esses vídeos de reviews, sinceramente podem até gerar views mas não geram autoridade alguma.

11

Perceba que eu fiz uma restrição.

12

Não é que você não precisa destas pastas, é mais uma questão de padrões, as pessoas esperam chegar em uma distro e encontrar esta mesma regra geral de “coisas coletivas dos usuários” instaladas em /usr. Então eu diria que no geral as pessoas precisam de um padrão, acho que é mais uma questão de não ser obrigado a seguir o padrão por questão de flexibilidade. Mas enfim, tem muito mais coisa que você não é obrigado também… /etc → ~/.config /lib → /.local/lib /tmp → ~/tmp.

Também não acho que seja uma questão de ser errado usar estes diretórios, a convenção é armazenar componentes de uso compartilhado nestes locais, e de uso pessoal no diretório do usuário. Inclusive, às vezes é uma boa dar uma olhada mais a fundo, pois meio que já existem vários diretórios pré-definidos como substitutos das versões globais, que são convenções já, como ~/.config ~/.bin, ~/.local, etc…

Outra coisa que vi agora, é que você meio que propõe usar /etc/profile como uma forma de contornar as limitações de sistemas imutáveis, acho que isso resolve várias coisas de fato, mas não tudo, /etc/profile tem várias limitações, provavelmente usar overlayFS seria o ideal. Eu acredito que muitas distros imutáveis já fazem isso.

13

Pela própria documentação do LHS é errado, /usr deve ser RO para usuários

OverlayFS é utilizados pelas distros imutaveis em um contexto diferente, a ideia é usar pacotes do repositório para modificar a imagem do sistema em /usr, o contexto aqui é usar arquivos avulsos para modificar o sistema em um contexto multiusuário, o /etc/profile cobre todos os cases prováveis de utilização, desde perfis de cor de impressoras até o caminho de busca por recursos do interpretador ELF padrão, se o usuário busca algo que o profile não cobre, é praticamente certo que ele não está utilizando um sistema desktop mas sim montando um cenário de imagem customizada não-LHS do sistema onde o único cenário fora de um docker da vida seria a criação de uma remasterização em ambos os casos: não é o foco desse post

14

Não vejo como OverlayFS já não cobre estes casos ao ser usado para permitir mudanças em /etc.

Se for mesmo específico ao usuário normal, eu acho que o ideal então seria mudar ~/.profile ou ~/.bashrc, etc. Evita dar problemas em outros usuários incluindo o root, já que /etc/profile vale também para a sessão do /root

Outra coisa bacana é que muitos utilitários de backup de dotfiles meio que suportam já esse paradigma quando o pessoal passa a guardar as coisas em arquivos padrões em ~/.

Tranquilo, é que eu acho que seria legal avisar que isso não afeta daemons ou serviços do sistema, devido ao fato de /etc/profile e afins só funcionarem em login shells. Logo, por exemplo, se a pessoa estiver pensando em tentar usar LD_LIBRARY_PATH para resolver algum conflito de alguma lib sendo usada por algum serviço ou daemon de sistema, não rola.

15

Se a pessoa estiver fazendo isso, muito provavelmente ela mexeu no /usr onde não devia ter mexido da forma que mexeu, e para casos de excessões a essa regra para um cenário muito ruim onde o próprio sistema causa conflito “porque sim” tem o /etc/*.d, como o /etc/ld.so.conf, sendo assim de novo, desnecessário alterar /usr

OverlayFS tem um escopo diferente, você pode usar o APT para versionar documentos online ao invés de .debs, mas definitivamente não é o ideal

Perceba o enfoque do texto: tenho um recurso X que eu quero partilhar entre diversos usuários, fazer isso usuário a usuário é inviável

Algo importante, alterar o /usr vai fazer com que na próxima atualização a modificação em serviços e daemons sejam desfeitas

16

Eu não estou dizendo para o usuário editar /usr, estava me referindo a casos onde a distro tem um bug mesmo. Sim, esta é uma possível solução, eu pessoalmente modificaria o serviço/daemon, que não é uma mudança global para todos os programas.

Algumas distros usam OverlayFS, que eu saiba, Vanila OS e Chrome OS tornam alguns diretórios como /etc mutáveis com ajuda de OverlayFS se não me engano. Outras usam um mecanismo próprio de overlaying, caso do Silverblue.

Depende dos objetivos da distro eu acho, o bom de técnicas envolvendo OverlayFS, é que permitem mudanças em tempo real, ainda tendo “para onde voltar”, no caso uma versão imutável no passado. Outra forma seria o uso de BTRFS também, que permite algum nível de imutabilidade também, mas OverlayFS costuma ser mais simples.

Tranquilo, só dei outra sugestão, que pode funcionar, sem os riscos envolvidos no /etc/profile.

Quanto a esta parte, sim, o LHS indica que o diretório seja RO, mas não é errado usar estes diretórios nos momentos corretos, no mesmo sentido que /etc/profile ou /etc/ld.so.conf nem sempre é errado ou correto, depende.

17

se aprendi errado, nessa altura do campeonato vai errado mesmo. ;-(

18

Aí você não vai poder atualizar o sistema, se está em /usr a resposta dos gestores de pacotes é sobrescrever

A desvantagem é ter que efetivamente converter o sistema operacional inteiro pra trabalhar dessa forma, nem de longe é uma tarefa trivial

Introduzindo outros riscos não previstos, o sistema por design vir com OverlayFS é uma coisa, o usuário implantar por conta e risco é outra

19

No meu caso, eu ia preferir pra ficar só no meu usuario, pq de qualquer forma só teria ele, então nem faz diferença, mas reconheço que o trabalho do colega ali ficou muito bom, e que eu tenho que procurar mais sobre isso, achei deveras interessante

20

Meu ponto era mais em nem tudo estar garantido só via /etc/profile. Às vezes, nem tudo está resolvido mesmo que você possa editar /etc inclusive. Linux é usado de formas bastante diversas. E dai inevitavelmente o usuário vai ter que ter dor de cabeça com contêineres, se não for familiarizado.

A solução que o pessoal do Vanila OS usa é bem simples comparado ao RPM-OSTree, demanda bem menos mudanças no sistema para acomodar o mecanismo que eles usam.

No caso deles, somente /etc faz uso contínuo de um OverlayFS, mas graças a isso, o método deles e realmente stateless, o sistema consegue se recuperar de danos em /etc.

Se não me engano, o pessoal do silverblue está trabalhando para permitir ao menos um mecanismo de factory reset, para casos como esse.

Claro, não vou dizer que só OverlayFS resolve essa questão em particular, nem que garante que o usuário vai resolver tudo como em um sistema mutável.

Estava me referindo a ~/.profile como alternativa quando possível. Existem menos riscos tanto não previstos como previstos neste caso.

A solução do @Natanael.755 é bem boa para máquinas de laboratório com várias contas, ou da família toda. Mas você faz certo, se não tem porque, o ideal é em ~/… mesmo, vai de encontro com práticas de sistemas imutáveis como isolamento, editar /etc tem sua cota de implicações.