Marcos FRM

A imagem não está boa, mas parece que você conectou em CHA_FAN, não em CPU_FAN...

Como o @GuilhermeGB comentou, se considerarmos o YouTube, praticamente tudo é VP9 ou AV1, sendo que o último está tomando lugar rapidamente lá. Mesmo assim, quando AV1 está disponível, o Google mantém streaming fallback de VP9 e H.264. Então você pode usar uma extensão como a enhanced-h264ify para bloquear os codecs indesejados. Veja este tópico: Em hardware velho, recomendo bloquear AV1 e ver como fica com VP9, que não é tão pesado para decodificar na CPU. Em último caso, bloqueie VP9 também, assim terá H.264 (provavelmente o único codec suportado pela sua GPU). Porém esteja ciente que a qualidade dos vídeos em H.264, principalmente envios recentes, está cada vez pior.

O repositório no GitHub foi restaurado e a limpeza está em andamento. Este commit é curioso: https://github.com/tukaani-project/xz/commit/77a294d98a9d2d48f7e4ac273711518bf689f5c4 ("Special author" )

Meio atrasado no tópico. Há boas notícias para o driver proprietário da Nvidia em relação ao Wayland: https://zamundaaa.github.io/wayland/2024/04/05/explicit-sync.html Requererá versões novíssimas dos ambientes, kernel, etc. Lembro de ter olhado por cima, sem entender quase nada, pull requests longuíssimos sobre isso no Mutter, no Xwayland e em outros lugares. Esse trabalho veio majoritariamente de engenheiros da Nvidia e levou anos para ficar pronto. Antes tarde do que nunca. Mesmo você, @KairanD , tendo comprado AMD, fica o link para referência. Talvez o futuro seja mais fácil para GPUs Nvidia no Linux.

De acordo, mas lembrando que Ryzen de primeira geração não é suportado pelo Windows 11. Só o R5 1600AF, que é um Zen+ remarcado. Então teria que ser um Ryzen pelo menos de segunda geração (Zen+)... Investigação que fiz tempos atrás:

Lasse Collin, criador do projeto e seu mantenedor, começou a agir: https://tukaani.org/xz-backdoor/ O processo de reverter as sabotagens do tal Jia Tan também começou: https://git.tukaani.org/?p=xz.git;a=commitdiff;h=f9cf4c05edd14dedfe63833f8ccbe41b55823b00 Ele promete uma investigação nos próximos dias: https://lore.kernel.org/lkml/202403291736.B7E9C61@keescook/T/#mb3010db819413cb42347c92428f8b4cf30e08f6d Cabe destacar que o backdoor foi descoberto por acaso por Andres Freund, um desenvolvedor do PostgreSQL que trabalha para a Microsoft: https://lwn.net/Articles/967194/ Serve de exemplo para deixarmos as bobocas guerras Linux vs Windows de lado...

https://www.openwall.com/lists/oss-security/2024/03/29/4 https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27 https://www.redhat.com/en/blog/urgent-security-alert-fedora-41-and-rawhide-users https://news.opensuse.org/2024/03/29/xz-backdoor/ https://lists.debian.org/debian-security-announce/2024/msg00057.html https://arstechnica.com/security/2024/03/backdoor-found-in-widely-used-linux-utility-breaks-encrypted-ssh-connections/ https://9to5linux.com/red-hat-warns-fedora-linux-40-41-and-rawhide-users-about-critical-security-flaw Grave, mas deu sorte porque foi descoberto antes de chegar a qualquer lançamento estável das distribuições. Senão vá saber qual seria o desastre. O tal código está sendo estudado neste momento, esperemos detalhes mais adiante. Há forte desconfiança que o autor (Jia Tan) das mudanças no repositório oficial que adicionaram o backdoor esteja envolvido: https://boehs.org/node/everything-i-know-about-the-xz-backdoor O que o sujeito fez em outros projetos open source está sendo revisado. Até no kernel; mesmo os patches sendo de Lasse Collin, decidiram não aceitar até a situação ser esclarecida: https://lore.kernel.org/lkml/202403291736.B7E9C61@keescook/T/#m1f559f130e6d463f83ea0960a1ec3da600341576 (igualmente não esteve em nenhum lançamento estável) Que coisa!!!

Há um esforço por parte do GNOME nos últimos anos para polir o ambiente na parte do design. Eu não consigo encontrar nada equivalente à salada da imagem postada pelo @KairanD na minha instalação (versão 45). Pelo menos no que diz respeito aos componentes do ambiente. Recomendo o blog do Allan Day, que é um dos ativos membros do time de design: https://blogs.gnome.org/aday/ E o blog de desenvolvimento do GTK: https://blog.gtk.org/ Algo notável é que a migração de GTK 3 para 4 está sendo bem menos disruptiva do que foi da 2 para 3 quinze anos atrás.

Pesquise no menu iniciar "Informações do sistema". Abra e veja o que consta em "Modo da BIOS" (sic). Se não tiver "UEFI" ali, você terá que reinstalar seu Windows nesse modo para só depois conseguir ativar o Secure Boot. Para criar pendrive de instalação, use apenas a ferramenta oficial da Microsoft (o Media Creation Tool: https://www.microsoft.com/pt-br/software-download) ou o Rufus (https://rufus.ie/, veja esta imagem para baixar o ISO por ele). Então desative o CSM e inicie pelo pendrive. O instalador vai reclamar que o particionamento é MBR (UEFI requer GPT no Windows), daí você faz isto:

Use um formato de compressão com perdas, como JPEG ou WebP; este último comprime mais, ou seja, terá melhor qualidade com o mesmo tamanho de arquivo quando comparado ao JPEG. Se salvar em PNG (que é sem perdas), fica gigante dependendo da complexidade da imagem. Armazenamento tem custo. Anexe arquivos pequenos que o @Gabriel Torres e equipe agradecem.

A atualização KB5034441 vinha falhando faz alguns meses no meu Windows 10 (não vi o problema no 11). Até que resolvi ler sobre a dita cuja: https://support.microsoft.com/pt-br/topic/kb5034441-atualização-do-ambiente-de-recuperação-do-windows-para-windows-10-versão-21h2-e-22h2-9-de-janeiro-de-2024-62c04204-aaa5-4fee-a02a-2fdea17075a8 O problema é que a partição de recuperação criada pelo instalador é pequena (~500 MB na minha instalação). Eles dão os passos para resolver. Consiste em redimensionar a partição principal (C) para abrir espaço, excluir a partição de recuperação, recriá-la com tamanho maior (+250 MB) e ativar novamente o WinRE: https://support.microsoft.com/pt-br/topic/kb5028997-instruções-para-redimensionar-manualmente-sua-partição-para-instalar-a-atualização-do-winre-400faa27-9343-461c-ada9-24c8229763bf Depois disso, instalou.

Deixe ativado (está na guia "Filters"), que ele auto detecta.

Então esses arquivos possuem bitrate de vídeo alto. Chuto uns 4~5 Mbps. Se você codificar em HEVC com metade do bitrate, a qualidade não cairá tanto mantendo a dimensão do vídeo. Tem AV1 como alternativa, que permitirá baixar mais. Isso pressupondo que a qualidade a olho nu do original seja boa... A interface gráfica do HandBrake requer um pouco de prática. Use a predefinição padrão mesmo, aquela "Fast 1080p30", altere o codificador de vídeo para "x265" e ajuste a qualidade por bitrate, usando múltiplas passadas (uma passada fica ruim). Na guia "Audio", remova a trilha e depois adicione de novo, selecionando "AAC Passthru" em "Codec" (adapte se for outro codec, como AC-3, etc). Por padrão o HandBrake aplica apenas o filtro de vídeo Decomb, que é um desentrelaçador seletivo. Não mexe em vídeos não entrelaçados.

Claro, é na minha opinião o melhor conversor de vídeo da praça. Antes, porém, precisamos saber qual a duração média (tempo) e resolução dos seus vídeos, bem como onde você pretende assistir os arquivos convertidos, para ter noção de quais codecs podem ser usados. (se você tiver o VLC aí, abra o arquivo e vá em "Ferramentas -> Informações sobre o Codificador")

Lembrei desta discussão de uma década atrás: https://narkive.com/aCFQ8UQq.46