Marcos FRM

O aplicativo Fotos atualizou aqui no Windows 10 para a versão 2023.11080.4003.0. Agora suporta WebP, basta configurar a associação de arquivo.

AMD Ryzen 5 1600 (AF) https://www.cpu-world.com/CPUs/Zen/AMD-Ryzen 5 1600 (AF).html CPUID 800F82 (Zen+, Pinnacle Ridge). MC Extractor v1.90.2 r274, arquivo B550MAE.18a (BIOS F18a): +-------------------------------------------------------------------+ ¦ AMD ¦ ¦-------------------------------------------------------------------¦ ¦ # ¦ CPUID ¦ Revision ¦ Date ¦ Size ¦ Offset ¦ Last ¦ ¦----+----------+----------+------------+--------+-----------+------¦ ¦ 1 ¦ 00800F82 ¦ 0800820D ¦ 2019-04-16 ¦ 0xC80 ¦ 0x449000 ¦ Yes ¦ ¦----+----------+----------+------------+--------+-----------+------¦ [...] Tem o microcódigo para funcionar... Para os Zen originais (Summit Ridge), CPUID 800F11, também está lá: [...] ¦----+----------+----------+------------+--------+-----------+------¦ ¦ 3 ¦ 00800F11 ¦ 08001138 ¦ 2019-02-04 ¦ 0xC80 ¦ 0x44AA00 ¦ Yes ¦ ¦----+----------+----------+------------+--------+-----------+------¦ [...]

Você mudou o rótulo... findmnt -u /media/usuario/LW

Estava montado? Tem que aparecer, no aplicativo Discos, aquela linha "Montado em ...".

Eu acho que é o codec usado. Tentei enviar um em MPEG-2 (do tempo do DVD...) e aconteceu isso. Já H.264 ele envia normal. Veja nas propriedades do arquivo... Outra coisa. Teste o aplicativo do WhatsApp da Microsoft Store. Talvez seja mais compatível.

Apple até que está colaborando. Suporta WebP (Safari 14+), AVIF (16.4+, quando o suporte ficou completo) e agora JPEG XL (17+). Firefox não suporta JPEG XL nas versões estáveis -- apenas na Nightly e requer uma configuração experimental em about:config. Chrome (e Edge por usar a mesma base) removeu o suporte na versão 110. Portanto, o Safari liderar a adoção é bem-vindo. Supondo que os demais sigam o mesmo caminho adicionando JPEG XL, também será em versões novas. O importante é ter suporte universal de pelo menos um, AVIF ou JPEG XL, nos quatro principais navegadores: Chrome, Edge, Safari, Firefox. Daí finalmente a web começará a sair dos Tempos Antigos no que diz respeito às imagens... AVIF está mais próximo de conseguir: basta o Edge adicioná-lo.

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?