Caixa Seca

…considerando o Arch Linux. E sem gambiarras. A linha de corte para um desktop performático começa em GPUs Intel Gen 8 ou superior, ou seja, nos processadores Intel Core de 5ª Geração (Broadwell) em diante. Essas arquiteturas possuem suporte completo e maduro ao Vulkan através do driver anv do Mesa (e ao OpenGL via iris ). Em contrapartida, CPUs de 3ª e 4ª gerações — GPU Gen 7 (Ivy Bridge) e Gen 7.5 (Haswell) — dependem do driver Vulkan hasvk , que é limitado — embora o OpenGL ainda seja bem atendido de forma retroativa pelo driver crocus , que estende seu suporte desde a antiquíssima arquitetura Gen 4, do longínquo chipset i965 para Core 2 Duo. Há uma nuance com modelos da AMD. Até o kernel 6.18, o módulo amdgpu — um requisito obrigatório para a integração com o driver Vulkan radv do Mesa — suportava por padrão apenas a arquitetura GCN 3 (Volcanic Islands) e superiores. A partir do kernel 6.19, o amdgpu passou a ser o padrão também para as gera...

Kernel 6.5 parece ter resolvido a compatibilidade do simpledrm com o driver da Nvidia através do commit 5ae3716 — ainda requer os obsoletos drivers fbdev habilitados ( CONFIG_FB_EFI=y e CONFIG_FB_VESA=y ). A solução definitiva está presente a partir do driver 545. O módulo nvidia_drm ganhou a opção fbdev=1 , que torna-o compatível independente do commit citado e sem requerer os obsoletos drivers fbdev. Para usá-la, crie /etc/modprobe.d/blabla.conf (nome não importa, desde que termine em .conf ) contendo: options nvidia_drm modeset=1 fbdev=1 (são desativadas por padrão) É importante o initramfs ser recriado para conter esse arquivo. No Arch: mkinitcpio -P (requer o hook modconf configurado). Ambas podem ser especificadas igualmente nas opções de inicialialização: nvidia_drm.modeset=1 e nvidia_drm.fbdev=1 (hífen em nvidia-drm… também é aceito). Entretanto, em distribuições cujo kernel tenha este patch quebra-galho, a primeira opç...

Desde o kernel 5.14, lançado em 29 de agosto de 2021, existe o driver Direct Rendering Manager (DRM) genérico simpledrm , que usa o framebuffer fornecido pelo VBIOS/UEFI. Em distribuições que ativem-no ( CONFIG_DRM_SIMPLEDRM=y e CONFIG_SYSFB_SIMPLEFB=y ), adicionar nomodeset nas opções de inicialização passa a ser verdadeiramente um modo de segurança gráfico, que funciona com o Wayland: driver DRM nativo da GPU — como i915 , amdgpu , etc. — não é carregado e o simpledrm fornece um dispositivo DRM funcional [1] . LLVMpipe (Mesa) completa o time fornecendo OpenGL via software. Acaba beneficiando também o Xorg, pois seus drivers do espaço de usuário vesa e fbdev (há muito tempo com manutenção precária) não são mais requeridos. [ 0.599209] [drm] Initialized simpledrm 1.0.0 20200625 for simple-framebuffer.0 on minor 0 [ 0.600186] simple-framebuffer simple-framebuffer.0: [drm] fb0: simpledrmdrmfb frame buffer device https://fedorapro...

Nem tão novo assim… SystemRescueCd é meu Linux live preferido para tarefas de manutenção faz tempo. Até a versão 5.3.2 era baseado no Gentoo, distribuição alienígena para mim. Há cerca de um ano, mudou sua base para o Arch. Versão saltou para 6.0.0 indicando a mudança. Testei-a rapidamente e, quando vi que o layout de teclado brasileiro não funcionava, voltei à antiga e nela fiquei. Passado um ano, a antiguidade dos pacotes começou a pesar, em especial o kernel por causa do suporte a hardware. Tendo como base o Arch, não podia ser muito difícil. Decidido a resolver a questão do teclado, lá fui eu caçar bugs e, claro, consertá-los. Acabei resolvendo mais problemas pelo caminho. Shell padrão mudou do Zsh para o Bash na 6.0.0. Ambos são modernos, porém o Zsh tem, entre outros, o fantástico recurso de preenchimento automático navegável. Com o redesenho que fiz no mecanismo de autologin, foi fácil implementar a opção de boot rootshell= . A partir da versão 6.1.1, as seguintes opç...

✌ Adotei o XFCE como ambiente desktop faz alguns meses . Fora das personalizações estéticas, é tudo padrão do Arch, que, por sua vez, é fiel ao upstream. Portanto, Xfwm é o gerenciador de janelas, ou compositor. Até a atual versão 4.12, nenhuma estratégia para evitar tearing é usada. Os efeitos são tão visíveis que prejudicam até navegação na internet. Na versão de desenvolvimento 4.13, os quadros, depois de montados com XRender, são exibidos via XPresent, extensão relativamente recente (2013) do protocolo X11, que depende de drivers que implementem DRI3. Drivers abertos são compatíveis; proprietários, não. Como fallback, o código também passou a suportar OpenGL, mas não tenho como testar. Segundo discussões no Bugzilla, XPresent/DRI3 exige menos do hardware gráfico e por isso tem preferência. Decidi arriscar e migrei para o Xfwm 4.13 com ajuda do AUR . Demais componentes do XFCE ficaram nas versões oficiais do repositório. Minha "GPU" é uma Intel GM45 e uso o dri...

Minha alforria do GRUB Bootloader no-nonsense: systemd-boot Não tenho nada contra o escopo do GRUB de ser um bootloader tipo pia da cozinha, que suporta tudo de todas as maneiras possíveis. Repugnante é o formato usado em seus arquivos de configuração. Como bom nômade, migrei para o Arch depois de longa estada no openSUSE. Só que desta vez decidi não usar o GRUB de jeito nenhum. Configurei meu notebook para iniciar em UEFI e passadas algumas horas, com relativa facilidade, tinha um Arch funcional e enxuto com o GNOME. No lugar do inchado bootloader , pus o systemd-boot, antigo Gummiboot. Achei a página que trata dele na wiki desnecessariamente complicada. Meu particionamento é o mais KISS possível ( sugiro o cfdisk ): Disk /dev/sda: 465.8 GiB, 500107862016 bytes, 976773168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: XXXXXXXX-XXX...

Sem LVM/RAID por software, um initramfs não tem muito propósito. Podemos pulá-lo e dizer para o kernel montar diretamente o sistema de arquivos de uma partição e executar /sbin/init . Daí para frente, o systemd assume o comando. Para isso, alguns requerimentos: - O kernel precisa ter o suporte ao controlador de disco e ao sistema de arquivos usado na partição compilados como bulit-in , ou seja, não podem ser módulos. - O sistema de arquivos raiz não pode ter o diretório /usr separado. - O bootloader não deve carregar o initramfs. Infelizmente o kernel do Arch não tem o primeiro item nem pretende ter. No Fedora, sim; contudo, apenas o driver ext4 (que serve para EXT2/3 também) e os drivers ahci e ata_piix são built-in . Para pular o initramfs, remova a linha "initrd" do bootloader e passe para o kernel as opções: root=/dev/sdxy rootfstype=xyz O sistema de arquivos precisa ser especificado (usar o mesmo nome do módulo), pois, lembre, o kernel está sozinho. Nã...

Para você que reclama do Tracker do Gnome, espere para saber que o KDE 4 requer o MySQL ( não é de hoje... ). Isso mesmo, um SGBD desse porte num desktop. Por padrão. Não existem palavras para expressar o que penso. Imagine aí alguns palavrões. No Arch, o pacote que traz a dependência é o Akonadi. Prováveis cadeias: - mysql, requerido por akonadi, este requerido por kdepimlibs, que por sua vez é requerido por kdebase-runtime, do qual o ambiente inteiro depende. - kdebase-runtime tem a dependência em kdepimlibs como "optional". Caso o seja de fato, outra possível cadeia é kdepimlibs ser requerido por libkgapi e libkolab, que são requeridos por kdepim-runtime, do qual kdebase-workspace depende. Dizendo para o Pacman ignorar qualquer pacote da cadeia aborta a instalação com "dependências não resolvidas". Segundo este post do fórum do Arch, o openSUSE quebra o Akonadi em pacotes runtime/lib [1] , sendo que o runtime (que depende do MySQL) só é necessário caso...

Final sysvinit deprecation warning Hoje, alguns pacotes do Arch ainda distribuem os scripts SysV (pasta /etc/rc.d ) simultaneamente com os arquivos unit do systemd (pasta /usr/lib/systemd/system ). Como o Pacman não ativa nada por padrão -- e, no caso de um script ter o mesmo nome do arquivo .service, o último tem preferência --, não causava quebradeira. Confuso, contudo. Agora, o time do Arch tomou a decisão final para limpar a situação: nos pacotes que ainda possuem scripts SysV, os mesmos serão removidos em futuras atualizações. Para encerrar a conta, os pacotes initscripts e sysvinit serão removidos do repositório. \o/ Boa viagem!

Ao invés de ficar enxugando o Fedora, melhor construir uma instalação pequena no Arch. Ainda acompanharei o Fedora, pela sua relevância técnica e decisões pioneiras que vêm do projeto. Daqui para frente, aqui fala um Arch user. Para inaugurar, sempre que testava o Arch eu nunca lembrava a sintaxe do arquivo para colocar em /etc/X11/xorg.conf.d para fazer o teclado ficar em ABNT2. E ainda não lembro. O systemd tem uma ferramenta que simplifica as coisas: # localectl set-x11-keymap br Ele criará /etc/X11/xorg.conf.d/00-keyboard.conf com a configuração correta e de quebra editará a linha KEYMAP caso necessário em /etc/vconsole.conf (que vale quando o X não está rodando), fazendo automaticamente a tradução entre os layouts.

Era só acompanhar o time do Arch, os patches que eles contribuem e sua participação no desenvolvimento do systemd para saber que era inevitável. [arch-dev-public] Migration to systemd Que venha logo uma mídia de instalação sem o SysVinit! (e também os haters... mas quem se importa com eles mesmo?) Posts aqui da Mãe Dináh de cuecas na tag systemd do blog.

Já era hora, porque as anteriores estavam defasadas demais e requeriam intervenções manuais na migração para o diretório /run , /lib como atalho para /usr/lib , pacman 4, entre outras. Nesse período, mudanças no empacotamento, como udev → systemd-tools, module-init-tools → kmod, também aconteceram. News: Install media 2012.07.15 released systemd com init padrão ainda não foi dessa vez. Contudo, acredito que a tendência, levando em conta o envolvimento dos desenvolvedores do Arch com o projeto, é que venha a acontecer no futuro.

https://wiki.archlinux.org/index.php/DeveloperWiki:UsrMove http://mailman.archlinux.org/pipermail/arch-dev-public/2012-July/023200.html Junta-se ao Fedora (F17) e ao openSUSE (próxima versão).

Alguns pacotes dos repositórios Core e Extra recém foram atualizados para carregarem por conta os arquivos unit necessários para funcionarem com o systemd nativamente (sem emulação dos scripts SysV). São eles: samba, nfs-utils, rpcbind. Os arquivos unit para esses daemons existentes no repositório mantido por Dave Reisner (empacotados como systemd-arch-units ) foram portanto removidos.

Sou um usuário do Fedora, mas admiro o Arch Linux. Para mim é o Slackware moderno. Do que infiro das listas de discussão de projetos FOSS, é comum o pessoal mais "tradicional", "da linha de comando", torcer o nariz para qualquer coisa que altere a forma como se administra o sistema. Não estou falando em mudanças de interface, mas mudanças estruturais por baixo do capô. Depois do PulseAudio, que é fundamental — a infraestrutura de áudio estaria nas trevas sem ele —, o systemd foi um dos projetos mais difamados pelo "pessoal das antigas". Tendo o Arch um público alvo mais técnico, seria razoável pensar que ambos os projetos ficassem relegados ao repositório Community , a segunda divisão da distribuição, correto? Errado. O PulseAudio hoje faz parte do repositório Extra . Significa que é plenamente suportado. Não faz muito aconteceu o mesmo com o systemd. O time do Arch não tornou-o padrão e empacota-o de forma a ser possível mantê-lo lado a lado com o sys...