Sim, em análises feitas no ano passado e neste ano com dezenas de distros com o máximo de ambientes gráficos possíveis o Fedora (ou os seus derivados) foi em 95% a distribuição Linux mais pesada. Criei um tópico para tratar de requisitos das distros e também deu isso. Tecnicamente a distro para propósito geral mais pesada atualmente é o Fedora com Gnome.
1 curtida
Resumindo minha participação no tópico.
Pretende se aprofundar no gerenciamento de pacotes RPM = Fedora, a parte bruta da biblioteca e suas funções são praticamente desenvolidas no fedora, o gerenciador seja zypper, dnf, apt-rpm, urpmi não importa.
Dentre os gerenciadores de pacotes rpm que já utilizei o zypper é o que engloba menos funções da biblioteca rpm (por isso é mais rápido), ele confia bastante na libsolv, mas pelo menos possui o básico da biblioteca rpm, porém não suporta caminho completo, não suporta curingas; pode parecer besteira, mas manter um sistema integro com essas duas funções da librpm é bem simples. Esses recursos fazem parte da biblioteca RPM fazem + ou - 18 anos e acho que deveriam estar disponíveis no zypper.
Um exemplo besta que pode levar um ou outro usuário a reinstalar o sistema, a perda da bibliotecas xyz.so.1, mas você não sabe o nome do bendito do pacote e está em modo texto, o padrão do formato rpm é você consegui utilizar curingas para procurar um pacote que você não sabe o nome ou poder instalar /usr/lib**/xyz.so.1, essa biblioteca faz parte do pacote vocẽ_não_lembra-xyz, então bastaria instalar *xyz*, *lembra*, experimente utilizar esse dois exemplo no zypper e me diga o resultado.
Vai usar como desktop padrão o GNOME = Fedora Workstation ou Silverblue, simplesmente pelo motivo desta distro ter seu desenvolvimento focado no GNOME, sua imagem de instalação apesar do tamanho 2GB + ou - vem com uma seleção de pacotes coerente e enxuta, pronta para usar.
Quanto a alguns comentários sobre consumo de memória, eu já expliquei o que faz o consumo de memória do fedora ser alto no inicio, se você for se aprofundar e utilizar somente o dnf para gerenciamente de pacotes, basta remover a gnome-software e o packagekitd. É recomendado? não.
Não é recomendado pois o packagekit faz parte da infraestrutura das distribuição, ele é o helper que vai se oferecer para instalar pacotes rpm, flatpaks, codecs, plugins que faltam, é ele que vai avisar sobre uma possível atualização para uma versão nova do sistema e por aí vai.
Sem packagekit/gnome-software, isso não é boot frio, isso são após 12 horas ligado, somente fechando as aplicações.
Então é isso, minha opinião.
Boa sorte aí, qualquer coisa só chamar que aqui você vai ter suporte para ambas.
3 curtidas
Lembro da primeira vez que vi YasT via terminal em um SUSE Enterprise fiquei maravilhado e ainda mais com da para fazer o mesmo no openSUSE (achava que apenas na versão enterprise era possível), openSUSE esta na minha lista pessoal de distros para servidor (Debian, CentOS, openSUSE).
1 curtida
Uma pergunta, como Wayland consegue ser tão estável no Fedora?
Não creio que seja só no fedora, eu não utilizo Xorg já fazem uns 8 anos, a diferença é que o fedora começou a utilizar wayland em 2013 oficialmente, as outras distribuições como o debian demoraram bastante, e quando começaram falharam miseravelmente pois não estavam preparadas para executar aplicações que precisavam de permissões de super usuário em modo gráfico, isso já foi resolvido, mas a culpa recai no wayland, sendo que o polkit foi criado para resolver isso.
Uso Arch, ouvi dizer q a Nvidia não tem suporte pro Wayland, não sei quanto ao AMD.
Tem um suporte ruinzinho, mas tem sim, creio que isso será resolvido em breve, pelo menos é o que se espera, se não me engano mandaram algumas alterações no driver para análise da NVIDIA, agora é só esperar a boa vontade deles.
https://blogs.gnome.org/uraeus/2019/09/23/fedora-workstation-31-whats-new/
No Fedora Workstation 31, Wayland ainda está desabilitado por padrão se você usar o driver binário da Nvidia. A razão para isso é devido à falta de aceleração no XWayland, o que significa que qualquer aplicativo que dependa do GLX, como muitos jogos, receberá apenas a renderização do software GL com o driver binário NVidia. Isso não é algo que possamos resolver por conta própria, a Nvidia tem que fazer o trabalho desde seu driver de código fechado, mas temos discutido isso regularmente com eles e fomos informados agora que eles estão olhando para o trabalho de Adam Jackson há algum tempo que tinha como objetivo específico ajudá-los a trazer seu driver X.org para o XWayland. Ainda não temos um cronograma, mas ele está sendo analisado ativamente e, esperançosamente, uma data adequada pode ser fornecida em breve. Na verdade, estou executando o Fedora Workstation 31 usando o driver NVidia neste momento neste laptop, e para aqueles interessados em ajudar a dogfood nesta configuração, em preparação para poder habilitar o Wayland em NVidia no Fedora Workstation 32, é uma coisa bastante simples de fazer. Sob
/usr/lib/udev/rules.d/você encontrar um arquivo chamado61-gdm.rules, apenas edite esse arquivo e comente (#) a linha que diz ’DRIVER=="nvidia", RUN+="/usr/libexec/gdm-disable-wayland"’ e você reverterá para uma configuração padrão onde sua sessão padrão é uma sessão de Wayland, mas com uma sessão x.org disponível como um substituto . Quanto mais pessoas executam isso e relatam problemas, melhor, pois isso nos ajuda a tornar essa rocha sólida antes de liberá-la para o mundo.
No Arch a nova atualização do Kernel 5.9 bug meu PC, eles mexeram no nouveau e o PC trava depois de um tempo de uso. Tenho que esperar eles atualizem o nouveau.
Se possível reverta o kernel e espere até meados de novembro, é conhecido problemas da NVIDIA com o kernel 5.9, mas achei que era só o driver binário deles.
Minha placa de vídeo e muito antiga e uma geforce 210.
É, nunca fui usuário de Fedora em uma máquina minha (só testes), mas, os dados não mentem mesmo, Fedora em quase todos os quadros, excetuando-se sistemas operacionais específicos como distros que rodam especialmente em mainframes, é a distro de propósito geral mais pesada.
Não experimento tanta memória ocupada quanto o pessoal fala. Salvo se abrir um monte de coisas, claro.
Tem uma explicação do PandaTitan que vou colar abaixo:
1 curtida
Já que o assunto foi para uso de ram, algumas imagens sequenciais para refletir antes de julgar “peso” apenas com sobre o free -h:
Esquerda Fedora Workstation / direita KDE neon
Conclusão, free -h não necessariamente informa o “peso” sobre a RAM, pois o sistema pode gerenciar com inteligencia e liberar espaço de acordo com que vai precisando.
2 curtidas
Sendo um pouco idiota
Fedora silverblue vs microOS
Eu gostaria de mais explicações, especialmente mais detalhes sobre as limitações do zypper e da libsolv.
Eu falei limitações do zypper e não da libsolv (o dnf também utiliza libsolv), a libsolv é otima na resolução de dependência, o caso da limitação do zypper está em sua citação e pelo menos até a última vez que testei o zypper ele ainda não lidava com curingas e caminho completo de arquivo.
Execute estas duas operações simples no zypper.
Legal! Eu faria a primeira usando zypper se --provides --match-exact /caminho/do/arquivo.
Aqui no meu sistema, o comando retorna:
skywall:~ # zypper se --provides --match-exact /etc/default/grub
Loading repository data...
Reading installed packages...
S | Name | Summary | Type
---+-------+-------------------------------------------------------+--------
i+ | grub2 | Bootloader with support for Linux, Multiboot and more | package
Como podemos ver, ele localizou que o arquivo pertence ao pacote grub2, que está instalado. Eu poderia, então, executar um zypper in na sequência.
Já para a segunda, é possível utilizar coringas normalmente para pesquisar…
skywall:~ # zypper se fvwm*
Loading repository data...
Reading installed packages...
S | Name | Summary | Type
---+-------------+------------------------------+--------
| fvwm-themes | FVWM Configuration Framework | package
i+ | fvwm2 | The F Virtual Window Manager | package
…e instalar pacotes:
skywall:~ # zypper in fvwm*
Loading repository data...
Reading installed packages...
'fvwm2' providing 'fvwm*' is already installed.
No update candidate for 'fvwm2-2.6.7-lp151.3.3.x86_64'. The highest available version is already installed.
Resolving package dependencies...
The following NEW package is going to be installed:
fvwm-themes
1 new package to install.
Overall download size: 835.1 KiB. Already cached: 0 B. After the operation, additional 2.5 MiB will be used.
Continue? [y/n/v/...? shows all options] (y): n
1 curtida
Eu estava olhando aqui e creio que citei um pacote que não estava no repositório como exemplo para o curinga *, “falha da minha parte”, mas quanto ao caminho completo há de concordar que se o formato suporta então o in diretamente teria que instalar o arquivo sem a necessidade de uma busca prévia --provides.
Obrigado por me corrigir, eu fui infeliz na escolha do pacote, logo zypper e dnf estão no mesmo nível, ainda não fiz um teste de transação com o zypper com uma atualização completa do sistema, mas isso só quando sobrar tempo.
Infelizmente aquelas opções para caminhos só funcionam para busca mesmo. Eu olhei a man page e dei uma pesquisada, mas não consegui fazer a operação de instalação diretamente. A página de manual até diz o seguinte:
The NAME component of a capability is not only a package name but any symbol provided by packages: /bin/vi, libcurl.so.3, perl(Time::ParseDate). Just remember to quote to protect the special characters from the shell, for example: zypper>0.8.10 or ‘zypper>0.8.10’.
1 curtida