Marcos FRM

Faz sentido. 8K requer mais largura de banda e o AV1 dá uma aliviada. O Edge não tem suporte nenhum ao AV1, nem ao formato de imagem baseado nele, o AVIF. Achei tempos atrás um post no Twitter dizendo que o motivo eram questões judiciais relacionadas às patentes. Mesmo o AV1 sendo livre de royalties, os advogados da Microsoft não teriam liberado a tecnologia ainda. GPUs discretas da AMD suportam decodificação de VP9 apenas a partir da microarquitetura RDNA. A RX 580 é GCN 4ª geração. Foi a empresa que adicionou suporte mais tardiamente das três. Nas APUs, veio um pouco antes com os Raven Ridge (baseados na GCN 5ª geração). Ficarei de olho, cedo ou tarde deve aparecer 1080p ou inferior em AV1 aqui.

Ah, sim, AV1 8K é pesado pacas em software. Acho que o padrão do YouTube em 4K já é AV1 também, não? Em 720p/1080p nunca vi servir AV1 aqui no Chrome. Apenas VP9 e, muito raramente, H.264. Caso AV1 comece a dar as caras em 720p/1080p, terei que recorrer à extensão enhanced-h264ify, deixando VP9 desbloqueado, pois é suportado aqui (VP8 não é, mas acho que foi aposentado): (captura de tela do Firefox; não uso no Chrome) Isso até eu ter uma GPU com suporte ao AV1, o que vai demorar. A designação "Estatísticas para nerds" do YouTube é bem apropriada...

Um conhecido estava caindo nesta baboseira: https://filmora.wondershare.com.br/youtube/av1-settings-on-youtube.html (tradução horrenda de https://filmora.wondershare.com/youtube/av1-settings-on-youtube.html ) Sim, AV1 é mais eficiente. Consegue-se qualidade similar com menos bitrate; ou seja, menos dados trafegados pela rede. No entanto, é um codec mais exigente. Sem decodificação por hardware, vai pressionar a CPU. Claro, uma CPU potente não sentirá, mas estará trabalhando quando não precisaria. VP9, que é o codec preferido pelo YouTube quase sempre, tem decodificação por hardware suportada há vários anos: Nvidia desde a microarquitetura Pascal APUs AMD Ryzen (desde as primeiras, Raven Ridge); GPUs a partir da microarquitetura RDNA Intel desde 7ª geração (Kaby Lake) e em todas GPUs Arc Suporte para decodificação de AV1 é mais recente: Nvidia desde a microarquitetura Ampere AMD a partir da microarquitetura RDNA 2 e APUs equivalentes (Ryzen 7000 e futuros 8000) Intel desde 11ª geração (Tiger/Rocket Lake) e em todas GPUs Arc Sem suporte para decodificação de AV1 por hardware, não existe razão para forçar o uso de AV1 no YouTube. Só gastará processamento da CPU à toa. Aliás, o mesmo vale para VP9. Caso não seja suportado em hardware, é preferível instalar a extensão enhanced-h264ify para fazer o YouTube servir H.264, este sim um codec do tempo da pedra nos dias atuais, que é suportado por qualquer hardware minimamente recente (de uns 10 anos para cá mais ou menos).

Finalmente achei um tempo para testar os SSDs. O Kingston é reconhecido pelo Linux como: ata2: SATA max UDMA/133 abar m2048@0xf7d16000 port 0xf7d16180 irq 27 ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300) ata2.00: ATA-8: KINGSTON SV300S37A120G, 541ABBF0, max UDMA/133 ata2.00: 234441648 sectors, multi 1: LBA48 NCQ (depth 32), AA ata2.00: configured for UDMA/133 Já o Markvision como: ata2: SATA max UDMA/133 abar m2048@0xf7d16000 port 0xf7d16180 irq 27 ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300) ata2.00: ATA-9: KINGSTON SV300S37A120G, P0831A, max UDMA/133 ata2.00: 234441648 sectors, multi 1: LBA48 NCQ (depth 32), AA ata2.00: Features: Dev-Sleep ata2.00: configured for UDMA/133 É um Kingston remarcado. SMART do Kingston: SMART do Markvision: O Kingston foi mais judiado. Firmware do Markvision é piorado, pois o aplicativo Discos do GNOME mostra menos coisa. Desempenho medi com o fio, usando a configuração "Mixed workload" de: http://blog.vmsplice.net/2017/11/common-disk-benchmarking-mistakes.html Escreve diretamente no disco, sem sistema de arquivos envolvido. Antes de rodá-lo, TRIMei o dispositivo inteiro (blkdiscard /dev/sdx). É um teste exigente, com 4 processos martelando o disco numa mistura de leitura e escrita aleatórias com blocos de 4 KiB. Kingston: Run status group 0 (all jobs): READ: bw=38.6MiB/s (40.4MB/s), 38.6MiB/s-38.6MiB/s (40.4MB/s-40.4MB/s), io=4629MiB (4854MB), run=120001-120001msec WRITE: bw=16.5MiB/s (17.3MB/s), 16.5MiB/s-16.5MiB/s (17.3MB/s-17.3MB/s), io=1985MiB (2081MB), run=120001-120001msec Markvision: Run status group 0 (all jobs): READ: bw=9586KiB/s (9816kB/s), 9586KiB/s-9586KiB/s (9816kB/s-9816kB/s), io=1123MiB (1178MB), run=120002-120002msec WRITE: bw=4118KiB/s (4217kB/s), 4118KiB/s-4118KiB/s (4217kB/s-4217kB/s), io=483MiB (506MB), run=120002-120002msec Markvision é consideravelmente inferior (~4x mais lento). É uma versão piorada do modelo original. Talvez nem a mesma controladora use. Conclusão: usarei o Kingston, mesmo estando pior de saúde.

firewalld: https://docs.fedoraproject.org/en-US/quick-docs/firewalld/

Pode ser que o Windows Update ainda não tenha atualizado, caso você tenha ativado TPM e/ou Secure Boot recentemente. Faça manualmente no Agendador de Tarefas ("Executar"). Espere uns minutos e confira novamente...

Lendo as páginas de manual, descobri a integração do systemd-boot com o systemd-logind (CanRebootToBootLoaderMenu(), SetRebootToBootLoaderMenu(), systemd 242+), suportada a partir do GNOME 3.38. A proposta é usar a configuração padrão do systemd-boot de não exibir menu, carregando a entrada padrão automaticamente, para acelerar a inicialização. Daí surge o problema de como acessar o menu quando necessário. Teclas pressionadas são detectadas e exibem-no. Contudo, é uma janela de tempo pequena, nem sempre fácil de acertar. Entra em cena o recurso do GNOME, acessível com Alt na janela de confirmação de reinicialização, que exibe "Opções de inicialização" no lugar de "Reiniciar": Por baixo do capô, systemd-logind cria uma variável UEFI temporária, indicando ao bootloader que, na próxima inicialização, deve exibir o menu. A API permite configurar o tempo de exibição, ajustado em 60 segundos pelo GNOME. Funciona bem. Outros bootloaders podem aproveitar a API -- até com Legacy/CSM se entendi direito o código (modo não suportado pelo systemd-boot). Fedora 39 terá patches implementando-a no GRUB, que talvez algum dia façam parte do GRUB oficial… não é bom ter expectativas muito altas, pois o desenvolvimento do GRUB é lento como uma tartaruga. Consegue-se o mesmo com "systemctl reboot --boot-loader-menu=<timeout>". A funcionalidade na interface gráfica é bem-vinda igual.

Novidades... Safari 17 Beta adicionou suporte ao JPEG XL: https://www.theregister.com/2023/06/07/apple_safari_jpeg_xl/ Esperemos os próximos capítulos.

Ao usar uma conta da Microsoft (ao invés de uma conta local), são usados apenas os primeiros 5 caracteres do nome. Aqui "marcos" fica "marco"... provavelmente é para evitar caminhos muito longos, pois o Windows é problemático com isso, ver:

Suporte para o R5 2400G (Raven Ridge) existe desde AGESA pré-histórico (2017-12-12: microcódigo 08101007h). Numa placa com o B450 é 99% de chance de suportar nativamente. No link postado pelo @1lokos , na guia das especificações, não consta suporte para "2000 G-Series". Isso não quer dizer grande coisa geralmente, igual a ASRock e outras, que "não recomendam" CPUs usando microarquitetura Zen 1 (como o R5 2400G), mas mantêm os microcódigos todos lá. Os únicos microcódigos que vemos serem removidos são dos A-xxx, aquelas APUs horrorosas anteriores aos Zen. Tanto que o BIOS listado com suporte, B1.3G, é a primeira versão.

Acho que é um recurso novo do Chrome, configurável em "Gerenciador de senhas -> Configurações -> Usar o Windows Hello ao preencher senhas".

@Necklace levantou uma boa hipótese. O padrão do kernel é remontar FAT em somente leitura caso ocorram erros críticos (errors=remount-ro), o que suponho possa acontecer com sistemas muito corrompidos. Então uma verificação é algo a tentar. No aplicativo "Discos" do GNOME, na tela da 4ª imagem, clique no ícone da engrenagem. Existirão duas opções: "Verificar sistema de arquivos" e "Corrigir sistema de arquivos". Prefira a primeira, pois primeiro procura por erros, mostrando opção para corrigi-los apenas se detectar algo anormal.

O que mostra na janela de log, acessível clicando no botão do lado esquerdo de "INICIAR"?

Brother não é genérica.

Então jato de tinta Epson, com cartucho mesmo. Impressora barata da HP acho tudo umas .

Jato de tinta é complicado. Acho as menos piores as Epson com tanque -- só que para quem imprime pouco não sei se é bom negócio por conta de entupimento e tal. Se você puder investir mais grana, multifuncional laser (preto e branco, senão fica muito caro) são mais robustas, mesmo os modelos de entrada. Trabalhei bastante usando Brother. A DCP-L2540DW é um modelo que compra e esquece que existe. A mais barata DCP-1617NW deve dar para o gasto, mas teria que pesquisar como anda sua reputação.

Qual erro dá no Rufus?

Sim, o Rufus: https://rufus.ie/ Aparecerá como "Large FAT32".

Estranho. O udisks era para conceder acesso total ao seu usuário. O que findmnt -u /media/usuario/disk retorna no terminal?

Um novo dia e uma nova leva de falhas de segurança nos processadores. AMD: Zenbleed - CVE-2023-20593 (microarquitetura Zen 2) https://lock.cmpxchg8b.com/zenbleed.html https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7008.html Consertada com AGESA ComboAM4v2PI 1.2.0.C. AMD: Inception - CVE-2023-20569 (microarquiteturas Zen 3 e Zen 4) https://comsec.ethz.ch/research/microarch/inception/ https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7005.html Consertada com AGESA ComboAM4v2PI 1.2.0.B e ComboAM5 1.0.8.0. Intel: Downfall - CVE-2022-40982 (afeta uma gama enorme de processadores da marca) https://downfall.page/ https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00828.html https://www.intel.com/content/www/us/en/developer/topic-technology/software-security-guidance/processors-affected-consolidated-product-cpu-model.html Essas falhas às vezes podem ser mitigadas via software pelo sistema operacional, geralmente com impacto no desempenho. Mesmo assim, a forma garantida de estar seguro é aplicar a atualização via BIOS. Colo aqui o texto da AMD (Inception) para encorajar os colegas e esquecerem a história de "em time que está ganhando não se mexe". Com falhas de segurança, seu time está perdendo! AMD recommends customers apply either the standalone µcode patch or a BIOS update that incorporates the µcode patch, as applicable, for products based on “Zen 3” and “Zen 4” CPU architectures. AMD plans to release updated AGESA™ versions to Original Equipment Manufacturers (OEM), Original Design Manufacturers (ODM) and motherboard manufacturers (MB) on the target dates listed below. Please refer to your OEM, ODM, or MB for a BIOS update specific to your product, which will follow after the dates listed below, as applicable.

O AFUDOS oficial da ASUS não deixa. Aqui tem uma versão especial do programa que permite ignorar o ID.

Com 2 GB de RAM é complicado. Windows apenas as versões de 32-bit... e olhe lá. Tente aumentar a quantidade de memória: é tão urgente quanto o SSD. Qual é a placa de vídeo?

Tem o lado macho (com o conector maluco) que conecta no Mac e do outro lado é M.2 fêmea. Esses slots dos Macs são PCIe x4. Qual versão do PCIe? Não sei. Tem que pesquisar cada modelo.

Esclarecendo caso alguém leia este tópico no futuro... Falei "não tem risco de nada" pois ficou claro que você não usava o fTPM antes. Para entender a utilidade do aviso:

Sendo um Celeron baseado numa microarquitetura "de gente grande" da Intel (não derivado do Atom...), é mil vezes mais rápido que o C-50, que é realmente terrível. A microarquitetura Jaguar da AMD (posterior à Bobcat do C-50) já é fraca, imagina o drama... Curiosidade: a CPU de 8 núcleos do PS4 e Xbox One usa núcleos Jaguar. Era o que a AMD tinha de baixo consumo na época, antes dos Zen.